TENSES

TENSES 

Tenses adalah bentuk waktu yang  biasa kita dapatkan di dalam mempelajari bahasa Inggris. Karena dengan tenses kita dapat menggunakan kalimat yang sesuai dengan keadaan. Misalnya, keadaan yang biasa kita lakukan, sedang berlangsung, akan kita lakukan, lampau. Pemakaian kata kerja yang depirgunakan untuk suatu perbuatan yang dilakukan dengan kebiasaan, berbeda dengan pemakaian kata kerja yang dipergunakan dalam kegiatan yang sedang berlangsung, dan kata kerja yang dipergunakan untuk perbuatan lampau, itu juga berbeda. Tenses yang dipergunakan di dalam bahasa Inggris, itu jumlahnya ada 16 waktu, yang lebih terkenal dengan sebutan 16 TENSES 

1. Present Tense

*        * Simple Present Tense 

Simple present tense terutama kita gunakan untuk menyatakan kebiasaan yang masih dilakukan hingga saat kita mengatakannya saat ini. Bila kebiasaan itu sudah tidak kita lakukan lagi, kita tidak menggunakan simple present tense melainkan simple past tense.  Simple present tense juga dapat digunakan untuk menyatakan tindakan /perbuatan atau situasi yang terjadi berulang-ulang, atau setiap saat dan kebenaran umum. Simple present tense sering kali digunakan dengan keterangan waktu atau frasa keterangan waktu, seperti often, usually, sometimes, never, always, on Monday, twice a year, every week. Bila subjek kalimat merupakan orang ketiga tunggal, kita perlu menambahkan (s / es) pada kata kerjanya.

     Rumus :

-                  Pola Kalimat Aktif

(+)  S + V1

(-) S + do/does + not +V1

(Y/N ?)  Do/Does + S + V1?

(Wh ?)  Wh + do/does +V1?

(Wh-S ?)  Wh + V1?

-                 Pola Kalimat pasif

(+)   S + is/am/are/V3 + by…

(-)   S + is/am/are + not + V3 + by…

(Y/N ?)   Is/am/are + S + V3 + by…?

(Wh ? )   Wh + is/am/are + S + V3 + by…?

(Wh-s ? )   Wh + is/am/are + A/N/A + by…?

·                    *Present Continuous Tense

Present continuous tense kita gunakan untuk menyatakan suatu kegiatan yang sedang atau masih kita lakukan/berlangsung pada saat kita mengatakannya saat ini.

Rumus:

-                     Pola Kalimat Aktif

(+)   S + is/am/are + V (ing)

(-)   S + is/am/are + not + V (ing)

( Y/N ?)   Is/am/are + S + V (ing)?

(Wh ?)   Wh + is/am/are + S + V (ing)?

(Wh-S)   Wh + is/am/are + V (ing)?

-                     Pola Kalimat pasif

(+)   S + is/am/are + being + V3 + by…

(-)   S + is/am/are + not + being + V3 + by…

(Y/N ?)   Is/am/are + S + being + V3 + by…?

(Wh ? )   Wh + is/am/are + S + being + V3 + by…?

(Wh-s ? )   Wh + is/am/are + being + V3 + by…?

·                    *Present Perfect Tense

Present perfect  tense juga dipakai untuk menyatakan pengulangan suatu kegiatan yang dilakukan sebelum saat mengatakannya / saat ini. Present perfect tense juga digunakan dengan keterangan waktu ‘ tidak tentu’ yang mengandung arti ‘kapan pun sampai saat ini’ atau menjelang saat ini . misalnya ever, never, yet, already, dan before.

Rumus:

-                    Pola Kalimat Aktif

(+)   S + has/have + V3

(-)   S + has/have + not + V3

( Y/N ?)   Has/Have + S + V3?

(Wh ?)   Wh + has/have+ S + V3?

(Wh-S)   Wh + has/have+ V3?

-                      Pola Kalimat pasif

(+)   S + has/have + been + V3+ by…

(-)   S + has/have + not + been + V3 + by…

(Y/N ?)   has/have + been + V3 + by…?

(Wh ? )   Wh + has/have + been + V3 + by …?

(Wh-s ? )   Wh + has/have + been + V3 + by …?

·                    * Present Perfect Continuous Tense

Present perfect continuous  tense juga digunakan untuk menyatakan lamanya (durasi), sudah atau belumnya suatu kegiatan atau situasi yang dimulai di waktu lampau dan masih berlanjut hingga saat mengatakannya / saat ini. Setelah mengatakannya, kegiatan atau situasi tersebut akan masih dilakukan / terjadi.  Present perfect continuous  tense juga digunakan keterangan waktu seperti for, since, all morning, all day, all week.

Rumus:

-                     Pola Kalimat Aktif

(+)   S + has/have + been + V(ing)

(-)   S + has/have + not + been + V(ing)

( Y/N ?)   Has/Have + S + been + V(ing)?

(Wh ?)   Wh + has/have + S + been + V(ing)?

(Wh-S)   Wh + has/have+ been + V(ing)? 

 2.  Past Tense

·                   *Simple Past Tense

Simplepast tense digunakan untuk menyatakan suatu kegiatan atau situasi yang dimulai dan berakhir pada waktu tertentu di waktu lampau. Pada saat mengatakannya/ saat ini, kegiatan atau situasi tersebut sudah selesai dilakukan/terjadi.  Simple past tense biasanya digunakan dengan keterangan waktu, seperti : yesterday , last…. (last week, last month, dsb), in… (in 1997), atau … ago) (two hours ago, for days ago, dsb).

Rumus:

-                      Pola Kalimat Aktif

(+)   S + V2

(-)   S + did not + V1

( Y/N ?)   Did + S + V1?

(Wh ?)   Wh + did + V1?

(Wh-S)   Wh + V2?

-                        Pola Kalimat pasif

(+)   S + was/were + V3+ by…

(-)   S + was/were + not + V3 + by…

