Dalam Mesin Entitas-Komponen-Sistem, Bagaimana cara saya menangani grup entitas dependen?

Setelah mempelajari beberapa pola desain gim, saya puas dengan Entity-Component-System (ES System) untuk mesin gim saya. Saya sudah membaca artikel (terutama T = Mesin ) dan meninjau beberapa kode sumber dan saya pikir saya sudah cukup untuk memulai.

Hanya ada satu ide dasar yang saya perjuangkan. Bagaimana cara saya berurusan dengan kelompok entitas yang saling bergantung?

Izinkan saya menggunakan contoh:

Anggaplah saya membuat penembak overhead standar (pikirkan Jamestown ) dan saya ingin membangun "entitas bos" dengan beberapa bagian yang berbeda tetapi terhubung. Rinciannya mungkin terlihat seperti ini:

• Badan kapal: Gerakan, Rendering
• Cannon: Posisi (terkunci relatif terhadap tubuh Kapal), Melacak \ Menembak pahlawan, Mengambil Kerusakan sampai dinonaktifkan
• Inti: Posisi (dikunci relatif terhadap tubuh Kapal), Pelacakan \ Menembak pahlawan, Mengambil Kerusakan sampai dinonaktifkan, Menonaktifkan (er ... menghancurkan) semua entitas lain dalam grup kapal

Tujuan saya akan menjadi sesuatu yang akan diidentifikasi (dan dimanipulasi) sebagai elemen permainan yang berbeda tanpa harus menulis ulang subsistem dari bawah ke atas setiap kali saya ingin membangun Elemen agregat baru.

Bagaimana cara menerapkan desain semacam ini dalam Sistem ES?

1. Apakah saya menerapkan semacam hubungan entitas orangtua-anak (entitas dapat memiliki anak)? Ini tampaknya bertentangan dengan metodologi bahwa Entitas hanyalah wadah kosong dan membuatnya terasa lebih OOP.
2. Apakah saya menerapkannya sebagai entitas yang terpisah, dengan beberapa jenis Komponen yang terhubung (BossComponent) dan sistem terkait (BossSubSystem)? Saya tidak dapat membantu tetapi berpikir bahwa ini akan sulit untuk diterapkan karena bagaimana komponen berkomunikasi tampaknya menjadi perangkap besar.
3. Apakah saya menerapkannya sebagai satu Entitas, dengan koleksi komponen (ShipComponent, CannonComponents, CoreComponent)? Yang ini sepertinya mengarah pada maksud Sistem ES (komponen di sini tampak terlalu mirip entitas yang berat), tapi saya tahu ini jadi saya pikir saya akan meletakkannya di sana.
4. Apakah saya menerapkannya sebagai hal lain yang telah saya sebutkan?

Saya tahu bahwa ini dapat diimplementasikan dengan sangat mudah di OOP, tetapi saya memilih ES daripada OOP adalah salah satu yang akan saya ikuti. Jika saya harus memutuskan dengan teori ES murni untuk mengimplementasikan desain ini saya akan (tidak seperti saya belum pernah kompromi desain murni sebelumnya), tetapi saya lebih suka melakukan itu untuk alasan kinerja daripada mulai dengan desain yang buruk.

Untuk kredit tambahan, pikirkan desain yang sama tetapi, masing-masing "entitas bos" sebenarnya terhubung ke "entitas BigBoss" yang lebih besar yang terbuat dari badan utama, inti utama, dan 3 "Entitas Bos". Ini akan membuat saya melihat solusi untuk setidaknya 3 dimensi (kakek-nenek-anak) ... yang seharusnya lebih dari cukup untuk saya.

Jika saya berada dalam situasi ini, saya akan membuat setiap bagian dari bos sebagai entitas yang terpisah. "Sub-entitas" ini akan mencakup beberapa jenis AttachmentPointatau ParentEntitykomponen. Komponen ini akan mencakup referensi ke entitas induk dan offset dari posisi orang tua. Saat memperbarui posisi, mereka memeriksa posisi induk dan menerapkan offset untuk menghasilkan posisi mereka sendiri. Selain itu, bisa melakukan pengecekan untuk memastikan entitas induk masih ada. Selanjutnya, Anda dapat memiliki SubEntitykomponen yang melacak keberadaan sub entitas untuk entitas induk. Ini memungkinkan Anda untuk melakukan hal-hal seperti hanya membuat inti bos rentan ketika lengan dengan perisai dihancurkan.

Saat ini saya menggunakan TargetEntitykomponen dalam gim saya, yang digunakan untuk pelacakan turet dan kapan goblin akan mengambil sumber daya. Itu dapat memeriksa posisi entitas target dan mengubah perilakunya sesuai. Entitas yang tidak memiliki posisi tidak pernah ditambahkan sebagai target, jadi tidak ada kekhawatiran di sana. Namun, ketika menjadi lebih mendalam, seperti memeriksa kesehatan orang tua atau entitas anak, perisai, cadangan daya atau apa pun, Anda harus memastikan orang tua atau entitas anak benar-benar memiliki komponen terkait.

Membuat setiap bagian itu sendiri entitas mempertahankan fleksibilitas kerangka kerja entitas / komponen dengan memungkinkan Anda untuk menambahkan komponen tambahan dan berbeda untuk setiap bagian dari bos. Misalnya, satu bagian dari bos mungkin memiliki komponen senjata dan komponen kesehatan sementara yang lain memiliki komponen pelindung dan komponen kesehatan.

Saya menemukan diskusi lain tentang topik ini di sini . Di mana pengguna mendiskusikan untuk menambahkan beberapa komponen dari jenis yang sama ke satu entitas (yang sepertinya ide yang buruk bagi saya). Sepertinya percakapan yang bermanfaat, meskipun saya belum membaca seluruh diskusi.

Tanpa mengetahui terlalu banyak detail tentang sistem Anda yang ada, cara saya memodelkan ini (dan sampai batas tertentu dalam sistem entitas saya sendiri) adalah memiliki komponen seperti AttachedTo (parentEntity). Setiap anak kemudian dapat diberi komponen AttachedTo (boss).

Sistem rendering (atau apa pun) kemudian mengambil entitas dengan komponen: Posisi, Terlampir, dll. Dan membentuk hierarki yang tepat.

Jika Anda ingin memiliki entitas yang diwakili hanya dengan ID, maka penahanan entitas dapat dilakukan melalui komponen khusus. Anda bisa menyebutnya CompositeComponent, dan ini berisi daftar ID entitas anak, dan antarmuka untuk menambah / menghapus anak-anak dari daftar itu.

Jelas setiap komponen yang bergantung pada posisi dll akan perlu bekerja dengan ini untuk menempatkan entitas dengan benar. Cara menerapkan ini akan tergantung pada bagaimana Anda menerapkan penentuan posisi saat ini.

Omong-omong, tidak ada "teori ES murni" - membuat entitas dari komponen adalah pendekatan yang populer tetapi metode yang tepat belum berarti standar.