模型 - 视图 - 控制器是否与人工智能和行为树很好地配合？

Question

我来自MVC背景(Flex和Rails),喜欢代码分离,可重用性,封装等的想法.它使得快速构建和在其他项目中重用组件变得容易.但是,在尝试构建复杂的,状态驱动的异步动画应用程序时,很难坚持使用MVC原则.

我试图在应用程序中的许多嵌套视图之间创建动画过渡,它让我思考我是否误导自己......你能否将MVC的原则应用于人工智能的原理(行为树,分层状态机) ,嵌套状态),像游戏？这两个学科能很好地融合在一起吗？

当事物是静态的时,很容易使视图/图形对于自身之外的任何东西都不了解,比如使用HTML CMS系统或其他任何东西.但是当你开始添加复杂的状态驱动的转换时,似乎所有东西都需要了解其他所有内容,而MVC几乎会阻碍它.你怎么看？

更新:

一个例子.那么我现在在Flex的网站上工作.我得出结论,为了正确地为应用程序中的每个嵌套元素设置动画,我必须将它们视为AI代理.然后,每个"视图"都有自己的行为树.也就是说,它根据上下文执行操作(显示和隐藏自身)(所选数据是什么,等等).为了做到这一点,我需要一个ViewController类型的东西,我称之为Presenter.所以我有一个View(在MXML中布局的图形),一个Presenter(根据应用程序的状态和嵌套状态定义View可以采取的动画和动作),以及一个将数据呈现给View的Presentation Model(通过主持人).我还有值对象和控制器的模型,用于处理URL和数据库调用等...所有正常的静态/类似HTML的MVC.

有一段时间,我试图弄清楚如何构建这些"代理人",以便他们可以响应周围的环境(选择的内容等).似乎所有事情都需要了解其他一切.然后我读到了游戏的路径/导航表/列表,并立即认为他们有一个集中存储的表,其中包含每个代理可以采取的所有预先计算的操作.所以这让我想知道他们如何实际构建他们的代码.

所有的3D视频游戏都是一个很大的秘密,我所看到的很多都是通过图形UI /编辑器完成的,比如定义行为树.所以我想知道他们是否使用某种MVC来构建他们的代理如何响应环境,以及他们如何保持代码模块化和封装.

Answer 1

“你能将 MVC 的原理应用到人工智能（行为树、分层状态机、嵌套状态）的原理中，比如游戏吗？”

当然。99.9% 的 AI 纯粹在模型中。控制器向其发送输入，视图是您在屏幕上向用户表示它的方式。

现在，如果你想开始让 AI 控制某些东西，你可能最终会嵌套概念，并且你的游戏“模型”包含实体的模型、实体的控制器（AI 向其发送命令）和实体的视图，代表控制器可以使用的实体的感知。但这与它能否“发挥出色”是另外一个问题。MVC 是将表示和输入与逻辑和状态分离，并且该方面并不关心逻辑和状态是什么样的。