Nyatakan perubahan entitas atau komponen

Saya mengalami beberapa kesulitan mencari cara untuk berurusan dengan manajemen negara di entitas saya.

Saya tidak memiliki masalah dengan manajemen status Game, seperti jeda dan menu, karena ini tidak ditangani sebagai sistem komponen entitas; hanya dengan keadaan dalam entitas / komponen.

Menggambar dari Orc Must Die sebagai contoh, saya memiliki entitas MainCharacter dan Trap saya yang hanya memiliki komponen mereka seperti PositionComponent, RenderComponent, PhysicsComponent.

Pada setiap pembaruan Entitas akan memanggil pembaruan pada komponen-komponennya. Saya juga memiliki EventManager generik dengan pendengar untuk berbagai jenis acara.

Sekarang saya harus bisa menempatkan jebakan: pertama pilih jebakan dan posisi jebakan kemudian tempat jebakan.

Ketika menempatkan jebakan, jebakan itu akan muncul di depan MainCharacter, ditampilkan dengan cara yang berbeda dan mengikutinya. Ketika ditempatkan itu harus merespon tabrakan dan diberikan dengan cara normal.

Bagaimana ini biasanya ditangani dalam sistem berbasis komponen?

(Contoh ini spesifik tetapi dapat membantu mencari cara umum untuk menangani status entitas.)

component-based state

— GriffinHeart
sumber

Bisakah Anda menambah dan menghapus komponen entitas berdasarkan pada acara masukan? Mungkin Anda dapat mengubah komponen jebakan saat kondisi berubah. Misalnya, saat menempatkan jebakan itu akan memiliki FollowComponent dan RenderEffectComponnent. Ketika ditempatkan, Anda menghapus kedua Komponen dan menambahkan CollisionComponent. (Sunting: Lebih jelas diungkapkan oleh Martin Sojka)

— Asakeron

Ya, saya bisa, setiap input diterjemahkan dari "HumanView" ke dalam peristiwa game, yang sebagian besar di antaranya, diproses terlebih dahulu oleh kelas GameLogic saya, yang akan memeriksa misalnya apakah MainCharacter memiliki cukup uang untuk membuat jebakan, bagaimana caranya terjadi setelah itu yang saya coba bayangkan.

— GriffinHeart

Jawaban:

Salah satu aplikasi sistem komponen yang menarik adalah Anda dapat mengubah komponen entitas saat runtime jika Anda mendesainnya agar dapat menangani hal itu. Keadaan suatu entitas dengan demikian menjadi jumlah komponen mana yang ditugaskan padanya dan nilai mana yang dipegangnya.

Sebagai contoh Anda, pertama-tama Anda dapat membuat perangkap dengan BuildControllerComponent(mengatur reaksi terhadap kontrol pemain dalam fase build), a PositionComponentdan a RenderComponent. Yang terakhir memiliki satu bidang data yang mengatur pixel shader (s) yang digunakan, dan salah satunya memberikan trap-to-be-build tampilan "ghostly". Anda akan melihat belum ada komponen fisika yang ditetapkan.

Setelah menempatkan jebakan, komponen-komponen tersebut dipertukarkan. Tidak BuildControllerComponentdiperlukan lagi, jadi itu dihapus. The RenderComponentshader 's diganti dengan yang normal tampilan standar Anda dari perangkap. Akhirnya, PhysicsComponentserta apa pun yang dibutuhkan untuk perangkap untuk bekerja ditambahkan ke entitas.

Dalam pendekatan berbasis warisan, ini setara dengan memiliki konstruktor untuk ActiveTrapEntitykelas yang menggunakan BuildTimeTrapEntitykelas sebagai argumennya, yang kedua digunakan untuk membuat perangkap selama membangunnya, yang pertama digunakan untuk perangkap setelah itu di tempat .

— Martin Sojka
sumber

Ini pintar.

— Cypher

Ini adalah strategi yang baik untuk menerapkan keadaan suatu entitas. Itu tidak membahas masalah bagaimana melacak keadaan setiap entitas. Bagaimana Anda tahu di negara mana entitas saat ini?

— MichaelHouse

