Le bouclier doit-il être sa propre entité qui suit l'emplacement du joueur? Cela pourrait rendre difficile la mise en œuvre du filtrage des dommages. Cela brouille également les lignes entre les composants et les entités attachés.
Edit: Je pense qu'il n'y a pas assez de "comportement autonome" pour une entité séparée. Dans ce cas spécifique, un bouclier suit la cible, fonctionne pour la cible et ne survit pas à la cible. Bien que j'aie tendance à convenir qu'il n'y a rien de mal avec le concept d'un "objet bouclier", dans ce cas, nous avons affaire à un comportement, qui s'intègre très bien dans un composant. Mais je suis également un défenseur des entités purement logiques (par opposition aux systèmes d'entités à part entière dans lesquels vous pouvez trouver des composants de transformation et de rendu).
Le bouclier devrait-il être un composant qui abrite d'autres composants? Je n'ai jamais vu ou entendu quelque chose comme ça, mais c'est peut-être courant et je ne suis pas encore assez profond.
Le voir dans une perspective différente; l'ajout d'un composant ajoute également d'autres composants, et lors de la suppression, les composants supplémentaires ont également disparu.
Le bouclier ne devrait-il être qu'un ensemble de composants ajoutés au joueur? Peut-être avec un composant supplémentaire pour gérer les autres, par exemple afin qu'ils puissent tous être supprimés en tant que groupe. (laissez accidentellement le composant de réduction des dégâts, maintenant ce serait amusant).
Cela pourrait être une solution, cela favoriserait la réutilisation, mais il est également plus sujet aux erreurs (pour le problème que vous avez mentionné, par exemple). Ce n'est pas nécessairement mauvais. Vous pourriez découvrir de nouvelles combinaisons de sorts avec essais et erreurs :)
Quelque chose d'autre qui est évident pour quelqu'un avec plus d'expérience en composants?
Je vais développer un peu.
Je pense que vous avez remarqué que certains composants devraient être prioritaires, peu importe quand ils ont été ajoutés à une entité (cela répondrait également à votre autre question).
Je vais également supposer que nous utilisons la communication basée sur les messages (pour les besoins de la discussion, ce n'est qu'une abstraction sur un appel de méthode pour le moment).
Chaque fois qu'un composant de bouclier est "installé", les gestionnaires de messages de composant de bouclier sont enchaînés avec un ordre spécifique (supérieur).
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)
Le composant "stats" installe un gestionnaire de messages "dommages" à l'index In / Invariant / Normal. Chaque fois qu'un message de "dommage" est reçu, diminuez les HP de sa valeur "value".
Comportement assez standard (insérez une résistance aux dommages naturels et / ou des traits raciaux, peu importe).
Le composant de bouclier installe un gestionnaire de messages "dommages" à l'index 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
Vous pouvez voir que cela est assez flexible, même si cela nécessiterait une planification minutieuse lors de la conception de l'interaction des composants, car vous devrez déterminer dans quelle partie du gestionnaire de messages le gestionnaire d'événements de message du composant de pipeline est installé.
Logique? Faites-moi savoir si je peux ajouter plus de détails.
Edit: concernant plusieurs instances de composants (deux composants d'armure). Vous pouvez soit garder une trace du nombre total d'instances dans une seule instance d'entité (cela tue toutefois l'état par composant) et simplement continuer d'ajouter des gestionnaires d'événements de message, ou vous assurer que vos conteneurs de composants autorisent à l'avance les types de composants en double.