Kode Jaringan Age of Empires: 1.500 pemanah per modem 28,8 kbps

Catatan penerjemah: artikel ini sudah berusia 17 tahun, dan menarik hanya dari sudut pandang historis. Sangat menarik untuk mempelajari bagaimana para pengembang berhasil mencapai permainan online yang lancar di era modem 28.8k dan Pentium pertama.

Artikel ini berbicara tentang arsitektur dan implementasi, serta beberapa pelajaran yang didapat dari membuat kode multi-pengguna (jaringan) untuk game Age of Empires 1 dan 2 . Itu juga menguraikan pendekatan arsitektur jaringan saat ini dan masa depan yang digunakan oleh Ensemble Studios di mesin permainan mereka.

Multiplayer Age of Empires: persyaratan struktur

Pada awal bekerja pada kode multi-pemain Age of Empires pada tahun 1996, kami menetapkan diri kami tujuan yang sangat spesifik yang diperlukan untuk penerapan gameplay yang diperlukan.

• Pertempuran skala besar dan epik dalam sejarah dengan banyak unit militer yang berbeda
• Mendukung hingga 8 pemain dalam mode multi-pemain
• Simulasi permainan yang lancar melalui LAN, melalui koneksi modem langsung dan melalui Internet
• Dukungan platform target: Pentium 90 dengan RAM 16 MB dan modem 28,8 kbps
• Sistem komunikasi harus bekerja dengan mesin yang ada (Genie)
• Stabil 15 frame per detik pada mesin dengan konfigurasi minimal

Mesin Genie sudah siap, dan gameplay dalam mode single-user mulai mengambil bentuknya. Mesin Genie adalah mesin loop game single-threaded dua dimensi. Sprite diberikan dalam 256 warna dalam dunia yang dikomposisi ubin. Peta yang dihasilkan secara acak diisi dengan ribuan objek: dari pohon yang dapat ditebang hingga rusa yang berlari kencang. Perkiraan rincian (setelah optimasi) waktu untuk melakukan tugas engine: 30% untuk rendering grafik, 30% untuk AI dan jalur pencarian, 30% untuk melakukan simulasi dan tugas resmi.

Sudah pada tahap yang cukup awal, mesinnya relatif stabil, dan komunikasi multi-pengguna harus bekerja dengan kode yang sudah jadi tanpa perlu perubahan signifikan dalam arsitektur (kerja) yang ada.

Untuk menyulitkan tugas, waktu yang dibutuhkan untuk menyelesaikan setiap langkah simulasi bisa sangat bervariasi: waktu rendering tergantung pada apakah pengguna menonton unit, menggulir atau melihat area yang belum dijelajahi, dan jalur panjang atau perencanaan strategis AI secara signifikan mempengaruhi waktu eksekusi pergerakan game. : osilasi hingga 200 ms.

Perhitungan singkat menunjukkan bahwa transfer bahkan set kecil data tentang unit dan upaya untuk memperbaruinya secara real time sangat membatasi jumlah unit dan objek yang dengannya pemain dapat berinteraksi. Jika Anda hanya mentransfer koordinat X dan Y, status, aksi, arah tampilan dan kerusakan, maka dalam permainan tidak boleh lebih dari 250 unit ponsel.

Kami ingin para pemain dapat menghancurkan kota-kota Yunani dengan ketapel, pemanah, dan prajurit, sementara pada saat yang sama mengepung pengepungan dengan triremes dari laut. Jelas, kami membutuhkan beberapa pendekatan lain.

Simulasi simultan

Alih-alih mentransmisikan keadaan masing-masing unit permainan, kami ingin melakukan simulasi yang benar-benar identik pada setiap mesin, melewati masing-masing set perintah yang sama yang diberikan oleh para pemain pada waktu yang sama. Komputer para pemain, pada dasarnya, harus menyinkronkan gameplay dalam tradisi terbaik dari film perang, memungkinkan pemain untuk mengeluarkan perintah, dan kemudian mengeksekusi mereka dengan cara yang sama dan pada saat yang sama, memastikan identitas permainan.

