Belajar Godot - Multiplayer & Networking

#Pendahuluan

Di episode 12 kalian memoles game dengan animasi, particle, dan shader — sekarang game sudah terasa hidup. Episode 13 menaikkan level: membuat game kalian dimainkan bersama. Kita membangun multiplayer dengan high-level API Godot yang menyembunyikan kompleksitas socket TCP/UDP, sehingga kalian lebih banyak menulis logika game daripada protokol jaringan.

Roadmap episode ini: mengenal high-level multiplayer API dan transport ENet, membuat lobby sederhana dengan host dan join, memakai RPC untuk memanggil fungsi lintas mesin, sinkronisasi state dengan MultiplayerSynchronizer, lalu menutup dengan pola authoritative server versus peer-to-peer serta dasar lag compensation dan keamanan jaringan.

#High-Level API dan Transport ENet

Godot punya high-level multiplayer API: satu set node dan metode yang menangani koneksi, serialisasi, dan routing secara otomatis. Kalian tidak perlu menulis byte buffer sendiri — cukup definisikan data apa yang dikirim, dan Godot mengurusnya.

Di balik layar, transport defaultnya adalah ENet, pustaka jaringan berbasis UDP dengan lapisan kehandalan. ENet memberikan pengiriman yang cepat seperti UDP sekaligus kemampuan untuk memastikan pesan penting sampai seperti TCP. Di Godot 4, kelas yang dipakai adalah ENetMultiplayerPeer. (Di Godot 3, kelas ini bernama NetworkedMultiplayerENet — kalau kalian membaca tutorial lama, itu nama lamanya.)

Komponen intinya tiga: MultiplayerAPI (otak routing), MultiplayerPeer (transport, diisi ENet), dan node pembantu seperti MultiplayerSynchronizer dan MultiplayerSpawner untuk sinkronisasi otomatis.

#Host dan Join dengan ENetMultiplayerPeer

Pola paling dasar adalah satu pemain menjadi host (server sekaligus client) dan pemain lain join ke alamatnya. Buatlah sebuah node autoload bernama Net agar seluruh game bisa mengakses koneksi:

Menjadi host di port tertentu

func jadi_host(port: int = 9999) -> void:
    var peer := ENetMultiplayerPeer.new()
    peer.create_server(port, 4)
    multiplayer.multiplayer_peer = peer
 
func on_peer_connected(id: int) -> void:
    print("Pemain masuk dengan ID ", id)

Join ke host

func gabung(ip: String, port: int = 9999) -> void:
    var peer := ENetMultiplayerPeer.new()
    peer.create_client(ip, port)
    multiplayer.multiplayer_peer = peer

Setiap client diidentifikasi dengan peer ID: host selalu 1, dan client diberi ID unik setelah join. ID inilah yang dipakai untuk mengarahkan pesan ke pemain tertentu. Hubungkan signal peer_connected dan peer_disconnected dari multiplayer untuk menangkap pemain yang masuk dan keluar.

#RPC: Memanggil Fungsi Lintas Mesin

RPC (Remote Procedure Call) adalah cara memanggil fungsi di mesin lain seolah-olah lokal. Di Godot 4, sebuah fungsi ditandai dengan anotasi @rpc, lalu dipanggil lewat rpc() atau rpc_id():

RPC untuk pindah scene bersama

@rpc("any_peer", "call_local")
func muat_level(level: int) -> void:
    get_tree().change_scene_to_file("res://levels/level_%d.tscn" % level)
 
func minta_ganti_level(level: int) -> void:
    rpc("muat_level", level)

@rpc menerima beberapa mode: any_peer (siapa pun boleh memanggil) versus authority (hanya authority yang boleh), call_local (pemanggil ikut mengeksekusi), dan reliable (pakai transport handal) versus unreliable. Untuk posisi yang diperbarui setiap frame, gunakan unreliable; untuk data penting seperti damage, gunakan reliable.

#Sinkronisasi State dengan MultiplayerSynchronizer

Menebar rpc untuk setiap perubahan posisi akan membanjiri jaringan. Untuk state yang berubah terus-menerus, Godot 4 menyediakan MultiplayerSynchronizer: node yang mendaftarkan properti node lain, lalu mengirim nilai terbarunya ke peer lain secara otomatis beberapa kali per detik.

Letakkan MultiplayerSynchronizer sebagai anak dari node pemain, daftarkan node target di property root_path, lalu daftarkan properti yang ingin disinkronkan:

