Mengapa beberapa game jaringan menggunakan interpolasi dan beberapa menggunakan pathfinding untuk pergerakan jarak jauh?

Ini sedikit pertanyaan terbuka tetapi saya ingin melihat seseorang berkontribusi alasan yang baik untuk keduanya.

Untuk contoh cepat keduanya:

Model Interpolasi

Pikirkan model Valve di mana klien sering menerima pembaruan posisi dan jarak jauh memperbarui posisi mereka menggunakan interpolasi pada data ini.

Menemukan jalan

Dalam model ini, anggap pengguna mengirim tujuan dan semua orang merintisnya.

Jenis permainan apa yang cocok untuk masing-masing dan kapan harus menggunakan masing-masing?

Saya telah bekerja pada kode jaringan untuk dua game jaringan AAA real time, satu untuk smartphone dan satu untuk konsol genggam.

Untuk langsung menjawab pertanyaan Anda "mengapa", well, beberapa gim menggunakan satu atau yang lain karena lebih cocok untuk mereka. Ini tergantung tidak hanya pada jenis permainan, tetapi juga pada jenis jaringan apa yang sedang kita bicarakan (kabinet arcade yang terhubung memiliki kondisi yang berbeda dibandingkan dengan game yang dimaksudkan untuk dimainkan melalui 3G) Beberapa game benar-benar menggunakan keduanya, atau bahkan sepenuhnya berbagai pendekatan untuk menyinkronkan data!

Saya ingin menggeneralisasi, dan mempertimbangkan tidak hanya data posisi, tetapi hampir semua jenis data yang dapat disinkronkan antara dua klien jaringan.

Alih-alih dua kemungkinan, saya ingin mengusulkan spektrum antara pembaruan sulit dan lunak.

• Pembaruan sangat sulit adalah peristiwa terpisah yang segera mengubah keadaan pada klien lain, tanpa jenis interpolasi apa pun, baik karena data bersifat kritis (pemain meninggal), karena itu bukan tipe data yang menerapkan interpolasi (online) permainan catur, pesan obrolan, dll.), atau karena jaringan Anda memungkinkan Anda untuk melakukan itu (pikirkan kabinet arcade yang terhubung di mana andal mengirim seluruh kondisi permainan 60 kali per detik berada dalam jangkauan kemungkinan).

  Dengan metode ini, penundaan jaringan akan selalu muncul sebagai pembaruan yang tertunda dan bermanifestasi sebagai karakter yang melompat-lompat.

• Sulit dengan pembaruan antar / ekstrapolasi mirip dengan pembaruan yang sangat sulit, tetapi untuk data yang terus berubah, yang secara praktis tidak mungkin mengirim data setiap kali ada perubahan. Pikirkan mengirim posisi dan vektor kecepatan; Anda harus dapat menginterpolasi data antara dua titik, dan memperkirakannya setelahnya. Anda harus memiliki rencana kontingensi jika data yang masuk tidak setuju dengan ekstrapolasi Anda. Saya akan mengatakan sebagian besar game yang membutuhkan pembaruan posisi menggunakan metode ini.

• Sulit dengan pembaruan sinkronisasi mirip dengan keras dengan inter / ekstrapolasi, tetapi jarang memerlukan sinkronisasi. Anda harus menggunakan ini untuk data yang benar-benar sepele untuk inter / ekstrapolasi, seperti jam dalam permainan pertempuran (sekali diatur di kedua sisi, tidak benar-benar perlu untuk melakukan sinkronisasi lagi setelah itu)

• Pembaruan sulit yang tertunda mirip dengan pembaruan yang sulit, tetapi yang Anda lihat adalah data di masa lalu. Saya menduga bahwa di banyak game arcade musik di Jepang di mana Anda dapat memutar lagu melawan orang lain, Anda sebenarnya bermain melawan data pemain yang direkam di masa lalu, mungkin beberapa jam atau bahkan beberapa hari sebelumnya. Tentu saja, jenis pembaruan ini hanya dapat digunakan ketika Anda tidak benar-benar berinteraksi dengan pemain lain.

• Pembaruan lunak terdiri dari pengiriman data perencanaan, dan menjalankan rencana pada semua host. Inilah yang Anda sebut "merintis jalan". Jumlah data yang diperlukan untuk menyinkronkan data seperti ini jauh lebih rendah; Anda dapat menggunakan jenis pembaruan ini ketika Anda bisa lolos dengan perbedaan tertentu dalam cara data disajikan kepada pengguna, seperti saat menyinkronkan ratusan musuh.

  Merencanakan pembaruan data sendiri juga bisa sekeras yang Anda inginkan, tentu saja.