(Y/N ?)   Was/were + S + V3 + by…?

(Wh ? )   Wh + was/were + S + V3 + by …?

(Wh-s ? )   Wh + was/were + V3 + by …?

·       

*                     *  Past Continuous Tense

Past continuous tense biasanya dipakai untuk mengatakan kegiatan yang dimulai lebih dulu dan masih (sedang)berlangsung ketika ada kegiatan / kejadian lain yang menyusul kemudian. Pada saat mengatakannya, kedua kegiatan tersebut sudah selesai dilakukan / terjadi.

Rumus:

-                     Pola Kalimat Aktif

(+)   S + was/were + V(ing)

(-)   S + was/were + not + V(ing)

( Y/N ?)   Was/were + S + V(ing)?

(Wh ?)   Wh + Was/were + S + V(ing)?

(Wh-S)   Wh + was/were + V(ing)?

-                      Pola Kalimat pasif

(+)   S + was/were + being + V3 + by…

(-)   S + was/were + not + being + V3 + by…

( Y/N ?)   Was/were + S + being + V3 + by…?

(Wh ?)   Wh + Was/were + S + being + V3 + by…?

(Wh-S)   Wh + was/were + being + V3 + by…?

·        

                        * Past Pefect Tense

Past perfect tense dipakai untuk menyatakan kegiatan atau situasi yang sudah selesai dilakukan / terjadi sebelum berlangsunnnya kegiatan lain diwaktu lampau. Pada saat mengatakannya kegiatan tersebut sudah selesai dilakukan/terjadi.

Rumus:

-                    Pola Kalimat Aktif

(+) S + Had + V3

(-) S + Had + V3

(Y/N?) Had + S + V3

(Why?) Wh + Had + S + V3

(Wh-S?) Wh + Had + V3

-                     Pola Kalimat pasif

(+) S + Had + Been + A/N/A

(-) S + Had + Not + Been + A/N/A

(Y/N?) Had + S + Been + A/N/A

(Wh?) Wh + Had + S + Been + A/N/A

(Wh-S?) Wh + Had + Been + A/N/A 

·                   *Past Perfect Continuous Tense

Past perfect continuous tense dipakai untuk menekankan durasi (lamanya waktu), sudah atau belumnya kegiatan yang sedang berlangsung sebelum kegiatan lain diwaktu lampau. Pada saat mengatakannya kegiatan tersebut sudah tidak dilakukan lagi.

Rumus:

-                     Pola Kalimat Aktif

(+) S + Had + Been + V(ing)

(-) S + Had + Not + Been + V(ing)

(Y/N?) Had + S + Been + V(ing) ?

(Wh?) Wh + Had + S + Been + V(ing)?

(Wh-S?) Wh + Had + Been + V(ing)? 

 3. Future Tense 

·                      * Simpel Future Tense

Simple future tense digunakan untuk mengatakan kegiatan/kejadian yang akan dilakukan/terjadi dimasa yang akan datang. Pada saat mengatakannya, kegiatan/kejadian tersebut belum dilakukan/terjadi. Untuk itu kita dapat menggunakan kata bantu “will” atau “be going to”

Rumus:

-                      Pola Kalimat Aktif

(+) S + will + V1

(+) S + be + going to + V1

(-) S + will + not + V1

(-) S + be + not + going to + V1

(Y/N?) Will + S + V1?

(Y/N?)  Be + S + going to + V1

(Wh?) Wh + will + S + V1

(Wh?)  Wh + be + S + going to + V1

(Wh-S?) Wh + will + V1

(Wh-S?)  Wh + be + going to + V1

-                       Pola Kalimat Pasif

(+) S + will + be + V3 + by…

(+) S + be + going to + be + V3 + by…

(-) S + will + not + be + V3 + by…

(-) S + be+ not + going to + be + V3 + by…

(Y/N?) Will + S + be + V3 + by…?

(Y/N?)  Be + S + going to + be + V3 + by…?

(Wh?) Wh + will + S + be + V3 + by…?

(Wh?)  Wh + be + S + going to + be + V3 + by…?

(Wh-S?) Wh + will + be + V3 + by…?

(Wh-S?)  Wh + be + going to + be + V3 + by…?

·                     * Future Continuous Tense

Future continuous tense dipakai untuk menyatakan kegiatan yang akan sedang berlangsung pada suatu waktu tertentu dimasa yang akan datang. Pada saat mengatakannya, kegiatan tersebut belum dilakukan.

Rumus:

-                     Pola Kalimat Aktif

(+) S + will + be + V(ing)

(-) S + will + not + be + V(ing)

(Y/N?) will + S + be + V(ing)?

(Why?) Wh + will + S + be + V(ing)?

(Wh-S?) Wh + will + be + V(ing)?

·                    *Future Perfect Tense

Future perfect tense dipakai untuk menyatakan suatu kegiatan/kejadian yang akan sudah atau belum selesai dilakukan/terjadi sebelum suatu saat tertentu diwaktu yang akan datang. Pada saat mengatakannya, kegiatan tersebut belum dilakukan.

Rumus:

-                      Pola Kalimat Aktif

(+) S + will + have + V3

(+) S + be + going to + have + V3

(-) S + will + not + have + V3

(-) S + be+ not + going to + have + V3

(Y/N?) Will + S + have + V3?

(Y/N?)  Be + S + going to + have+ V3 ?

(Wh?) Wh + will + S + have + V3 ?

(Wh?)  Wh + be + S + going to + have + V3 ?

(Wh-S?) Wh + will + have + V3 ?

(Wh-S?)  Wh + be + going to + have+ V3 ?

·                   *Future Perfect Continuous Tense

Future perfect continuous tense dipakai untuk menekankan durasi, sudah atau belumnya suatu kegiatan yang akan sudah (sedang) berlangsung sebelum kejadian lain diwaktu yang akan datang. Pada saat mengatakannya, kegiatan tersebut belum dilakukan. 

