游戏中类似MVC的分区？[关闭]

我当时正在考虑游戏的设计（特别是将棋盘游戏转换为计算机，我认为在这种情况下是相关的），我想到将“游戏”与“显示器”分开构建可能是有意义的。

这将使我能够通过简单的文本界面快速原型化某些东西，然后稍后对其进行完善。这也使我可以更轻松地将游戏移植到其他媒体上。

这种分隔在游戏中是否常见？我是否应该尝试进一步分解？我可能会错过一些并发症吗？

棋盘游戏是可以使用MVC制作的游戏的一个很好的例子，因为游戏逻辑（模型）确实与视觉效果（视图）完全无关。但是，如果考虑使用《战争机器》这样的动作游戏，则3D模型的几何结构是游戏逻辑所固有的，因此，将视图视作可互换的分离就显得毫无意义。Unity3D是组织代码的特定于游戏的更好方式的一个很好的例子。您有一个基础实体类，可以使用组件添加功能，其中一个组件可以处理绘制实体，一个可以处理游戏逻辑等。请查看以下有关该主题的著名博客文章：

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpatterns.com/component.html

我对此：

• 该模型是存放大多数数据并进行所有逻辑的地方。
  它读取输入事件的队列，并相应地修改游戏状态。
  然后，它处理诸如物理学和其他核心组件之类的东西，这些东西也会更新游戏状态。
  环。就这样。
  目的是使模型独立：它对视图或控制器没有任何依赖：您应该能够制作仅运行模型的程序。
• 该视图仅读取模型的游戏状态，更新其专用于数据表示的组件，并在屏幕上显示内容。
  它永远不会在模型上写任何东西，它是一个只读过程，除了可能注册了某些事件处理程序外（例如“嘿先生模型，当您检测到这两个对象之间的冲突时，请致电我的事件处理程序，发出声音！” ”）。
• 该控制器捕获输入事件，并将它们传递到模型的输入队列。它读取视图（此按钮是否在UI按钮上单击了？）。

这样，您可以插入伪造的控制器，该控制器读取包含预先记录的输入事件的文件。
还可以做一个简单的视图，仅将内容记录在文件中。
对于测试和调试非常有用。

记住要使模型以恒定的速率（固定的时间步长）进行更新，并且视图和控制器要尽可能快地进行更新（但变量不要太大）。

这种划分是引擎和游戏代码之间的划分，并且非常普遍。沿途有足够的抽象空间。

您的引擎和游戏的特定图形数据可能是视图，游戏代码是模型，而控制器则是您用来告诉引擎将哪种纹理应用于游戏代码中哪个实体的粘合剂。