Peran status entitas dalam sistem berbasis komponen?

8

Sistem entitas berbasis komponen sangat populer akhir-akhir ini; semua orang tampaknya setuju bahwa mereka adalah jalan yang harus ditempuh, tetapi tidak ada yang benar-benar memiliki implementasi yang pasti dari sistem semacam itu. Saya bertanya-tanya, apa peran yang dimiliki entitas (berjalan-kiri, berdiri, melompat, dll) dalam CBS? Apakah mereka bertindak seperti pengontrol (yaitu mereka menangani acara dan mengubah atribut entitas berdasarkan peristiwa tersebut)?

Bagaimana dengan kasus-kasus di mana suatu negara bagian, misalnya, mengharuskan entitas memasuki mode tanpa klip? Haruskah, keadaan itu, ketika masuk, mungkin mengatur CollisionComponent entitas ke null pointer atau sesuatu? (Kemudian, saat keluar, negara harus mengembalikan CollisionComponent entitas ke keadaan sebelumnya.)

Juga, saya kira itu adalah tugas negara saat ini untuk mengubah keadaan entitas menjadi sesuatu yang lain, bukan?

architecture component-based entity-system

— Paul Manta
sumber

5

Saya berpendapat tidak ada "implementasi definitif" karena semua game memiliki persyaratan yang berbeda, dan setiap keputusan yang Anda buat dalam desain sistem memiliki pengorbanannya sendiri. Lakukan saja apa yang masuk akal bagi Anda, dan pastikan untuk refactor ketika semuanya menjadi berantakan.

— Tetrad

@The Bebek komunis, adalah sedikit rendah ... haha

— deceleratedcaviar

9

Saya mendapat kesan bahwa dalam desain berbasis komponen entitas pada dasarnya adalah wadah komponen (dengan kemungkinan beberapa pesan dilemparkan ke dalam). Dilihat dari perspektif ini masing-masing komponen akan menyimpan sedikit keadaan. Misalnya jika komponen perilaku hantu memutuskan perlu memasuki mode tak berwujud, komponen itu juga mengirim pesan ke komponen fisika yang memerintahkannya untuk mengaktifkan tanpa klip. Itu mungkin juga akan mengirim pesan ke ghost-model-components yang memberitahu untuk menendang alpha.

— deft_code
sumber

2

Mesin dan komponen negara adalah teknik ortogonal. Anda dapat memiliki status di komponen Anda atau tidak, sama seperti Anda dapat memiliki status di kelas apa pun. Anda dapat memiliki komponen mengamati (lihat Pola Pengamat) dan mengubah status komponen lain. Mesin negara memiliki banyak kegunaan dan implementasinya akan tergantung pada kebutuhan Anda.

Untuk karakter, karakter yang Anda gambarkan (berjalan, berdiri, melompat), saya telah melihat implementasi di mana semua komponen mempertahankan mesin negara mereka sendiri ... fisika, animasi, kontrol, ai. Komponen-komponen tersebut harus memiliki otoritas yang jelas tentang komponen mana mereka bereaksi, dan komponen mana yang dapat diubah.

— Evan Rogers
sumber

2

Desain Komponen sebagai struktur dengan data saja, tidak ada logika yang lebih kompleks daripada getter dan setter. Jangan membuat dependensi antar Komponen atau Anda akan kehilangan sebagian besar manfaat Sistem Entitas.

Lihat contoh pendekatan ini (dekat dengan visi mesin) di sini: https://github.com/thelinuxlich/starwarrior_CSharp

Dan mesinnya sendiri: https://github.com/thelinuxlich/artemis_CSharp

— thelinuxlich
sumber

Saya sangat tidak setuju dengan "tidak ada logika yang lebih kompleks daripada getter dan setter", tapi saya datang dari kerangka referensi Unity di mana semuanya merupakan komponen. Saya akan berpikir bahwa komponen harus dapat mengatur diri mereka sendiri.

— Tetrad

1

Itu karena Unity tidak memiliki apa pun sebagai Sistem yang melekat pada permainan itu sendiri, yang memproses entitas yang komponennya membentuk aspek sistem.

— thelinuxlich