Sistem Entitas / Komponen dan “Entitas” UI


14

Saya masih hijau untuk sistem entitas / komponen. Saya menemukan bahwa karena saya memiliki komponen yang berguna untuk menggambar sprite (atau spritesheets) dan menangani input (klik mouse / sentuhan), saya secara alami ingin menggunakan kembali ini untuk membuat komponen UI (seperti tombol, misalnya layar tingkat-pilih).

Ini menurut saya sangat aneh. Saya selalu memahami entitas sebagai "model permainan" hal-hal seperti pemain, musuh, power-up, dll. Di sisi lain, dari perspektif penggunaan kembali kode, menggunakan kembali komponen untuk UI masuk akal.

Bagaimana (dan di mana) kekhawatiran UI / GUI masuk ke dalam sistem entitas / komponen?

(Catatan: pertanyaan ini adalah platform agnostik karena berlaku untuk beberapa platform / bahasa)


3
Saya pikir ini masuk akal bagi Anda hanya karena Anda membuat game 2d. Bayangkan Anda akan membuat game 3d (dengan gui 2d) hampir tidak ada logika rendering yang dapat digunakan kembali, dan komponen gu 2d di dunia 3d tidak akan masuk akal. Anda harus membangun GUI di atas sistem komponen. Seperti halnya GameplayScreen Anda menciptakan dunia entitas dengan komponen, dan salah satu komponen akan menjadi kamera dengan "kanvas" yang akan ditampilkan oleh penyaji Anda. Dan kanvas itu akan menjadi latar belakang layar itu.
Kikaimaru

1
@Kikaimaru Anda memiliki poin tentang 2D. Mungkin saya terlalu banyak ke MVC, tapi sepertinya campuran "model" (entitas game) dan view / controller (komponen UI). Memang berhasil, tetapi apakah ini cara yang seharusnya ? Apakah ada cara yang lebih baik? Bagaimana orang lain melakukannya?
ashes999

@ ashes999 komentar dan pertanyaan awal Anda adalah dari lubuk hati saya yang dalam :)
Narek

@Arman, saya tidak pernah mendapatkan jawaban yang memuaskan untuk ini.
ashes999

@ ashes999 saya untuk. Di mana-mana orang mengatakan bahwa Anda tidak boleh mencampur MVC dengan ECS, tetapi mengapa? Bukankah itu menyenangkan? Senjata yang berbeda untuk tugas yang berbeda, tidakkah Anda setuju?
Narek

Jawaban:


4

Setelah menggunakan beberapa sistem entitas-komponen, terutama CraftyJS, saya kurang lebih mendapat jawaban untuk pertanyaan saya: ya, Anda dapat menggunakan kembali komponen (terutama sprite atau gambar dan penangan klik mouse di game 2D) untuk GUI.

Sebagian besar waktu, Anda hanya memiliki akses ke ECS, dan bukan sistem yang mendasarinya (mis. Sistem gambar). Dalam hal ini, boleh saja menggunakan komponen, karena Anda tidak punya pilihan lain.

Jika Anda memiliki akses ke sistem yang mendasarinya (mis. Ruby roguelike dengan akses langsung ke Curses), Anda mungkin menemukan bahwa menggambar / merender langsung pada sistem itu lebih efektif (lebih sedikit kode, kurang rapuh, lebih alami) daripada menggunakan banyak entitas dan komponen.


Di mana Anda meletakkan logika elemen UI canggih? Yaitu. bar kesehatan yang perlu tahu kapan pemain terkena dan berapa banyak untuk mengurangi bar. Saya tidak dapat menyadari apakah itu membutuhkan sistem tertentu, atau naskah atau sesuatu yang lain ...
Emir Lima

@EmirLima untuk hal seperti itu, saya akan menempatkan sebagian besar logika UI di bilah kesehatan (mengubah ukuran bilah kesehatan), dan membuat pemain membuat acara ketika dia terkena, menunjukkan apa yang baru / mengubah nilai kesehatan. (Bilah kesehatan dapat menangkap acara ini dan bereaksi dengan tepat.)
ashes999

Tapi apa objek bar kesehatan dalam arsitektur itu? Apakah ini entitas dengan komponen "bilah kesehatan"? Kelas yang diwarisi dari Entity? Objek normal dengan panggilan pembaruan kode keras?
Emir Lima

1
@EmirLima Saya akan memodelkan bar kesehatan sebagai entitas dan pemain sebagai entitas. Anda dapat melakukan apa pun yang masuk akal bagi Anda.
ashes999

1

Dalam 2D ​​atau 3D, sistem komponen entitas (ECS) setidaknya harus memiliki akses ke sistem GUI, jika itu bukan bagian dari ECS yang sama.

Secara pribadi, saya tidak akan mencampur keduanya. Penggunaan kembali kode untuk GUI hanya benar-benar terjadi di tingkat atas. Menanggapi mouse / keyboard, rendering, dan sebagainya. Fungsi yang diambil oleh tombol yang berbeda, atau informasi yang ditampilkan daftar tertentu sebenarnya bukan sesuatu yang dapat dibuat cukup umum untuk digunakan kembali.

Sebagai contoh, saya akan membayangkan komponen untuk entitas GUI akan seperti position, renderdan gui. Di mana komponen GUI akan menentukan jenis tindakan yang dilakukan entitas GUI. Namun, tindakan itu akan menjadi sangat unik dan spesifik konteks. Ini menghasilkan sistem yang menangani komponen GUI yang sangat besar dan pada dasarnya dirancang untuk menangani masing-masing fungsi GUI (memuat game, menyimpan game, mencari server, dll). Kedengarannya berantakan.

Saya lebih suka melakukan file kelas standar untuk setiap "layar" GUI. Memiliki semua fungsionalitas untuk layar itu di satu tempat (dengan referensi ke kelas fungsionalitas umum). Ini jauh lebih rapi dan lebih mudah dikelola.

Namun, seperti yang saya katakan, ECS harus memiliki akses ke sistem GUI. Perlu untuk dapat memberikan informasi kepada GUI berdasarkan entitas dalam sistemnya. Misalnya, melayang di atas unit sekutu akan memunculkan jendela GUI dengan semua informasi tentang unit itu. Di mana melayang di atas kesatuan musuh akan muncul jendela GUI dengan informasi terbatas. Anda mungkin tidak ingin memprogram GUI untuk mengetahui perbedaan antara keduanya, Anda ingin meminta entitas untuk menampilkan informasinya.

Jadi, entitas kemungkinan masih memiliki beberapa jenis komponen GUI, tetapi mereka akan menjadi entitas "dalam game", bukan entitas GUI. Komponen ini akan menggunakan sistem GUI eksternal untuk membuat antarmuka GUI mereka.


Kedengarannya seperti sistem yang saya miliki sangat berbeda dari yang Anda gambarkan. Saya memiliki kelas entitas seperti TouchButtonyang terdiri dari spritesheet dan pendengar klik-sentuh. Untuk unit popup, saya mungkin akan mengimplementasikannya sebagai kombinasi komponen sprite + komponen pendengar tikus. Hmm.
ashes999
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.