Jaringan Pong Clone

Saya memiliki dasar-dasar soket TCP, komunikasi UDP dll, tetapi tidak dapat menemukan banyak tentang cara menerapkannya ke lingkungan permainan waktu nyata.

Saya memiliki klon Pong, dengan 4 pemain, dan perlu menyinkronkan posisi dayung antara tiga klien dan server (server adalah pemain keempat). Saat ini saya menggunakan UDP untuk mengirim pembaruan waktu nyata (gerakan mendayung), dan TCP untuk mengatur lobi permainan dll.

Apakah ini BURUK HAL untuk mengirim spam dalam jumlah besar dari lalu lintas UDP? Haruskah saya melihat sesuatu seperti DCCP untuk fitur kemacetannya? Atau apakah ini bukan masalah dengan proyek skala kecil seperti ini?

Kapan pesan sinkronisasi harus dikirim antara klien / server? Saat ini server mengirimkan spam paket UDP dengan status permainan saat ini secepat yang dapat dikelola, dan klien mengirim spam pada posisi dayung mereka kembali ke server secepat mungkin. Apakah ini cara terbaik untuk melakukannya? Apakah ada semacam penundaan yang harus saya tambahkan sehingga pesan dikirim sekali setiap X milidetik, atau haruskah saya hanya mengirimkan pesan saat peristiwa terjadi? (mis., kecepatan dayung berubah karena input pengguna)

Akankah lebih baik untuk membuat klien mengomunikasikan posisi dayung mereka satu sama lain peer to peer?

Saya mengajukan pertanyaan-pertanyaan ini dalam konteks Pong tetapi saya juga tertarik pada bagaimana masalah ini akan diatasi dalam permainan lain, atau solusi umum.

Memiliki interval pembaruan yang dapat dikonfigurasi (sehingga Anda dapat men-tweak dan mencoba 5 paket per detik atau 20), dan setiap frame melihat apakah sudah waktunya mengirim pembaruan. Anda mungkin tidak masalah dengan permainan sederhana yang mengirim paket untuk setiap acara, tetapi dalam permainan yang lebih kompleks ini tidak praktis. Juga perlu diingat bahwa ada overhead paket jadi jika Anda mengirim banyak paket kecil Anda akan membuang-buang bandwidth.

Setiap interval pembaruan meminta setiap klien mengirimkan posisi dayungnya ke server, atau ke setiap klien (peer-peer). Suruh server juga mengirim posisi bola dan vektor kecepatan. Setiap klien dapat menjalankan kode menggambar layar yang sama seperti yang dilakukan dalam pemain tunggal sehingga pergerakan bola akan lancar. Di multiplayer, Anda hanya memiliki server yang mengirim pembaruan posisi / kecepatan untuk bola secara berkala (dan jika Anda suka setiap kali itu mengenai sesuatu).

Buat pembaruan posisi bola referensi gametime di semua klien sehingga Anda dapat membuang paket pesanan dan bahkan membuat interpolasi posisi bola lebih akurat (Anda tahu posisi dan kecepatan pada waktu tertentu di masa lalu sehingga Anda dapat menginterpolasi yang baru posisi).

Dengan model ini dengan permainan laggy Anda mungkin melihat bola bergerak mundur kadang-kadang atau melompat-lompat sedikit. Tetapi dengan koneksi yang layak seharusnya cukup lancar.

Mengenai masalah lalu lintas - Anda ingin menghindari pengiriman lebih dari 20-30 paket per detik per rekan. Dalam kasus umum, jika Anda mengirim paket yang lebih kecil, lebih sedikit, Anda akan mengalami (sedikit) lebih sedikit latensi dan kemungkinan berkurangnya paket yang jatuh.

Anda tentu tidak ingin mengirim pembaruan dengan kecepatan lebih cepat daripada framerate, karena pemain tidak akan dapat membedakannya - memang, jika Anda hanya mengirim paket 10 kali per detik dan menginterpolasi / memperkirakan hasil pada sisi penerima , sebagian besar pemain tidak akan melihat perbedaan.

Ini adalah pertanyaan yang cukup luas, tetapi saya akan mencoba merangkum aspek-aspek penting.

Keputusan pertama yang dibuat dalam kode jaringan untuk gim Anda adalah apakah Anda menginginkan pengaturan klien / server dari pengaturan peer to peer. Sebagian besar game, dengan RTS mungkin menjadi satu-satunya pengecualian yang terkenal, mungkin menggunakan arsitektur klien / server. Keuntungan utama adalah bahwa pengaturan ini lebih toleran terhadap kesalahan dan memberikan lebih banyak kontrol atas data apa yang diterima setiap klien. Peer to peer memungkinkan untuk mengirim data yang jauh lebih sedikit, tetapi mengharuskan masing-masing peer untuk sepenuhnya mensimulasikan dunia persis seperti yang dilakukan peer lainnya. Jika satu rekan tertinggal atau tidak sinkron, semua orang harus menunggu mereka pulih atau mereka hilang begitu saja.