@ MartinSojka Ini mendekati apa yang saya pikirkan setelah mengajukan pertanyaan. Saya sedang mempertimbangkan untuk menambahkan BuildTrapProcess (Sesuatu yang diperbarui di GameLogic) yang akan mengelola aspek runtime dari perubahan komponen untuk mencapai perubahan status yang diperlukan untuk membangun jebakan. Ketika tombol untuk membuat jebakan ditekan, logika game akan menciptakan Proses dan memulainya. ada pemikiran tentang pendekatan ini?

— GriffinHeart

@ Byte56: Secara umum, Anda dapat meminta komponen terkait dan nilainya. Dalam praktiknya, Anda seringkali hanya perlu mengetahui bagian yang relevan dari seluruh negara, misalnya "Apakah entitas ini memiliki BuildControllerComponent?" atau "Apa posisi entitas ini sebagaimana dicatat dalam entitasnya PositionComponent, jika ada?" - yang Anda lakukan dengan memeriksa daftar komponen untuk komponen yang Anda minati dan secara opsional menanyakan (beberapa) nilainya.

— Martin Sojka

@ GeffinHeart: Saya baru saja mengimplementasikan apa pun yang diperlukan untuk "membangun" jebakan dalam sistem yang terkait dengan pengelolaan BuildControllerComponents. Itu sudah perlu memproses perubahan sudut pandang karakter pemain (atau kamera) dan acara tombol dan mouse.

— Martin Sojka

Saya tidak suka gagasan entitas memanggil pembaruan pada komponen mereka (sistem harus melakukan pekerjaan), dan itu akan menyebabkan masalah dengan menjaga komponen tidak saling menyadari.

Anda dapat menambahkan komponen tambahan yang disebut "Negara". Ini akan diakses oleh sistem render dan collision Anda. Komponen status hanyalah sebuah bendera yang memiliki banyak status tersedia untuknya. Untuk situasi yang Anda gambarkan keadaan akan Playdan Build. Ketika sistem render melihat bahwa keadaan Builditu akan menarik objek tembus. Ketika sistem tumbukan melihat Buildkeadaan, itu tidak akan memproses tumbukan dengan pemain.

Tetapi sungguh, jika Anda tidak memiliki sistem dan Anda mengandalkan komponen untuk melakukan semua pekerjaan Anda akan mengalami banyak masalah. Komponen seharusnya tidak saling mengetahui dan mereka tidak boleh melakukan pemrosesan.

— MichaelHouse
sumber

Apa yang Anda katakan bertentangan, pertama-tama mereka harus tidak sadar (yang saya setuju) kemudian Anda ikuti dengan memiliki komponen yang diakses oleh orang lain. Bisakah Anda mengklarifikasi? Saya menjaga komponen dipisahkan oleh sistem acara.

— GriffinHeart

Saya mengatakan keduanya. Saya mengatakan mereka seharusnya tidak sadar dan mencoba menyesuaikan tanggapan saya terhadap bagaimana saya pikir Anda menangani komponen. Ketika Anda mengatakan "Entity akan memanggil pembaruan pada komponen-komponennya" itu membuat saya percaya bahwa Anda tidak memiliki entitas pemroses sistem. Saya telah menghapus bahasa yang membingungkan dan membuatnya menjadi sistem. Saya mengatakan komponen karena saya mengerti bahwa itulah yang Anda perbarui.

— MichaelHouse

Saya suka ide StateComponentyang dapat dikonsumsi oleh banyak sistem.

— Cypher

Adalah sopan untuk memberikan alasan untuk downvotes. Terima kasih.

— MichaelHouse

Pada catatan yang berbeda, keberatan Anda terhadap pendekatan penanya didasarkan pada asumsi bahwa semua desain berbasis komponen harus memperbarui komponen dari sistem yang terpisah (seperti desain sistem entitas). Itu adalah salah satu cara untuk melakukannya, tetapi tentu saja bukan satu-satunya, dan tidak ada alasan untuk menghalangi pendekatan semacam itu untuk game yang tidak memerlukan loop pembaruan komponen yang mengoptimalkan cache.

— Sean Middleditch