Algoritma Pemrograman Unity

Ada banyak bahasa pemrograman di dunia. Misalnya Assembler, Pascal, C, C++, Basic, Java, C#, Phyton, ASP, PHP, Ruby dan lainnya. Masing-masing memiliki bentuk, struktur, fungsi, penggemar serta komunitas tersendiri.

Sudah bahasanya banyak, IDE dan editor yang digunakan pun sangat beragam.
Untuk Pascal ada Editor text, Free Pascal/Lazarus dan Borland/Embaracedero Delphi. Untuk keluarga C ada Visual Studio, SharpDevelop, dan Xamarin yang juga bisa digunakan untuk pemrograman mobile. Untuk PHP kebanyakan editor text seperti Notepad++, ATOM atau yang agak ‘berat’ seperti Dreamweaver dan Aptana Studio. Belum lagi IDE Java seperti Netbeans dan Eclipse.
Saya tidak bisa menguasai semua bahasa dan IDE itu. Dan saya juga ragu ada mahasiswa yang bisa menguasai semuanya. Kecuali kalau dia sangat jenius.

Masalahnya, dunia nyata cukup kejam. Proyek yang ada per tahunnya kadang sudah dipatok untuk menggunakan bahasa pemrograman tertentu dan IDE tertentu, untuk PHP bahkan framework tertentu.
Saya seorang Delphi Minded murni. Dan sialnya, saya pernah terlibat dalam sebuah proyek simulator menggunakan C# + Visual Studio, salah satu bahasa dan IDE yang sangat saya benci.



Lalu bagaimana saya mengatasi hal itu?

Saya membuat sebuah Pola Pemrograman (yang diturunkan dari prinsip pemrograman Delphi) untuk mengatasi gap antara kemampuan saya dengan Delphi yang berbahasa Pascal dan Visual Studio dengan bahasa yang sangat saya benci: C#.

Percayalah, istilah itu tidak akan anda temukan di tempat lain. Soalnya itu adalah istilah yang super ngarang. Istilah yang paling dekat mungkin blok diagram dari sebuah algoritma.
Pola Pemrograman yang saya pikirkan kurang lebih seperti ini.



Intinya, dalam sebuah aplikasi terdapat 3 buah unsur besar yaitu Initizaliation, Operation State, dan Finalization.

Initialization bisa berisi koneksi ke database, seting client server atau library pihak ketiga yang mungkin digunakan.

Finalization bisa digunakan untuk memutuskan semua koneksi atau menghancurkan resource yang telah digunakan untuk menghemat memori.

Initialization dan Finalization umumnya telah dienkapsuliasi secara otomatis dengan IDE. Meski ada beberapa yang harus dibuat manual.
Dan yang paling utama tentu saja adalah Operation State, yang berupa kumpulan program inti yang telah dibangun oleh programmer (biasanya) dengan berdarah-darah.
Perhatikan pola umumnya.

Ada sebuah Form yang berisi Object (misalnya button, text, combobox) dan Unit (yang merupakan source code utama program). Ketiga komponen inilah yang membentuk alur standar baku dalam dunia pemrograman yaitu Input > Proses > Output.

Jadi untuk bahasa pemrograman atau bahkan IDE yang berbeda, saya cukup memetakan pola pemrograman ini agar tidak terlalu pusing jika terpaksa harus pindah ke lain coding. Misalnya pada saat saya harus memetakan ke dalam Visual Studio. Saya cukup mengubahnya seperti ini:



Alhamdulillah, secara umum bentuk umum Visual Studio tidak terlalu beda dengan Delphi. Sehingga saya hanya harus fokus pada ekstensi file yang berbeda, dan script yang 180 derajat bertentangan. Soal ini, saya menjadi sangat tergantung pada script references C#..

Bertahun-tahun berlalu dan pola pemrograman ini masih tetap saya gunakan. Ketika saya pertama kali mempelajari pemrograman mobile (Android Studio), saya coba petakan skema ini. Dan hasilnya, ada perubahan sedikit, tapi tidak terlalu signifikan.



