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 "
Tidak ada komentar:
Posting Komentar