Belajar Godot - Performance & Profiling

#Pendahuluan

Di episode 13 kalian membuat game multiplayer — dan seperti game online mana pun, ia rentan terhadap lag dan frame drop. Episode 14 mengajarkan cara menjaga game tetap mulus: performance & profiling. Kalian akan belajar mengukur sebelum mengoptimasi, karena optimasi tanpa data hanyalah tebakan.

Roadmap episode ini: mengenal profiler bawaan dan performance monitor, memahami draw calls dan batching di rendering, mengoptimasi physics yang sering menjadi biang keladi, mengelola memory dan FPS budget, lalu menutup dengan optimisasi saat export — termasuk export templates dan pengaturan spesifik platform.

#Ukur Dulu: Profiler dan Performance Monitor

Aturan emas performa: jangan optimasi sebelum mengukur. Godot menyediakan dua alat utama. Yang pertama adalah Profiler (menu Debug → Profiler): ia merekam waktu yang dihabiskan setiap sistem — script, rendering, physics, audio — beserta jumlah panggilan per frame. Setelah game berjalan beberapa detik, kalian bisa membaca frame mana yang paling berat dan sistem mana penyebabnya.

Yang kedua adalah Performance Monitor (Debug → Monitor): grafik real-time dari FPS, draw calls, jumlah node aktif, memory, dan lainnya. Dari sini kalian bisa melihat tren: apakah draw calls melonjak saat banyak musuh muncul? Apakah memory terus naik tanpa pernah turun? Dua gejala itu sudah memberi petunjuk besar.

Profiler juga bisa diakses dari kode untuk telemetri otomatis:

Membaca FPS dan waktu physics dari kode

func _process(_delta: float) -> void:
    var fps: float = Engine.get_frames_per_second()
    var physics_time: float = Performance.get_monitor(Performance.TIME_PHYSICS_PROCESS)
    if fps < 30.0:
        print("FPS menurun: ", fps, " physics: ", physics_time)

Buatlah kebiasaan sederhana: sebelum mengubah apa pun, catat FPS dan waktu physics. Setelah perubahan, bandingkan. Kalau tidak ada bedanya, kembalikan — itu berarti optimasi kalian hanya menambah kompleksitas tanpa hasil.

#Draw Calls dan Batching

Satu penyebab utama game terasa berat adalah terlalu banyak draw calls — perintah yang dikirim CPU ke GPU untuk menggambar satu objek. Setiap sprite, setiap efek partikel, setiap elemen UI menambah satu atau lebih draw call. GPU bisa menangani jutaan vertex, tetapi CPU terbatas dalam mengirim perintah, jadi di sinilah bottleneck biasanya terjadi.

Kunci untuk mengurangi draw calls adalah batching: menggabungkan banyak objek kecil menjadi satu draw call. Di 2D, batching otomatis bekerja ketika sprite-sprite memakai texture yang sama dan material yang sama. Karena itu pola yang paling efektif adalah menyatukan banyak objek kecil dalam satu atlas texture (satu gambar besar berisi semua sprite), sehingga Godot bisa menggambar mereka sekaligus.

Untuk objek yang bergerak sendiri seperti peluru atau partikel, batasi jumlahnya: lebih baik 20 peluru yang terlihat jelas daripada 200 yang membanjiri layar. Gunakan pool (kumpulan objek yang dipakai ulang) alih-alih membuat dan menghancurkan node terus-menerus:

Pola sederhana memakai ulang node peluru

func tembak(posisi: Vector2) -> void:
    for peluru in pool:
        if not peluru.visible:
            peluru.global_position = posisi
            peluru.visible = true
            return

#Optimasi Physics

Physics adalah sistem kedua yang paling sering membebani. Tiga penyetelan yang berdampak besar:

• Batasi jumlah body dan shape. Godot membandingkan collision berpasangan; setiap penambahan objek menambah biaya kuadrat. Jangan memberi CollisionShape2D pada objek yang tidak butuh tabrakan, seperti debu partikel.
• Naikkan layer dan mask dengan bijak. Bagi collision layer (pemain, musuh, lingkungan, pickup) dan atur mask agar objek hanya dicek terhadap objek yang relevan.
• Sesuaikan physics tick. Default Godot adalah 60 tick per detik. Untuk game yang tidak butuh presisi tinggi, turunkan physics/ticks_per_second di Project Settings — separuh tick berarti separuh kerja CPU untuk physics.

