Kompensasi lag dengan game 2D jaringan

Saya ingin membuat game 2D yang pada dasarnya adalah permainan sandbox / activity yang didorong oleh fisika. Ada sesuatu yang saya benar-benar tidak mengerti. Dari penelitian, sepertinya pembaruan dari server hanya sekitar 100ms. Saya dapat melihat bagaimana ini bekerja untuk seorang pemain karena mereka dapat secara bersamaan mensimulasikan fisika dan melakukan kompensasi lag melalui interpolasi.

Yang tidak saya mengerti adalah bagaimana ini berfungsi untuk pembaruan dari pemain lain. Jika klien hanya mendapat pemberitahuan tentang posisi pemain setiap 100 ms, saya tidak melihat cara kerjanya karena banyak yang bisa terjadi dalam 100 ms. Pemain bisa saja mengubah arah dua kali atau lebih dalam waktu itu. Saya bertanya-tanya apakah ada yang akan memiliki wawasan tentang masalah ini.

Pada dasarnya bagaimana ini berfungsi untuk pemotretan dan hal-hal seperti itu?

Terima kasih

Ringkasan untuk mereka yang tidak suka jawaban panjang ...

Itu bisa dilakukan tetapi tidak mungkin untuk melakukan fisika multi-pemain sempurna jika ada latensi. Mengapa dampak latensi fisika dijelaskan, dan kemudian kiat untuk mengurangi dampak latensi pada simulasi fisika Anda ditawarkan.

Membuat game fisika multi-pemain bisa penuh bahaya. Tidak mungkin untuk membuat pengalaman fisika multi-pemain online "sempurna". Ada hal-hal yang dapat Anda lakukan untuk menjadikannya lebih baik, tetapi tidak ada cara untuk membuat fisika sempurna dengan asumsi latensi apa pun.

Masalahnya adalah, fisika harus cepat dan responsif agar realistis, tetapi pada saat yang sama harus dihitung berdasarkan aksi gabungan dari semua faktor - artinya aksi gabungan dari semua pemain. Dan jika ada latensi, ini tidak dapat dilakukan secara real time.

Terserah Anda sebagai pengembang untuk memutuskan apakah Anda dapat mengendalikan faktor-faktor yang berbeda, dan untuk memahami bahwa pengalaman pemain akan menurun jika latensi menjadi terlalu tinggi. Jika Anda bisa hidup dengan itu (dan pemain Anda bisa), maka lakukanlah. Lihat pada akhir posting ini untuk beberapa catatan tentang bagaimana Anda dapat menjaga semuanya berjalan lebih lancar.

Contoh untuk menunjukkan bagaimana hal-hal dapat kacau

Bayangkan sebuah permainan di mana dua pemain (klien) terhubung ke server. Dibutuhkan 100 milidetik (1/10 detik) untuk mengirim pesan di internet dari klien ke server. Ketika seorang pemain melakukan sesuatu, sebuah pesan dikirim ke server mengatakan apa yang mereka lakukan. Server kemudian menyiarkan pesan ke pemain lain sehingga mereka semua tahu apa yang dilakukan pemain akting.

Sekarang buat skenario di mana dua pemain memiliki peti di tanah yang merupakan objek fisika. Pemain A memukulnya di satu sisi, mengirimkannya bergerak ke beberapa arah. Namun pada saat yang sama, pemain B memukulnya di sisi lain, mengirimkannya ke arah lain.

Mari kita lihat berbagai cara untuk menangani ini dan apa hasilnya ...

Bagaimana jika fisika dihitung hanya di server?

Misalkan kita hanya menghitung fisika di server. Pemain A mengirimkan pesan "Saya tekan peti dengan cara ini" ke server, 1/10 detik kemudian server menerima pesan. Pemain B mengirimkan pesan "Saya tekan peti dengan cara lain". Server menghitung perubahan fisika dari kombinasi dua aksi, dan mengirim pesan kembali ke kedua pemain yang mengatakan, "OK bergerak seperti ini." Fisika sempurna dilakukan, berdasarkan aksi dari kedua pemain yang digabungkan.

Tetapi masalahnya adalah, itu akan menjadi 2/10 detik sebelum salah satu pemain melihat peti bereaksi. Pesan dari kedua pemain memerlukan 1/10 detik untuk mencapai server, lalu 1/10 detik untuk hasil perhitungan server yang akan dikirim untuk kedua pemain.