Awalnya, sinkronisasi yang rumit seperti itu sulit untuk diimplementasikan, tetapi sebagai hasilnya, ini membawa keuntungan yang tidak terduga di bidang lain.

Peningkatan model dasar

Pada tingkat konseptual yang paling sederhana, menerapkan simulasi simultan tampak sangat mudah. Dalam beberapa game yang menggunakan simulasi dengan langkah tetap (kunci-langkah) dan timing konstan, bahkan bisa sangat mungkin.

Karena dengan pendekatan ini, ia harus bertanggung jawab untuk memindahkan ratusan atau ribuan objek secara bersamaan, sistem harus tetap dapat bertahan bahkan dengan fluktuasi keterlambatan 20 hingga 1000 milidetik dan berhasil memproses perubahan selama pemrosesan bingkai.

Mengirim perintah pemain, mengonfirmasi semua pesan dan kemudian memprosesnya sebelum pindah ke langkah berikutnya akan menjadi mimpi buruk dari sudut pandang proses permainan, dengan menunggu terus-menerus dan pertukaran tim yang lambat. Kami membutuhkan skema yang dapat melanjutkan pemrosesan game secara paralel dengan latar belakang menunggu selesainya proses pertukaran data.

Tandai [Terrano] menggunakan sistem untuk menandai perintah yang harus dieksekusi melalui dua "gerakan pertukaran data" di masa depan (gerakan pertukaran data di AoE dipisahkan dari kerangka rendering sendiri).

Artinya, perintah yang diberikan selama kursus 1000 ditugaskan untuk dieksekusi selama kursus 1002 (lihat Gambar 1). Selama 1001, perintah yang diberikan selama 0999 dieksekusi. Ini memungkinkan kami untuk menerima, mengkonfirmasi, dan menyiapkan pesan untuk diproses, sementara permainan terus menggambar animasi dan melakukan simulasi.


Gambar 1. Markup perintah yang akan dieksekusi melalui dua "gerakan pertukaran data".

Biasanya gerakan membutuhkan waktu 200 ms, dan tim dikirim selama giliran ini. Setelah 200 ms, langkah itu berhenti dan langkah baru dimulai. Pada setiap saat pertandingan, tim diproses dalam satu langkah, diterima dan disimpan untuk langkah berikutnya, dan kemudian dikirim untuk dieksekusi dua langkah kemudian.

"Kontrol kecepatan"

Gambar 2. Kontrol kecepatan.

Karena simulasi harus selalu memiliki input yang persis sama, sebuah gim dapat berjalan tidak lebih cepat dari mesin paling lambat yang mengatur proses pertukaran data, membuat gerakan dan mengirim perintah baru. Kami menyebut sistem yang mengubah durasi goresan untuk mempertahankan animasi dan permainan yang lancar dalam kondisi penundaan pertukaran data variabel dan kecepatan pemrosesan "Kontrol Kecepatan".

Gameplay dapat dirasakan "pengereman" karena dua alasan: jika frame rate satu mesin jatuh (atau lebih rendah dari yang lain), maka mesin lain memproses perintah mereka, memberikan semuanya pada waktu yang ditentukan dan sebagai akibatnya mereka harus menunggu langkah selanjutnya. Dalam hal ini, jeda apa pun segera terlihat. Selain itu, permainan diperlambat oleh keterlambatan pertukaran data - pemain harus menunggu sampai mesin menerima data yang cukup untuk menyelesaikan gerakan.

Setiap klien menghitung frame rate yang dianggap dapat secara konstan dicapai, yang dihitung dengan rata-rata waktu pemrosesan beberapa frame. Karena nilai ini berubah selama permainan tergantung pada ruang lingkup, jumlah unit, ukuran peta, dan faktor lainnya, nilai itu ditransmisikan dalam setiap pesan tentang penyelesaian langkah.

