Le modèle-vue-contrôleur est-il compatible avec l'intelligence artificielle et les arbres de comportement ?

Question

Je viens d'un environnement MVC (Flex et Rails) et j'aime les idées de séparation du code, de réutilisation, d'encapsulation, etc. Il est facile de construire des choses rapidement et de réutiliser des composants dans d'autres projets. Cependant, il a été très difficile de respecter les principes MVC lorsque j'ai essayé de construire des applications complexes, pilotées par l'état, asynchrones et animées.

J'essaie de créer des transitions animées entre plusieurs vues imbriquées dans une application et cela m'a fait réfléchir pour savoir si je ne me trompais pas moi-même... Peut-on appliquer les principes du MVC à ceux de l'intelligence artificielle (arbres de comportement, machines à états hiérarchiques, états imbriqués), comme les jeux ? Ces deux disciplines se combinent-elles bien ?

Il est très facile de garder les vues/graphiques ignorantes de tout ce qui est extérieur à elles-mêmes lorsque les choses sont statiques, comme avec un système CMS HTML ou autre. Mais lorsque vous commencez à ajouter des transitions complexes pilotées par l'état, il semble que tout doit savoir tout ce qui se passe, et le MVC devient presque un obstacle. Qu'en pensez-vous ?

Mise à jour :

Un exemple. En ce moment, je travaille sur un site web en Flex. Je suis arrivé à la conclusion que pour animer correctement chaque élément imbriqué dans l'application, je dois les considérer comme des agents d'intelligence artificielle. Chaque "vue" possède donc son propre arbre de comportement. C'est-à-dire qu'elle effectue une action (s'affiche et se cache) sur la base de l'option contexte (quelles sont les données sélectionnées, etc.). Pour ce faire, j'ai besoin d'une chose de type ViewController, que j'appelle un Presenter. J'ai donc une vue (les graphiques présentés en MXML), un présentateur (qui définit les animations et les actions que la vue peut entreprendre en fonction de l'état et des états imbriqués de l'application), et un modèle de présentation pour présenter les données à la vue (par le biais du présentateur). J'ai également des modèles pour les objets de valeur et des contrôleurs pour gérer les URL et les appels de base de données, etc... tous les trucs statiques/html normaux de type MVC.

Pendant un certain temps, j'ai essayé de trouver comment structurer ces "agents" de manière à ce qu'ils puissent réagir au contexte qui les entoure (ce qui est sélectionné, etc.). Il me semblait que tout devait être conscient de tout le reste. Et puis j'ai lu quelque chose sur une table/liste de chemin/navigation pour les jeux et j'ai immédiatement pensé qu'ils avaient une table centralisée de toutes les actions précalculées que chaque agent peut prendre. Je me suis donc demandé comment ils structurent réellement leur code.

Tout ce qui concerne les jeux vidéo en 3D est un grand secret et, d'après ce que j'ai vu, une grande partie est réalisée avec une interface utilisateur/éditeur graphique, comme la définition des arbres de comportement. Je me demande donc s'ils utilisent une sorte de MVC pour structurer la façon dont leurs agents répondent à l'environnement, et comment ils gardent leur code modulaire et encapsulé.

Answer 1

"Pouvez-vous appliquer les principes de MVC à principes de l'intelligence artificielle (arbres de comportement, machines à états hiérarchiques, états imbriqués États imbriqués), comme les jeux ?"

Bien sûr. 99,9% de l'IA est purement dans le modèle. Le contrôleur lui envoie les entrées, la vue est la façon dont vous le représentez à l'écran pour l'utilisateur.

Maintenant, si vous voulez que l'IA contrôle quelque chose, vous pouvez finir par imbriquer les concepts, et votre "modèle" de jeu contient un modèle pour une entité, un contrôleur pour l'entité qui est l'IA qui lui envoie des commandes, et une vue pour l'entité qui représente les perceptions de cette entité avec lesquelles le contrôleur peut travailler. Mais il s'agit là d'une question distincte de celle de savoir s'il est possible de "jouer gentiment". MVC consiste à séparer la présentation et l'entrée de la logique et de l'état, et cet aspect ne se soucie pas de l'apparence de la logique et de l'état.

Answer 2

Gardez ceci à l'esprit : Les choses qui doivent réagir doivent simplement être conscientes des choses auxquelles elles doivent réagir. Donc, si elles doivent être au courant de tout, alors elles doivent être au courant de tout. Sinon, comment les rendre conscients ? Dans les jeux vidéo en 3D, disons les jeux de tir à la première personne, les ennemis réagissent au son et à la vue (bruits de pas / coups de feu et vous / cadavres, par exemple). Notez que j'ai indiqué une base abstraite, et des parties de l'arbre de décision.

Dans votre cas spécifique, il pourrait être erroné de séparer le tout entre plusieurs agents, et plus simple de le laisser à un agent principal qui peut déléguer des ordres à des processus distincts (/début du bavardage) : chaque vue pourrait être un processus auquel l'agent principal pourrait demander de passer à n'importe quelle vue (ou à un certain nombre de vues), en fonction des données que l'agent principal a reçues.

J'espère que cela vous aidera Prenez tout cela avec un grain de sel :)

Answer 3

Il semble que vous ayez besoin d'utiliser davantage le modèle Observer/Event Aggregator. Si plusieurs composants doivent réagir à des événements d'application arbitraires sans introduire de couplage excessif, l'utilisation d'un agrégateur d'événements peut vous aider. Exemple : lorsqu'un élément est sélectionné, un événement d'application est publié, les contrôleurs concernés demandent à leur vue d'exécuter des animations, etc. Les différents composants ne sont pas conscients des autres, ils écoutent simplement les événements communs.

De même, le code qui permet à la vue de faire des choses (lancer une animation en fonction de l'état du modèle/contrôleur) fait partie de la vue elle-même, de sorte que vous n'avez pas à rendre votre architecture bizarre en ayant un contrôleur et un viewcontroller. Si c'est du code spécifique à l'interface utilisateur, alors il fait partie de la vue. Je ne connais pas bien Flex, mais dans WPF/Silverlight, ce genre de choses doit être intégré dans le code-behind (bien que, dans la plupart des cas, Visual State Manager soit plus que suffisant pour gérer les animations d'état, ce qui permet de tout conserver en XAML).