Selama beberapa dekade, pemrogram game mengembangkan berbagai teknik untuk memformalkan dan membantu memecahkan masalah penerapan NPC yang cerdas dan menyenangkan. Teknik yang paling dikenal adalah:

  • Mesin negara (Terbatas).
  • Pohon perilaku

Teknik-teknik tersebut membantu pemrogram game dan desainer game untuk mengulangi penerapan perilaku NPC dan juga mampu mempertimbangkannya.

Dengan semakin populernya ECS (Entity Component System), muncul pertanyaan: Apakah teknik tersebut kompatibel dengan ECS?

Menurut saya, meskipun kita perlu mengkajinya, berapa biayanya.

Mari kita mulai dengan mesin negara

Mesin negara adalah pilihan yang sangat bagus jika Anda dapat mengidentifikasi keadaan NPC yang terpisah dan jika Anda perlu membatasi kemungkinan transisi dari satu keadaan ke keadaan lainnya. Seringkali kita juga dapat mendefinisikan peristiwa/tindakan yang akan bertanggung jawab atas transformasi keadaan dan peristiwa/tindakan yang akan dipicu ketika transformasi dilakukan.

Di ECS, negara bagian direpresentasikan dengan komponen-komponen yang diasosiasikan oleh suatu entitas. Manipulasi keadaan dilakukan oleh sistem, yang menanyakan entitas berdasarkan tipe komponen. Dalam ECS, suatu entitas hanya dapat diasosiasikan dengan satu instance dari tipe komponen tertentu, namun karena kita dapat memiliki jumlah tipe komponen yang “tak terhingga”, ruang statusnya pun menjadi tak terhingga.

Mari kita lihat contoh yang lebih praktis

Lampu lalu lintas dapat memiliki 3 keadaan, Merah, Kuning, Hijau. Jika kita mendefinisikan komponen flag untuk setiap negara bagian, kita dapat menambahkan ketiga komponen tersebut ke entitas yang sama, sehingga mematahkan logika kita. Untuk memberikan batasan pada keadaan, kita dapat mendefinisikan satu komponen saja: TrafficLightStateComponent, yang menyimpan nilai enum TrafficLightState yang memiliki 3 kasus red, yellow, green. Dengan cara ini, kita dapat memastikan bahwa suatu entitas yang mewakili lampu lalu lintas hanya berada dalam satu keadaan valid.

Bagaimana dengan kendala dalam transformasi negara?

Katakanlah kita ingin memastikan bahwa red tidak dapat berubah langsung ke green tanpa berada dalam status yellow. Hal ini sebenarnya jauh lebih rumit. Apa yang dapat kami lakukan adalah menerapkan TrafficLightStateComponent sedemikian rupa sehingga pengembang tidak dapat menetapkan nilainya secara langsung, namun hanya menggunakan metode mutasi publik, yang akan memeriksa apakah transisi yang ingin kami lakukan masuk akal.

Bagaimana dengan melakukan tindakan terhadap perubahan negara?

Perubahan status dalam skenario ECS kami adalah pembaruan nilai komponen. Ada konsep sistem reaktif, di mana suatu sistem (atau lebih tepatnya kode tertentu dalam sistem) dieksekusi tidak pada setiap centang, tetapi hanya pada satu centang, setelah terjadi perubahan status entitas.

Kemungkinan implementasi di Unity ECS

Apa yang saya jelaskan di beberapa paragraf terakhir dapat diimplementasikan dalam jangka waktu yang wajar oleh programmer yang terampil, namun seperti yang saya sebutkan, teknik AI dibuat tidak hanya untuk membuat programmer senang, tetapi juga memberdayakan desainer game dan membantu kedua belah pihak memahami a perilaku NPC yang kompleks, dengan memvisualisasikan keadaan saat ini dalam aplikasi yang sedang berjalan.

Untuk mencapai semua ini, kita memerlukan alat editor, yang memungkinkan kita menentukan status dan transformasi status. Alat ini juga harus menyediakan kemungkinan untuk menghasilkan tipe komponen yang mewakili status dan metode transformasi status yang valid. Alat ini juga dapat menghasilkan infrastruktur untuk sistem reaktif. Dan yang tak kalah pentingnya, ia harus memberikan kemungkinan untuk memilih entitas dengan tipe status saat runtime dan melihat statusnya saat ini.

Pohon perilaku

Menurut pendapat saya, pohon perilaku adalah cara terbaik untuk membuat aliran kontrol dari algoritma yang kompleks, dapat dikonfigurasi dan “dapat diungkapkan” pada tingkat abstraksi tertentu. Segala sesuatu yang dapat kita lakukan dengan pohon perilaku, dapat dilakukan dengan bahasa pemrograman tujuan umum, namun hal ini tidak dapat diakses oleh desainer game dan lebih sulit untuk dievaluasi, khususnya jika Anda memiliki alat untuk memvisualisasikan status pohon perilaku saat runtime.

Memproyeksikan idenya ke ECS, kami menyadari bahwa pohon perilaku dapat mewakili kode internal suatu sistem. Node daun (Aksi dan Kondisi) dari pohon perilaku dapat bekerja secara langsung pada dunia entitas, atau salinan nilai dari dunia entitas.

Ada banyak pertanyaan menarik

  • Haruskah pohon itu terpicu pada setiap centang?
  • Haruskah kita mendukung status simpul yang berjalan dan saat memicu pohon, ia harus melompat langsung ke simpul terakhir yang berjalan?
  • Haruskah node beroperasi pada sekelompok entitas, atau pada satu entitas?
  • Haruskah kita membuat pohon berjalan secara paralel untuk setiap entitas dengan menggunakan tugas?
  • Bagaimana seharusnya pohon tersebut direpresentasikan (dalam editor)?
  • Haruskah node pohon memiliki parameter/statusnya sendiri, atau haruskah semuanya ditentukan dengan komponen dan entitas?

Itu semua adalah pertanyaan bagus dan IMHO sangat sulit untuk memberikan jawaban pasti. Saya kira, satu-satunya jawaban yang masuk akal adalah:

Tergantung pada Alat Pohon Perilaku yang Anda bayangkan.

Anda perlu mengidentifikasi manfaat sebenarnya yang ingin Anda peroleh dengan mengekspresikan algoritma NPC dengan pohon perilaku. Dan selain manfaat dan kerugian yang ditimbulkan oleh pembatasan ECS. Dan jangan pernah lupa:

Kalau tidak pas, jangan dipaksakan.