Perbedaan terbesar mungkin adanya fitur pause dan resume (yang sebenarnya) mirip dengan OnDeactive dan OnActive pada pemrograman Desktop biasa. Secara garis besar semuanya sama.
Gampangnya gini deh. Seluruh bahasa pemrograman dan IDE itu dapat digeneralisir seperti berikut:

Aplikasi itu terdiri dari satu atau beberapa FORM/PAGE/LAYOUT yang berisi OBJECT/WIDGET/CONTROL yang dikendalikan oleh sebuah UNIT/SCRIPT/ACTIVITY.
Hubungannya satu ke satu. Secara umum. Bisa lebih jika menggunakan library atau package lain. Tapi intinya seperti itu.

Lalu bagaimana dengan Unity?

Unity itu beda.

Saya bahkan harus menghabiskan waktu bertahun-tahun hanya untuk memahami arsitektur Unity karena pola pemrograman Unity tidak sama dengan yang pernah saya kenal dan bahkan tidak bisa dipetakan kepada diagram Pola Pemrograman yang pernah saya buat.
Saya frustasi.



Saya berpikir lama sebelum akhirnya saya menyadari jika pola Game Engine TIDAK SAMA dengan pola aplikasi apa pun platformnya.

Game Engine memiliki skema khas yang tidak dimiliki oleh aplikasi sejenis.

Sebagai perbandingan ini adalah aplikasi yang pernah saya buat dulu menggunakan Borland Delphi dan Game Engine True Vision 3D.

Pada jaman masa kegelapan (duh, berasa tua), sebuah game engine harus numpang di sebuah bahasa pemrograman untuk dapat digunakan.



Dan pada kasus TV3D ini, pola pemrogamannya sendiri memang sudah berbeda. Dulu dosen saya, (lupa namanya), pernah menyebutkan tentang sebuah fungsi sakral yang kala itu tidak diketahui kegunannya.

Looping Forever.

Sebuah loop berulang yang dijalankan terus menerus sampai aplikasi dimatikan. Proses loop tanpa henti jelas akan memakan resource yang sangat besar. Masalahnya, semua proses rendering game menggunakan mekanisme Looping Forever.

Makanya tidak heran jika game baik 2D atau bahkan 3D selalu membutuhkan proses yang lebih tinggi. Karena memang kunci dari semua proses game development terletak dari fungsi sakral yang satu ini.

Jika fungsi sakral itu kita masukkan ke dalam pola pemrograman yang pernah saya buat, maka hasilnya akan menjadi seperti berikut.



Intinya hanya ada 1 form utama yang melakukan render. Sisanya adalah unit-unit tambahan yang memberikan support pada form utama untuk menampilkan apa pun yang harus ditampilkan.
Dalam Delphi, fungsi Looping Forever ini dimasukkan ke dalam method FormUpdate dan fungsi render TV3D nya dibatasi dengan 2 fungsi dasar: BeginRender dan EndRender.

Saya kemudian mencoba pola pemrograman ini pada beberapa game engine lainnya seperti Ogre3D, Irrlicht, Lazarus, bahkan Carmenta Spatial Ace dan Vega Prime.

Semuanya sama. Prinsip kerja beberapa game engine itu sama persis dengan diagram yang saya buat. Ah, saya memang hebat.

Saya lantas berpikir jika si Unity ini pun prinsipnya sama.

Ternyata tidak.

Unity itu beda.

Saya frustasi. Lagi.


Sampai kemudian saya mengikuti pelatihan Unity yang diselenggarakan oleh Gunung Batu Enterprise via Mang Ugeng, saya pun mulai paham mengenai arsitektur Unity yang sebenarnya.
Anda bisa membaca soal itu di sini: Kursus Unity Rp. 30 Juta

Unity itu keren.

Asli.

Beberapa fungsi “ecek-ecek” Unity ternyata sama persis dengan fungsi yang pernah saya buat menggunakan TV3D. Beberapa hal yang dulu membutuhkan puluhan baris, kini diselesaikan oleh library Unity hanya dengan 1-2 baris.

