Teknik, algoritma, dan sumber daya MMO untuk menjaga bandwidth tetap rendah?

Apakah ada sumber daya dan dokumentasi tentang bagaimana MMO saat ini menangani data tindakan dan perpindahan dari kompresi ke penanganan pada klien? Adakah sumber daya untuk algoritme prediksi gerakan?

Saya terutama tertarik pada mereka yang memiliki gerakan wsad dan fokus pada menjaga latensi rendah. Juga, berapa kecepatan dan ukuran paket untuk berbagai jenis MMO (jaringan bijaksana)?

Apakah ada cara untuk skala tingkat paket atau langsung menonaktifkan beberapa paket jika pemain tidak dapat mencapai atau dalam kasus nanti melihatnya?

mmo networking scalability

— adrix89
sumber

Jawaban:

Nah, ada buku ini - yang sudah agak tua sekarang, dan saya belum pernah benar-benar membacanya, tetapi dari penerbit terkemuka. Saya juga menemukan ini , yang lebih baru, tetapi saya belum pernah mendengar sebelumnya. Keduanya mengklaim mencakup masalah pengembangan game MMO (atau setidaknya online); yang mengatakan, prediksi sisi klien kurang lebih sama terlepas dari skala basis pemain bersamaan Anda, dan Google memiliki banyak informasi tentangnya .

Sangat penting untuk menyadari bahwa dari perspektif praktis, agak sulit bagi pengembang indie / hobi untuk menyatukan permainan yang akan cukup populer untuk mengumpulkan cukup banyak pemain untuk mencapai puncak teori konkurensi yang cukup tinggi untuk dianggap "masif." Namun tekniknya masih bisa edukatif untuk diteliti.

Ada dua klasifikasi utama yang dapat Anda lakukan:

Jadilah agresif dalam mengirim hanya jumlah data minimum ke set minimal klien yang membutuhkannya.
Rancang game yang tidak memberikan insentif pemain untuk menggumpal terlalu banyak, membantu Anda menjaga "set klien yang membutuhkan" hal-hal kecil secara umum.

Yang kedua benar-benar masalah desain permainan dan manipulasi sosial - ini terutama rumit karena permainan multipemain secara sosial bersifat sosial, itu bagian dari daya tarik mereka, jadi Anda tidak ingin terlalu banyak mengecilkan kelompok pemain. Di sisi lain, gim di mana semua orang di dunia menelurkan orang yang menjatuhkan barang rampasan terbaik dalam gim akan sulit untuk diukur.

Untuk opsi pertama, Anda dapat mempertimbangkan untuk melakukan olahpesan berjenjang - ada beberapa hal tentang pemain lain yang selalu penting untuk diketahui, seperti posisi. Tetapi hal-hal lain, seperti kesehatan, mungkin tidak sepenting objek yang tidak dapat dilihat oleh pemain saat ini, sehingga Anda mengirim apa yang Anda kirim ke pemain itu berdasarkan jarak relatif semua entitas lain di sekitarnya - ini pada dasarnya adalah pelambatan data yang Anda kirim, seperti yang Anda sebutkan di bagian terakhir dari pertanyaan Anda, serta memfilternya.

Arsitektur multipemain skala sangat besar juga akan menyangga laporan yang tidak perlu segera diambil tindakan. Karakter menyimpan pesan yang dikirim ke server dapat dilakukan dalam delta, dengan pembaruan penuh hanya pada titik-titik kritis, dan pembaruan ini dapat disangga pada server pelambatan sehingga mereka dikirim ke server yang benar-benar menyimpan data karakter dalam keadaan stabil, mode berkala - sebagai basis pemain Anda, Anda harus khawatir tentang mengoptimalkan IO disk serta lalu lintas jaringan. Anda tidak ingin menyebabkan database karakter Anda rusak.

Kecepatan dan ukuran paket sangat berbeda dari game ke game, seperti halnya untuk game non-MMO. Ini benar-benar persyaratan yang sangat spesifik dan tidak ada standar umum.

Ada juga sekuel dari buku pertama (Massively Multiplayer Game Development 2). Ini bukan seri buku yang sangat berguna menurut saya (itu jelas bukan buku make-a-MMO-in-x-jam awal-to-selesai seperti kebanyakan buku dev game), tapi itu membahas beberapa masalah teoritis ditanyakan dalam pertanyaan ini. Dan mungkin itu akan lebih bermanfaat bagi seseorang yang sudah memiliki MMO yang sebagian dikembangkan.

— Ricket

Selain jawaban di atas, baca di TCP_NODELAY dan bagaimana penskalaan jendela beroperasi. Memahami rincian TCP (dan ya, Anda ingin menggunakan TCP bukan UDP kecuali prospek menangani pembaruan diferensial yang keluar dari pesanan terdengar menyenangkan bagi Anda) dan pengiriman ulang sangat penting untuk kontrol latensi.

— pembuat kode
sumber

Saya akan ulangi bahwa jika Anda menggunakan pembaruan diferensial (biasanya struktur biner berbeda dalam game) dan Anda menggunakan apa pun dengan pengiriman yang tidak sesuai pesanan (dapat diandalkan atau tidak), Anda akan menyesalinya. Orang-orang yang tidak menyukai TCP dalam permainan pada umumnya tidak cukup tahu tentang hal itu (seperti mengetahui apa yang dilakukan NODELAY). UDP masuk akal untuk hal-hal seperti data suara, di mana paket-paket rusak dapat dengan mudah dijatuhkan, ini jarang terjadi dalam permainan.

— coderanger

"Jarang terjadi dalam permainan"? Asalkan server memberi saya status permainan otoritatif setiap frame, saya tidak peduli apa yang terjadi di masa lalu. Nomor bingkai sederhana yang meningkat secara monoton dari paket UDP sangat cocok untuk ini. Berapa banyak data yang benar-benar Anda butuhkan untuk mengirimkan dengan andal?

— ChrisE

"Asalkan server memberi saya game otoritatif menyatakan setiap frame" Tentu, jika Anda menganggap itu sebagai yang diberikan. Perhatikan bahwa saya berkata "jika Anda menggunakan pembaruan diferensial" yang akan menjadi kebalikan dari nyala keadaan penuh setiap frame. Dalam MMO dengan tingkat kerumitan apa pun kepada dunia, dengan cepat menjadi tidak mungkin untuk mengirimkan pembaruan penuh sesering itu.

— coderanger

Bahkan jika mengirim keadaan penuh dari hal-hal yang berubah, Anda berakhir dengan masalah pengiriman yang tidak sesuai pesanan di mana menggabungkan berbagai hal menjadi tidak mungkin. Pikirkan pembaruan "x = 1, y = 2" dan kemudian "y = 1, z = 2". Jika mereka tiba mundur Anda ingin menjatuhkan yang "pertama" sehingga nilai y sudah benar, tetapi kemudian Anda kehilangan perubahan ke x.

— coderanger

@Adam Itulah sebabnya saya mengatakan Anda harus membaca spec TCP dan memahami bagaimana penskalaan jendela bekerja dan bagaimana ia berinteraksi dengan pengiriman ulang ;-) Menulis ulang TCP pada dasarnya selalu salah, kemungkinan mengacaukannya mendekati 100%. Jika Anda ingin pengiriman yang andal dan andal, Anda tidak boleh menggunakan UDP.

— coderanger