Haruskah perisai menjadi entitasnya sendiri yang melacak lokasi pemain? Itu mungkin membuat sulit untuk menerapkan penyaringan kerusakan. Ini juga agak mengaburkan garis antara komponen dan entitas yang terpasang.
Sunting: Saya pikir tidak ada "perilaku otonom" yang cukup untuk entitas yang terpisah. Dalam kasus khusus ini, perisai mengikuti target, bekerja untuk target dan tidak hidup lebih lama dari target. Walaupun saya cenderung setuju bahwa tidak ada yang salah dengan konsep "objek pelindung", dalam hal ini kita berurusan dengan perilaku, yang cocok dengan komponen. Tapi saya juga seorang penganjur entitas logis murni (sebagai lawan dari sistem entitas full-blown di mana Anda dapat menemukan komponen Transform dan Rendering).
Haruskah perisai menjadi komponen yang menampung komponen lainnya? Saya belum pernah melihat atau mendengar hal seperti ini, tapi mungkin itu biasa dan saya belum cukup dalam.
Lihat dalam perspektif yang berbeda; menambahkan komponen menambahkan komponen lain juga, dan setelah dihapus, komponen tambahan juga hilang.
Haruskah perisai hanya set komponen yang ditambahkan ke pemain? Mungkin dengan komponen tambahan untuk mengelola yang lain, misalnya sehingga mereka semua dapat dihapus sebagai grup. (Tanpa sengaja meninggalkan komponen pengurangan kerusakan, sekarang akan menyenangkan).
Ini bisa menjadi solusi, itu akan mempromosikan penggunaan kembali, namun juga lebih rentan kesalahan (untuk masalah yang Anda sebutkan, misalnya). Itu tidak selalu buruk. Anda mungkin menemukan kombinasi mantra baru dengan coba-coba :)
Hal lain yang jelas bagi seseorang dengan lebih banyak pengalaman komponen?
Saya akan menguraikan sedikit.
Saya yakin Anda memperhatikan bagaimana beberapa komponen harus diprioritaskan tidak peduli kapan mereka telah ditambahkan ke entitas (ini akan menjawab pertanyaan Anda yang lain juga).
Saya juga akan menganggap kita menggunakan komunikasi berbasis pesan (demi diskusi, itu hanya abstraksi atas panggilan metode untuk saat ini).
Setiap kali komponen pelindung "dipasang", penangan pesan komponen pelindung dirantai dengan urutan tertentu (lebih tinggi).
Handler Stage Handler Level Handler Priority
In Pre System High
Out Invariant High
Post AboveNormal
Normal
BelowNormal
Low
System Low
In - incoming messages
Out - outgoing messages
Index = ((int)Level | (int)Priority)
Komponen "stats" menginstal pawang pesan "damage" di indeks In / Invariant / Normal. Setiap kali pesan "kerusakan" diterima, kurangi HP dengan jumlah "nilainya".
Perilaku standar yang adil (dimasukkan ke dalam beberapa resistensi kerusakan alami dan / atau sifat ras, apa pun).
Komponen perisai menginstal pawang pesan "kerusakan" di indeks In / Pre / High.
Every time a "damage" message is received, deplete the shield energy and substract
the shield energy from the damage value, so that the damage down the message
handler pipeline is reduced.
damage -> stats
stats
stats.hp -= damage.value
damage -> shield -> stats
shield
if(shield.energy) {
remove_me();
return;
}
damage.value -= shield.energyquantum
shield.energy -= shield.energyquantum;
stats
stats.hp -= damage.value
Anda dapat melihat ini cukup fleksibel, meskipun itu akan memerlukan perencanaan yang cermat ketika mendesain interaksi komponen, karena Anda harus menentukan di bagian mana dari pesan penanganan pipa menangani pesan komponen komponen handler yang diinstal.
Masuk akal? Beri tahu saya jika saya dapat menambahkan lebih banyak detail.
Sunting: mengenai beberapa komponen komponen (dua komponen pelindung). Anda bisa melacak jumlah instance total hanya dalam satu instance entitas (namun, ini membunuh status per-komponen) dan tetap menambahkan penangan event pesan, atau memastikan kontainer komponen Anda memperbolehkan jenis komponen duplikat di muka.