Je viens d'un fond MVC (Flex and rails) et j'adore les idées de la séparation de code, de la réutilisabilité, de l'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 coller avec les principes MVC lors de la formation d'applications asynchrones complexes, axées sur l'état, asynchrones et animées.
J'essaie de Créez Transitions animées entre de nombreuses vues imbriquées dans une application , et cela m'a fait penser à la question de savoir si je me faisais trompier ou non ... Pouvez-vous appliquer des principes de MVC aux principes de l'intelligence artificielle (arbres comportementaux, machines d'état hiérarchique, États imbriqués), comme des jeux? Est-ce que ces deux disciplines jouent bien ensemble?
Il est très facile de garder les vues / graphiques ignorants de tout en dehors d'eux-mêmes lorsque les choses sont statiques, comme avec un système HTML CMS ou autre. Mais lorsque vous commencez à ajouter des transitions complexes axées sur l'état, il semble que tout doit savoir sur tout le reste, et le MVC obtient presque dans la voie. Que 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 tous les éléments imbriqués de la demande, je dois y penser comme des agents d'AI. Chaque "vue", alors, a son propre arbre de comportement. C'est-à-dire qu'il effectue un action (spectacles et se cache) basé sur le contexte (quelles sont les données sélectionnées, etc.). Afin de faire cela, j'ai besoin d'une chose de type ViewController, je l'appelle un présentateur. J'ai donc une vue (les graphismes définis dans mxml), un présentateur (définissant les animations et les actions que la vue peut prendre en compte sur l'état et les états imbriqués de l'application) et un modèle de présentation pour présenter les données à la vue ( à travers le présentateur). J'ai également des modèles d'objets de valeur et de contrôleurs pour la manutention des URL et des appels de base de données, etc. Tous les trucs MVC normaux statiques / HTML.
Pour un moment, j'essayais de déterminer comment structurer ces "agents" de manière à répondre à leur contexte environnant (ce qui est sélectionné, etc.). Il semblait que tout devait être conscient de tout le reste. Et ensuite, j'ai lu sur une table / une liste de navigation / liste des jeux et j'ai immédiatement pensé qu'ils ont une table stockée de toutes les actions précalculées que chaque agent peut prendre. Donc, cela me demandait comment ils structurent réellement leur code.
Tous les trucs de jeu vidéo 3D sont un grand secret, et beaucoup de ce que je vois est fait avec une interface utilisateur graphique / éditeur, comme la définition des arbres de comportement. Je me demande donc s'ils utilisent une sorte de MVC pour structurer la manière dont leurs agents répondent à l'environnement et comment ils gardent leur code modulaire et encapsulé.
3 Réponses :
Gardez cela à l'esprit: Les choses qui doivent réagir doivent simplement être conscientes des choses auxquelles ils doivent réagir. Donc, s'ils ont besoin de savoir sur tout, ils ont besoin de savoir sur tout. Sinon, -Comment-ce que vous les faites au courant? Dans les jeux vidéo 3D, disons des tireurs à la première personne, les ennemis réagissent au son et à la vue (traces / 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.
Cela peut être faux dans votre cas spécifique de séparer le tout entre plusieurs agents et plus simple pour le laisser à un agent principal qui peut déléguer les commandes à séparer les processus (/ commencez à babuler): chaque vue pourrait être un processus qui pourrait être un processus qui pourrait On vous demander de passer à n'importe quel (nombre de) vue par l'agent principal, en fonction des données que l'agent principal a reçu.
espère que cela aide .. Prenez tout avec un grain de sel :)
"Pouvez-vous appliquer des principes de MVC à Principes de l'artificiel Intelligence (arbres comportementaux, Machines d'état hiérarchique, imbriquées États), comme des jeux? "
Bien sûr. 99,9% de l'AI est purement dans le modèle. Le contrôleur lui envoie les entrées, la vue est la manière dont vous le représentez à l'écran à l'utilisateur.
Maintenant, si vous souhaitez commencer à contrôler l'AI quelque chose, vous pouvez vous retrouver à imager les concepts et que votre jeu "modèle" contient un modèle pour une entité, un contrôleur pour l'entité qui correspond à la commande d'envoi d'IA. et une vue pour l'entité qui représente les perceptions de cette entité que le contrôleur peut fonctionner avec. Mais c'est un problème séparé de la question de savoir si cela peut «jouer bien». MVC consiste à séparer la présentation et l'entrée de la logique et de l'état et que l'aspect ne se soucie pas de la logique et de l'état.
Merci! Vous sonnez comme vous savez ce qui se passe avec tout cela, avez-vous des ressources pour pointer? N'importe quel code source ???
Non, les développeurs de jeux n'utilisent généralement pas MVC, vous ne trouverez donc pas une grande partie de cela dans la pratique. Mais je vous conseillerais de ne pas prendre la chose MVC trop loin. Il a été conçu explicitement pour la séparation de la présentation du contenu dans les applications de l'interface graphique plutôt que d'être un protocole universel pour la rédaction de logiciels. Par exemple, je ne vois pas que votre message d'origine nécessite des «agents», ni quelque chose de plus complexe que de simplement mettre à jour tout, puis lire leur nouvelle présentation visuelle, comme les jeux le font habituellement.
On dirait que vous devez utiliser plus d'utilisation du motif d'observateur / d'agrégateur d'événement. Si plusieurs composants doivent réagir à des événements d'application arbitraires sans introduire un couplage indu, l'utilisation d'un agrégateur d'événement vous aiderait à sortir. Exemple: lorsqu'un élément est sélectionné, un événement d'application est publié, les contrôleurs pertinents racontent leur vision d'exécuter des animations, etc. Différents composants ne sont pas au courant des autres, ils n'écoutent que des événements courants.
En outre, le code qui fait la vue faire des choses (lancez l'animation en fonction de l'état du modèle / du contrôleur) - cela fait partie de la vue elle-même, de sorte que vous n'ayez pas à faire votre architecture bizarre en ayant un contrôleur et une vérification de la vue. Si c'est un code spécifique de l'UI, alors cela fait partie de la vue. Je ne connais pas avec Flex, mais dans WPF / Silverlight, des trucs comme ça iraient dans le code-derrière (bien que pour la plupart des états visuels, le gestionnaire d'état visuel soit plus que suffisant pour traiter des animations d'état afin que vous puissiez tout garder dans XAML) .
Pouvez-vous donner un exemple très simple? La question liée est également trop longue.
Votre question semble liée à l'architecture du tableau.
OOH, cette architecture du tableau noir a l'air intéressant! Merci!