Belajar Game Developer - Game Design Collaboration

#Pendahuluan

Di episode 1 kita menyinggung bahwa game developer tidak bekerja sendiri — ia bekerja bersama designer. Episode ini membedah kerja sama itu secara khusus, karena kualitas game ditentukan di celah antara desain dan kode. Desainer punya visi, programmer punya teknik; keduanya harus bertemu untuk menghasilkan game yang terasa hidup.

Kita akan bahas bagaimana programmer berkolaborasi dengan game designer, memahami game feel (mengapa kontrol terasa enak) dan mechanics dari sisi teknis, serta menjalankan iterasi desain yang berbasis data playtest. Di akhir, kita iterasi lompatan Rimba Runner — satu parameter, satu pengukuran, sampai terasa benar.

#Bahasa Bersama Programmer dan Designer

Penyebab terbesar konflik programmer-designer bukan kemampuan — tapi bahasa. Designer berbicara rasa ("lompatannya terasa berat"), programmer berbicara angka (gravity = 1500). Jembatannya: menerjemahkan rasa menjadi parameter yang bisa diubah.

Kunci praktisnya: semua angka desain harus tuningable tanpa masuk ke kode. Di Godot pakai @export, di Unity public field / ScriptableObject, di Unreal UPROPERTY + Data Table. Begitu designer bisa mengubah angka di editor, diskusi berubah dari "tolong ubah kodenya" menjadi "coba gravity 1800, rasakan perbedaannya" — iterasi puluhan kali lebih cepat.

Parameter desain yang bisa di-tuning

@export_group("Movement Tuning")
@export var run_speed := 300.0
@export var jump_velocity := -500.0
@export var coyote_time := 0.1
@export var jump_buffer := 0.15

Perhatikan: semua parameter angka gerak dikelompokkan dan terlihat di editor. Designer bisa memainkan feel tanpa menyentuh logika. Ini bukan kenyamanan — ini infrastruktur kolaborasi.

#Game Feel: Mengapa Kontrol Terasa Enak

Game feel adalah sensasi keseluruhan saat berinteraksi dengan game: berat, kecepatan, respons, dan kepuasan. Ia dibangun dari detail kecil yang bisa dihitung dan diprogram:

• Timing: response terhadap input dalam 1-2 frame (terasa instan) vs 100 ms (terasa telat). Jump buffer & coyote time (episode 6) adalah contoh.
• Curve: gerakan tidak harus linear. Kurva ease-out (mulai cepat, melambat) membuat lompatan terasa "menendang"; ease-in membuat terasa berat.
• Squash & stretch: sprite memipih saat mendarat, meregang saat melompat — animasi sederhana yang memberi bobot.
• Juice: efek partikel, sedikit screen shake, flash — respons visual kecil yang membuat aksi terasa berdampak.

Contoh konkret — lompatan dengan variable jump height: jika pemain melepas tombol lebih awal, kecepatan lompatan dipotong, sehingga karakter melompat rendah. Satu fitur ini mengubah lompatan dari "saklar mati-nyala" menjadi kontrol yang terampil:

Variable jump height

if Input.is_action_just_released("jump") and velocity.y < 0:
    velocity.y *= 0.5   # potong kecepatan naik → lompat rendah

Designer tidak akan meminta "velocity.y dikali 0.5" — ia akan minta "pemain bisa lompat rendah dengan tap cepat". Pekerjaan programmer adalah tahu parameter mana yang menghasilkan rasa itu.

#Mechanics dan Iterasi Desain

Mechanics adalah aturan yang membentuk gameplay: bagaimana pemain berinteraksi dengan dunia. Dari sinilah iterasi desain dimulai. Siklus standarnya:

1. Prototipe — bangun versi kasar mekanik dalam sehari (fokus fungsi, bukan grafis).
2. Playtest — orang lain memainkannya; kumpulkan reaksi.
3. Ukur — apa yang bisa diukur? Waktu menyelesaikan level, jumlah kematian, titik di mana pemain berhenti.
4. Iterasi — ubah satu variabel desain berdasarkan data, mainkan, ulangi.

100%

Data yang bisa diukur di Rimba Runner: jumlah kematian per level, waktu per level, skor rata-rata, dan posisi kematian. Kalau semua pemain mati di titik yang sama, level itu terlalu sulit — bukan "pemainnya kurang jago". Desain yang didukung data menghindari perdebatan opini.

#Komunikasi yang Efektif

Kerja sama programmer-designer juga soal proses. Praktik yang membuat tim sehat:

• Tulis design brief ringkas sebelum implementasi: apa yang dilakukan mekanik, kapan sukses, apa yang dihindari. Selembar kertas ini mencegah implementasi yang meleset dari maksud.
• Demo sering, diskusi pendek — tunjukkan prototipe, bukan presentasi panjang. Reaksi 10 menit lebih berharga daripada dokumen 10 halaman.
• Jangan defensif — umpan balik tentang gameplay bukan serangan pada kode. Matikan ego, dengar kenapa sesuatu terasa buruk, lalu cari solusi teknis.
• Bicarakan angka, bukan kepribadian — "waktu respawn 3 detik terasa lama" lebih baik daripada "game-nya lambat".

#Praktik: Iterasi Desain Rimba Runner

Iterasi lompatan sebagai latihan lengkap:

1. Prototipe — parameter lompat sudah @export (dari episode 6).
2. Playtest — minta tester memainkan level 1; catat komentar rasa lompatan.
3. Ukur — berapa kematian di bagian lompat sempit? Berapa lama pemain ragu sebelum melompat?
4. Iterasi — ubah satu parameter (misal tambah coyote time dari 0,1 ke 0,15), mainkan, ukur ulang.
5. Konvergen — ulangi sampai playtest menunjukkan lompatan "tidak terpikirkan" (tidak dikomentari = sudah natural).

#Penutup

Kolaborasi desain adalah keterampilan yang menentukan kualitas akhir game.

Inti yang harus dibawa pulang:

• Terjemahkan "rasa" desain menjadi parameter tuningable yang bisa diubah tanpa kode.
• Game feel = timing, curve, squash & stretch, juice — semua bisa dihitung dan diprogram.
• Siklus iterasi: prototipe → playtest → ukur → ubah satu hal → ulangi.
• Komunikasi sehat: brief ringkas, demo sering, bicara angka bukan opini.
• Satu perubahan per iterasi, dengan pengukuran yang konsisten.

Di episode 18 selanjutnya kita akan mengamankan game: game security & anti-cheat — server authority, anti-tamper, dan cheat detection, lengkap dengan praktik keamanan dasar Rimba Runner. Sampai jumpa di episode 18!