Kelihatannya para developer Unity paham betul atau minimal pernah mengalami sulitnya membuat game jika menggunakan engine jadul. Dan mereka menemukan solusinya.
Secara umum, pola pemrograman Unity yang bisa saya petakan adalah seperti ini:



Perbedaan terbesar dari pola pemrograman Unity dan pola pemrograman visual biasa, atau bahkan sesama pola game engine adalah, Unity memisahkan porsi untuk mesin dan porsi untuk manusia dengan sangat jelas.

Maksudnya begini.

Secara mesin, apa yang dihasilkan dengan Unity tidak ada bedanya dengan apa yang dihasilkan oleh Delphi + TV3D. Sama-sama biner, sama-sama exe.

Perbedaannya terletak justru pada interaksi dengan manusia yaitu developer.

Salah satu yang paling signifikan adalah Unity “menyembunyikan” fungsi Looping Forever dari mata para developer.

Kebanyakan dari pengguna Unity pemula bahkan beberapa jago Unity senior tidak pernah tahu kenapa setiap baris yang dipasang di fungsi Update() akan berjalan secara otomatis. Mereka hanya menganggap, ya memang harusnya begitu. Namanya juga fungsi Update kan?
Padahal aslinya nggak begitu.

Unity membungkus mekanisme yang rumit itu sedemikian rupa sehingga para programmer cukup fokus pada konten sedangkan urusan render biar ditangani langsung oleh Unity.
Pola ini juga yang akhirnya berhasil menjawab pertanyaan saya beberapa tahun yang lalu.

Di mana Main Function Unity?

Unity “menyembunyikan” Main Function-nya.
Unity akan menjalankan Scene Pertama dan secara berurutan menjalankan semua script yang sudah ready termasuk berpindah ke Scene lain.

Apa yang dimaksud dengan script sudah ready?

Yaitu Script yang sudah dipasang di GameObject yang sudah dipasang di Scene.

Bingung?

Gambaran eksekusi Unity kurang lebih seperti ini.



Jadi dalam Unity, anda cukup fokus pada panel Hierarchy Scene karena panel itulah yang akan berisi GameObject yang akan digunakan pada game anda. Sedangkan panel Assets berisi seluruh GameObject, Script, dan Gambar yang mungkin digunakan, mungkin tidak dalam game anda.
Unity akan melakukan kompilasi secara selektif dan hanya mengikutkan GameObject yang benar-benar digunakan saja pada produk akhir.

Kalau cara saya dulu, saya cek manual via windows explorer file-file yang akan digunakan, dan hapus yang tak berguna. Ribet? Memang.

Makanya Unity itu beda.

Hal lainnya yang juga sangat berbeda adalah: Unity menjalankan script yang dipasang pada GameObject secara independen.

Perhatikan pola perbedaan ini.

Pemrograman Visual: 1 FORM + 1 UNIT = RESULT
Game Engine: 1 FORM + 1-n UNIT = RESULT
Unity: 1 SCENE + (1 GAMEOBJECT + 1-n Script) * n = RESULT
Dalam Unity, 1 buah GameObject bisa memiliki beberapa buah script sekaligus. Memangnya kenapa kalau dibikin korelasi 1 ke 1? Kan bisa saja?

Benar.

Tapi Unity sengaja membedakan hal ini agar pengembangan game bisa menjadi sangat fleksibel dan pemrograman berorientasi objeknya lebih kerasa.

Unity itu multi-platform. Sekali ngoding bisa dipublish di mana saja.

Unity itu punya lisensi free yang bisa digunakan oleh perorangan atau indi studio untuk pembuatan game komersil dengan penghasilan maksimal di bawah $100.000 per tahun.

Dan Unity itu beda.

Percayalah.

Jika anda pernah mengalami masa-masa sulit membuat pemrograman game dengan engine-engine zaman kegelapan yang saya sebutkan di atas, anda pasti setuju dengan pendapat saya.