Gim heisters adalah gim aksi tactical dimana player akan merampok markas musuh bersama tiga karakter lainnya yang akan membantu. Perlu diketahui sebelumnya pada program heister, setiap karakter dipasang bit kondisi. Sebagai contoh kondisi “kehabisan peluru” pada bit pertama, kondisi “mendengar suara yang mencurigakan” pada bit kedua. Namun jumlah kondisi yang bisa dipasang maksimal sejumlah panjang bit integer yaitu 32. Jadi mesti harus memperhitungkan jumlah kondisi yang akan digunakan. Karena gim heisters ini merupakan gim team-battle, kami memutuskan agar karakter memiliki properti squad-condition. Squad-condition merupakan class properti tambahan yang menyimpan kondisi terkini dari satu squad tim dan dapat melihat siapa saja member yang termasuk ke dalam tim. Selain itu juga memuat informasi member mana saja yang sedang baku tembak, member yang kekurangan darah, objective squad saat ini, dan informasi inventori item-item yang dimiliki masing-masing member. Layaknya bit kondisi miliki persona karakter, Squad condition juga dipasang bit kondisi. Seperti kondisi “squad sedang menjaga pemimpin squad” pada bit pertama, “member sudah standby dekat pintu” pada bit kedua, dan seterusnya.
Saya juga menambahkan satu kelas yang dikhususkan sebagai kelas kontrol untuk squad-condition yang kemudian saya namakan Squad-Member. Kelas ini juga dimiliki masing-masing karakter namun saling berbagi data squad-condition yang sama. Akan tetapi saya di sini tidak melakukan trigger suatu perintah kepada member secara tiba-tiba, saya memasang bit kondisi pada squad-condition tentunya. Misalnya, ada member yang knocked karena kehabisan darah dan squad-condition memiliki kondisi “ada rekan yang knocked” sedangkan saat ini dalam keadaan baku tembak. Maka karakter lain lebih memprioritaskan membunuh musuh terlebih dahulu supaya bisa menolong karakter yang sedang knocked dengan aman. Namun ada efek samping nya yaitu ada jeda waktu sedikit sebelum perintah terpanggil. Hal ini saya lakukan karena menurut saya, input logika sebisa mungkin tetap berangkat dari HFSM yang sudah saya paparkan pada tulisan saya sebelumnya. Terlebih lagi kalau menggunakan sistem event-subcriber atau listener, maka annoucer harus melakukan invoke pemanggilan beberapa kali sampai listener mengkonfirmasi perintah squad. Kesalahan yang saya lakukan di sini adalah tidak merubah kelas squad-member menjadi Partial-Class sehingga skrip program terlalu panjang dan sulit untuk dilakukan debugging untuk mencari error ataupun bug. Apabila saya ditanya model ini sebagai sebuah best-practice, maka jawabnya saya belum bisa pastikan. Saya terbuka akan saran dan kritik apabila pembaca punya pengalaman yang sama. Akhir kata terima kasih sudah membaca artikel yang saya tulis ini.