Informasi tentang arsitektur server MMO mulus


9

Saya mencari bahan apa saja di server MMO yang mulus! Saya memiliki beberapa artikel di buku "Massively Multiplayer Game Development" dan "Game Programming Gems 5." Adakah yang punya pengalaman tentang topik itu atau tahu artikel tentang itu?

Saya tertarik pada "pandangan tingkat tinggi" serta implementasi. Ini mungkin menjadi topik tesis master saya dan saya ingin mengetahui betapa sulitnya untuk menulis sistem seperti itu, sebelum saya benar-benar memulai tesis. Saat ini saya belum memutuskan bahasa yang akan digunakan, saya sedang memikirkan Java atau Scala. Erlang bisa menjadi pilihan, tetapi saya tidak pernah bekerja dengan itu.

Catatan: Persyaratan dasar adalah perpindahan. Sistem permainan lain mana pun bersifat opsional dan memberikan "kredit bonus."

Sekarang untuk apa yang saya maksud dengan "seamless server": Saya ingin mengatur cluster server di mana setiap node mengontrol beberapa bagian dari dunia game, dengan batas-batas statis. Pemain sekarang dapat berpindah dari satu ujung dunia ke ujung yang lain tanpa mengganti instance atau memukul "teleporter". Saya pikir WoW melakukan itu. Namun di back-end saya pemain melakukan transisi dari satu server ke yang berikutnya.


Beberapa waktu yang lalu saya membaca bahwa setiap server WoW berisi 5+ pisau - 1 untuk setiap benua dan database. Dulu juga merupakan ruang bawah tanah dan medan pertempuran meskipun saya berasumsi bahwa sekarang mereka yang berada di kelompok mereka sendiri untuk memungkinkan koneksi lintas-dunia. Singkatnya, benua dipegang pada satu server - tidak ada titik di mana Anda dipindahkan ke server lain kecuali Anda mengubah benua.
Leniency

Menarik, apakah Anda ingat di mana Anda membacanya? Seperti yang saya katakan, saya tidak pernah memainkan WoW dan tidak tahu seberapa besar benua itu, tetapi saya tidak dapat membayangkan bahwa setiap benua di-host pada satu server terpisah.
Lurca

3
Statistik server WoW: 13.250 total server blade, 75.000 core CPU total, 112,5 terabyte RAM (pada GDC Austin 09). Lihat di sini ; belum tentu semua dikhususkan untuk WoW, tapi cukup dekat.

@ Josh Petrie: Terima kasih, temukan artikel ini sebelumnya hari ini. Tapi saya masih mencari hal-hal tentang arsitektur server yang mulus atau berkelanjutan.
Lurca

Jawaban:


5

Kompleksitas utama dalam mengelola sistem seperti itu berasal dari betapa mulusnya Anda membutuhkannya. Seperti yang dikatakan Josh, menyelesaikan masalah dengan menyerahkan entitas dari satu server ke server lain adalah bagian penting dari paket.

Ini bukan satu-satunya masalah - jika entitas di beberapa server perlu berinteraksi sebagai bagian dari satu operasi Anda sekarang memiliki masalah sinkronisasi di mana setiap sistem membutuhkan data dari sisi lain untuk melanjutkan, tetapi pada saat data tiba mungkin sudah tidak valid. Anda dapat mencoba menyelesaikannya dengan memecah operasi menjadi beberapa pesan dengan kemampuan rollback jika satu sisi mundur, tetapi seperti yang Anda lihat dari Bab 3.1 dalam "Massively Multiplayer Game Development", ini secara signifikan menyulitkan logika permainan apa pun yang harus Anda lakukan. lakukan ini dengan. Scala dan Erlang membantu Anda mengatur sistem pengiriman pesan dengan benar - mereka tidak membantu Anda dengan penguraian dari apa yang dulunya merupakan fungsi 10 baris ke dalam banyak pesan berbeda dan menyatakan bahwa Anda sekarang perlu melacak.

