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.
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
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.
