Belajar Game Developer - Online Services & Backend

#Pendahuluan

Setelah multiplayer membuat pemain bermain bersama (episode 13), episode ini membuat game terhubung: online services & backend. Leaderboard yang menampilkan skor dunia, akun pemain yang menyimpan progres lintas perangkat, dan game services seperti cloud save dan achievement — semua ini adalah sisi backend yang membuat game terasa hidup dan terukur.

Di episode ini kalian akan memahami apa saja game services yang umum, bagaimana backend game dibangun dan diskalakan, serta praktik membuat fitur online Rimba Runner: API leaderboard + integrasi di client. Kalian tidak harus jadi backend engineer, tapi game developer yang paham backend bisa berkomunikasi dengan tim server dan merancang fitur yang layak produksi.

#Game Services yang Umum

Sebuah game modern biasanya butuh beberapa service berikut:

Strategi umum: mulai dengan backend-as-a-service (BaaS) seperti PlayFab (Azure), GameSparks, atau Supabase/Firebase untuk fitur dasar, lalu pindah ke backend custom saat butuh kontrol. BaaS menghemat bulan-bulan kerja infrastruktur — fokus ke gameplay, bukan login flow.

#Arsitektur Backend Game

Backend game berarsitektur mirip backend web biasa, dengan satu perbedaan penting: traffic sering spiky dan tidak seimbang (lonjakan saat rilis event). Arsitektur referensinya:

Lapisan-lapisannya:

• API server — endpoint REST/WebSocket yang dipanggil game. Contoh: POST /scores, GET /leaderboard/top.
• Database — menyimpan akun, skor, save. Multiplayer real-time sering butuh Redis untuk state sesaat.
• Anti-cheat & rate limit — batasi frekuensi request; validasi semua data dari client (topik episode 18).
• Analytics pipeline — terima event dari client untuk dashboards.

Pola penting yang jarang dibahas pemula: client tidak pernah boleh dipercaya. Skor yang dikirim client (POST /scores { score: 999999 }) tidak bisa diterima mentah-mentah — harus divalidasi server (cek sesi game, aturan skor maksimum, dan bahkan verifikasi komputasional untuk game tertentu). Kita akan dalami di episode 18.

#REST API untuk Leaderboard

Mari rancang API leaderboard Rimba Runner. Skema endpoint:

GET  /leaderboard/top?limit=10    → 10 skor tertinggi
GET  /leaderboard/rank/:playerId  → peringkat & skor pemain
POST /scores                      → kirim skor baru (dari client)

Contoh respons GET /leaderboard/top:

{
    "leaderboard": [
        { "player": "Ayu", "score": 12400, "rank": 1 },
        { "player": "Bimo", "score": 9800, "rank": 2 }
    ]
}

Di sisi game client (Godot), panggil API dengan HTTPRequest:

Memanggil leaderboard di Godot

func fetch_top_scores() -> void:
    var http := HTTPRequest.new()
    add_child(http)
    http.request_completed.connect(_on_fetched)
    http.request("https://api.rimbarunner.dev/leaderboard/top?limit=10")
 
func _on_fetched(result: int, code: int, headers: PackedStringArray, body: PackedByteArray) -> void:
    if code == 200:
        var data = JSON.parse_string(body.get_string_from_utf8())
        populate_leaderboard_ui(data["leaderboard"])

Catatan arsitektur: client game tidak boleh menampung API key rahasia — API key untuk layanan pihak ketiga (analytics, payment) wajib tinggal di backend. Client hanya boleh memegang token sesi pemain (lihat bagian akun di bawah). Kunci yang bocor di binary game bisa diambil siapa pun yang membongkar file — ini topik anti-tamper di episode 18.

#Akun Pemain dan Sesi

Sistem akun menjawab pertanyaan: "siapa yang sedang bermain, dan boleh memakai data apa?" Alur standarnya:

1. Sign-in — pemain login (email, platform, atau guest).
2. Server mengeluarkan token sesi — misal JWT, yang berisi identitas pemain dan masa berlaku.
3. Client memakai token untuk semua request berikutnya.

Login → server verifikasi → return token → client simpan token
→ tiap request bawa token → server cek siapa & boleh/tidak

Kenapa tidak sekadar kirim playerId? Karena token bisa diverifikasi server (tanda tangan kriptografis) tanpa perlu query DB setiap request, dan bisa dicabut (revoke) saat curiga disalahgunakan. Prinsip ini — identity via token, bukan ID polos — adalah dasar keamanan akun.

#Skalabilitas

Game yang tiba-tiba viral bisa meledakkan traffic. Prinsip skala yang wajib dipahami sejak awal:

• Stateless API — server tidak menyimpan sesi di memori lokal; skala horizontal (tambah instance) jadi mudah. State sesi tinggal di DB/Redis atau di token.
• Cache leaderboard — top 100 jarang berubah per detik; cache 5-30 detik di server jauh lebih murah daripada hit DB per request.
• Queue untuk beban berat — event analytics dikirim ke queue (misal Kafka/Redis) dan diproses asinkron, bukan langsung di request path.
• Rate limiting — batasi request per pemain (misal submit skor maksimal 1x/menit) untuk mencegah penyalahgunaan.

#Praktik: Fitur Online Rimba Runner

Rakit fitur leaderboard end-to-end:

1. Pilih backend — mulai dengan Supabase/Firebase (gratis untuk prototipe) atau server minimal (Node.js + Express) kalau mau kontrol penuh.
2. Endpoint — implementasikan POST /scores (validasi input) dan GET /leaderboard/top.
3. Client — fetch skor saat main menu; tampilkan top 10 di layar leaderboard.
4. Submit — kirim skor saat game over.
5. Uji — submit skor dari dua device, pastikan leaderboard sinkron.

#Penutup

Backend mengubah game dari produk menjadi layanan.

Inti yang harus dibawa pulang:

• Game services inti: akun, cloud save, leaderboard, achievement, analytics, live config.
• Backend game = API + DB + cache + analytics; traffic-nya spiky, desain untuk itu.
• Client tidak boleh dipercaya: validasi semua data yang masuk ke server.
• Autentikasi memakai token sesi, bukan ID polos; secret tidak pernah di client.
• Mulai dengan BaaS, tambah kompleksitas skala hanya saat metrik menuntut.

Di episode 15 selanjutnya kita akan menjaga kualitas: game testing & QA — playtesting, bug tracking, dan automated testing, lengkap dengan praktik QA pass untuk Rimba Runner. Sampai jumpa di episode 15!