Belajar Game Developer - Multiplayer Fundamentals

#Pendahuluan

Game yang dimainkan sendiri menyenangkan, tapi game yang dimainkan bersama punya daya tarik yang berbeda. Multiplayer adalah salah satu topik paling sulit dalam game development — bukan karena menulis kodenya, tapi karena masalah konseptualnya: bagaimana dua komputer yang tidak pernah benar-benar sinkron bisa berbagi satu dunia yang tampak sama?

Episode ini membangun fondasi multiplayer Rimba Runner versi co-op: arsitektur client-server, pilihan netcode, dan sinkronisasi state. Kalian akan paham kenapa "siapa yang berkuasa atas dunia game" adalah pertanyaan terpenting dalam netcode — dan jawabannya menentukan keamanan, keadilan, dan performa.

#Arsitektur: Client-Server vs Peer-to-Peer

Semua game online berjalan di atas satu dari dua arsitektur dasar:

• Client-Server — satu mesin (server) adalah pemegang otoritas dunia game; semua client terhubung padanya dan bertukar pesan. Server bisa dedicated (pusat data) atau dihosting salah satu pemain (listen server).
• Peer-to-Peer (P2P) — semua pemain setara; tiap mesin berbagi state langsung. Lockstep memakai ini (misal RTS lawas).

Mengapa client-server menjadi standar modern? Karena server sebagai pemegang otoritas tunggal memudahkan (1) sinkronisasi — satu sumber kebenaran, (2) anti-cheat — pemain tidak bisa memaksa state sendiri (kita dalami di episode 18), dan (3) penanganan pemain yang datang dan pergi.

#Netcode: Pilihan Arsitektur Jaringan

Netcode adalah lapisan yang mengirim state antar mesin. Pilihan arsitekturnya tergantung jenis game:

Aturan praktis: semakin penting keadilan & keamanan, semakin banyak logika di server. Game kasual co-op bisa memakai client-authoritative dengan host pemain; game kompetitif berperingkat wajib server-authoritative (akan kita bedah di episode 18 dan 21).

#Sinkronisasi State

Setiap frame, tiap client berada di posisi yang sedikit berbeda dengan server karena latency (delay jaringan). Tugas netcode adalah menutup kesenjangan ini. Tiga teknik inti:

• State updates — server mengirim state dunia secara periodik (misal 10-20 kali/detik); client memperhalus di antaranya.
• Prediction — client menjalankan simulasi lokal (misal gerakan sendiri) sehingga terasa instan, lalu mengoreksi saat update server datang.
• Interpolation — untuk objek orang lain, client menampilkan posisi "di antara" dua state yang diterima agar gerakan halus, bukan patah-patah.

Implementasi sinkronisasi paling sederhana di Godot memakai RPC (Remote Procedure Call) dan MultiplayerSynchronizer. Contoh: pemain memberitahu posisinya ke yang lain.

Sinkronisasi posisi via RPC

@rpc("any_peer", "call_local")
func sync_position(pos: Vector2) -> void:
    global_position = pos
 
func _physics_process(delta: float) -> void:
    if is_multiplayer_authority():
        # Hanya pemilik objek yang mengupdate posisinya
        move_and_slide()
        sync_position.rpc(global_position)

Prinsip penting yang muncul di sini: is_multiplayer_authority() — hanya satu mesin yang berhak mengubah posisi objek (pemiliknya). Client lain hanya menerima dan menampilkan. Ini bentuk pertama dari authority yang akan berkembang menjadi tema besar anti-cheat di episode 18.

#Tantangan Latency dan Reliability

Tidak semua pesan harus sampai dengan urutan yang pasti. Netcode membedakan dua jenis transport:

• Reliable — pesan dijamin sampai, berurutan. Dipakai untuk event penting: join, kill, pilih karakter.
• Unreliable — pesan dilempar secepatnya; jika hilang tidak fatal. Dipakai untuk posisi & input yang berulang terus.

Mengapa posisi pakai unreliable? Karena mengirim posisi tiap 50 ms dengan penjaminan pengiriman ulang justru membuat gerakan lebih lambat (retry menambah latency). Posisi yang hilang satu paket langsung "terganti" paket berikutnya. Inilah kenapa game online tidak membangun seluruh komunikasinya di atas satu tipe transport.

#Praktik: Prototipe Multiplayer Co-op

Bangun prototipe sederhana: dua pemain bisa bergerak di level yang sama, melihat satu sama lain. Langkah:

1. Host — satu pemain buat lobby/room sebagai host (listen server).
2. Join — pemain kedua join via IP/room code.
3. Player prefab — setiap pemain spawn instance karakter; hanya pemilik yang menggerakkan (authority), lainnya menerima posisi via RPC.
4. Uji — dua instance Godot (atau editor + build) dijalankan bersamaan; pastikan gerakan satu terlihat di layar yang lain.

[x] Host & join dengan peer id
[x] Setiap pemain spawn karakter sendiri
[x] Hanya pemilik karakter yang menggerakkan (authority)
[x] Posisi tersinkron via RPC ke pemain lain
[x] Dua instance jalan tanpa desync yang mengganggu

#Penutup

Multiplayer mengubah game dari pengalaman pribadi menjadi ruang sosial.

Inti yang harus dibawa pulang:

• Dua arsitektur dasar: client-server (standar modern) dan peer-to-peer (lockstep).
• Netcode dipilih sesuai jenis game; server-authoritative untuk keadilan & keamanan.
• Tiga teknik sinkronisasi: state updates, prediction, interpolation.
• Hanya satu mesin yang berkuasa atas tiap objek (authority); sisanya menerima.
• Transport reliable untuk event, unreliable untuk state berulang seperti posisi.

Di episode 14 selanjutnya kita akan melengkapi sisi online: online services & backend — leaderboard, account, dan game services, lengkap dengan praktik membangun fitur online Rimba Runner. Sampai jumpa di episode 14!