Menyinkronkan posisi dan rotasi

$MultiplayerSynchronizer.root_path = get_path()
$MultiplayerSynchronizer.update_interval = 0.05
$MultiplayerSynchronizer.replication_config

Untuk objek yang dibuat saat runtime — peluru, musuh spawn — pasangkan MultiplayerSpawner: setiap instance yang ditambahkan ke scene tree di mesin pembuat otomatis dibuat ulang di mesin lain. Dengan Spawner + Synchronizer, sebagian besar game action bisa disinkronkan tanpa menulis kode jaringan manual.

#Pola Authoritative Server vs Peer-to-Peer

Pertanyaan arsitektur paling penting: siapa yang menentukan kebenaran game? Ada dua pola besar:

• Peer-to-peer: semua pemain setara, masing-masing mengirim state ke semua orang. Mudah diatur, tapi tidak ada pihak yang "menjadi saksi" — rawan curang dan rawan desinkronisasi.
• Authoritative server: satu mesin (host) menghitung seluruh logika — posisi, damage, loot — dan client hanya mengirim intent. Client menampilkan hasilnya. Ini standar industri untuk game kompetitif.

Di Godot, pola authoritative server berarti kode fisika dan damage hanya berjalan di host, sementara client mengirim aksi dan menerima hasil. Contoh kecil: client mengirim perintah "melompat", host yang mengeksekusi:

Client mengirim intent, server mengeksekusi

@rpc("any_peer")
func minta_lompat() -> void:
    if multiplayer.is_server():
        karakter.melompat()

Meskipun peer-to-peer lebih mudah untuk prototipe, bangunlah game kalian dengan pola authoritative server sejak awal — memindahkannya belakangan akan jauh lebih menyakitkan.

#Lag Compensation dan Keamanan Jaringan

Di jaringan nyata, paket tiba dengan latensi — tidak instan. MultiplayerSynchronizer membantu dengan interpolasi, tapi untuk game aksi kalian perlu beberapa teknik lag compensation:

• Client-side prediction: client langsung memproyeksikan gerakannya tanpa menunggu server, mengurangi rasa "terlambat".
• Reconciliation: state client dibandingkan dengan state server dan dikoreksi saat server mengirim kebenaran.
• Interpolation: posisi objek lain di-render di antara dua update agar pergerakannya mulus, bukan patah-patah.

Keamanan menyusul: karena semua data melewati jaringan, kalian tidak bisa mempercayai client. Aturan dasarnya:

• Validasi semua input di server — jangan pernah percaya posisi yang dikirim client.
• Jangan kirim data yang tidak perlu: batasi bandwidth dengan unreliable dan update_interval yang wajar.
• Pikirkan rate limiting: jumlah request per detik dibatasi agar satu pemain tidak membanjiri server.
• Enkripsi di level transport (TLS) untuk game yang sensitif; untuk prototipe, fokus dulu pada validasi.

#Penutup

Episode 13 membawa kalian dari nol ke multiplayer fungsional: ENetMultiplayerPeer sebagai transport berbasis ENet, pola host dan join dengan peer ID, @rpc untuk memanggil fungsi lintas mesin, MultiplayerSynchronizer dan MultiplayerSpawner untuk sinkronisasi otomatis, perbandingan pola authoritative server versus peer-to-peer, serta dasar lag compensation dan aturan keamanan jaringan.

Inti yang harus dibawa pulang:

• Transport default multiplayer Godot 4 adalah ENetMultiplayerPeer; di Godot 3 bernama NetworkedMultiplayerENet.
• Gunakan @rpc untuk event yang jarang terjadi dan MultiplayerSynchronizer untuk state yang berubah terus-menerus.
• Host selalu is_server() dan memiliki peer ID 1; client dapat ID unik setelah join.
• Pola authoritative server lebih sulit pada awalnya, tetapi satu-satunya cara melindungi integritas game.
• Validasi semua input di server; client tidak pernah bisa dipercaya.

Di episode 14, setelah game bisa dimainkan bersama, kalian menghadapi pertanyaan baru: mengapa game terasa berat di mesin kalian? Kita membedah performance & profiling — optimasi draw calls dan batching, physics, profiler bawaan, penggunaan memory dan FPS, sampai optimisasi pada saat export. Game yang cepat bukanlah keberuntungan, melainkan hasil pengukuran.