UDP umumnya merupakan pilihan yang tepat juga, tentu saja untuk setiap model klien / server. TCP mungkin praktis untuk permainan peer to peer, tetapi meskipun demikian UDP mungkin merupakan pilihan yang lebih baik. Pada dasarnya, UDP menangani lebih sedikit untuk Anda, yang berarti lebih banyak upaya tetapi juga lebih banyak kontrol atas bagaimana Anda menangani kesalahan.

Untuk Pong pilihan yang akan saya buat adalah klien / server, karena itu adalah permainan berorientasi aksi. Satu hal yang perlu diperhatikan di sini, meskipun Anda mengatakan bahwa satu pemain "adalah server", Anda sebaiknya menyusun kode Anda sehingga mereka pada dasarnya menjalankan server lokal dan menghubungkannya sebagai klien.

Anda pasti tidak ingin menjadi "spam" pembaruan di arah manapun juga. Satu pembaruan dari server per frame adalah semua yang diperlukan, dan server Anda harus berjalan pada kecepatan bingkai tetap. Apa yang terserah Anda, tetapi tidak perlu berlebihan. Bingkai 50ms (20 FPS) banyak untuk mendapatkan permainan yang bagus dan lancar. Agar semuanya lancar pada klien, Anda ingin memanfaatkan interpolasi. Klien harus terus-menerus melakukan transisi antara snapshot bingkai server, ini bisa dengan mudah menjadi topik pertanyaan terpisah.

Pembaruan klien juga harus dibatasi, meskipun satu per frame kemungkinan akan terlalu banyak jika klien Anda berjalan pada frame rate yang layak.

Apakah kamu peduli tentang selingkuh?

Jika tidak, melakukan peer-to-peer akan membagi dua lag Anda, karena A <-> C bukan A <-> B <-> C. Jika demikian, untuk keadilan dalam sinkronisasi, Anda mungkin ingin membuat respons agak lamban untuk pemain lokal, atau apa yang dilakukan sebagian besar permainan - biarkan pemain melakukan apa pun secara lokal lalu snap kembali jika hasil server berbeda dari simulasi yang disimulasikan secara lokal.

Klon pong sebenarnya agak sulit, karena tidak seperti kebanyakan game Anda tidak bisa (sebagai pengembang) menipu dengan membuat satu sisi melihat hit dan yang lainnya tidak.

Adapun sesuatu yang digeneralisasi, salah satu teknik yang pernah saya dengar tetapi belum merasa perlu (mungkin untuk game aksi) adalah menjaga aksi dengan stempel waktu yang sebenarnya (menerima waktu - ping / 2), dan membuat server memutar kembali ( jepret) jika acara sebelumnya muncul, dan kemudian mengajukan kembali tindakan selanjutnya. Dengan begitu, semua orang konsisten secara lokal kecuali ada konflik karena interaksi pemain yang berbeda. Satu-satunya bahaya adalah kemampuan untuk 'memutar kembali waktu' jika mereka memalsukan koneksi yang lamban.

Perhitungan mati Google. Mengirim pembaruan untuk 4 pemain tidak akan berarti. Jumlah data yang dikirim akan berada di urutan byte. Jadi, itu berarti pembaruan yang sering harus ok. Dengan perhitungan mati, Anda memindahkan pemain pada klien dan server. Server adalah otoritas. Ketika posisi klien menjadi terlalu jauh dari sinkronisasi dari server, itu harus melayang kembali ke penyelarasan. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Menggunakan UDP adalah caranya. Bupdates akan sering dikirim ke data yang hilang akan segera digantikan oleh data yang masuk. Paket ulang TCP tidak layak untuk posisi pemain. Lihat artikel ini untuk info lebih lanjut tentang cara menjaga klien dan server tetap selaras.

Saya telah memprogram permainan 2 pemain-jaringan-lokal-pong beberapa minggu yang lalu, inilah cara saya melakukannya:

-Satu sisi membuka server, yang lain terhubung secara otomatis -mereka mengayunkan dayung x posisi mereka satu sama lain @ 60fps atau kurang [UDP] -Jika satu sisi memukul bola mereka memutuskan tentang bola kecepatan baru dan posisi dan mengirim itu ke yang lain [TCP] -jika bola terbang melewati dayung, pemain yang melewatkannya menghubungi yang lain dengan pesan skor peningkatan dan bola disetel ulang [TCP] -b bola disimulasikan secara independen sepanjang waktu, yang sesuai dengan fisika bola sederhana pong

Ini menciptakan sekitar 0,3 hingga 0,5 KByte / detik lalu lintas pada 60fps dan para pemain tidak memiliki lag dalam persepsi mereka, tetapi hanya jika ping di bawah ambang tertentu, karena bola posisi baru perlu ditransmisikan.

Juga curang itu mudah dengan sistem ini dan ada kemungkinan besar untuk tidak sinkron dengan koneksi yang sangat lossy, tapi siapa yang peduli soal curang di pong ?!