Intinya, gameplay yang laggy.

Bagaimana jika fisika hanya dihitung pada klien?

Misalkan kita memiliki perhitungan fisika hanya pada klien. Mari kita melihatnya dari sudut pandang Player A. Player A hits peti dan segera mulai menuju ke arah mereka. Sebuah pesan juga dikirim ke server mengatakan apa yang Player A lakukan.

Pada saat yang sama, B telah melakukan hit mereka dan melihat peti menuju ke arah mereka dan mengirim pesan ke server tentang apa yang mereka lakukan.

2/10 detik kemudian, pesan datang dari server ke klien. A diberi tahu apa yang B lakukan, dan B diberi tahu apa yang A lakukan. Masalahnya adalah, kedua klien mengatakan, "Pemain X mungkin telah melakukan pukulan itu di tempat ini, tetapi tidak ada lagi peti di lokasi itu, jadi pukulan mereka tidak melakukan apa pun."

Intinya adalah, dua game tidak sinkron dan pemain tidak memiliki pengalaman bersama. Apa gunanya multiplayer jika mereka berdua melihat hal yang berbeda?

Bagaimana jika fisika dihitung pada klien dan server?

Dalam hal ini, fisika dihitung pada klien sehingga pemain melihat reaksi langsung tanpa penundaan, tetapi juga dihitung pada server sehingga "benar" untuk semua pemain.

Kedua pemain mengenai peti arah mereka masing-masing dan masing-masing melihat peti bergerak berdasarkan hit mereka saja. Tapi kemudian 2/10 detik kemudian, server kembali dan berkata, "Sebenarnya, Anda berdua salah. Peti pergi ke sini." Tiba-tiba kedua pemain melihat peti secara drastis mengubah arah dan kesalahan ke lokasi baru.

Intinya adalah, game yang glitchy.

Kesimpulan

Pada dasarnya tidak ada cara untuk membuat permainan fisika yang sempurna dengan banyak pemain ketika jenis latensi ada. Anda dapat membuat gim yang cukup bagus, tetapi Anda selalu memiliki risiko latensi berlebih yang menciptakan pengalaman buruk bagi beberapa pemain. Namun ada beberapa hal yang dapat Anda lakukan untuk menjaga pengalaman gim Anda tetap bagus.

Hal-hal yang dapat Anda lakukan untuk membuat game multi pemain berjalan dengan baik

Gunakan volume tumbukan sederhana. Jangan repot-repot memodelkan setiap detail bentuk dengan fisika saat bentuk kubus sederhana akan dilakukan. Bola spikey tidak harus dimodelkan sebagai bola spikey untuk fisika. Alih-alih hanya memodelkannya sebagai bola.

Membuat objek kecil yang tidak penting hanya item klien. Contohnya mungkin pecahan kaca dari jendela yang pecah. Anda dapat membiarkan setiap klien mensimulasikannya sendiri, dan tidak masalah jika mereka berbeda.

Hanya membuat objek fisika objek jika mereka perlu objek fisika untuk menjaga jumlah objek fisika aktif rendah.

Jalankan game Anda dalam gerakan lambat saat melakukan fisika multi-pemain. Pikirkan "waktu peluru" mungkin. Game gerak lambat mengimbangi latensi dan memungkinkan banyak pemain berinteraksi dengan fisika bersama.

Izinkan pemain untuk mengatur situasi semacam bersama-sama, dan kemudian pada beberapa isyarat, fisika disimulasikan untuk kedua pemain dan keduanya menonton hasil dari tindakan gabungan mereka. Pemain tidak boleh mengganggu urutan sampai selesai.

Pisahkan pemain phsyics sehingga mereka tidak bisa saling mengganggu. Ini akan bagus untuk permainan seperti bowling atau biliar, di mana hanya satu pemain pada suatu waktu memiliki kontrol, atau setiap pemain memiliki "kotak pasir" mereka sendiri (seperti jalur bowling).

Jika Anda tidak bisa mengalahkan mereka, bergabunglah dengan mereka dan jadikan fisika lag menjadi bagian dari gim Anda. Bayangkan sebuah cerita tentang berada di alam semesta yang gemerlap dengan hukum fisika yang rusak atau sesuatu :)

Lampiran: Bagaimana game menembak menghadapinya

