Rôle d'un état d'entité dans un système basé sur des composants?

8

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?

architecture component-based entity-system

— Paul Manta
source

5

Je dirais qu'il n'y a pas de "mise en œuvre définitive" car tous les jeux ont des exigences différentes, et chaque décision que vous prenez dans la conception d'un système a son propre ensemble de compromis. Faites juste ce qui vous semble logique et assurez-vous de refactoriser lorsque les choses deviennent désordonnées.

— Tetrad

@The Communist Duck, était un peu bas ... haha

— deceleratedcaviar

9

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.

— deft_code
source

2

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.

— Evan Rogers
source

2

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

— thelinuxlich
source

Je suis assez fortement en désaccord avec "aucune logique plus complexe que les getters et setters", mais je viens du référentiel Unity où tout est un composant. Je pense que les composants devraient pouvoir se gérer eux-mêmes.

— Tetrad

1

C'est parce que l'unité n'a rien en tant que systèmes attachés au jeu lui-même, qui traitent les entités dont les composants composent l'aspect système.

— thelinuxlich