Pengembangan game multi pemain itu rumit karena banyak alasan: hosting mereka bisa mahal, strukturnya tidak jelas, dan implementasinya sulit. Dalam tutorial ini saya akan mencoba membantu Anda mengatasi penghalang terakhir.
Artikel ini ditujukan untuk pengembang yang dapat membuat game dan terbiasa dengan JavaScript, tetapi belum pernah menulis game online multi-pemain sebelumnya. Setelah menyelesaikan tutorial ini, Anda akan menguasai implementasi komponen jaringan dasar dalam gim Anda dan dapat mengembangkannya menjadi sesuatu yang lebih! Inilah yang akan kami buat:
Anda dapat memainkan game yang sudah selesai di
sini ! Ketika Anda menekan tombol W atau "atas", kapal mendekati kursor, ketika Anda mengklik tetikus, ia menembak.
(Jika tidak ada yang online, maka untuk memeriksa cara kerja multi-pemain, buka dua jendela browser di satu komputer, atau salah satunya di telepon,). Jika Anda ingin menjalankan game secara lokal, maka kode sumber lengkap tersedia di
GitHub .
Saat membuat game, saya menggunakan sumber daya grafis dari
Kenney's Pirate Pack dan framework game
Phaser . Dalam tutorial ini Anda ditugaskan peran programmer jaringan. Titik awal akan menjadi versi pengguna tunggal yang berfungsi penuh dari permainan, dan tugas kami adalah menulis server di Node.js menggunakan
Socket.io untuk bagian jaringan. Agar tidak membebani tutorial, saya akan fokus pada bagian yang terkait dengan multipemain dan melewati konsep yang terkait dengan Phaser dan Node.js.
Anda tidak perlu mengonfigurasi apa pun secara lokal, karena kami akan membuat game ini sepenuhnya di browser di
Glitch.com ! Glitch adalah alat yang luar biasa untuk membangun aplikasi web, termasuk backend, database, dan banyak lagi. Ini bagus untuk membuat prototipe, pelatihan, dan kolaborasi, dan saya akan sangat senang memperkenalkan Anda dengan kemampuannya dalam tutorial ini.
Mari kita mulai.
1. Persiapan
Saya memposting draft proyek di
Glitch.com .
Tip Antarmuka: Anda dapat meluncurkan pratinjau aplikasi dengan mengklik tombol
Show (kiri atas).
Bilah samping vertikal di sebelah kiri berisi semua file aplikasi. Untuk mengedit aplikasi ini, Anda harus membuat "remix" -nya. Jadi kita akan membuat salinannya di akun kita (atau "fork" di git jargon). Klik pada tombol
Remix this .
Pada titik ini, Anda sedang mengedit aplikasi di bawah akun anonim. Untuk menyimpan pekerjaan Anda, Anda dapat masuk (kanan atas).
Sekarang, sebelum melanjutkan, penting bagi Anda untuk berkenalan dengan game tempat kami akan menambahkan mode multipemain. Lihatlah
index.html . Ini memiliki tiga fungsi penting yang perlu Anda ketahui:
preload
(baris 99),
create
(line 115) dan
GameLoop
(line 142), serta objek pemain (baris 35).
Jika Anda lebih suka belajar dengan berlatih, maka pastikan untuk memahami pekerjaan permainan dengan menyelesaikan tugas-tugas berikut:
- Tingkatkan ukuran dunia (baris 29) - perhatikan bahwa ada ukuran dunia yang terpisah untuk dunia dalam game dan ukuran jendela untuk kanvas halaman itu sendiri .
- Memungkinkan untuk bergerak maju dengan bantuan "ruang" (baris 53).
- Ubah jenis kapal pemain (baris 129).
- Perlambat gerakan kerang (baris 155).
Pasang Socket.io
Socket.io adalah pustaka untuk mengelola komunikasi real-time di dalam browser menggunakan
WebSockets (alih-alih menggunakan protokol seperti UDP, yang digunakan untuk membuat game multipemain klasik). Selain itu, perpustakaan memiliki cara berlebihan untuk memastikan operasi, bahkan ketika WebSockets tidak didukung. Artinya, dia berurusan dengan protokol pengiriman pesan dan memungkinkan penggunaan sistem pesan berbasis acara yang nyaman.
Hal pertama yang perlu kita lakukan adalah memasang modul Socket.io. Di Glitch, ini dapat dilakukan dengan masuk ke file
package.json , dan kemudian memasukkan modul yang diperlukan di dependensi, atau mengklik
Tambah paket dan memasukkan "socket.io".
Sekarang adalah waktu yang tepat untuk berurusan dengan log server. Klik tombol
Log di sebelah kiri untuk membuka log server. Anda akan melihat bahwa ia menginstal Socket.io dengan semua dependensinya. Di sinilah Anda perlu mencari semua kesalahan dan output dari kode server.
Sekarang mari kita pergi ke
server.js . Di sinilah kode server kami berada. Sejauh ini, hanya ada beberapa kode boilerplate dasar untuk menyajikan HTML kami. Tambahkan baris ke bagian atas file untuk mengaktifkan Socket.io:
var io = require('socket.io')(http);
Sekarang kita juga perlu mengaktifkan Socket.io di klien, jadi mari kita kembali ke
index.html dan tambahkan baris berikut di dalam
<head>
:
<!-- Socket.io --> <script src="/socket.io/socket.io.js"></script>
Catatan: Socket.io secara otomatis memproses pemuatan pustaka klien di sepanjang jalur ini, jadi baris ini berfungsi bahkan jika tidak ada direktori /socket.io/ di folder Anda.Sekarang Socket.io termasuk dalam proyek dan siap untuk pergi!
2. Pengakuan dan pemijahan pemain
Langkah nyata pertama kami adalah menerima koneksi di server dan membuat pemain baru di klien.
Menerima koneksi server
Tambahkan kode ini ke bagian bawah
server.js :
Jadi kami meminta Socket.io untuk mendengarkan semua acara
connection
yang secara otomatis terjadi ketika klien terhubung. Perpustakaan membuat objek
socket
baru untuk setiap klien, di mana
socket.id
adalah pengidentifikasi unik untuk klien ini.
Untuk memverifikasi bahwa ini berfungsi, kembali ke klien (
index.html ) dan tambahkan baris ini di suatu tempat di fungsi
buat :
var socket = io();
Jika Anda memulai permainan dan melihat log server (klik tombol
Log ), Anda akan melihat bahwa server telah mendaftarkan acara koneksi ini!
Sekarang, saat menghubungkan pemain baru, kami berharap dia memberi kami informasi tentang kondisinya. Dalam kasus kami, kami perlu tahu setidaknya
x ,
y dan
sudut untuk membuatnya dengan benar di titik yang tepat.
Acara
connection
adalah acara inline yang dipicu oleh Socket.io. Kami dapat mendengarkan acara yang diatur secara independen. Saya akan memberi nama
new-player
acara saya, dan saya akan mengharapkan klien untuk mengirimkannya segera setelah terhubung dengan informasi tentang posisinya. Ini akan terlihat seperti ini:
Jika Anda menjalankan kode ini, maka sampai Anda melihat sesuatu di log server, karena kami belum memberi tahu klien untuk membuat acara
new-player
ini. Tapi mari kita berpura-pura sejenak bahwa kita sudah melakukan ini, dan terus bekerja di server. Apa yang harus terjadi setelah mendapatkan lokasi pemain yang baru bergabung?
Kami dapat mengirim pesan ke semua pemain
lain yang terhubung sehingga mereka tahu bahwa pemain baru telah muncul. Socket.io memiliki fungsi yang nyaman untuk ini:
socket.broadcast.emit('create-player',state_data);
Ketika
socket.emit
dipanggil
socket.emit
pesan itu hanya diteruskan ke klien tunggal ini. Ketika
socket.broadcast.emit
dipanggil
socket.broadcast.emit
ia dikirim ke setiap klien yang terhubung ke server, kecuali pada soket siapa fungsi ini dipanggil.
Fungsi
io.emit
mengirimkan pesan ke setiap klien yang terhubung ke server tanpa pengecualian. Dalam skema kami, kami tidak memerlukan ini, karena jika kami menerima pesan dari server yang meminta kami membuat kapal kami sendiri, maka kami akan mendapatkan duplikat sprite, karena kami sudah membuat kapal kami sendiri ketika permainan dimulai.
Berikut tip praktis tentang berbagai jenis fitur perpesanan yang akan kami gunakan dalam tutorial ini.
Kode server sekarang akan terlihat seperti ini:
Artinya, setiap kali pemain terhubung, kami berharap dia mengirimi kami pesan berisi informasi tentang lokasinya, dan kami mengirim data ini ke semua pemain lain sehingga mereka dapat membuat sprite-nya.
Pemijahan klien
Sekarang, untuk menyelesaikan siklus ini, kita perlu melakukan dua tindakan di klien:
- Hasilkan pesan dengan data lokasi kami setelah koneksi.
- Dengarkan acara membuat pemain dan buat pemain pada saat ini.
Untuk melakukan tindakan pertama setelah membuat pemain di fungsi
buat (kira-kira di baris 135), kami dapat membuat pesan berisi data lokasi yang perlu kami kirim:
socket.emit('new-player',{x:player.sprite.x,y:player.sprite.y,angle:player.sprite.rotation})
Kita tidak perlu khawatir tentang serialisasi data yang dikirim. Anda dapat mentransfernya di semua jenis objek, dan Socket.io akan memprosesnya untuk kami.
Sebelum melanjutkan,
uji kodenya . Kita akan melihat pesan serupa di log server:
New player has state: { x: 728.8180247836519, y: 261.9979387913289, angle: 0 }
Sekarang kita tahu bahwa server kami menerima pemberitahuan tentang koneksi pemain baru dan dengan benar membaca data tentang lokasinya!
Selanjutnya, kami ingin mendengarkan permintaan untuk membuat pemain baru. Kita dapat menempatkan kode ini segera setelah membuat pesan, seharusnya terlihat seperti ini:
socket.on('create-player',function(state){
Sekarang
uji kodenya . Buka dua jendela dengan permainan dan pastikan itu berfungsi.
Anda harus melihat bahwa setelah membuka dua klien, klien pertama memiliki dua kapal dibuat, dan yang kedua hanya memiliki satu.
Tugas: dapatkah Anda mencari tahu mengapa itu terjadi? Atau bagaimana Anda bisa memperbaikinya? Langkah demi langkah ikuti logika klien / server yang kami tulis dan coba debug.
Saya harap Anda mencoba mencari tahu sendiri! Berikut ini terjadi: ketika pemain pertama terhubung, server mengirimkan acara
create-player
ke semua pemain lain, tetapi belum ada pemain yang bisa menerimanya. Setelah menghubungkan pemain kedua, server mengirim kembali pesannya, dan pemain pertama menerimanya dan membuat sprite dengan benar, sementara pemain kedua melewatkan pesan dari pemain pertama.
Artinya, masalahnya adalah bahwa pemain kedua terhubung ke permainan nanti dan dia perlu mengetahui keadaan permainan. Kami harus memberi tahu semua pemain penghubung baru bahwa para pemain sudah ada (serta acara lain yang telah terjadi di dunia) sehingga mereka dapat mengarahkan diri mereka sendiri. Sebelum kita menyelesaikan masalah ini, saya memiliki peringatan singkat.
Peringatan Sinkronisasi Status Game
Ada dua pendekatan untuk mengimplementasikan sinkronisasi semua pemain. Yang pertama adalah mengirim sejumlah informasi minimum tentang perubahan yang terjadi melalui jaringan. Yaitu, setiap kali pemain baru terhubung, kami akan mengirimkan semua pemain lain hanya informasi tentang pemain baru ini (dan mengirim daftar semua pemain lain di dunia ke pemain baru ini), dan setelah memutuskan sambungan kami memberi tahu semua pemain bahwa pemain tertentu ini telah terputus.
Pendekatan kedua adalah untuk menyampaikan seluruh kondisi permainan. Dalam hal ini, kami hanya setiap kali Anda menghubungkan atau memutuskan mengirim semua orang daftar lengkap semua pemain.
Pendekatan pertama lebih baik karena meminimalkan jumlah informasi yang dikirimkan melalui jaringan, tetapi bisa sangat sulit untuk diterapkan, dan memiliki kemungkinan pemain tidak sinkron. Yang kedua memastikan bahwa pemain selalu sinkron, tetapi setiap pesan harus mengirim lebih banyak data.
Dalam kasus kami, alih-alih mencoba mengirim pesan ketika pemain terhubung untuk membuatnya dan ketika terputus untuk menghapusnya, serta ketika bergerak untuk memperbarui posisinya, kami dapat menggabungkan semua ini menjadi satu peristiwa
update
umum. Acara pembaruan ini akan selalu mengirim posisi masing-masing pemain ke semua pelanggan. Inilah yang harus dilakukan server. Tugas klien adalah untuk menjaga kesesuaian dunia dengan negara yang diterima.
Untuk mengimplementasikan skema semacam itu, saya akan melakukan hal berikut:
- Saya akan menyimpan kamus pemain, yang kuncinya adalah ID mereka, dan nilainya akan menjadi data di lokasi mereka.
- Tambahkan pemain ke kamus ini saat terhubung dan kirim acara pembaruan.
- Hapus pemain dari kamus ini ketika dimatikan dan kirim acara pembaruan.
Anda dapat mencoba menerapkan sistem ini sendiri, karena langkah-langkah ini cukup sederhana (
tip fitur saya mungkin berguna di sini). Seperti apa implementasi penuh kelihatannya:
Sisi klien sedikit lebih rumit. Di satu sisi, sekarang kita seharusnya hanya peduli pada acara
update-players
, tetapi di sisi lain, kita harus mempertimbangkan membuat kapal baru jika server mengirim lebih banyak kapal daripada yang kita tahu, atau menghapus jika ada terlalu banyak dari mereka.
Inilah cara saya menangani acara ini di klien:
Di sisi klien, saya menyimpan kapal di kamus
other_players
, yang baru saja saya definisikan di bagian atas skrip (tidak ditampilkan di sini). Karena server mengirim data pemain ke semua pemain, saya harus menambahkan tanda centang agar klien tidak membuat sprite tambahan untuk dirinya sendiri. (Jika Anda memiliki masalah dengan penataan, maka di sini adalah
kode lengkap yang seharusnya ada di index.html saat ini).
Sekarang
uji kodenya . Anda harus dapat membuat beberapa pelanggan dan melihat jumlah kapal yang benar dibuat di posisi yang tepat!
3. Sinkronisasi posisi kapal
Di sini dimulai bagian yang sangat menarik. Kami ingin menyinkronkan posisi kapal pada semua klien. Ini akan mengungkapkan kesederhanaan struktur yang telah kita buat saat ini. Kami sudah memiliki acara pembaruan yang dapat menyinkronkan lokasi semua kapal. Cukup bagi kita untuk melakukan hal berikut:
- Paksa klien untuk menghasilkan pesan setiap kali ia pindah ke posisi baru.
- Ajari server untuk mendengarkan pesan gerakan ini dan memperbarui elemen data
players
kamus players
. - Hasilkan acara pembaruan untuk semua klien.
Dan itu sudah cukup! Sekarang giliran Anda untuk mencoba mengimplementasikannya sendiri.
Jika Anda benar-benar bingung dan membutuhkan petunjuk, maka lihatlah
proyek yang sudah selesai .
Catatan tentang meminimalkan data yang dikirim melalui jaringan
Cara paling mudah untuk mengimplementasikannya adalah dengan memperbarui posisi semua pemain setiap kali acara pergerakan diterima dari pemain
mana pun . Sangat bagus jika pemain selalu mendapatkan informasi terbaru segera setelah itu muncul, tetapi jumlah pesan yang dikirim melalui jaringan dapat dengan mudah bertambah menjadi ratusan per bingkai. Bayangkan Anda memiliki 10 pemain, yang masing-masing mengirim pesan gerakan di setiap frame. Server harus meneruskannya kembali ke 10 pemain. Ini sudah 100 pesan per bingkai!
Akan lebih baik untuk melakukan ini: tunggu sampai server menerima semua pesan dari semua pemain, dan kemudian kirim semua pemain pembaruan besar yang berisi semua informasi. Dengan demikian, kami akan mengurangi jumlah pesan yang ditransmisikan ke jumlah pengguna yang ada dalam game (bukan kuadrat dari nomor ini). Masalahnya di sini adalah bahwa semua pengguna akan mengalami penundaan yang sama seperti pemain dengan koneksi paling lambat.
Solusi lain adalah mengirim pembaruan server pada frekuensi konstan, terlepas dari jumlah pesan yang diterima dari pemain. Standar umum adalah memperbarui server sekitar 30 kali per detik.
Namun, ketika memilih struktur server Anda, Anda harus mengevaluasi jumlah pesan yang dikirimkan dalam setiap frame pada tahap awal pengembangan game.
4. Sinkronisasi shell
Kita hampir selesai! Bagian serius terakhir adalah menyinkronkan melalui jaringan kerang. Kami dapat menerapkannya dengan cara yang sama seperti pemain yang disinkronkan:
- Setiap klien mengirimkan posisi semua cangkang mereka di setiap frame.
- Server mengarahkan mereka ke setiap pemain.
Tapi ada masalah.
Perlindungan curang
Jika Anda mengarahkan ulang segala sesuatu yang dikirim klien sebagai posisi sebenarnya dari shell, pemain dapat dengan mudah menipu dengan memodifikasi kliennya dan mengirimkan data palsu kepada Anda, misalnya, shell yang melakukan teleportasi ke posisi kapal. Anda dapat dengan mudah memverifikasi ini sendiri dengan mengunduh halaman web, mengubah kode menjadi JavaScript, dan membukanya lagi. Dan ini adalah masalah tidak hanya untuk game browser. Dalam kasus umum, kami tidak pernah bisa mempercayai data yang berasal dari pengguna.
Untuk mengatasi sebagian masalah ini, kami akan mencoba menggunakan skema lain:
- Klien menghasilkan pesan tentang shell tembakan dengan posisi dan arahnya.
- Server mensimulasikan pergerakan cangkang.
- Server memperbarui data setiap klien, melewati posisi semua shell.
- Klien membuat shell di posisi yang diterima dari server.
Dengan demikian, klien bertanggung jawab atas posisi proyektil, tetapi tidak untuk kecepatannya dan bukan untuk pergerakan selanjutnya. Klien dapat mengubah posisi cangkang untuk dirinya sendiri, tetapi ini tidak akan mengubah apa yang dilihat klien lain.
Untuk mengimplementasikan skema semacam itu, kami akan menambahkan pembuatan pesan saat dipecat. Saya tidak akan lagi membuat sprite itu sendiri, karena keberadaan dan lokasinya akan sepenuhnya ditentukan oleh server. Sekarang tembakan proyektil baru kami di
index.html akan terlihat seperti ini:
Juga sekarang kita dapat mengomentari seluruh fragmen kode yang memperbarui shell di klien:
Akhirnya, kita perlu membuat klien mendengarkan pembaruan shell. Saya memutuskan untuk mengimplementasikan ini dengan cara yang sama seperti dengan para pemain, yaitu, server hanya mengirim array dari semua posisi shell dalam peristiwa yang disebut
bullets-update
, dan klien membuat atau menghancurkan shell untuk menjaga sinkronisasi. Begini tampilannya:
Dan hanya itu yang seharusnya ada di klien. Saya akan berasumsi bahwa Anda sudah tahu di mana harus menyematkan fragmen kode ini dan bagaimana menyatukannya, tetapi jika Anda memiliki masalah, Anda selalu dapat melihat hasil yang sudah selesai .Sekarang di server.js kita perlu melacak dan mensimulasikan shell. Pertama, kami akan membuat array untuk melacak shell, mirip dengan array untuk pemain: var bullet_array = [];
Selanjutnya, kami mendengarkan acara tembakan proyektil:
Sekarang kami mensimulasikan cangkang 60 kali per detik:
Dan langkah terakhir adalah mengirim acara pembaruan di suatu tempat di dalam fungsi ini (tapi jelas di luar for for loop):
Sekarang kita akhirnya bisa menguji permainan! Jika semuanya ternyata benar, maka Anda akan melihat bahwa cangkang disinkronkan dengan benar pada semua klien. Fakta bahwa kami menerapkan ini pada server memaksa kami untuk melakukan lebih banyak pekerjaan, tetapi itu memberi kami lebih banyak kontrol. Misalnya, ketika kami menerima peristiwa penembakan proyektil, kami dapat memeriksa apakah kecepatan proyektil berada dalam interval tertentu, dan jika tidak demikian, kami akan tahu bahwa pemain ini curang.5. Tabrakan dengan kerang
Ini adalah mekanisme dasar terakhir yang kami laksanakan. Saya harap Anda sudah terbiasa dengan prosedur untuk merencanakan implementasi Anda, pertama menyelesaikan implementasi klien sepenuhnya, dan kemudian pindah ke server (atau sebaliknya). Metode ini jauh lebih rentan kesalahan daripada melompat ketika diterapkan bolak-balik.Memeriksa tabrakan adalah mekanik gim yang penting, jadi kami ingin agar terlindung dari kecurangan. Kami mengimplementasikannya di server dengan cara yang sama seperti yang kami lakukan dengan shell. Kami membutuhkan yang berikut:- Periksa apakah proyektilnya cukup dekat dengan pemain di server.
- Hasilkan acara untuk semua klien saat proyektil mengenai pemain.
- Ajari klien untuk mendengarkan acara hit dan buat kapal berkedip saat mengenai.
Anda dapat mencoba mengimplementasikan bagian ini sendiri. Untuk membuat kapal pemain berkedip ketika mengenai, cukup setel saluran alfa ke 0: player.sprite.alpha = 0;
Dan itu akan dengan lancar kembali ke opacity penuh (ini dilakukan dalam pembaruan pemain). Untuk pemain lain, aksinya akan serupa, tetapi Anda harus mengembalikan saluran alfa ke satu di fungsi pembaruan dengan sesuatu yang serupa: for(var id in other_players){ if(other_players[id].alpha < 1){ other_players[id].alpha += (1 - other_players[id].alpha) * 0.16; } else { other_players[id].alpha = 1; } }
Satu-satunya bagian yang sulit adalah memverifikasi bahwa pemain tidak mengenai cangkangnya sendiri (jika tidak, ia akan mendapat kerusakan setiap kali ia menembak).Perhatikan bahwa dalam skema ini, bahkan jika klien mencoba menipu dan menolak untuk menerima pesan hit yang dikirim kepadanya oleh server, ini hanya akan mengubah apa yang dilihatnya di layarnya sendiri. Semua pemain lain masih akan melihat bahwa mereka menekan pemain.6. Gerakan menghaluskan
Jika Anda telah menyelesaikan semua langkah hingga saat ini, saya dapat memberi selamat kepada Anda. Anda baru saja membuat game multiplayer yang berfungsi! Kirim tautan ke teman dan lihat bagaimana keajaiban multiplayer online dapat menyatukan pemain!Permainan ini berfungsi penuh, tetapi pekerjaan kami tidak berakhir di sana. Ada beberapa masalah yang dapat memengaruhi permainan secara negatif, dan kita harus mengatasinya:- Jika tidak semua orang memiliki koneksi cepat, maka pergerakan pemain lain terlihat sangat gugup.
- Kerang tampaknya lambat, karena tidak segera dipecat. Sebelum muncul di layar klien, mereka menunggu pesan balasan dari server.
Kami dapat memecahkan masalah pertama dengan menginterpolasi data posisi kapal kami di klien. Karena itu, jika kami tidak menerima pembaruan dengan cukup cepat, kami dapat dengan lancar memindahkan kapal ke tempat di mana seharusnya, dan tidak hanya memindahkannya ke sana.Kerang membutuhkan solusi yang lebih kompleks. Kami ingin server memproses cangkang untuk melindungi dari kecurangan, tetapi kami juga membutuhkan reaksi instan: tembakan dan proyektil terbang. Solusi terbaik adalah pendekatan hybrid. Baik server dan klien dapat mensimulasikan shell, dan server masih akan mengirim pembaruan ke posisi shell. Jika mereka tidak sinkron, maka kami mengasumsikan bahwa server benar dan mendefinisikan kembali posisi proyektil di klien.Kami tidak akan menerapkan sistem shell ini dalam tutorial ini, tetapi senang mengetahui bahwa metode ini ada.Melakukan interpolasi sederhana posisi kapal sangat sederhana. Alih-alih mengatur posisi secara langsung dalam acara pembaruan, tempat kami pertama kali menerima data posisi baru, kami hanya menyimpan posisi target:
Kemudian, dalam fungsi pembaruan (juga di sisi klien), kami memutar semua pemain lain dan mendorong mereka ke arah tujuan mereka:
Dengan demikian, server mengirimkan pembaruan kepada kami 30 kali per detik, tetapi kami masih bisa bermain dengan kecepatan 60 fps dan permainan masih terlihat lancar!Kesimpulan
Kami memeriksa banyak masalah. Mari kita buat daftar: kita belajar cara mentransfer pesan antara klien dan server, cara menyinkronkan keadaan permainan, menyiarkannya dari server ke semua pemain. Ini adalah cara termudah untuk mengimplementasikan game online multi-pemain.Kami juga belajar cara melindungi gim dari kecurangan, mensimulasikan bagian-bagian penting di server dan memberi tahu pelanggan tentang hasilnya. Semakin sedikit Anda mempercayai klien, semakin aman permainannya.Akhirnya, kami belajar cara mengatasi penundaan menggunakan interpolasi klien. Kompensasi untuk keterlambatan adalah topik serius dan sangat penting (beberapa game dengan penundaan yang cukup besar menjadi tidak bisa dimainkan). Interpolasi sambil menunggu pembaruan berikutnya dari server hanyalah salah satu cara untuk mengurangi masalah. Yang lain sedang memprediksi beberapa frame berikutnya di muka, dan memperbaikinya ketika menerima data nyata dari server, tetapi, tentu saja, pendekatan ini bisa sangat sulit.Cara yang sama sekali berbeda untuk mengurangi dampak penundaan adalah membuat desain sistem mem-bypass masalah ini. Keuntungan dari putaran kapal lambat adalah bahwa itu adalah mekanisme gerakan yang unik, dan itu adalah cara untuk mencegah perubahan tiba-tiba dalam pergerakan. Karenanya, meski dengan koneksi lambat, mereka tetap tidak akan merusak gameplay. Sangat penting untuk mempertimbangkan keterlambatan saat mengembangkan elemen-elemen dasar permainan. Terkadang keputusan terbaik sama sekali bukan trik teknis.Anda dapat menggunakan fungsi Glitch lain yang bermanfaat, yang terdiri dari kemampuan untuk mengunduh atau mengekspor proyek Anda sendiri melalui Opsi Tingkat Lanjut di sudut kiri atas: