Tag: godot best practices

“Studi literatur” terakhir sebelum benar-benar melakukan “practices”. Sudah kuterima saja kalau manualnya perlu dibaca berulang kali biar ngerti dan kalaupun sudah ngerti ada saja pemahaman yang berubah saat baca bagian lain.

Bab III: When to use scenes versus scripts

Aku belum sepenuhnya paham kenapa ada pertanyaan: “Pilih scene atau script?”. Mungkin karena di Godot kita bisa membuat scene yang merupakan instance dari tipe node tertentu, juga bisa membuat script dengan class_name yang keduanya dapat digunakan sebagai class. Namun, perbedaan keduanya cukup jelas bukan?

Secara umum, scene lebih cepat dan bagus performanya. Namun, script bisa bikin tipe node baru yang mempermudah pengembangan, khususnya kalau mau bikin tool internal atau plugin.

Kesimpulannya sih katanya begini:

• Kalau perlu bikin tool internal atau plugin yang bakal dipake oleh non-programmer, bikin class pakai script.
• Kalau perlu bikin suatu class atau konsep sistem yang cuma berlaku di game ini, bikin scene aja. Scene lebih mudah diedit dan lebih “secure”.

Selebihnya, hanya bisa dipahami dengan praktik. Mungkin belajar “best practices” dengan baca manual secara berurutan bukan cara terbaik. Nanti aku belajar bikin game jenis tertentu lewat ngikutin tutorial lalu dibandingkan dengan “best practices” aja.

Masih melanjutkan materi tentang Scene organization, masih di bagian koneksi antar node.

Intinya ada dua:

1. 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’.
2. 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:

1. 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”.
2. 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.
3. Tentukan apakah suatu script atau scene menggunakan Autoload atau node biasa. Perhatikan bagaimana data di simpan dan dengan scene lain.
4. Pastikan masing-masing subsistem punya tempat khusus di hirarki. Dengan kata lain, kelompokkan dengan rapih.
5. 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.
6. Player sebaiknya juga tidak menjadi child dari suatu level. Tempatkan di posisi lain dalam hirarki.
7. 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.

Paska mengerjakan proyek di pelatihan Game Development Professional Program, saya menyadari bahwa untuk memahami teori-teori pemrograman yang baik memerlukan praktek dan pengalaman. Selain itu, saat membaca kriteria rekrutmen dalam iklan lowongan kerja, saya merasa bisa ngoding saja tidak cukup; harus paham tata cara pemrograman yang baik dan benar. Karenanya, saya terpikir, mungkin saya perlu belajar ‘best practices’. Dan karena aku masih ingin ngulik Godot, saya belajar dari sini.

Saya masih percaya kalau ‘praktik terbaik’ itu bukan segalanya. Ada yang bilang, kode pemrograman dengan praktik terbaik adalah: yang jalan. Namun, saya yakin bahwa menguasai ‘praktik terbaik’ bisa menjadi nilai tambah yang membuat kita dipandang lebih mampu bekerja dalam tim dan dalam proyek besar. Kebanyakan ‘praktik terbaik’ dibuat agar enak buat temen kerja. Meskipun solo, tata cara membuat kode yang baik, khususnya yang membuat kode bisa dipahami dan mudah dikembangkan sendiri adalah bentuk self-love yang sebaiknya dilakukan programmer.

Maka untuk beberapa hari ke depan, saya coba meringkas (sepahamnya) dan mempraktikkan satu per satu bab-bab dari manual ‘best practices’ Godot tersebut.

Bab I: Applying object-oriented principles in Godot

Scene dalam Godot adalah Class.

Itu saja yang benar-benar kupahami dari bagian itu. Namun, ini mengubah mindset saya yang menganggap scene di Godot itu ibarat scene dan prefab di Unity. Mungkin di class diagram, tiap blok class bisa dianggap scene. Setiap objek di hirarki dalam scene bisa dianggap sub-class yang diperlukan oleh method atau property dari class. Mindset ini perlu diuji.

Hal lain yang perlu diingat:

• Node adalah instance dari tipe node (Node2D, Control, Button, dll.) yang juga merupakan class
• Tiap membuat script dalam node, maka ia menjadi ekstensi (atau child?) dari class tipe node tersebut

Bab II: Scene organization

Saya baru baca bagian pertama yang menjelaskan tentang bagaimana hubungan antar node dilakukan. Pada dasarnya, mengulang tentang hal yang selalu saya ingat di Godot: Dari parent ke child pakai method, dari child ke parent pakai signal. Namun, selain itu ada beberapa cara spesifik yang menarik untuk diuji.

Sesuai dengan prinsip ‘loose coupling’, tiap class sebaiknya bisa digunakan tanpa dependensi. Bahkan, manual ini menyarankan agar tiap scene memuat data dan node yang diperlukan tanpa bergantung pada scene lain. Ini dilakukan agar programmer tidak perlu terlalu banyak bikin dokumentasi biar tidak lupa hubungan antar scene atau node. Agar tidak susah-susah seperti itu, disarankan juga pakai tool script seperti _get_configuration_warnings() yang dapat memberi tanda peringatan di samping node pada hirarki jika scene tidak merujuk pada node tipe tertentu.

Dan di sini saya mulai keluar jalur.

Karena tool script ini gak jalan, saya jadi cari-cari di dokumentasi dan juga googling. Susah dapat artikel yang membahas ini. Sampai akhirnya nemu video dari while(free) yang merupakan video kedua dari seri “Godot 4 Editor Scripting Series“. Playlist tersebut intinya membahas penggunaan @tool untuk memanipulasi inspector objek di editor Godot. Aku jadi tertarik meski tidak terlalu penting untuk saat ini.

Video kedua menjawab pertanyaan saya, namun tidak mungkin dipahami tanpa menonton video pertama. Video ketiga menunjukkan cara membuat dropdown menu seperti isian enum tapi menggunakan item-item dari array yang diinput dari inspector juga. Namun, pilihan dropdown menu itu hanya diperbaharui jika kita men-deselect node dan memilihnya lagi. Video keempat hasilnya kira-kira sama dengan video ketiga, tapi caranya lebih ribet tapi mungkin lebih terstruktur.

Belum kepikiran kapan aku akan mengimplementasikan teknik manipulasi editor ini, tapi mungkin saat diperlukan aku akan ingat video-video ini.

Kembali ke jalur.

Sebaiknya saya coba dulu mempraktikkan teori-teori di atas sebelum lanjut ke bagian berikutnya. Namun, aku sebaiknya juga menyelesaikan membaca Bab 2 ini.