Masih melanjutkan materi tentang Scene organization, masih di bagian koneksi antar node.
Intinya ada dua:
- Seperti di postingan sebelumnya, usahain suatu scene atau script bisa berdiri sendiri tanpa perlu memiliki reference di luar scene nya. Ini dilakukan agar kalau ada perubahan di objek reference-nya, scene tersebut tidak terlalu terpengaruh. Kalau tidak memungkinkan, usahakan scene tersebut terhubung dengan scene lain secara anonim (pakai signal atau semacamnya) alias ‘loose-coupling’.
- Semua aturan Object Oriented Programming (OOP) berlaku pada scene dan script, termasuk:
- SOLID, aturan-aturan biar kodenya rapih, fleksibel, dan gampang di -maintain (artinya lebih mudah buat diutak-atik). Bisa baca wikipedia buat penjelasannya, tapi kalau mau dengan contoh langsung, cek ini.
- DRY, akronim dari “Don’t Repeat Yourself”. Intinya sebisa mungkin jangan nulis dua kode dengan fungsi yang sama.
- KISS, alias “Keep It Simple, Stupid!”. Aku memahaminya sebagai: “Tulis kode yang bisa dipahami tanpa mikir”. Mungkin begitu.
- YAGNI, akronim dari “You Aren’t Gonna Need It”. Tahan diri dari godaan buat nulis kode yang fungsinya belum dibutuhkan saat ini agar kodenya gak terlalu kompleks dan sulit di-maintain.
Bagian selanjutnya dari bab ini adalah tentang menentukan struktur SceneTree, atau hirarki node dalam game. Sebaiknya saya tuliskan berurutan:
- Buat sebuah node “Main” dengan script (misalnya main.gd). Ini akan menjadi “entry point” atau titik awal saat kita mau mulai menelusuri logika game. Node utama ini akan menjadi parent dari node lainnya seperti “World” dan “GUI”.
- Pergantian level atau layar dapat dilakukan dengan mengganti objek scene di bawah “World”. Dibanding bikin scene utama dan pindah-pindah ke scene lain saat ganti level, kita bisa punya kontrol lebih, seperti yang pernah saya lakukan di sini.
- Tentukan apakah suatu script atau scene menggunakan Autoload atau node biasa. Perhatikan bagaimana data di simpan dan dengan scene lain.
- Pastikan masing-masing subsistem punya tempat khusus di hirarki. Dengan kata lain, kelompokkan dengan rapih.
- Sebaiknya, hubungan parent-child ditentukan bukan karena relasi posisi (misal, child ngikutin posisi parent), tapi hubungan dependensi. Dengan kata lain, jadikan suatu node child atau parent hanya jika ia tidak akan berfungsi kecuali seperti itu. Ini dimaksudkan agar jika node diubah, parent atau childnya ga terpengaruh.
- Player sebaiknya juga tidak menjadi child dari suatu level. Tempatkan di posisi lain dalam hirarki.
- Jika posisi suatu node tergantung node lain, pakai RemoteTransform saja.
Meski sudah ditulis pun, sejujurnya saya kurang paham konsep-konsep di atas. Semuanya teori abstrak yang masih ambigu. Seperti ada rasa gatal untuk mempraktikkan atau memvisualisasikannya sebelum bisa paham.
Atau seperti tiba-tiba bahasa Inggrisku jadi payah dan kalimat-kalimat penjelasannya jadi sulit dipahami. Mungkin memang perlu mengenal dulu praktik-praktiknya baru bisa memahami “praktik terbaik”.
Jadi, sebaiknya memang saya mulai bikin proyek buat praktik teori-teori ini dulu. Mungkin satu bab lagi deh.