Les systèmes d'entités basés sur les composants font fureur de nos jours; tout le monde semble d'accord pour dire que c'est la voie à suivre, mais personne n'a vraiment de mise en œuvre définitive d'un tel système. Je me demandais quel rôle les états d'entité (marcher à gauche, debout, sauter, etc.) ont-ils dans un CBS? Agissent-ils comme des contrôleurs (c'est-à-dire qu'ils gèrent les événements et modifient les attributs de l'entité en fonction de ces événements)?
Qu'en est-il des cas où un État exigerait, par exemple, que l'entité passe en mode sans clip? Cet état, lorsqu'il entre, devrait-il peut-être définir le CollisionComponent de l'entité sur un pointeur nul ou quelque chose? (Ensuite, à la sortie, l'état doit restaurer le composant CollisionComponent de l'entité à son état précédent.)
En outre, je suppose que c'est le travail de l'état actuel de changer l'état de l'entité en quelque chose d'autre, non?
la source
Réponses:
J'avais l'impression que dans une conception basée sur des composants, les entités sont essentiellement des conteneurs de composants (avec éventuellement un message). Dans cette perspective, chaque composant stockerait un peu de l'état. Par exemple, si les composants du comportement fantôme décident qu'ils doivent entrer dans le mode intangible, ils envoient également un message au composant physique lui disant d'activer le non-clip. Cela enverrait probablement aussi un message aux composants du modèle fantôme disant de relancer l'alpha.
la source
Les machines d'état et les composants sont des techniques orthogonales. Vous pouvez avoir des états dans vos composants ou non, tout comme vous pouvez avoir des états dans n'importe quelle classe. Vous pouvez faire observer un composant (voir Modèle d'observateur) et changer l'état d'un autre composant. Les machines d'état ont de nombreuses utilisations et la mise en œuvre dépendra de vos besoins.
Pour le personnage que vous avez décrit (marcher, se tenir debout, sauter), j'ai vu des implémentations où les différents composants maintiennent tous leurs propres machines à états ... physique, animation, contrôles, ai. Les composants doivent avoir une autorité claire sur les autres composants auxquels ils réagissent et sur les états de composants qu'ils peuvent modifier.
la source
Concevez les composants comme des structures avec des données uniquement, aucune logique plus complexe que les getters et les setters. Ne créez pas de dépendances entre les composants ou vous finirez par perdre la plupart des avantages d'un système d'entité.
Voir un exemple de cette approche (proche de la vision t-machine) ici: https://github.com/thelinuxlich/starwarrior_CSharp
Et le moteur lui-même: https://github.com/thelinuxlich/artemis_CSharp
la source