Permainan menembak menghadapinya dengan tidak melakukan fisika yang terlalu rumit. Mereka memang menggunakan efek samping klien sehingga pemain melihat sesuatu dengan cepat, tetapi kemudian server melakukan panggilan terakhir pada apa yang telah terjadi.

Bayangkan sebuah skenario di mana pemain A menembak pemain B. Permainan shooter khas Anda akan melakukan sesuatu seperti ini ...

1. A akan menghitung secara lokal jika mereka memukul B, dan jika sepertinya ada klik, ia memainkan efek "memukul" seperti embusan darah. Ini dilakukan sisi klien sehingga pemain segera melihat reaksi atas tindakan mereka. Jika Anda tidak melakukan ini, permainannya terasa lamban.
2. A juga mengirim pesan ke server dengan mengatakan, "Saya memotret vektor ini"
3. Ketika server mendapatkan pesan, ia melihat di mana IT berpikir para pemain berada, dan memutuskan apakah vektor tembakan A mengenai B.
4. Jika server memutuskan A hit B, ia memutuskan B hit, dan mengirim pesan ke KEDUA klien yang mengatakan apa yang terjadi.
5. Jika server memutuskan A TIDAK menekan B, B baik-baik saja, dan A "gagal". Itu mungkin terlihat seperti mereka memukul ("Saya melihat kepulan darah!") Tetapi itu adalah panggilan server yang mereka lewatkan.

Jadi bagaimana mungkin A miss B ketika mereka memukul mereka? Karena B mungkin sudah pindah, tetapi A belum melihatnya karena server belum mengirim pesan, "B pindah ke sini" ke klien.

Valve memiliki Langgan yang baik di situs mereka tentang ini. Lihat http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Saya telah menulis serangkaian artikel tentang topik di sini: http://www.gabrielgambetta.com/fpm1.html

Tiga artikel pertama membahas pengantar topik, prediksi sisi klien, rekonsiliasi server, dan interpolasi entitas (ini adalah bagian yang menjawab pertanyaan spesifik Anda). Artikel ke-4 (segera hadir) akan membahas "hal-hal penembakan" :)

Jawaban Tim Holt cukup banyak. Artikel saya memiliki beberapa diagram yang dapat membantu Anda memahami apa yang terjadi, tetapi Tim dan saya pada dasarnya mengatakan hal yang sama.

Tidak masuk akal untuk melakukan prediksi penuh pada karakter Anda sendiri untuk responsif dan memiliki karakter lain tertinggal 100ms untuk konsistensi. Jika ini terlihat buruk maka pertimbangkan untuk sedikit lag karakter Anda sendiri agar tetap sinkron. Apa pun cara Anda masih akan membutuhkan mekanisme koreksi untuk memperlancar prediksi yang salah jika terjadi lonjakan lag, dan sistem itu akan menghadapi situasi seperti yang Anda gambarkan. Tidak masalah apakah latensi adalah 100 ms atau 1 ms - klien Anda selalu 'terlambat' dalam beberapa hal dan karena itu selalu harus bertindak seperti berurusan dengan data lama dan menerapkan efek kosmetik seperti interpolasi agar terlihat masuk akal.

Pada akhirnya ini semua berhubungan dengan sumber daya jaringan yang tersedia. Idealnya kita akan hidup di dunia dengan nol latensi dan semuanya dapat disinkronkan dengan sempurna. Secara realistis, Anda memperbarui klien setiap 100, 200, 300 ms dan pada klien harus ada logika untuk membuat apa yang terjadi terlihat lancar. "Kelancaran" sangat penting, pada akhirnya permainan hanya perlu terasa halus bahkan jika di bagian belakang ada beberapa sinkronisasi kacau terjadi antara klien dan server.

Pos yang bagus dan jawaban yang lebih baik dapat ditemukan:

Bagaimana cara menulis game jaringan?

Masalahnya sebenarnya bukan latensi. Itu bisa dikompensasi dan diprediksi cukup baik untuk menyembunyikan masalah yang disebabkannya. Paket loss juga bukan masalah - sistem jaringan harus ditulis agar kuat dan dapat ditoleransi untuk kehilangan paket. Namun, masalahnya adalah lonjakan lag dan latensi yang tidak dapat diprediksi. Paket yang tiba dari sinkronisasi, beberapa dari mereka dijatuhkan hanya karena ayunan latensi, ketidakmampuan untuk memprediksi dan menginterpolasi karena ayunan latensi dll.