Putar ulang sistem: rekam input atau acara?


9

Saya membaca ini: Cara merancang sistem replay Tapi itu tidak benar-benar menjawab pertanyaan saya.

Gim saya dibuat dengan "tampilan" klien dari gim tersebut sebagai program terpisah dari "model" dan "pengontrol" server. (sedikit seperti mmo, atau game multipemain yang dibuat dengan cara ini). Sisi server selalu merupakan "kebenaran" dari gim, hanya menerima permintaan tindakan sebagai masukan dari klien dan acara keluaran dan pesan "keadaan saat ini".

Model dan aturan gim sepenuhnya deterministik dengan siklus pembaruan "centang" yang telah diperbaiki, sehingga di sisi server saya dapat merekam peristiwa yang dikirim ke tampilan klien, dan permintaan tindakan. Keduanya terkait dengan nomor siklus tertentu.

Pertanyaannya adalah: dalam hal ini, untuk mengatur sistem replay, haruskah saya menggunakan input, atau permintaan tindakan pengguna (seperti yang disarankan di sana) atau peristiwa?

Tampak bagi saya bahwa keduanya akan memberikan output yang persis sama. Satu-satunya perbedaan yang dapat saya lihat adalah:

  • Acara memberikan hasil nyata sementara permintaan tindakan harus diproses untuk memberikan acara.
  • Permintaan tindakan mungkin jauh lebih sedikit data untuk direkam.

Apakah ada hal lain yang perlu dipertimbangkan?

Jawaban:


5

Diberikan sistem deterministik, keduanya setara secara logis sehingga ringkasan Anda cukup benar. Namun ada 2 hal lagi yang akan mempengaruhi saya dalam merekam tindakan input daripada output event:

  1. Jika Anda menyimpan tindakan, Anda dapat menggunakannya sebagai data uji nanti, karena mereka menggunakan lebih banyak kode Anda daripada sekadar mengulangi peristiwa. Ini dapat membantu dengan mendiagnosis bug mogok, menemukan regresi perilaku antara build, dll.
  2. Di masa mendatang, Anda dapat mengubah acara yang Anda kirim untuk tindakan tertentu, atau Anda mungkin mengirim acara yang berbeda untuk klien yang berbeda karena alasan tertentu. Dalam hal ini, pemutaran ulang dapat menjadi tidak valid atau tidak lengkap. Masalah yang sama secara teori bisa berlaku untuk input, tetapi biasanya domain input lebih terbatas daripada output dan karena itu lebih kecil kemungkinannya untuk berubah dan lebih mudah mengakomodasi dengan kompatibilitas ke belakang ketika itu terjadi. (Input terbatas pada apa yang dapat dilakukan oleh pemain dan sumber input lainnya (mis. Generator angka acak), sedangkan output mencakup semua hasil input tersebut ditambah output lain yang dihasilkan oleh aturan permainan, seperti petunjuk presentasi, server berkala - acara sampingan, dll.)

Poin bagus, khususnya yang pertama. Saya lupa tentang penggunaan ini tetapi cukup membantu.
Klaim

Bingo, terutama di # 1. Jika saya punya waktu untuk membuat beberapa sistem perekaman input, saya akan dapat mencatat setiap tes, serta menangkap beberapa bug yang sulit direproduksi. Mampu memuat log "kasus langka" ini lagi membuatnya lebih mudah untuk menemukan bug saat Anda menelusuri kode Anda.
ChrisC

1

Keduanya berfungsi, meskipun ada beberapa hal yang perlu dipertimbangkan.

Pertama, ingatlah bahwa Anda perlu mencatat informasi waktu. Untuk game dengan segala jenis frame rate, ini bisa sangat rumit; Anda perlu memastikan data replay Anda dapat memberikan informasi waktu yang persis sama dengan game yang awalnya digunakan untuk simulasi.

Anda juga perlu memperhitungkan tweak untuk perilaku game. Jika Anda merekam input dan kemudian men - tweak apapun bagian dari bagaimana input ditangani, bagaimana fisika diselesaikan, dll, rekaman Anda menjadi tidak valid. Bahkan jika Anda merekam acara permainan, jika ada bagian dari bagaimana peristiwa itu ditafsirkan perubahan, Anda terjebak.

Jika Anda hanya ingin pemutaran, pendekatan yang baik adalah merekam daftar posisi dan rotasi tertentu untuk entitas pemain bersama dengan informasi waktu. Nonaktifkan sebanyak mungkin logika fisika dan gameplay lainnya saat menjalankan pemutaran sebanyak yang Anda bisa. Seberapa mudah atau layaknya ini tergantung pada berapa banyak objek lain yang perlu Anda selaraskan.


Dalam pertanyaan saya menentukan bahwa model permainan sepenuhnya deterministik. Tidak ada variasi fisika dan laju bingkai hanya terlihat di sisi klien, tidak dalam model permainan yang benar-benar tergantung pada "centang".
Klaim
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.