Jelas, masalah ini tidak sepenuhnya baru, dan database relasional mendukung masalah semacam ini dengan menyimpan semua data secara terpusat dan membiarkan banyak klien meminta dan mengubahnya sesuai kebutuhan, memutar kembali transaksi jika diperlukan. Ini memberi Anda sebagian besar persyaratan kebenaran Anda tetapi sayangnya membebankan masalah kinerja yang tidak praktis serta membuat implementasi logika game canggung (karena banyak dari logika Anda sekarang ditulis dalam prosedur yang tersimpan dalam basis data). Jenis database yang berbeda mungkin memberikan solusi yang baik di sini, terutama jika Anda bersedia menukar persyaratan keandalan yang disediakan sebagian besar RDBMSes.

Sebagian besar permainan profesional mengatasi masalah ini dengan bahkan tidak mencobanya, dengan menjaga ukuran beling cukup kecil untuk menempatkan semua pemain di satu server, dengan membagi dunia menjadi bagian-bagian yang tidak benar-benar berinteraksi (lihat contoh WoW dalam komentar di atas) , atau dengan mendistribusikan game di server berdasarkan fungsi daripada geografi (mis. semua pertempuran terjadi di satu server, semua mengobrol di server lain) sehingga tidak ada 'jahitan' untuk bersaing.


3

Saya tertarik pada "pandangan tingkat tinggi" serta implementasi.

Implementasi umumnya cukup terlibat dan Anda mungkin tidak akan melihat banyak pembicaraan tentang mereka di sini. Perangkat lunak StackExchange tidak cocok untuk jenis diskusi yang terlibat, belum lagi itu akan melibatkan investasi yang signifikan dari waktu seseorang.

Saya ingin mengetahui betapa sulitnya menulis sistem seperti itu

Tidak lebih atau kurang sulit daripada sistem lain: itu akan tergantung pada kebutuhan Anda dan fitur yang ingin Anda kendarai. Anda dapat menulis implementasi sepele sepele, tetapi hal-hal yang tidak sepele tentu akan jauh lebih sulit. Salah satu masalah terbesar adalah itu Anda mungkin tidak akan memiliki cukup klien nyata untuk mengetahui apakah sistem Anda benar-benar berkembang ke tingkat "masif" di mana WoW dan game lain beroperasi.

MMO tidak magis. Sebagian besar teknologi mereka tidak ada yang istimewa ketika diambil secara terpisah, hanya saja sejumlah teknologi yang lebih kecil dan lebih sederhana digabungkan dengan sangat cerdas untuk memungkinkan simulasi paralel berskala lebih besar yang terhubung dari beberapa negara dunia bersama.

Saya ingin mengatur server cluster di mana setiap node mengontrol beberapa bagian dari dunia game, dengan batas-batas statis. Pemain sekarang dapat berpindah dari satu ujung dunia ke ujung yang lain tanpa mengganti instance atau memukul "teleporter".

Pada dasarnya apa yang Anda bicarakan adalah simulasi hand-off. Ini dapat dilakukan dengan cukup sederhana dan tidak harus teknologi MMO-spesifik (game peer-to-peer cenderung mendukung semua mekanisme dasar yang sama untuk mengimplementasikan migrasi host). Premis dasarnya adalah membuat setiap server memahami topologi server "di sekelilingnya" (khususnya, server untuk simpul dunia A harus tahu tentang server untuk simpul dunia yang berdekatan dengan simulasi) serta menentukan buffer di sekitar yang Anda pertimbangkan entitas simulasi tertentu "tutup" ke server yang berdekatan.

Ketika suatu entitas memasuki buffer "tutup", Anda mulai melaporkannya ke server yang berdekatan juga. Setelah entitas melewati ambang sebenarnya, Anda mengirim pesan ke server yang berdekatan dengan status penuh entitas dan pesan yang menunjukkan bahwa server yang berdekatan harus mengambil alih entitas. Jelas Anda ingin ini dapat diandalkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.