Saya telah melakukan ini untuk game balap PSP komersial, yang bekerja baik melalui jaringan ad hoc, dan melalui hotspot nirkabel. (Atau ke server statis di Internet, jika diinginkan)
Karena poin 2 sistem tidak perlu menjadi kompleks berkaitan dengan optimasi
Dalam pengalaman saya, ini tidak benar. Perangkat nirkabel (terutama yang portabel kecil) tidak seperti komputer dengan koneksi jaringan kabel - smartphone dan konsol game nirkabel cenderung memiliki antarmuka jaringan yang lambat untuk tujuan permainan.
Jangan salah paham - throughput mereka biasanya baik (yaitu, jumlah data per detik; bagus untuk streaming film atau lain-lain), tetapi latensi pengiriman paket tertentu bisa sangat buruk, dan bisa jadi sangat bervariasi sehingga sulit untuk memperkirakan berapa lama setiap paket akan dikirimkan. Variasi ini menjadi lebih buruk karena lebih banyak perangkat nirkabel yang dikemas bersama dalam satu area umum, karena sinyalnya mulai saling mengganggu. Sebagai akibatnya, cukup banyak waktu saya dihabiskan untuk mengurangi jumlah paket yang perlu dikirim, jadi kami akan memiliki lebih sedikit tabrakan paket. (Perhatikan bahwa ini agak kurang masalah dalam kasus hotspot jaringan bertenaga yang terlibat, daripada meminta perangkat berbicara satu sama lain secara langsung melalui jaringan ad hoc)
Sebagai contoh optimasi semacam ini, game balap kami berlangsung di dunia yang memiliki lampu lalu lintas. Ribuan dari mereka. Dan kami perlu memastikan bahwa sinyal mereka selaras antara semua pemain dalam sesi jaringan. Alih-alih mencoba mengirim paket untuk memberi tahu semua orang yang lampu berada dalam keadaan apa, kami menetapkan jadwal statis untuk semua lampu lalu lintas, dan kemudian hanya memastikan bahwa semua klien menyetujui "waktu permainan" saat ini. Karena mereka semua tahu waktu permainan, dan semua status lampu lalu lintas dapat ditentukan dari waktu permainan, kami menyinkronkan semua data keadaan itu tanpa benar-benar mengirim data khusus apa pun. Perubahan ini membuat perbedaan besar untuk kinerja jaringan kami.
Apa yang dikatakannya, membangun sinkronisasi jam yang andal antara beberapa perangkat nirkabel (dengan waktu ping yang sangat bervariasi karena hilangnya paket) merupakan tantangan besar. Senang berbicara lebih banyak tentang itu jika Anda tertarik.
Setiap klien dapat menjadi sumber data otoritatif tentang dirinya dan lingkungan terdekatnya (misalnya peluru.)
Inilah yang kami lakukan, dan itu bekerja dengan baik untuk kami dalam situasi kami (mobil). Bagian yang bermasalah, tentu saja, adalah ketika sebuah objek berhenti menjadi lebih dekat dengan pemain 'a' daripada pemain 'b', dan kepemilikannya kemudian ditransfer dari satu pemain ke pemain lainnya.
Ini sebenarnya negosiasi yang sangat kompleks antara pemain, di mana permainan 'a' mengusulkan ke permainan 'b': "Saya pikir objek ini lebih dekat dengan Anda. Anda harus mengendalikannya." Dan kemudian permainan 'b' dapat menerima, atau mungkin menolak, berdasarkan pada pandangannya sendiri tentang situasi. Perbedaan dalam kondisi permainan yang dirasakan antara 'a' dan 'b', dan perubahan waktu antara saat permintaan dan respons dikirim dan diterima membuat ini merupakan negosiasi kecil yang tidak menyenangkan untuk menjadi andal, dan dapat dengan mudah berubah menjadi permainan "kentang panas", dengan kepemilikan benda memantul terus-menerus di antara banyak pemain. Dan bahkan ketika itu berfungsi dengan baik, jika dilihat dari sudut pandang permainan 'c', ada '
Intuisi saya adalah bahwa pendekatan "kepemilikan benda" semacam ini mungkin terlalu rumit untuk benda kecil yang berumur pendek seperti peluru. Kami menggunakannya untuk mobil lalu lintas dan pembalap AI, yang cenderung tinggal dalam simulasi untuk waktu yang relatif lama. Sepertinya pendekatan yang lebih berkinerja, jika Anda mau mempercayai klien, akan memiliki permainan masing-masing pemain memiliki posisi mereka dan proyektil mereka, dan menyatakan kapan pemain itu telah terkena oleh proyektil orang lain. (Jadi sebagai "game A", saya bertanggung jawab untuk mengatakan di mana proyektil pemain A dan pemain A berada, tetapi pemain B bertanggung jawab untuk mengatakan apakah saya telah menekan pemain B). Dengan beberapa perhitungan mati yang baik, Anda harus bisa mendapatkan perilaku yang cukup masuk akal dari sistem seperti ini.
