Berdasarkan Mengapa begitu sulit untuk mengembangkan MMO? :
Pengembangan game berjaringan tidak sepele; ada banyak kendala yang harus diatasi tidak hanya dalam latensi, tetapi juga mencegah penipuan, manajemen negara, dan penyeimbangan beban. Jika Anda tidak berpengalaman menulis game jaringan, ini akan menjadi latihan pembelajaran yang sulit.
Saya tahu teori tentang soket, server, klien, protokol, koneksi, dan hal-hal semacam itu.
Sekarang saya bertanya-tanya bagaimana orang bisa belajar menulis permainan jaringan:
- Bagaimana cara menyeimbangkan masalah beban?
- Bagaimana cara mengatur kondisi permainan?
- Bagaimana cara menjaga sinkronisasi?
- Bagaimana melindungi komunikasi dan klien dari rekayasa terbalik?
- Bagaimana cara mengatasi masalah latensi?
- Hal-hal mana yang harus dihitung secara lokal dan hal-hal apa di server?
- ...
Apakah ada buku bagus, tutorial, situs, artikel menarik atau pertanyaan lain mengenai ini?
Saya mencari jawaban yang luas, tetapi yang spesifik juga baik untuk mempelajari perbedaannya.
networking
multiplayer
books
scalability
Tamara Wijsman
sumber
sumber
Jawaban:
Selain artikel yang ditautkan dalam jawaban lain, saya dapat menceritakan sedikit tentang pengalaman Proyek Arianne .
Bagaimana cara menjaga sinkronisasi?
Kami telah membangun kerangka kerja " Marauroa " di sekitar konsep tindakan dan persepsi: Tindakan dikirim dari klien ke server yang membawa input pengguna seperti (berjalan ke kiri, serang monster # 47, katakan 'halo'). Dan persepsi dikirim dari server ke klien untuk memberi tahu mereka tentang keadaan dunia di sekitar mereka. Persepsi itu dikirim setiap belokan. Bergantung pada permainan, kami menggunakan waktu pergantian 30ms ke 300ms.
Kami memiliki dua jenis persepsi : Persepsi penuh dikirim saat masuk dan saat pemain memasuki area (zona) baru. Setelah itu persepsi diferensial dikirim termasuk hanya atribut yang dimodifikasi (misalnya posisi) dari objek yang dimodifikasi, dan tentu saja objek yang baru dan dihapus.
Bagaimana cara mengatasi masalah latensi?
Kami sangat meyakini “server selalu benar”. Klien melakukan beberapa prediksi seperti berjalan mulus, cek tabrakan, dan sebagainya. Tetapi jika klien dan server tidak setuju tentang sesuatu, server menang. Subproyek Stendhal (RPG 2D) menggunakan waktu pergantian 300ms secara default (dengan banyak sisi klien yang dihaluskan). Ini membuat Stendhal sangat tahan terhadap lag.
Catatan: Beberapa game lain mempercayai klien untuk memperluas beberapa untuk meminimalkan dampak dari keterlambatan jaringan. Di WoW itu sering dieksploitasi di salah satu medan perang yang disebut "Warsong Gulch". Ada dua cara yang bisa dipilih pemain dengan bendera: Aktif di tengah melalui terowongan dan satu di sisi kanan naik bukit. Jadi pemain yang curang berlari menuju terowongan, dan kemudian menyebabkan lag untuk dirinya sendiri. Server dan klien lain akan terus melihatnya berlari ke arahnya. Tetapi setelah beberapa saat klien ini dapat memberi tahu server bahwa ia pergi menuju bukit. WoW akan memeriksa bahwa jarak antara koordinat yang terakhir ditransmisikan dan yang sekarang sesuai dengan segmen waktu dan menerimanya.
Penggunaan UDP vs. TCP
Dalam versi awal kami menggunakan UDP untuk mengurangi overhead TCP. Kami menangani paket yang hilang sendiri. Ini bekerja dengan sempurna pada hari-hari awal proyek. Tetapi ketika server dipindahkan dari beberapa koneksi DSL rumah ke pusat data nyata beberapa tahun yang lalu, kami mendapat masalah besar. UDP (atau setidaknya 5 tahun yang lalu) sangat menuntut daya CPU dari perangkat keras firewall: Aturan harus diterapkan ke setiap paket UDP. Untuk TCP, bagaimanapun, aturan hanya diterapkan untuk 3 paket pertama. Setelah itu koneksi dibuat. Semua paket berikut akan mem-bypass aturan normal karena mereka berada di tabel pelacakan yang menghubungkan atau karena mereka tidak memiliki flag SYN.
Bagaimana melindungi komunikasi dan klien dari rekayasa terbalik?
Arianne sepenuhnya open source, ini termasuk klien, server, grafik, musik. Dan tentu saja itu termasuk dokumentasi protokol kami dan bahkan analisa yang digunakan untuk debugging.
Sangat mudah untuk melindungi komunikasi terhadap sniffing yang tidak sah oleh pihak ketiga menggunakan SSL.
Namun, mustahil untuk melindunginya dari rekayasa balik. Tentu Anda dapat mengaburkannya dan menggunakan teknik anti debugging. Tetapi pada akhirnya Anda tidak dapat mencegah rekayasa balik perangkat lunak yang Anda berikan kepada pengguna. Ada presentasi yang sangat menarik tentang bagaimana Skype dibalik direkayasa meskipun para pengembang berupaya keras dalam teknik anti debugging: http://recon.cx/en/f/vskype-part1.pdf
Catatan: Ada beberapa negara di mana reverse engineering ilegal atau yang memungkinkan untuk memasukkan paragraf ke dalam lisensi atau ToS yang melarang reverse engineering. Tetapi ada negara lain (seperti yang saya tinggali) yang secara eksplisit memungkinkan rekayasa terbalik dalam konteks pengembangan format penyimpanan data yang kompatibel atau protokol transmisi, paragraf dalam lisensi atau ToS yang mencoba melarang yang tidak berlaku. (Segala sesuatu di bagian ini sejauh yang saya tahu, saya bukan pengacara)
Hal-hal mana yang harus dihitung secara lokal dan hal-hal apa di server?
Kami menghitung semua yang terkait dengan logika game di server. Klien akan memprediksi acara tertentu untuk membuat permainan berjalan dengan lancar. Namun pada akhirnya server selalu benar.
Perkiraan kejadian misalnya menghentikan pergerakan saat tabrakan terjadi. Stendhal menggunakan kisi untuk memposisikan elemen. Dan dari sudut pandang server, sudut kiri atas setiap entitas tepat pada satu persegi. Tetapi klien akan memindahkannya dengan lancar di antara ubin. Ini akan menggambar efek 3d semu juga. Jadi entitas yang memiliki basis 1x1 mungkin lebih tinggi di klien.
Bagaimana cara menyeimbangkan masalah beban?
Cobalah untuk menjaga ini sesederhana mungkin, untuk memudahkan perawatan.
Penyeimbangan muatan konten statis dikenal di area cluster server http dan jaringan distribusi konten.
Konsep yang agak sederhana untuk menyeimbangkan beban layanan game adalah untuk membagi server di seluruh wilayah / zona. Jadi zona AC ada di satu server dan zona DF berada di yang lain. Ini sangat mudah jika Anda tidak dapat melihat dari zona di satu set ke zona di set lain. Anda perlu menaruh beberapa cek di sana sehingga klien hanya dapat terhubung ke server zona yang bertanggung jawab atas zona pemain tersebut.
Cara termudah untuk mentransfer pemain dari satu server ke yang lain adalah dengan menuliskannya ke basis data, memberi tahu klien untuk terhubung ke server zona lain, dan memutuskan koneksi mereka dari yang sekarang. Klien kemudian akan terhubung ke server zona baru yang akan memuatnya dari database. (Karena Anda tetap memerlukan load dari / store ke kode database, komunikasi langsung antara server untuk serah terima dapat diimplementasikan kemudian).
Beberapa layanan global tambahan diperlukan melalui: Pada login, klien harus diberitahu untuk terhubung ke server zona yang benar. Dan Anda mungkin menginginkan sistem obrolan di seluruh dunia.
Saya masuk ke detail tentang topik ini di Bagaimana cara menyeimbangkan beban dicapai dalam MMO?
sumber
http://gafferongames.com/networking-for-game-programmers/
Merupakan seperangkat artikel hebat tentang berbagai masalah dan solusi yang berhubungan dengan jaringan game.
sumber
Tergantung pada jenis permainan yang Anda tulis, Anda mungkin dapat menghindari beberapa pemrograman jaringan tingkat rendah. Beberapa jenis permainan tidak memerlukan banyak komunikasi bolak-balik antara klien dan server. Dalam kasus seperti itu, seseorang dapat memilih untuk menggunakan kerangka kerja tingkat yang lebih tinggi. Sebagai contoh, saya sedang mengembangkan permainan strategi berbasis giliran di C # /. NET. Permainan strategi berbasis giliran agak unik karena sebagian besar komunikasi klien / server terjadi pada awal dan akhir pergantian, dengan relatif sedikit di antaranya. Jadi, saya memilih untuk menggunakan Windows Communication Foundation (WCF), kerangka kerja komunikasi tingkat tinggi yang dirancang terutama untuk layanan web. Alih-alih bekerja secara langsung dengan soket dan semua gunk networking tingkat rendah itu, saya dapat membuat apa yang tampak sebagai panggilan metode standar, dan biarkan WCF menangani protokol dan lapisan transport untuk saya. Satu-satunya waktu saya harus berurusan dengan hal-hal jaringan tingkat rendah adalah ketika saya mengkonfigurasi titik akhir saya, yang merupakan kesepakatan satu kali dalam file konfigurasi. Mungkin masih perlu untuk mengimplementasikan beberapa logika serialisasi khusus, tetapi Anda harus melakukan hal semacam itu.
sumber
Pertanyaannya terlalu luas. Jawabannya dapat mengisi situs web sendiri. Tapi, ada buku yang menyentuh ini, terutama dua ini:
Perhatikan bahwa bahkan buku-buku ini bukan panduan lengkap, tetapi merupakan kumpulan ide dan pendekatan yang dapat Anda gunakan, beberapa di antaranya tidak akan bekerja bersama, atau bahkan bertentangan. Biasanya mengasumsikan beberapa pengalaman mengembangkan game, aplikasi jaringan, atau idealnya keduanya.
(Perhatikan bahwa saya berbicara lebih banyak tentang MMO dalam pertanyaan awal - 'permainan jaringan' dapat berarti segala hal mulai dari permainan teks berbasis PHP hingga MMO, dan sub-pertanyaan di atas tidak semuanya berlaku untuk setiap jenis.)
sumber
ukuran geografis tetap + beberapa instance adalah solusi termudah. Orang-orang yang bekerja di SWG mencoba ukuran dinamis dan menyesalinya.
Server berwibawa.
Pembaruan sinkronisasi berkala dari server. (tidak yakin apa masalahnya di sini)
Mustahil. pastikan Anda tidak mempercayai apa pun yang Anda terima dari klien, dan bahwa server itu otoritatif.
Ini bermil-mil dalam, tetapi di permukaan Anda menjalankan simulasi yang sama pada klien sebagai server dan ketika sinkronisasi terjadi, perbaiki beberapa hal. Semua keputusan yang dibuat pada klien disimulasikan di server juga, jadi mungkin ada keputusan yang buruk, tetapi hal-hal umumnya berhasil.
Anggap klien menjalankan sim non-otoritatif tentang apa yang terjadi di server. Responsiveness adalah kunci untuk pengalaman pemain, jadi Anda harus melakukan sesuatu setiap kali pemain membuat keputusan, bahkan jika itu baru memulai sebuah bar.
Sejujurnya, banyak dari masalah ini bersifat ortogonal, dan dapat diterapkan solusinya nanti. Mulailah melakukan permainan dan jangan terlalu khawatir tentang hal-hal ini.
sumber
Pertanyaan ini sangat luas. Ini juga merupakan bidang yang sangat sulit untuk dikuasai, pemrogram jaringan cukup dicari di industri dengan pembayaran yang sesuai, yang agaknya menunjukkan itu adalah wilayah yang 'tidak terpecahkan'. Apakah ada buku di luar sana, ya, banyak. Apakah ada buku bagus di luar sana, tidak diragukan lagi. Apakah ada buku di luar sana yang akan menjawab pertanyaan Anda? ... Saya kira tidak. Mereka mungkin memiliki solusi yang bekerja dalam beberapa situasi atau petunjuk tentang apa yang harus dicari, tetapi hampir semua pertanyaan Anda tergantung pada permainan .... ini adalah area di mana Anda benar-benar harus banyak bekerja pada Anda sendiri, itu tampak sangat sepele dan bisa salah dalam begitu banyak (tidak terkontrol) cara.
sumber