Selain itu, setiap klien juga mengukur "waktu ping" dari dirinya sendiri ke klien lain dan sebaliknya. Dia juga mengirim ping rata-rata ke klien terpanjang dalam pesan tentang penyelesaian langkah (total, 2 byte digunakan untuk mengontrol kecepatan).

Dalam setiap gerakan, mesin yang ditunjuk oleh tuan rumah menganalisis pesan penyelesaian, menghitung laju bingkai yang diperlukan dan koreksi untuk keterlambatan pengiriman data melalui Internet. Kemudian tuan rumah mengirim frame rate baru dan durasi pertukaran data. Gambar 3-5 menunjukkan bagaimana aliran pertukaran data dipecah dalam kondisi yang berbeda.


Gambar 3. Alur pertukaran data umum.


Gambar 4. Transmisi data latensi tinggi melalui Internet pada kecepatan mesin normal.


Gambar 5. Kecepatan mesin rendah dengan penundaan transfer data normal.

"Kemajuan pertukaran data", yang kira-kira sama dengan waktu ping untuk perjalanan pulang pergi untuk pesan, dibagi dengan jumlah kerangka simulasi yang dapat diselesaikan oleh mesin paling lambat rata-rata selama waktu ini.

Durasi pertukaran data tertimbang, sehingga dapat dengan cepat meningkat sesuai dengan perubahan latensi pengiriman data melalui Internet dan perlahan-lahan menurun ke kecepatan rata-rata terbaik yang dapat terus dipertahankan. Biasanya permainan melambat dan melambat hanya pada saat-saat puncak terburuk - penundaan transmisi perintah meningkat, tetapi tetap mulus (dan hanya meningkat beberapa milidetik per belokan), karena permainan secara bertahap mengurangi penundaan ke kecepatan terbaik. Ini menciptakan kehalusan gameplay sebaik mungkin, sementara pada saat yang sama memberikan penyesuaian terhadap kondisi yang berubah.

Pengiriman terjamin

UDP digunakan di lapisan jaringan, dan setiap klien terlibat dalam pemesanan perintah, pengakuan kehilangan, dan pengiriman ulang. Setiap pesan menggunakan sepasang byte, yang menunjukkan arah pelaksanaan eksekusi perintah, dan nomor seri pesan. Jika pesan diterima setelah pindah, itu ditolak, dan pesan masuk disimpan untuk dieksekusi. Karena sifat UDP, Mark menggunakan prinsip berikut saat menerima pesan: "Jika ragu, Anda harus mempertimbangkan pesan yang hilang. Jika pesan diterima rusak, penerima segera mengirim permintaan untuk pengiriman kembali pesan yang hilang. Jika konfirmasi penerimaan diterima lebih lambat dari perkiraan waktu, pengirim cukup mengirim pesan lagi, tanpa menunggu sinyal tentang kehilangannya. "

Manfaat tersembunyi

Karena hasil yang dihitung oleh permainan bergantung pada semua pengguna yang melakukan simulasi identik, itu sangat sulit bagi klien (atau aliran data klien) untuk meretas dan menipu. Simulasi apa pun yang dilakukan secara berbeda ditandai sebagai "tidak sinkron" dan permainan berhenti. Masih mungkin untuk menipu secara lokal untuk pengungkapan informasi, tetapi kebocoran seperti itu relatif mudah diperbaiki dalam tambalan dan revisi berikutnya. Keamanan telah menjadi kemenangan terbesar kami.

Masalah tersembunyi