• Pembaruan sangat lunak digunakan ketika hasil suatu tindakan dapat dihitung dengan andal jauh sebelum itu terjadi. Anda hanya mengirim hasilnya, dan klien lain hanya memainkannya kembali. Sebagai contoh, beberapa game browser dan smartphone memungkinkan Anda bertarung dengan orang lain, tetapi pertempuran sebenarnya membutuhkan waktu berjam-jam untuk diselesaikan (pikirkan game yang mirip Travian). Sangat mungkin bahwa game-game ini menghitung hasil pada saat pertempuran dimulai, dan Anda hanya melihat hasil pertempuran itu.

  Contoh non-jaringan lain dari ini adalah Peradaban 4 dengan animasi pertempuran diaktifkan. Ketika Anda menyerang seseorang, hasil pertempuran segera dihitung, tetapi Anda bisa melihat animasi yang diputar ulang. Saya dapat meyakinkan Anda bahwa pertempuran tidak dihitung karena sedang dianimasikan.

Seperti yang Anda lihat, ada banyak cara untuk menyinkronkan data, dan saya yakin Anda bisa membayangkan banyak hal lain. Semua kecuali permainan online yang paling sederhana kemungkinan besar akan menggunakan campuran metode ini, tergantung pada jenis data yang disinkronkan, jenis permainan, dan bahkan keadaan jaringan (menggunakan pembaruan yang sulit ketika jeda rendah, dan pergi untuk pembaruan yang lebih lunak ketika jeda semakin tinggi).

Saya tidak memiliki wawasan tentang proses pengembangan Valve, jadi ini murni pendapat saya, tetapi:

Interpolasi : Saya akan mengatakan itu akan lebih baik untuk permainan serba cepat, seperti FPS misalnya, di mana memiliki posisi yang konsisten untuk musuh tepat waktu di seluruh pemain adalah penting. Interpolasi berarti bahwa, bahkan jika beberapa paket dijatuhkan (AFAIK, sebagian besar FPS multiplay menggunakan UDP alih-alih TCP / IP, yang tidak menjamin integritas maupun urutan paket-paket itu tiba), Anda akan memiliki pergerakan yang mulus di layar.

pencarian jalur : Jika waktu bukan elemen penting dari gameplay Anda, dan algoritme Anda menemukan jalur yang konsisten saat dijalankan kembali, penelusuran jalan bisa menjadi menarik karena tidak mengharuskan Anda mengirim frekuensi, dan dengan demikian pembaruan yang berat dengan posisi masing-masing kesatuan. Saya akan mengatakan ini tampaknya cocok untuk sistem berbasis giliran misalnya, di mana Anda kemudian dapat membatasi jumlah permintaan jaringan (satu di awal pergantian, satu ketika pergantian berakhir untuk memastikan semua klien dalam keadaan "waras") "negara.

Sekali lagi, saya tidak pernah bekerja di game jaringan atau untuk studio game besar, tetapi dari apa yang saya baca kadang-kadang begitulah cara saya melakukannya :)

Jawaban Panda Piyama cukup bagus.

Pada dasarnya pertanyaannya adalah berapa jumlah minimal data yang dapat Anda kirim yang akan menempatkan banyak klien dalam kesadaran yang sama satu sama lain, dan bagaimana Anda menangani jeda di mana selama jeda klien itu berada dalam keadaan yang berbeda.

Jadi dihasilkan secara prosedural, di mana semua interaksi diketahui sebelumnya paling mudah, karena jika semua variabel diketahui maka hasilnya diketahui. Misalnya mengisolasi seseorang di ruangan, yang Anda tahu metode pengolahan, dan memberinya beberapa set data, Anda dapat memprediksi hasilnya secara akurat. Karenanya, Anda dapat memberikan hasil kepada setiap klien lainnya tanpa harus menunggu klien itu menyelesaikan perhitungannya.

Namun dia tidak menyebutkan satu metode. Hasil paksa.

Jika sistem mengharapkan suatu tindakan oleh beberapa entitas, dan tindakan lain bergantung pada tindakan itu, dan perhitungan lain memperhitungkan tindakan itu, dan telah diproses sebelumnya dengan hasil yang diharapkan. Kemudian untuk menjaga sinkronisasi, seluruh sistem dihentikan sementara satu entitas yang tidak berada di tempat yang tepat dimasukkan kembali ke jalurnya.

Contoh dunia nyata adalah semua entitas lain dalam pola holding untuk memastikan kompensasi yang tepat dikirimkan kepada saya.