Rumus:

-                       Pola Kalimat Aktif

(+) S + will + have + been + V(ing)

(-) S + will + not + have + been + V(ing)

(Y/N?) will + S + have + been + V(ing)?

(Why?) Wh + will + S + have + been + V(ing)?

(Wh-S?) Wh + will + have + been + V(ing)? 

    4. Past Future Tense 

·                     *Simple Past Future Tense

Waktu kita berbicara tentang suatu kegiatan dimasa lampau, kita pun kadang-kadang ingin mengatakan tentang suatu kegiatan/kejadian yang akan kita lakukan / terjadi sesudahnya. Kegiatan / kejadian itu juga dilakukan / terjadi dimasa lampau dan pada saat mengatakannya kegiatan/kejadian tersebut sudah tidak dilakukan / terjadi lagi. Untuk situasi seperti itu kita memakai past future tense. Pola kalimat simple past future juga dipakai kalau kita ingin mengatakan suatu pengandaian yang sudah pasti tidak terjadi dimasa lampau.

Rumus:

-                      Pola Kalimat Aktif

(+) S + would + V1

(-) S + would + not + V1

(Y/N?) Would + S + V1?

(Why?) Wh + Would + S + V1?

(Wh-S?) Wh + would + V1?

·                     *Past Future Continuous Tense

Pola kalimat ketika kita berbicara tentang suatu kegiatan di masa lampau, kita pun kadang-kadang ingin mengatakan tentang suatu kegiatan yang akan sedang kita lakukan sesudahnya. Kegiatan itu juga akan sedang dilakukan dimasa lampau dan pada saat mengatakannya kegiatan tersebut sudah tidak dilakukan lagi. Untuk situasi seperti itu kita memakai past future continuous tense. Pola kalimat past future continuous tense juga dipakai kalau kita ingin mengatakan suatu pengandaian yang sudah pasti tidak terjadi di masa lampau

Rumus:

-                        Pola Kalimat Aktif

(+) S + would + be + V(ing)

(-) S + would + not + be + V(ing)

(Y/N?) Would + S + be + V(ing)?

(Why?) Wh + Would + S + be + V(ing)?

(Wh-S?) Wh + would + be + V(ing)?

·                       *Past Future Perfect Tense

Ketika kita berbicara tentang suatu kegiatan di masa lampau kita pun kadang-kadang ingin mengatakan tentang suatu kegiatan / kejadian yang akan sudah atau belum selesai kita lakukan / terjadi sesudahnya. Kegiatan/kejadian itu juga dilakukan / terjadi di masa lampau dan pada saat mengatakannya kegiatan / kejadian itu sudah tidak dilakukan/terjadi lagi. Untuk situasi seperti itu kita memakai past future perfect tense. Pola kalimat past future perfect tense juga dipakai kalau kita ingin memangatakan suatu pengandaian  yang sudah pasti tidak terjadi di masa lampau

Rumus:

-                      Pola Kalimat Aktif

(+) S + would + have + V3

(-) S + would + not + have + V3

(Y/N?) Would + S + have + V3?

(Why?) Wh + Would + S + have + V3?

(Wh-S?) Wh + would + have + V3?

·                      *Past Future Perfect Continuous Tense

Ketika kita berbicara tentang suatu kegiatan di masa lampau kita pun kadang-kadang mengatakan tentang suatu kegiatan/kejadian yang akan sudah dan sedang / masih kita lakukan / terjadi di masa lampau dan pada saat mengatakannya kegiatan/kejadian itu sudah tidak dilakukan / terjadi lagi. Untuk situasi seperti itu kita memakai past future perfect continuous tense . pola kalimat past future perfect continuous tense juga dipakai kalau kita ingin mengatakan suatu pengandaian yang sudah pasti tidak terjadi di masa lampau

Rumus:

-                    Pola Kalimat Aktif

(+) S + would + have + been + V(ing)

(-) S + would + not + have + been + V(ing)

(Y/N?) Would + S + have + been + V(ing)?

(Why?) Wh + Would + S + have + been + V(ing)?

       (Wh-S?) Wh + would + have + been + V(ing)?









Sumber referensi :

S-wardhana, Dony dkk. Cara Cerdas Menguasai Tenses, Jakarta: Penerbit Kawan Pustaka, 2008.
http://student.eepis-its.edu/~praszz/Tenses.html 

BAB 10.4 Extrapolating data to cover network lags "Ekstrapolasi data untuk menutupi kelambanan jaringan"

Figure 10.4. Extrapolating data to cover network lags. 