Pada awalnya, mungkin tampak bahwa eksekusi yang sama dari dua contoh kode yang sama mudah diimplementasikan, tetapi tidak. Pada tahap awal proyek, Manajer Produk Microsoft Tim Znamenachek mengatakan kepada Mark: "Setiap proyek memiliki satu bug persisten yang tidak menyerah sampai selesai. Saya pikir dalam kasus kami itu akan tidak sinkron. " Dan dia benar. Kesulitan menemukan kesalahan sinkronisasi dikalikan dengan setiap perubahan kecil. Rusa, yang posisinya sedikit berbeda saat membuat peta acak, akan bergerak sedikit berbeda, dan beberapa menit kemudian pemburu akan bergerak sedikit keluar dari jalan atau kehilangan tombak, sebagai akibat dari pulang tanpa daging. Oleh karena itu, apa yang kadang-kadang tampak hanya perbedaan dalam jumlah makanan yang ada memiliki alasan yang sangat sulit dilacak.

Meskipun kami memeriksa dunia, objek, mencari jalur, membidik, dan semua sistem lain dengan checksum, selalu ada sesuatu yang tidak dapat kami perhitungkan. Volume pelacakan pesan dan dump objek dunia yang besar (masing-masing 50 MB) membuat masalahnya semakin rumit. Sebagian dari kesulitannya adalah konseptual - programmer tidak terbiasa menulis kode yang menggunakan jumlah panggilan generator nomor acak yang sama dalam simulasi (ya, nomor acak juga dihasilkan dan disinkronkan).

Pelajaran yang dipetik

Saat mengembangkan bagian jaringan Age of Empires, kami menerima beberapa pelajaran yang dapat diterapkan pada pengembangan sistem multi-pengguna game apa pun.

Pelajari pengguna Anda. Mempelajari pengguna adalah langkah paling penting dalam memahami harapannya mengenai kecepatan multipemain, rem yang dirasakan, dan keterlambatan dalam mengirimkan perintah. Setiap genre bersifat individual, dan Anda perlu memahami apa yang sesuai dengan gaya permainan dan manajemen Anda.

Pada tahap awal proses pengembangan, Mark dan desainer utama menunda penundaan pertukaran data (prototipe ini direvisi beberapa kali selama proses pengembangan). Karena mereka memainkan permainan pemain tunggal, sangat mudah untuk mensimulasikan berbagai tingkat keterlambatan transfer tim dan mendapatkan umpan balik pemain ("kontrol tampaknya baik / lambat / berkedut / hanya mengerikan").

Untuk game dengan genre RTS, keterlambatan pengiriman perintah 250 milidetik bahkan tidak terlihat, pada 250-500 ms gameplaynya cukup dapat dimainkan, dan remnya menjadi terlihat pada 500 ms dan lebih tinggi. Menarik juga untuk dicatat bahwa pemain terbiasa dengan "kecepatan permainan" dan harapan mental akan penundaan antara klik mouse dan reaksi unit. Respons tertunda yang konstan lebih baik daripada lompatan dalam keterlambatan transmisi perintah (misalnya, dari 80 hingga 500 ms) - dalam kasus ini, keterlambatan konstan 500 ms dianggap dapat dimainkan, dan yang dapat diubah tampak "gelisah" dan menyulitkan permainan.

Programer ini dipaksa untuk mengarahkan upaya mereka untuk memastikan kelancaran - lebih baik untuk memilih durasi stroke yang lebih lama dan memastikan bahwa semuanya akan lancar dan konstan daripada melakukan operasi secepat mungkin, dihadapkan dengan perlambatan teratur. Semua perubahan kecepatan harus bertahap, dan tingkat pertumbuhan harus sekecil mungkin.

Kami juga mengukur kebutuhan pengguna untuk sistem - biasanya mereka memberi perintah (bergerak, menyerang, memotong pohon) kira-kira setiap satu setengah hingga dua detik, kadang-kadang dengan puncak 3-4 tim per detik selama pertempuran sengit. Karena aksi aktif dalam game kami terus berkembang, persyaratan tertinggi untuk pertukaran data muncul di tengah dan menjelang akhir game.

