Belajar Game Developer - Performance & Optimization Game

#Pendahuluan

Game yang lambat menghancurkan segalanya — gameplay yang dirancang berbulan-bulan terasa payah jika frame-nya patah-patah. Performance optimization bukan sekadar "membuat game cepat", melainkan menjaga game tetap dalam budget di semua perangkat target, dari PC gaming hingga HP menengah.

Episode ini mengajarkan pendekatan optimasi yang benar. Dan kata kuncinya adalah data: optimasi tanpa ukuran adalah tebakan. Kita akan paham frame budget, belajar profiling untuk menemukan bottleneck nyata, lalu membahas optimasi draw calls, physics, dan memori dengan studi kasus Rimba Runner.

#Frame Budget: Duit Waktu per Frame

Setiap frame punya anggaran waktu. Pada 60 fps, satu frame hanya 16,6 ms. Kalau frame melebihi budget, game terasa lambat (stutter). Kalau terus-menerus, fps turun. Mari hitung anggarannya:

Simulasi/logika   : ± 4 ms
Physics           : ± 3 ms
Rendering         : ± 6 ms
GPU work          : ± 3 ms
Total             : 16,6 ms (maksimal)

Angka di atas hanya contoh — yang penting adalah kesadaran: waktu per frame adalah sumber daya yang bisa habis. Semua yang kita tambahkan (AI musuh, partikel, shader, pencahayaan) memakan porsi budget. Tugas optimasi adalah memastikan porsi itu wajar.

Aturan emas optimasi:

1. Jangan optimasi sebelum ada masalah — ukur dulu, baru optimasi.
2. Ukur lagi setelah optimasi — pastikan perubahannya benar-benar berdampak.
3. Optimasi satu bottleneck pada satu waktu — mempercepat hal yang bukan bottleneck tidak mengubah apa pun.

#Profiling: Menemukan Bottleneck

Profiler adalah alat yang mengukur di mana waktu per frame dihabiskan. Tiap engine punya profiler bawaan: Godot (Debugger/Profiler, Renderer Debugger), Unity (Profiler window, Frame Debugger), Unreal (Unreal Insights, stat GPU). Ada juga alat eksternal seperti RenderDoc (GPU) dan Perfetto (sistem).

Alur profiling yang benar:

Yang sering salah: mengoptimasi berdasarkan firasat. "Pasti banyak musuhnya yang bikin lambat." Mungkin saja benar — tapi mungkin juga bottleneck-nya justru partikel, atau pemuatan tekstur, atau garbage collection di script. Profiler menyingkirkan firasat.

Saat memprofil, jaga disiplin: profil pada scene yang representatif (level penuh, bukan test scene kosong), di perangkat terlemah yang menjadi target (bukan mesin dev yang super kencang), dan dengan build release bila memungkinkan (mode debug editor jauh lebih lambat).

#Draw Calls: Bahasa GPU yang Boros

Draw call adalah perintah "gambar objek ini" yang dikirim CPU ke GPU. Masalahnya: tiap draw call butuh waktu pengiriman. Ribuan draw call per frame membuat CPU jadi bottleneck meski GPU nganggur.

Sumber draw call berlebihan di game 2D:

• Ratusan sprite objek kecil yang digambar terpisah.
• Tiap objek punya material/tekstur berbeda sehingga tak bisa digabung.
• Efek partikel dalam jumlah besar.

Solusi standar:

• Batching — engine menggabungkan objek bertekstur sama menjadi satu draw call. Godot dan Unity melakukannya otomatis untuk objek statis bertekstur atlas.
• Texture atlas — satukan banyak gambar kecil jadi satu tekstur agar batching efektif.
• Gunakan tilemap — satu tilemap menggambar ratusan tile dalam beberapa draw call, jauh lebih efisien daripada ratusan sprite terpisah.
• Static batching di Unity untuk objek tidak bergerak.

Cara melihat dampaknya: buka statistik renderer. Di Godot, Renderer Debugger menampilkan jumlah draw calls; jika ribuan padahal scene sederhana, ada yang salah.

#Physics dan Memori

Dua kategori yang sering jadi pembunuh performa diam-diam:

Physics — tiap rigidbody yang aktif berpartisipasi dalam simulasi collision. Masalah umum: ratusan rigidbody aktif padahal kebanyakan statis. Perbaikan: gunakan StaticBody untuk objek diam, batasi jumlah rigidbody aktif, perbesar collision margin bila aman, dan matikan physics untuk objek di luar layar.

Memori — allocation berlebihan di update loop menyebabkan garbage collection (GC) yang memicu stutter. Contoh klasik: membuat string baru tiap frame, atau objek sementara di dalam _process. Di Godot/GDScript dan Unity C#, alokasi per-frame adalah musuh stutter:

Hindari alokasi di update loop

# Buruk: membuat string & array baru tiap frame
func _process(delta):
    label.text = "Skor: " + str(score)   # alokasi string baru tiap frame
    var temp = [1, 2, 3]                 # alokasi array baru tiap frame
 
# Baik: simpan hasil yang bisa disimpan
func _process(delta):
    if score != last_score:
        label.text = "Skor: " + str(score)
        last_score = score

Prinsipnya: jangan buat sampah di dalam loop. Semua yang bisa dihitung di luar update (precompute), di luar loop (konfigurasi sekali), atau di-cache, lakukan di sana.

#Praktik: Optimasi Rimba Runner

Ikuti alur data-driven:

1. Target — tetapkan budget: 60 fps di desktop, 30 fps di HP menengah.
2. Profile — buka profiler di level penuh; catat CPU vs GPU time dan draw calls.
3. Temukan bottleneck #1 — misal draw calls 5.000.
4. Optimasi — gabung sprite ke texture atlas, ubah rintangan statis jadi tilemap, aktifkan static batching.
5. Ukur ulang — pastikan draw calls turun dan frame time membaik; ulangi untuk bottleneck berikutnya.

Bottleneck awal   : 5.200 draw calls, frame 28 ms
Setelah atlas     : 1.100 draw calls, frame 18 ms
Setelah batching  : 640 draw calls,  frame 15 ms  ← masuk budget 60 fps

#Penutup

Optimasi adalah disiplin mengukur, bukan menebak.

Inti yang harus dibawa pulang:

• Frame budget 16,6 ms (60 fps) adalah sumber daya nyata yang harus dikelola.
• Profiling dulu, optimasi kemudian; ukur ulang setiap perubahan.
• Draw calls adalah bottleneck CPU yang umum; solusinya batching + atlas + tilemap.
• Hindari alokasi memori dan benda physics aktif yang tidak perlu di dalam loop.
• Tetapkan target platform terendah sejak awal; performa melayani gameplay.

Di episode 17 selanjutnya kita akan mengasah kerja sama inti: game design collaboration — bekerja dengan designer, memahami game feel & mechanics, dan iterasi desain, lengkap dengan praktik iterasi desain Rimba Runner. Sampai jumpa di episode 17!