As a result, we can trust this polynomial to accurately represent the future behavior of the position (assuming we don't get too far from T2 in time).

So, every time a new position update arrives, we must discard the oldest update and rebuild the interpolation polynomials. Thus, we will use the interpolator to evaluate the position of the networked player until we receive a new update, and so on. If lag grows, we might perceive a "jump" in position when a new sampling point arrives (because we are moving from a very distant predicted position to a very close one). However, in real-world, moderate-lag scenarios, the preceding technique should help to significantly smooth out a player's trajectories.

Hierarchical Messaging

Imagine a game where lots of network packets are continually being sent between players. Not all players have the same level of connection. Some players are playing on high-speed DSL or cable, whereas others are still using an analog modem. As traffic intensity increases, the modem user will begin feeling an information overload, and his playing experience will degrade. Hierarchical messaging is a technique

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (2 of 6)2/9/2009 5:57:34 PM

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

designed to ensure that everyone gets the best information on a heterogeneous configuration.

 At the core of the method lies the notion that messages have different importance levels. For example, an enemy position update is more relevant than the configuration of his arms with regard to the animation system. Messages should be classified and assigned relevance levels. Then, as a new player enters the game, a network test should provide us with information on the user's expected bandwidth-how much data he can exchange per second. Then, we will decide which messages are sent to him depending on that bandwidth to ensure he gets the most important messages, but maybe loses some secondary information.

Take, for example, a first-person shooter. Messages could be (in descending order of relevance):

Position updates

*Shooting

*Weapon changes

*Mesh configuration/animation

Each "level" of transmission must be quantified in bytes per second, and then the right set of messages will be determined. Thus, in a first-person-shooter, maybe one player is just seeing positions and ignoring the rest of the information. But because he has the most relevant information, the game is still playable on a low-end machine.

 

Spatial Subdivision

Spatial subdivision is designed specifically for massively multiplayer games. It uses spatial indexing to ensure that only relevant packets are transmitted and, by doing so, it can decrease the overall traffic by orders of magnitude.

Imagine a squad-based game, where a player can join teams of up to four players in a quest-something like Diablo, for example. Obviously, we will need to send the position updates quite frequently, because the game is pretty high-paced. This is not much of a problem, because we are only dealing with four players.

However, try to imagine what goes on inside a game such as Everquest-thousands of players roaming a huge game world, many of them located at days of distance (in gameplay terms) from other gamers. Under these circumstances, does it really make sense to update everyone about our current state? We might be consuming the bandwidth of a gamer at the other end of the game world with useless information.

Now, imagine that players are stored in a spatial index data structure, usually held on the game servers managed by the publisher. Every time we want to broadcast new data regarding a player, we start by querying the spatial index about which players are located within a certain distance from the first one.

Then, we only send the data to those players, saving lots of bandwidth. Let's stop and review an example. Think of an Everquest type of game with 100,000 players in a game world that is 100x100 kilometers cross. The first alternative is to use standard broadcasts, where each packet is sent to everyone. Using very simple math, you will see that this requires sending 100,0002 packets of information if we want to update

all players. Now, imagine that we divide the game world into a grid 100x100 meters. Each grid section contains the players specific to that grid. Assuming that their distribution is homogeneous, we would have 10 players per grid cell. Now, let's assume we only send the update to those players located in the current cell or in

any of the nine neighboring cells. That means an update must be sent to 100 players (10 cells, 10 players per cell). Thus, the grand total of packets required to update everyone is just 10,000,000, which is 1,000

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (3 of 6)2/9/2009 5:57:34 PM

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

times less than if we did not use spatial subdivision. The only hidden cost is the data structure, but we can definitely afford that for a game server, which usually comes with lots of RAM.

Send State Changes Only

If you are willing to accept some restrictions, you can greatly reduce your game's bandwidth by sending only state change information, not the actual in-game data stream. To understand how this method works and which restrictions we need to apply, think of a game like Diablo or Dungeon Siege, where two peers connected in a network are playing in cooperative multiplayer fashion. They explore the game world and solve quests. There are lots of monsters (each with its own logic routines) onscreen and lots of items to choose.

In a game like this, you can choose between two networked approaches. Using one approach, you can run the game logic engine on only one of the two machines and propagate results to the other machine, which would receive all game logic information through the network and use it to drive the presentation layer. The

second PC would thus only have the graphics engine and not much else, becoming a "game terminal." But the problem is ensuring that the network will be able to pump the data at the right speed, so the other player sees exactly the same game world, and the experience is seamless. This can be achieved on a local area network (LAN), but the Internet is a whole different business. Thus, we need an alternative. Basically, we keep two world simulators working in sync on both PCs. Both simulators must be 100 percent deterministic for this to work, meaning they must not depend on any

outside events or random numbers. Only by ensuring this can we stop sending all game world update messages (monster positions, and so on) and focus on transmitting just player positions. This is a very popular approach, which requires checking for world syncing every now and then to make sure both game worlds don't diverge and end up being two completely different representations of the same level.

If you are following such an approach, we can move one step further, changing the explicit information in our messages by using state change messages. Currently, you are sending a player position update for

every logic tick, which is a waste of bandwidth. If the player is on a deterministic system (obviously, with the chaos inherent to gamer interaction), we can send only state changes and save much of this bandwidth. Instead of saying "the player is here" all the time, you only need to send "the player pressed the advance key" when a state change condition takes place. Do not forget that our player is, at the core, a

finite-state machine. The player will continue performing the same action (such as walking or fighting) for many clock cycles. Sending only the state change lets you forget about all this continuous messaging, making your bandwidth requirements drop sharply. Just remember the restrictions imposed by this method: Both game worlds must be kept in sync. This will

force some changes in your code, like the random number processing, for example. You can still have random numbers as long as both PCs have the same ones. Generating the same sequence in both PCs might seem like a crazy idea, but it's one of the essential tasks to ensure proper synchronization. To keep both random number generators in sync, all you have to do is have a random number table precomputed in

memory (the same one for both machines, obviously) and use it instead of actually computing numbers. This change will have the desirable side effect of a significant performance gain, because random number generators are traditionally very slow, and tabulating them is a classic optimization trick as well.

Working with Server Clusters

No serious MMG can be managed with a single server. As player count increases, we reach a point when we need to move to a cluster, so more users can be accommodated. This opens the door to a whole new area of programming, which deals with how to lay out the players on the servers, how to communicate with

them efficiently, and so on. This is a relatively new science, but some interesting methods have already

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (4 of 6)2/9/2009 5:57:34 PM

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

arisen. I will now comment on those, explaining the methods behind some popular solutions. To begin with, multiple servers are used to reduce the number of players that each server must handle. This might seem obvious, but most problems come from not understanding this key fact. We need each server to handle less players. So, we need:

* Less players connected directly to the server

*Tests for one player inside one server to be resolved in the same server

The second item in the list is the key fact. Imagine that we have 100 users, and we split them randomly into two groups of 50. Because we split them randomly, chances are that checking the collision of a player will require us to look at other players on his server, and on the other server as well, totally killing performance. We will still need to check with all the players in the game world. The solution, obviously, is to map our spatial subdivision engine to the server level. Each server will handle players located in a continuous part of the game world, thus ensuring that most tests can be solved locally.

For example, we can divide the game world in half. Then, when we need to send a player update to the rest of the players, we test which other players are close to the original player. This is performed by the game server, hopefully on a local basis. All players needing the update will lie on the same machine as the original player. Once we have the list of those players that actually need to know that the original player

has moved, we send the message to them only. Notice how we have improved performance in two ways. At the server level, only half of the gamers were tested. The rest of them lie on another server and did not even notice the player in the example moved. We optimized network bandwidth as well, sending the update only to those players within a certain range of the player. Now, let's generalize this to N servers in a large game world. We can divide the scenario in a gridlike fashion and assign grid quadrants to individual servers, so all players within that region are handled

internally, and CPU and bandwidth are kept to a minimum. If the developer wants to add new regions to the game world, all we need to do is add extra servers to the cluster. Obviously, this approach will mostly have server-user traffic, but server-server communications will be important as well. How do we notify a server that a player has crossed the grid boundaries and must thus be relocated to the neighboring grid

cell? To help visualize this, think in terms of vertical (server-user) and horizontal (server-server) messages. Vertical messages will be most frequent, whereas horizontal messages will carry control information and be less frequent.

Dynamic Servers and the Braveheart Syndrome

Sometimes the clustered approach explained in the preceding section will fail to do its work. Basically, we have divided the game world spatially, assuming that means a homogeneous player division as well. Each cell region has approximately the same number of players. But what happens if a large number of gamers are, at a point in time, located in the same grid cell? Imagine a "hotspot" region to which many players

converge for some game-related reason. Obviously, that server will sustain more workload than the rest. Imagine the "launchpad" area, where most gamers in a MMG appear when they first enter a game. It's an overpopulated area, which will make our servers stall. The first option would be to study these cases carefully and further divide the game world, much like in a quadtree, around these regions. But this implies that these hotspot regions are fixed, which doesn't really have to be the case. Imagine that one day there's an extra quest proposed by the game developers, and that quest increases traffic in a certain portion of the game world. How can we ensure that the gaming experience will not degrade that day? And how can we get things back to normal after the activity is over, and the traffic level is reduced? This is often referred to as the Braveheart syndrome: how to prevent a situation in which lots of gamers move to a small portion of the map and then leave it, much like in a battle

 

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (5 of 6)2/9/2009 5:57:34 PM

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

TRANSLETE :

Gambar 10.4. Ekstrapolasi data untuk menutupi kelambanan jaringan.

Akibatnya, kita dapat percaya polinomial ini untuk secara akurat mewakili perilaku masa depan posisi
(Dengan asumsi kita tidak terlalu jauh dari T2 dalam waktu). Jadi, setiap kali update posisi baru tiba, kita harus membuang update tertua dan membangun kembali interpolasi polinomial. Dengan demikian, kita akan menggunakan interpolator untuk mengevaluasi posisi jaringan pemain sampai kita menerima update baru, dan sebagainya. Jika lag tumbuh, kita mungkin melihat sebuah "lompatan" dalam posisi ketika titik pengambilan sampel baru tiba (karena kita bergerak dari posisi diprediksi sangat jauh dengan yang sangat dekat satu). Namun, dalam dunia nyata, sedang-lag skenario, teknik sebelumnya harus membantu secara signifikan kelancaran keluar lintasan pemain.

Hirarkis Pesan
Bayangkan sebuah permainan di mana banyak paket jaringan yang terus-menerus dikirim antara pemain. Tidak semua pemain memiliki tingkat yang sama dari koneksi. Beberapa pemain yang bermain di kecepatan tinggi DSL atau kabel, sedangkan yang lain masih menggunakan modem analog. Seiring dengan peningkatan intensitas lalu lintas, pengguna modem akan mulai merasakan suatu informasi yang berlebihan, dan pengalamannya bermain akan menurunkan. Hirarkis pesan adalah teknik

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (2 dari 6) 2009/02/09 17:57:34
http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

dirancang untuk memastikan bahwa setiap orang mendapatkan informasi terbaik pada konfigurasi heterogen.
Pada inti dari metode ini adalah pandangan bahwa pesan memiliki tingkat kepentingan yang berbeda. Sebagai contoh, sebuah musuh pembaruan posisi lebih relevan daripada konfigurasi lengan berkaitan dengan animasi sistem. Pesan harus diklasifikasikan dan ditugaskan tingkat relevansi. Kemudian, sebagai pemain baru memasuki permainan, tes jaringan harus memberikan kami informasi tentang diharapkan pengguna bandwidth berapa banyak data ia dapat bertukar per detik. Kemudian, kami akan memutuskan mana pesan akan dikirim kepadanya tergantung pada bandwidth untuk memastikan ia mendapatkan pesan yang paling penting, tapi mungkin kehilangan beberapa informasi sekunder. Ambil, misalnya, pertama-orang jujur. Pesan bisa (dalam urutan relevansi):
*Posisi update
* Menembak
*Senjata perubahan
*Mesh konfigurasi / animasi

Setiap "tingkat" dari transmisi harus diukur dalam byte per detik, dan kemudian hak mengatur pesan akan
ditentukan. Jadi, dalam penembak orang pertama, mungkin satu pemain hanya melihat posisi dan mengabaikan
sisa informasi. Tapi karena ia memiliki informasi yang paling relevan, permainan ini masih dimainkan pada
low-end mesin.

Subbagian Tata Ruang
Subdivisi spasial dirancang khusus untuk game massively multiplayer. Menggunakan indeks spasial untuk
memastikan bahwa paket yang relevan hanya ditransmisikan dan, dengan demikian, dapat mengurangi lalu lintas secara keseluruhan dengan lipat. Bayangkan sebuah permainan skuad berbasis, dimana pemain dapat bergabung dengan tim hingga empat pemain dalam pencarian sesuatu- seperti Diablo, misalnya. Jelas, kita perlu mengirim update posisi cukup sering, karena permainan yang cukup tinggi yang serba. Hal ini tidak banyak masalah, karena kita hanya berurusan dengan empat pemain. Namun, cobalah untuk membayangkan apa yang terjadi di dalam permainan seperti EverQuest-ribuan pemain jelajah sebuah dunia permainan besar, banyak dari mereka yang terletak di hari jarak (dalam hal gameplay) dari gamer lainnya. Bawah keadaan ini, apakah itu masuk akal untuk memperbarui semua orang tentang negara kita saat ini? Kita mungkin mengkonsumsi bandwidth gamer di ujung lain dari dunia permainan dengan informasi berguna. Sekarang, bayangkan bahwa pemain disimpan dalam struktur data indeks spasial, biasanya diadakan pada server game
dikelola oleh penerbit. Setiap kali kita ingin menyiarkan data baru tentang pemain, kita mulai dengan
query indeks spasial tentang mana pemain berada dalam jarak tertentu dari yang pertama. Kemudian, kita hanya mengirim data ke para pemain, menghemat banyak bandwidth. Mari kita berhenti dan meninjau contoh. Pikirkan tipe Everquest permainan dengan 100.000 pemain dalam dunia permainan yang 100x100 kilometer di seluruh. Alternatif pertama adalah dengan menggunakan siaran standar, di mana setiap paket dikirim ke semua orang. Menggunakan sangat matematika sederhana, Anda akan melihat bahwa ini membutuhkan mengirim 100,0002 paket informasi jika kita ingin memperbarui semua pemain. Sekarang, bayangkan bahwa kita membagi dunia permainan menjadi 100x100 meter grid. Setiap bagian kotak berisi
khusus untuk grid yang pemain. Dengan asumsi bahwa distribusi mereka adalah homogen, kita akan memiliki 10 pemain per sel grid. Sekarang, mari kita asumsikan kita hanya mengirim update ke para pemain berada dalam sel saat ini atau di salah satu dari sembilan sel tetangga. Itu berarti pembaruan harus dikirim ke 100 pemain (10 sel, 10 pemain per sel). Dengan demikian, grand total paket yang dibutuhkan untuk memperbarui semua orang hanya 10.000.000, yang adalah 1.000

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (3 dari 6) 2009/02/09 17:57:34
http://www.tar.hu/gamealgorithms/ch10lev1sec9.html

kurang dari jika kita tidak menggunakan subdivisi spasial kali. Satu-satunya biaya tersembunyi adalah struktur data, tetapi kita bisa pasti mampu yang untuk server permainan, yang biasanya datang dengan banyak RAM.

Hanya Kirim Perubahan Negara
Jika Anda bersedia untuk menerima beberapa pembatasan, Anda dapat sangat mengurangi bandwidth permainan Anda dengan mengirimkan hanya negara perubahan informasi, bukan yang sebenarnya dalam game aliran data. Untuk memahami bagaimana metode ini bekerja dan yang pembatasan kita perlu menerapkan, memikirkan permainan seperti Diablo atau Dungeon Siege, di mana dua rekan terhubung dalam jaringan bermain dalam mode multiplayer kooperatif. Mereka menjelajahi dunia permainan dan memecahkan quests. Ada banyak monster (masing-masing dengan rutinitas sendiri logika) pada layar dan banyak item untuk pilih. Dalam sebuah permainan seperti ini, Anda dapat memilih antara dua pendekatan jaringan. Menggunakan satu pendekatan, Anda dapat menjalankan logika permainan mesin hanya pada satu dari dua mesin dan menyebarkan hasil ke mesin lain, yang akan menerima semua informasi logika game melalui jaringan dan menggunakannya untuk mendorong lapisan presentasi. Itu PC kedua demikian akan hanya memiliki mesin grafis dan tidak banyak lagi, menjadi "terminal game." Tapi masalahnya adalah memastikan bahwa jaringan akan mampu memompa data pada kecepatan yang tepat, sehingga yang lain pemain melihat persis dunia permainan yang sama, dan pengalaman yang mulus. Hal ini dapat dicapai pada lokal area jaringan (LAN), tetapi Internet adalah bisnis yang berbeda. Jadi, kita perlu alternatif. Pada dasarnya, kami terus simulator dua dunia bekerja di sync di kedua PC. Kedua simulator harus 100 persen deterministik untuk bekerja, yang berarti mereka tidak harus bergantung pada setiap luar peristiwa atau angka acak. Hanya dengan memastikan ini kita bisa menghentikan pengiriman semua pembaruan permainan dunia
pesan (posisi rakasa, dan sebagainya) dan fokus pada transmisi hanya posisi pemain. Ini adalah sangat
pendekatan populer, yang membutuhkan memeriksa dunia sinkronisasi setiap sekarang dan kemudian untuk memastikan kedua permainan dunia dengan tidak menyimpang dan berakhir menjadi dua representasi yang sama sekali berbeda dari tingkat yang sama. Jika Anda mengikuti pendekatan semacam itu, kita bisa bergerak satu langkah lebih jauh, mengubah informasi eksplisit dalam kami pesan dengan menggunakan pesan negara perubahan. Saat ini, Anda mengirim update pemain untuk posisi setiap tick logika, yang merupakan pemborosan bandwidth. Jika pemain berada pada sistem deterministik (jelas, dengan kekacauan yang melekat pada interaksi gamer), kita dapat mengirim hanya perubahan negara dan menyimpan banyak dari ini bandwidth. Daripada mengatakan "pemain ada di sini" sepanjang waktu, Anda hanya perlu mengirim "pemain ditekan kunci muka "ketika kondisi perubahan keadaan berlangsung Jangan. lupa bahwa pemain kita adalah, pada intinya, sebuah terbatas-mesin negara. Pemain akan terus melakukan tindakan yang sama (seperti berjalan atau berjuang) untuk banyak jam siklus. Mengirim hanya perubahan keadaan memungkinkan Anda lupa tentang semua ini pesan terus menerus, membuat kebutuhan bandwidth Anda drop tajam. Hanya ingat pembatasan yang diberlakukan dengan metode ini: Kedua dunia permainan harus disimpan di sync. Ini akan memaksa beberapa perubahan dalam kode Anda, seperti proses nomor acak, misalnya. Anda masih dapat memiliki angka acak sepanjang kedua PC memiliki yang sama. Menghasilkan urutan yang sama di kedua PC mungkin tampak seperti ide gila, tapi itu salah satu tugas penting untuk menjamin sinkronisasi yang tepat. Untuk menjaga kedua nomor acak generator sinkron, yang harus Anda lakukan adalah memiliki tabel nomor acak precomputed di memori (yang sama untuk kedua mesin, jelas) dan menggunakannya bukan angka sebenarnya komputasi. Perubahan ini akan memiliki efek samping yang diinginkan dari keuntungan kinerja yang signifikan, karena nomor acak generator secara tradisional sangat lambat, dan tabulasi mereka adalah trik optimasi klasik juga.

Bekerja dengan Cluster Server
Tidak ada MMG serius dapat dikelola dengan server tunggal. Seiring dengan peningkatan jumlah pemain, kita mencapai suatu titik ketika kita perlu untuk pindah ke cluster, sehingga lebih banyak pengguna dapat diakomodasi. Ini membuka pintu untuk area baru pemrograman, yang berkaitan dengan bagaimana lay out pemain di server, bagaimana berkomunikasi dengan secara efisien, dan sebagainya. Ini adalah ilmu yang relatif baru, tetapi beberapa metode menarik sudah

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (4 dari 6) 2009/02/09 17:57:34
http://www.tar.hu/gamealgorithms/ch10lev1sec9.html
muncul. Sekarang saya akan mengomentari mereka, menjelaskan metode balik beberapa solusi populer.

Untuk mulai dengan, beberapa server digunakan untuk mengurangi jumlah pemain bahwa setiap server harus menangani. Hal ini mungkin tampak jelas, tetapi masalah yang paling berasal dari tidak memahami fakta kunci. Kami saling membutuhkan
server untuk menangani pemain kurang. Jadi, kita perlu:
* Kurang pemain terhubung langsung ke server
* Pengujian untuk satu pemain dalam satu server yang harus diselesaikan di server yang sama

Item kedua dalam daftar adalah fakta kunci. Bayangkan bahwa kita memiliki 100 pengguna, dan kami membaginya secara acak menjadi dua kelompok dari 50. Karena kita membaginya secara acak, kemungkinan bahwa memeriksa tabrakan pemain akan membutuhkan kita untuk melihat pemain lain di server, dan pada server lain juga, benar-benar membunuh kinerja. Kami masih perlu memeriksa dengan semua pemain di dunia game. Solusinya, jelas, adalah untuk memetakan mesin subdivisi spasial kita ke tingkat server. Setiap server akan menangani pemain terletak di bagian kontinu dari permainan dunia, sehingga memastikan bahwa tes yang paling dapat diselesaikan secara lokal. Sebagai contoh, kita dapat membagi dunia permainan dua. Kemudian, ketika kita perlu mengirim pemain update ke yang lain para pemain, kita menguji mana pemain lainnya yang dekat dengan pemain asli. Ini dilakukan oleh permainan
server, mudah-mudahan secara lokal. Semua pemain membutuhkan update akan terletak pada mesin yang sama sebagai asli pemain. Setelah kita memiliki daftar para pemain yang benar-benar perlu tahu bahwa pemain asli telah pindah, kami mengirim pesan ke mereka saja. Perhatikan bagaimana kita harus meningkatkan kinerja dalam dua cara. Di tingkat server, hanya setengah dari gamer diuji. Sisa dari mereka berbaring di server lain dan tidak bahkan melihat pemain dalam contoh dipindahkan. Kami dioptimalkan bandwidth jaringan juga, mengirim pembaruan hanya untuk para pemain dalam kisaran tertentu dari pemain.
Sekarang, mari kita generalisasi ini ke server N dalam dunia permainan besar. Kita dapat membagi skenario dalam gridlike fashion dan menetapkan kuadran grid untuk setiap server, sehingga semua pemain di kawasan yang ditangani internal, dan CPU dan bandwidth dijaga agar tetap minimum. Jika pengembang ingin menambahkan daerah baru untuk dunia permainan, semua yang perlu kita lakukan adalah menambahkan server tambahan untuk cluster. Jelas, pendekatan ini sebagian besar akan memiliki server pengguna lalu lintas, tapi server-server komunikasi akan menjadi penting juga. Bagaimana kita memberitahukan server yang seorang pemain telah melintasi batas-batas grid dan dengan demikian harus direlokasi ke jaringan tetangga
sel? Untuk membantu memvisualisasikan ini, berpikir dalam kerangka vertikal (server-pengguna) dan horizontal (server-server) pesan. Pesan Vertikal akan paling sering, sedangkan pesan horizontal akan membawa informasi kontrol dan menjadi kurang sering.

Dinamis Server dan Sindrom Braveheart
Kadang-kadang pendekatan berkerumun dijelaskan pada bagian sebelumnya akan gagal untuk melakukan tugasnya. Pada dasarnya, kami telah membagi dunia permainan spasial, dengan asumsi bahwa berarti sebuah divisi pemain homogen juga. Setiap wilayah sel memiliki sekitar jumlah yang sama pemain. Tapi apa yang terjadi jika sejumlah besar gamer adalah, pada suatu titik waktu, yang terletak di sel grid yang sama? Bayangkan sebuah "hotspot" Daerah yang banyak pemain bertemu untuk beberapa alasan permainan yang terkait. Jelas, server yang akan mendukung beban kerja lebih dari sisanya. Bayangkan "launchpad" daerah, di mana gamer paling dalam MMG muncul ketika mereka pertama kali masuk permainan. Ini adalah
kelebihan penduduk daerah, yang akan membuat kios server kami. Opsi pertama adalah dengan mempelajari kasus ini dengan seksama dan selanjutnya membagi dunia permainan, seperti dalam Quadtree, sekitar daerah ini. Tapi ini berarti bahwa wilayah hotspot adalah tetap, yang tidak benar-benar harus terjadi. Bayangkan bahwa suatu hari ada suatu pencarian tambahan yang diusulkan oleh para pengembang game, dan pencarian yang meningkatkan lalu lintas di suatu bagian tertentu dari dunia permainan. Bagaimana kita bisa memastikan bahwa game pengalaman tidak akan menurunkan hari itu? Dan bagaimana kita bisa mendapatkan sesuatu kembali normal setelah kegiatan berakhir, dan tingkat lalu lintas berkurang? Hal ini sering disebut sebagai sindrom Braveheart: bagaimana mencegah situasi di mana banyak gamer pindah ke sebagian kecil dari peta dan kemudian meninggalkannya, seperti di banyak pertempuran

http://www.tar.hu/gamealgorithms/ch10lev1sec9.html (5 dari 6) 2009/02/09 17:57:34
http://www.tar.hu/gamealgorithms/ch10lev1sec9.html


"Translete buku Core Algorithm In Game Technology BAB 10.4 " 

Pengamatan pada Game : The Sims

The Sims adalah permainan komputer simulasi strategik yang dibuat oleh desainer permainan Will Wright, dipublikasi oleh Maxis, dan didistribusikan oleh Electronic Arts. Permainan ini adalah simulasi aktivitas sehari-hari dalam rumahtangga. Pada tanggal 4 Februari 2000, permainan ini telah terjual sebanyak 16 juta kopi yang membuatnya sebagai permainan komputer dengan penjualan terbesar dalam sejarah. The Sims berfokus pada kehidupan orang virtual yang disebut sebagai Sims. Pemain dapat mengontrol aktivitas keseharian Sims, seperti menyuruhnya tidur, makan, membaca, atau mandi. Will Wright, desainer game ini, menyebut The Sims sebagai permainan rumah-rumahan digital ("digital dollhouse"). selain itu kita juga dapat membuat orang dengankarakter masing masing. The Sims adalah salah satu game yang paling banyak memiliki pak ekspansi. Hingga saat ini, ada 7 pak ekspansi yang telah diproduksi untuk The Sims (diurutkan berdasarkan tanggal rilis): * The Sims: Livin' Large Tanggal rilis: 31 Agustus 2000 (Amerika Utara) The Sims: Livin' Large (dikenal pula sebagai The Sims: Livin' It Up di Britania Raya, Irlandia and Finlandia) adalah pak ekspansi pertama yang dirilis untuk The Sims. Pak ini memberikan tambahan karakter, karir, barang-barang, dan fitur baru.

*The Sims: House Party Tanggal rilis: 21 April 2001 (Amerika Utara) The Sims: House Party adalah pak ekspansi kedua untuk game The Sims. House Party memberikan tambahan fitur untuk mengadakan pesta, serta tambahan karakter dan barang-barang baru.

*The Sims: Hot Date Tanggal rilis: 12 November 2001 (Amerika Utara) The Sims: Hot Date adalah pak ekspansi ketiga untuk The Sims. Hot Date memberikan sebuah fitur baru yang tidak ada di pak ekspansi sebelumnya, yakni kemampuan untuk meninggalkan rumah dan pergi ke sebuah tempat baru yang disebut "Downtown." Di Downtown, sim dapat mengajak sim lainnya untuk makan atau kencan. Selain itu, Hot Date juga memberikan tambahan barang furniture, karakter, dan pakaian baru.

*The Sims: Vacation Tanggal rilis: 28 Maret 2002 (Amerika Utara) The Sims: Vacation (atau The Sims: On Holiday di Irlandia, Britania Raya, dan Cina) adalah pak ekspansi ke-4 untuk game The Sims. Vacation memberikan tambahan perumahan (neighborhood) baru yang disebut Vacation Island, dimana Sims dapat berlibur bersama keluarga mereka. Vacation Island dibagi menjadi tiga zona, yaitu pantai, hutan, dan gunung salju.

*The Sims: Unleashed Tanggal rilis: 7 November 2002 (Amerika Utara) The Sims: Unleashed adalah pak ekspansi kelima yang dikembangkan oleh Maxis/EA untuk game The Sims. Di Unleashed, terdapat fitur tambahan yang memungkinkan pemain untuk memelihara hewan. Beberapa hewan, yaitu anjing dan kucing, diperlakuakn seperti Sim—mereka butuh makan dan minum. Sementara hewan-hewan lainnya diperlakukan sebagai objek (hiasan). Di Unleashed, lot perumahaan (neighborhood) yang awalnya hanya berjumlah 10, kini dikembangkan menjadi lebih dari 40 buah yang terbagi dalam zona perumahan dan komersial. Di lot komersial, pemain dapat mendirikan toko dan berbagai jenis restoran. Selain itu, ekspansi ini juga memberikan banyak tambahan musik dalam game. *The Sims: Superstar Tanggal rilis: 13 Mei 2003 (Amerika Utara) The Sims: Superstar adalah pak ekspansi ke enam dari game The Sims. Pak ekspansi ini memungkinkan Sims pemain untuk menjadi seorang selebritas.

*The Sims: Makin' Magic Tanggal rilis: 29 Oktober 2003 (Amerika Utara) The Sims: Makin' Magic adalah pak ekspansi terakhir yang dirilis untuk game The Sims. Pak ekspansi ini memberikan fitur baru yang memungkinkan pemain menggunakan sihir dalam game.

Sumber referensi : http://id.wikipedia.org/wiki/The_Sims http://blog.unsri.ac.id/kaskuserr/nais-inpo-gan/sejarah-the-sims/mrdetail/5835/