Jika Anda meluangkan waktu untuk mempelajari perilaku pengguna, Anda akan melihat fitur-fitur lain tentang cara mereka bermain, dan ini akan membantu dalam menyiapkan permainan jaringan. Di AoE selama serangan, pengguna dengan cepat mengklik mouse (klik-klik-klik-klik - maju-maju-maju-maju!), Yang menyebabkan puncak besar dalam jumlah perintah yang dikeluarkan. Selain itu, mereka mengirim kelompok besar unit yang perlu membuka jalan - juga puncak besar dalam persyaratan untuk transmisi data melalui jaringan. Filter sederhana, memotong perintah berulang pada satu titik, secara signifikan mengurangi dampak negatif dari perilaku ini.

Secara umum, pengguna pemantauan akan memungkinkan Anda untuk:

• Cari tahu harapan pengguna tentang penundaan game
• Aspek multi-pemain prototipe pada tahap awal pengembangan
• Lihat perilaku yang merugikan kecepatan mode multi-pengguna.

Pengukuran adalah hal yang paling penting. Jika Anda memperkenalkan metrik pada tahap awal pekerjaan, maka Anda akan mempelajari hal-hal menakjubkan tentang sistem pertukaran data Anda. Jadikan metrik dapat dibaca oleh penguji dan gunakan untuk memahami apa yang terjadi di dalam mesin jaringan.

Pelajaran: Bagian dari masalah pertukaran data di AoE muncul ketika Markus menyimpulkan metrik terlalu dini, dan tidak memeriksa lagi tingkat pesan (panjang dan frekuensi) setelah menyiapkan kode akhir. Hal-hal yang tidak terduga seperti balapan acak antara AI, jalur yang sulit dihitung, dan paket perintah yang tidak terstruktur dapat menyebabkan masalah kinerja yang sangat besar, bahkan ketika sistem bekerja dengan baik.

Buat sistem memberitahukan penguji dan pengembang tentang apa yang tampaknya merupakan kondisi batas yang berlebihan - pemrogram dan penguji akan melihat dalam proses pengembangan tugas yang memuat sistem; ini akan memecahkan masalah pada tahap awal kemunculannya.

Luangkan waktu untuk menjelaskan kepada penguji bagaimana sistem pertukaran data bekerja, tunjukkan dan jelaskan metrik kepada mereka - Anda mungkin terkejut bahwa mereka akan memperhatikan ketika kegagalan aneh terjadi dalam kode jaringan.

Secara umum, metrik harus memiliki properti berikut:

• Jadilah manusia yang mudah dibaca dan dimengerti oleh penguji
• Tunjukkan kemacetan, rem, dan masalah
• Dampak kecil pada eksekusi dan terus diluncurkan.

Pelatihan pengembang. Sangat sulit untuk mengajar programmer yang terbiasa membuat aplikasi pengguna tunggal untuk memikirkan pemisahan antara memberi, menerima dan memproses perintah. Sangat mudah untuk melupakan bahwa Anda dapat meminta sesuatu yang tidak terjadi, atau apa yang bisa terjadi beberapa detik setelah perintah itu dikeluarkan. Perintah harus diperiksa kebenarannya saat mengirim dan setelah menerima.

Dalam model sinkron, programmer juga harus mempertimbangkan bahwa di dalam simulasi, kode tidak boleh bergantung pada faktor lokal (seperti ketersediaan waktu luang, peralatan khusus, atau pengaturan yang berbeda). Eksekusi kode pada semua mesin harus cocok. Misalnya, keberadaan bunyi medan acak dalam simulasi dapat menyebabkan perilaku permainan yang berbeda.

Pelajaran lainnya. Ini seharusnya menjadi akal sehat yang biasa - tetapi jika Anda bergantung pada jaringan pihak ketiga (dalam kasus kami, ini adalah DirectPlay), kemudian tulis aplikasi pengujian independen yang mengonfirmasikan bahwa ketika pemilik mengklaim "pengiriman terjamin", pesan benar-benar mendapatkan "pesanan paket dijamin" sebenarnya ada, dan bahwa produk tidak memiliki hambatan tersembunyi atau perilaku aneh saat memproses data yang dikirimkan dalam game Anda.

