游戏框架架构 - 视图组件还是MVC？

Question

我试图构建一个非常轻量级的可重复使用的游戏框架，而不是每次开始一个新游戏都要从头开始。我采用组件驱动的架构 - 例如，实体由位置组件、健康组件和AI组件等组成。

我的重点问题是，是否要使用模型组成视图组件以允许对模型进行多个视图，还是使用更真实的MVC，其中模型不知道其视图，并且由外部管理。

我尝试过两种方法，但如果有人知道每种方法的优缺点以及哪种是业界标准，那就太好了。

- Iain

Answer 1

根据你的受众来定，游戏开发者（包括我在内）并不太习惯MVC模型，虽然大多数人都知道它，但很难保持其简洁性，因为开发过程中可能会出现问题（而非技术原因）。因此，从经验上看，我见过许多游戏框架最初采用MVC，但只有一小部分能够坚持到最后。我的理论是，对于小型即将被抛弃的游戏（通常只有几个开发人员），MVC增加了太多复杂性，却没有多少好处；对于大型/复杂游戏，很难将大多数游戏对象真正地清晰地分成这些层。由于游戏有发布日期，它们往往会为了性能和快速的临时解决方案而牺牲代码清晰度和可重用性（如果有续集，这些代码可能会被重写）。

然而，在上述警告下，更好的做法是追求高标准，因为如果成功，效果更佳，如果失败，那就太糟糕了。所以你应该尝试MVC，但如果失败也不必担心，专业游戏开发人员都曾多次失败 :)

- Robert Gould

---

伟大的回答 - MVC对游戏实际上有什么优势吗？通过组件，您仍然可以拥有多个视图，那它到底添加了什么呢？ - Iain

理论上，它可以允许任务的分工，让另一个开发人员负责视图，而另一个则负责模型和控制。问题在于游戏任务往往是垂直切片的（AI、物理、地图、角色等），因此通常由同一开发人员负责制作MVC堆栈。但理想情况下，设计师应该进行建模，程序员进行控制，艺术家进行可视化。因此，如果建模和可视化层可以制作成用户友好的工具，则存在潜在的收益。 - Robert Gould

但对于一个独立的程序员来说，学习工具会增加负担，因此往往会使其组件化。另一个选择是查看混合类，这也可以起到作用，至少我曾看到它运行得很好。 - Robert Gould

Answer 2

我肯定会支持模型不了解它的观点。松散耦合是好的：更简单的模型代码，更容易的测试，更多的选择。

- zoul

Answer 3

我知道这个问题可能已经过时了，但我需要回答它。 实际上，我开始用Lua（带有LÖVE）编写游戏，并为其编写MVC框架。 首先，使用MVC确实取决于您想要什么。 我知道我的游戏编程问题，当程序变得更大时，大多数结构变得太复杂而无法维护。 接下来，我知道当我找到愿意为此工作的艺术家时，我将更改所有图形。但在那之前，我会使用自己的虚拟图形。 我希望艺术家可以随心所欲地做任何事情，而不受任何分辨率或颜色限制的影响。 这意味着我可能必须更改整个（！）演示代码。甚至是对象交互的方式（例如碰撞检测）。 游戏逻辑被捕获在模型中，因此我可以专注于此。而且我认为游戏逻辑是制作游戏最重要的部分。不是吗？ 希望你能理解我的观点。

但是，如果您已经准备好所有内容：所有图形，声音，整个东西；那么您可以直接编码。

我的MVC是一种以配置为导向的固执己见，这会稍微减慢原型制作的速度。 但是(!)开发的迭代可以更轻松地进行。特别是单元测试的测试速度更快。 我认为MVC会将您的开发速度曲线（通常是反指数曲线）转变为指数曲线。开始时缓慢，但后来越来越快。

- Stephan

Answer 4

MVC在游戏开发中非常有效，至少对于我设计的跨平台游戏来说是如此。真正取决于你如何实现它以获得好处。

- Ramon Chan