模型-视图-控制器与人工智能和行为树配合得很好吗？
我有 MVC 背景（Flex 和 Rails），喜欢代码分离、可重用性、封装等思想。它使快速构建事物并在其他项目中重用组件变得很容易。然而，在尝试构建复杂的、状态驱动的、异步的动画应用程序时，坚持 MVC 原则是非常困难的。
我正在尝试 在之间创建动画过渡应用程序中有许多嵌套视图，这让我开始思考我是否在误导自己...您能否将 MVC 的原则应用于人工智能的原则（行为树、分层状态机、嵌套状态） ，喜欢游戏？这两个学科能很好地结合起来吗？
当事物是静态的时，很容易让视图/图形不知道其自身之外的任何事物，例如使用 HTML CMS 系统或其他系统。但是，当您开始添加复杂的状态驱动转换时，似乎一切都需要了解其他一切，而 MVC 几乎会成为障碍。你怎么认为？
更新：
一个例子。现在我正在 Flex 中开发一个网站。我得出的结论是，为了正确地为应用程序中的每个嵌套元素设置动画，我必须将它们视为人工智能代理。每个“视图”都有它自己的行为树。也就是说，它根据上下文（所选数据是什么等）执行操作（显示和隐藏自身）。为了做到这一点，我需要一个 ViewController 类型的东西，我称之为 Presenter。因此，我有一个视图（MXML 中布局的图形）、一个演示器（根据应用程序的状态和嵌套状态定义视图可以采取的动画和操作）和一个用于向视图呈现数据的演示模型（通过主持人）。我还有用于值对象的模型和用于处理 URL 和数据库调用等的控制器...所有正常的静态/类似 html 的 MVC 内容。
有一段时间，我试图弄清楚如何构建这些“代理”，以便它们能够响应周围的环境（选择的内容等）。似乎一切都需要了解其他一切。然后我读到了游戏的路径/导航表/列表，并立即想到他们有一个集中存储的表，其中包含每个代理可以采取的所有预先计算的操作。所以这让我想知道他们实际上是如何构建代码的。
所有 3D 视频游戏内容都是一个大秘密，据我所知，其中很多内容都是通过图形 UI/编辑器完成的，例如定义行为树。所以我想知道他们是否使用某种 MVC 来构建代理如何响应环境，以及如何保持代码模块化和封装。
I come from an MVC background (Flex and Rails) and love the ideas of code separation, reusability, encapsulation, etc. It makes it easy to build things quickly and reuse components in other projects. However, it has been very difficult to stick with the MVC principles when trying to build complex, state-driven, asynchronous, animated applications.
I am trying to create animated transitions between many nested views in an application, and it got me thinking about whether or not I was misleading myself... Can you apply principles from MVC to principles from Artificial Intelligence (Behavior-Trees, Hierarchical State Machines, Nested States), like Games? Do those two disciplines play nicely together?
It's very easy to keep the views/graphics ignorant of anything outside of themselves when things are static, like with an HTML CMS system or whatever. But when you start adding complex state-driven transitions, it seems like everything needs to know about everything else, and the MVC almost gets in the way. What do you think?
Update:
An example. Well right now I am working on a website in Flex. I have come to the conclusion that in order to properly animate every nested element in the application, I have to think of them as AI Agents. Each "View", then, has it's own Behavior Tree. That is, it performs an action (shows and hides itself) based on the context (what the selected data is, etc.). In order to do that, I need a ViewController type thing, I'm calling it a Presenter. So I have a View (the graphics laid out in MXML), a Presenter (defining the animations and actions the View can take based on the state and nested states of the application), and a Presentation Model to present the data to the View (through the presenter). I also have Models for value objects and Controllers for handling URLs and database calls etc... all the normal static/html-like MVC stuff.
For a while there I was trying to figure out how to structure these "agents" such that they could respond to their surrounding context (what's selected, etc.). It seemed like everything needed to be aware of everything else. And then I read about a Path/Navigation Table/List for games and immediately thought they have a centrally-stored table of all precalculated actions every agent can take. So that got me wondering how they actually structure their code.
All of the 3D video game stuff is a big secret, and a lot of it from what I see is done with a graphical UI/editor, like defining behavior trees. So I'm wondering if they use some sort of MVC to structure how their agents respond to the environment, and how they keep their code modular and encapsulated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当然。99.9% 的 AI 纯粹位于模型中。控制器向其发送输入，视图是您在屏幕上向用户表示它的方式。
现在，如果您想开始让 AI 控制某些东西，您最终可能会嵌套概念，并且您的游戏“模型”包含实体的模型、实体的控制器（AI 向其发送命令）以及代表实体的视图。但这与它能否“很好地发挥作用”是一个单独的问题，MVC 是将表示和输入与逻辑和状态分开，而这方面并不关心逻辑和状态是什么样的。 。
Of course. 99.9% of the AI is purely in the Model. The Controller sends the inputs to it, the View is how you represent it on the screen to the user.
Now, if you want to start having the AI control something, you may end up nesting the concepts, and your game 'model' contains a Model for an entity, a Controller for the entity which is the AI sending commands to it, and a View for the entity which represents the perceptions of that entity that the Controller can work with. But that's a separate issue from whether it can 'play nicely'. MVC is about separating presentation and input from logic and state and that aspect doesn't care what the logic and state looks like.
请记住这一点：
需要做出反应的事物只需知道它们需要做出反应的事物即可。
因此，如果他们需要了解一切，那么他们就需要了解一切。
否则，你如何让他们意识到？在 3D 视频游戏中，比如第一人称射击游戏，敌人会对声音和视觉做出反应（例如脚步声/枪声和你/尸体）。请注意，我指出了抽象基础和决策树的一部分。
在您的具体情况下，将整个事情分开在多个代理之间可能是错误的，而将其留给一个可以将订单委托给单独流程的主要代理更简单（/开始胡言乱语）：每个视图都可以是一个可以被告知的流程根据主代理收到的数据，切换到主代理的任何（多个）视图。
希望有帮助..对此持保留态度:)
Keep this in mind:
The things which need to react simply have to be aware of the things to which they need to react.
So if they need to know about everything, then they need to know about everything.
Otherwise, -how- do you make them aware? In 3D video games stuff, say first-person shooters, the enemies react to sound and sight (footsteps / gunshots and you / dead bodies, for instance). Note that I indicated an abstract basis, and parts of the decision tree.
It might be wrong in your specific case to separate the whole thing between several agents, and simpler to leave it to one main agent who can delegate orders to separate processes (/begin babble) : each view could be a process which could be told to switch to any (a number of) view by the main agent, depending on what data the main agent has received.
Hope that helps.. Take it all with a grain of salt :)
听起来您需要更多地利用观察者/事件聚合器模式。如果多个组件需要对任意应用程序事件做出反应而不引入不当的耦合，那么使用事件聚合器将帮助您。例如：当选择一个项目时，会发布一个应用程序事件，相关控制器告诉它们的视图运行动画等。不同的组件不知道其他组件，它们只是监听公共事件。
另外，使视图执行操作的代码（根据模型/控制器状态启动动画） - 这是视图本身的一部分，因此您不必通过拥有控制器和视图控制器来使您的架构变得奇怪。如果它是 UI 特定的代码，那么它就是视图的一部分。我不熟悉 Flex，但在 WPF/Silverlight 中，类似的东西会进入代码隐藏（尽管在大多数情况下，Visual State Manager 足以处理状态动画，因此您可以将所有内容保留在 XAML 中） 。
It sounds like you need to make more use of the Observer/Event Aggregator pattern. If multiple components need to react to arbitrary application events without introducing undue coupling, then using an event aggregator would help you out. Example: when an item is selected, an application event is published, relevant controllers tell their view to run animations, etc. Different components aren't aware of others, they just listen for common events.
Also, the code that makes the view do things (launch animation depending on model/controller state) - that's part of the View itself, so you don't have to make your architecture weird by having a controller and a viewcontroller. If it's UI specific code, then it's part of the view. I'm not familiar with Flex, but in WPF/Silverlight, stuff like that would go into the code-behind (though for the most part Visual State Manager is more than enough to deal with state animations so you can keep everything in XAML).