Bersiaplah untuk membuat aplikasi simulasi dan simulator uji stres. Pada akhirnya, kami menciptakan tiga aplikasi tes minimal yang berbeda yang digunakan untuk mempelajari masalah individual dan penting: banjir koneksi, masalah dengan koneksi simultan saat memilih lawan, dan kehilangan paket yang dijamin.

Uji dengan modem (dan, jika beruntung, dengan simulator modem) sedini mungkin; Lanjutkan pengujian modem (betapapun menyakitkannya) selama proses pengembangan. ( — , , , , - ?), dialup-, LAN. , LAN.

Age of Empires 2

Age of Empires 2: The Age of Kings , , The Zone. , DirectPlay , , Age of Empires .

, , «» . -. , , . . , , , .

() The Zone Age of Empires . Age of Kings , . , , , . . The Zone , . - The Zone.

RTS3:

RTS3 — Ensemble (. .: Age of Mythology) . RTS3 , Age of Empires, .

• Age of Empires 1 2 . , , , .
• 3D: RTS3 — .
• — .
• TCP/IP: — - TCP/IP 56 /.
• — , NAT.

RTS3 , Age of Empires 1 2 — — RTS3 . AOE/AOK DirectPlay, RTS3 , .

, . , , . Genie , — BANG! , .

Age of Kings , , . , , .

RTS3

6. - RTS3.

- . RTS3 - (. 6). -, , , .

. . , (, , -). ( Channels, TimeSync ..) , .

. Genie peer-to-peer, «». RTS3 , .

«» ( 7). . Age 1 2 .


7. «» .

Peer-to-peer:

• «-» «--».
• Tidak ada tautan lemah pusat - jika klien (bahkan tuan rumah) terputus dari sesi, permainan dapat dilanjutkan.

Kerugian peer-to-peer:

• Lebih banyak senyawa aktif dalam sistem (jumlah dari n = 0 hingga k-1 (n)), yaitu, lebih banyak mata rantai potensial dan kemungkinan penundaan yang lebih tinggi.
• Ketidakmampuan untuk mendukung beberapa konfigurasi NAT dalam skema semacam itu.

Net.lib. RTS3 , , , , . , , , , , .


Gambar 8. Empat lapisan layanan dalam model jaringan kami.

RTS3 didasarkan pada mesin BANG kami! generasi baru yang menggunakan arsitektur modular dengan pustaka komponen seperti suara, rendering, dan jaringan. Subsistem jaringan terintegrasi di sini sebagai komponen, tetapi terhubung ke mesin BANG! (serta dengan berbagai alat di rumah). Model jaringan kami dibagi menjadi empat lapisan layanan, yang hampir, tetapi tidak sepenuhnya, tidak mirip dengan model jaringan OSI yang digunakan dalam game (lihat Gambar 8).

Socks Level 1

, Socks, API C. . . Socks .

Link, 2

2, Link, . , Link, Listener, NetworkAddress Packet, , (. 9).

• Packet (): — , / ( ) .
• Link (): . , . send receive , , void*.
• Listener (): . .
• Data stream ( ): , , , .
• Net Address ( ): , .
• Ping: . , .
• 
  
  9. Link.

Multiplayer, 3
— , API net.lib. , RTS3 , / — , .

BANG! , . API , , .

• Client (): . () ( ). , .
• Session (): , , , . . host() join(), , , . / , .
• Channel Ordered Channel: . . TimeSync, .
• Shared Data: . , , .
• Time Sync: .

Game Communications, 4

RTS3. , , . , , .