Perhatikan juga sinyal body_entered dan body_exited yang bisa membanjiri saat banyak objek bersentuhan. Gunakan monitoring mati pada Area2D yang tidak butuh deteksi aktif, dan pertimbangkan memakai set_deferred untuk mengubah properti physics agar tidak terjadi di tengah tick.

#Memory dan FPS Budget

Dua metrik yang wajib dipantau: memory dan FPS. Memory yang naik terus-menerus menandakan kebocoran — biasanya karena node atau texture yang tidak pernah dibebaskan. Selalu ingat pola dasar Godot: node yang ditambahkan harus dihapus, texture yang dimuat harus dilepas. Tool yang berguna adalah get_node_count() dan ResourceMonitor (Debug → Monitors → Memory).

FPS yang tidak stabil sering kali bukan masalah GPU, melainkan spike: satu frame yang sangat berat di antara frame-ringan. Penyebab umumnya adalah load() yang memuat scene atau texture besar di tengah permainan, atau change_scene yang tidak ditangani dengan baik. Solusinya: muat scene dan asset secara asinkron, lalu tampilkan loading screen sementara menunggu:

Memuat scene secara asinkron

func muat_level(level: String) -> void:
    ResourceLoader.load_threaded_request(level)
    var state := ResourceLoader.load_threaded_get_status(level)
    if state == ResourceLoader.THREAD_LOAD_LOADED:
        var scene: PackedScene = ResourceLoader.load_threaded_get(level)
        get_tree().change_scene_to_packed(scene)

Tentukan juga target FPS yang realistis. Game 2D sederhana sering berjalan di 120 FPS tanpa masalah, tetapi jika perangkat targetnya lemah, pasang Engine.max_fps atau application/run/max_fps untuk menjaga konsistensi dan baterai.

#Optimisasi saat Export

Optimasi tidak berhenti di editor — pengaturan export juga menentukan performa. Di dialog Export, beberapa pilihan yang berdampak besar:

• Texture compression: aktifkan kompresi texture yang sesuai platform. VRAM compression (ETC2/ASTC untuk mobile, BC untuk desktop) jauh lebih cepat dimuat dan lebih hemat memory GPU.
• Occlusion culling dan visibility range untuk 3D: objek yang tidak terlihat tidak perlu digambar.
• Limit physics dan audio sesuai kebutuhan game, lalu jalankan --headless atau --quit-after di CI untuk memastikan game tidak error tanpa display.

Kebiasaan yang paling terlihat dampaknya di ekspor: periksa apa yang ikut terpaket. Scene atau asset yang tidak dipakai menambah ukuran file dan waktu load. Gunakan Resource Manager untuk membersihkan file yang tidak dirujuk sebelum export.

#Export Templates dan Pengaturan Platform

Saat mengekspor, Godot membutuhkan export templates — versi runtime Godot yang khusus platform tujuan. Install lewat menu Editor → Manage Export Templates, lalu pilih template di dialog Export. Ada dua jenis: debug (untuk pengembangan, lebih besar dan lambat) dan release (untuk distribusi, lebih kecil dan cepat). Selalu export dengan template release untuk pengguna akhir.

Setiap platform punya pengaturan spesifik: di Android kalian mengatur min_sdk dan target; di iOS bitcode dan signing; di Windows icon dan aplikasi yang bersih; di Linux format AppImage atau tar. Yang terpenting: uji build sejak awal, bukan di akhir — masalah platform (icon, permission, path) jauh lebih murah diperbaiki lebih cepat.

#Penutup

Performa adalah disiplin mengukur, bukan menebak: profiler bawaan dan performance monitor menunjukkan di mana waktu benar-benar habis, batching dan atlas texture menekan draw calls, physics disetel dengan membatasi body dan menyesuaikan tick, memory dan FPS diawasi dengan muat asinkron dan target FPS, dan saat export kalian mengatur kompresi texture, culling, serta memakai export template release.

Inti yang harus dibawa pulang:

• Ukur dengan profiler sebelum mengoptimasi apa pun; tanpa data, optimasi hanya tebakan.
• Draw calls adalah bottleneck CPU; atlas texture dan batas jumlah objek adalah solusinya.
• Physics disetel lewat jumlah body, layer/mask, dan ticks_per_second.
• Muat scene dan asset secara asinkron untuk mencegah spike FPS.
• Pakai export template release dan kompresi texture yang sesuai platform.

Di episode 15, setelah game cepat dan mulus, giliran workflow kalian yang dioptimalkan: custom tools & editor plugins — membuat EditorPlugin, script dengan @tool, custom inspector, hingga automasi asset pipeline. Bayangkan kalau editor bisa bekerja untuk kalian, bukan sebaliknya.