Conception basée sur les composants / entités + Arbres de comportement => comment intégrer?

Pour mon projet actuel, j'ai implémenté un système basé sur des composants / entités , suivant essentiellement la plupart des meilleures pratiques qui existent dans ce domaine plutôt indéfini .

J'ai donc obtenu des entités (légèrement étendues) , qui sont essentiellement un intID, un nom lisible par l'homme, un std::mapdes composants et un long"indicateur de type" qui est utilisé pour montrer quels composants sont présents (j'ai une puissance de deux enumpour tous les composants types et chaque fois qu'un composant est ajouté à l'entité, je modifie automatiquement cette longue via des opérations au niveau du bit, comparer cette réponse ).

Ensuite, il y a les composants , également assez simples: l' intID, enumcomme type de composant, le pointeur d'entité parent et une std::mapde toutes les propriétés de ce composant.

Enfin, certains systèmes / gestionnaires qui gèrent le traitement logique réel. Ils vérifient d'abord si l'entité actuellement traitée a un long"indicateur de type" correspondant = tous les composants nécessaires pour ce système sont présents. Il accède ensuite à certaines propriétés si nécessaire et appelle directement certaines fonctions dans le composant respectif ou envoie des messages (via un répartiteur de messages).

Conclusion: Jusqu'à présent, un système basé sur des composants / entités plutôt standard basé sur des événements combiné à une approche basée sur les données (comparer, les composants n'ont pas de variables de données codées en dur, mais plutôt une carte générique, comme (certains) composants / Les archétypes de composants seront ensuite lus à partir de fichiers avec la possibilité d'ajouter des données supplémentaires, qui ne font pas partie du code de composant réel.

Maintenant, je voudrais également introduire des arbres de comportement (basés sur AiGameDev BTSK ) dans ce projet, mais je ne sais pas si et comment ils doivent être liés aux composants déjà existants ou comment intégrer ces conceptions en général.

Plusieurs idées / points / questions connexes me viennent à l'esprit:

1. Mes BT seront lus à partir de fichiers (à nouveau). J'ai actuellement du mal à voir comment je ferais au mieux la connexion entre un BT Actiondans cet arbre et le codage réel dans mon application. Dois-je créer une sorte de mappage entre les noms d'actions utilisés dans les fichiers BT et un pointeur de fonction vers l'implémentation logique réelle? Quelle est l'approche habituelle pour résoudre ce problème?

2. Je suppose que je devrai créer des BT pour tous mes différents Entitytypes (donc pour chaque combinaison de composants de logique de jeu / IA, comme indiqué par mon long "indicateur de type" mentionné plusieurs fois). Par conséquent, il n'est pas logique de mettre les BT Actionimplémentations dans les composants, car de nombreux composants seront probablement impliqués par action, n'est-ce pas?

3. La BT Actionlogique devrait-elle donc reposer sur un / plusieurs systèmes séparés (vers les méthodes desquelles la carte de l'idée n ° 1 pointe)? Le système vérifierait alors par mon long"indicateur de type" si le Entitypour lequel le BT est actuellement vérifié et qui a été invité à exécuter une certaine action (= méthode dans le système) est réellement autorisé à le faire (= a les composants nécessaires). Mais alors, sinon (parce que par exemple le créateur de BT a négligé une situation spécifique, où un composant nécessaire pourrait ne plus être attaché à l'entité au moment de l'exécution), rien ne se passerait.

Des questions:

• Existe-t-il des concepts éprouvés pour ce type d'intégration?
• Quelle est votre opinion sur mes 3 points ci-dessus?
• Y a-t-il d'autres choses qui me viennent à l'esprit, concernant également ma conception basée sur les composants / entités en général?

J'ai actuellement du mal à voir comment je ferais au mieux la connexion entre une action BT dans cet arbre et le codage réel dans mon application. Dois-je créer une sorte de mappage entre les noms d'actions utilisés dans les fichiers BT et un pointeur de fonction vers l'implémentation logique réelle? Quelle est l'approche habituelle pour résoudre ce problème?

Oubliez les pointeurs de fonction et pensez aux objets. Chaque nœud de l'arbre de comportement (BT à partir de ce moment) correspondrait idéalement à un objet dans votre code. Ces objets auront une interface standard pour vous permettre de les organiser comme un arbre et de les parcourir. Un ensemble de pointeurs de fonction convient parfaitement au comportement, mais il ne capture pas du tout la structure de votre arbre.

Par conséquent, il n'est pas logique de mettre les implémentations BT Action dans les composants, car de nombreux composants seront probablement impliqués par action, n'est-ce pas?

Je m'attendrais à ce que les entités aient un seul composant BehaviorTree qui stocke les données pertinentes pour le BT de cette entité. L'exécution du BT est effectuée par le composant BT ou le sous-système BT, selon la façon dont vous gérez les composants de votre système. Comme avec à peu près tout ce qui utilise des composants, ils devront se référer à d'autres composants pour faire le travail, mais ces autres composants n'auront rien à savoir sur les BT.

Les différentes actions disponibles seraient, au niveau le plus simple, encodées dans les différents objets nœuds BT. Ils devraient être capables de faire agir l'entité concernée en manipulant les composants selon les besoins, par exemple. accéder au composant de mouvement pour se déplacer.