Sistem sinkronisasi ditingkatkan. Tidak ada tim pengembangan Age of Empires yang dapat mengatakan bahwa kita tidak memerlukan alat sinkronisasi yang lebih baik. Seperti dalam proyek apa pun, ketika menganalisis proses pengembangan di post-mortem, ternyata sebagian besar waktu dihabiskan untuk beberapa bidang, tetapi bisa jadi jauh lebih sedikit jika kita menanganinya terlebih dahulu. Pada awal pengembangan RTS3, di bagian atas daftar bidang tersebut adalah sinkronisasi debugging.

Sistem pelacakan sinkronisasi RTS3 terutama ditujukan untuk mengenali bug sinkronisasi dengan cepat. Prioritas lainnya adalah penyederhanaan penggunaan, kemampuan untuk memproses sejumlah besar data yang disinkronkan secara sewenang-wenang melewati sistem, kemampuan untuk sepenuhnya mengkompilasi kode sinkronisasi dalam versi rilis, dan akhirnya, kemampuan untuk benar-benar mengubah konfigurasi pengujian dengan mengubah variabel alih-alih mengkompilasi ulang sepenuhnya.

Pemeriksaan sinkronisasi di RTS3 dilakukan menggunakan dua set makro:

#define syncRandCode(userinfo)
gSync->addCodeSync(cRandSync, userinfo, __FILE__, __LINE__)


#define syncRandData(userinfo,
v) gSync->addDataSync(cRandSync, v, userinfo, __FILE__, __LINE__)

Kedua makro ini menerima parameter string userinfo, yang merupakan nama atau indikasi elemen tersinkronisasi tertentu. Misalnya, panggilan sinkronisasi mungkin terlihat seperti ini:

syncRandCode("syncing the random seed", seed);

Perintah konsol sinkron dan variabel konfigurasi. Seperti yang dapat dikonfirmasi oleh pengembang mod Quake , perintah konsol dan variabel konfigurasi sangat penting untuk proses pengembangan. Perintah konsol adalah panggilan fungsi sederhana yang dibuat menggunakan file konfigurasi peluncuran, konsol dalam gim, atau UI, yang menjalankan fungsi gim sewenang-wenang. Variabel konfigurasi dinamai tipe data yang disediakan melalui fungsi sederhana dapatkan, atur, tetapkan, dan alihkan, yang kami gunakan untuk semua jenis pengujian dan pengaturan parameter konfigurasi.

Paul menciptakan versi multiplayer yang kompatibel dari sistem perintah konsol kami dan konfigurasi variabel. Dengan bantuan mereka, kita dapat dengan mudah mengubah variabel konfigurasi reguler (misalnya, enableCheating) menjadi variabel konfigurasi multipemain dengan menambahkan tanda pada definisi variabel konfigurasi. Jika flag ini diaktifkan, maka variabel konfigurasi ditransfer di dalam game multi-pemain, dan keputusan dalam-game yang disinkronkan (misalnya, atas izin transfer sumber daya gratis) dapat didasarkan pada nilainya. Perintah konsol multi-pemain memiliki prinsip yang sama - panggilan ke perintah konsol multi-pemain ditransmisikan melalui jaringan dan dijalankan secara serempak pada semua mesin klien.

Dengan menggunakan dua alat ini, pengembang dapat menggunakan sistem multipemain tanpa menulis kode. Mereka dapat dengan cepat menambahkan pengujian dan alat konfigurasi baru dan dengan mudah mengintegrasikannya dalam lingkungan jaringan.

Untuk meringkas

Simulasi tersinkronisasi dan model peer to peer telah berhasil digunakan dalam seri game Age of Empires. Meskipun sangat penting menginvestasikan waktu dalam menciptakan alat dan teknologi untuk memecahkan masalah utama dari pendekatan ini (seperti sinkronisasi dan metrik jaringan), kelayakan arsitektur ini dalam genre strategi waktu nyata telah dibuktikan oleh pengalaman. Perbaikan selanjutnya yang kami lakukan pada RTS3 menghasilkan fakta bahwa gameplay multi-pemain hampir tidak dapat dibedakan dari pemain tunggal, bahkan dalam kondisi koneksi jaringan yang paling mengerikan.