游戏框架架构 - 查看组件还是MVC？

Question

我正在尝试为我的游戏构建一个非常轻的可重用框架，而不是每次开始游戏时从头开始。我有一个组件驱动的架构 - 例如实体组成一个Position组件和一个Health组件和Ai组件等。

我的一个大问题是，我的模型是否构成视图组件以允许模型的多个视图，或者是否使用更真实的MVC，其中模型不知道其视图，以及它们在外部进行管理。

我尝试了这两种方法，但如果有人知道每种方法的优缺点，哪种方法是行业标准，那就太棒了。

Answer 1

取决于你的观众，游戏开发者，我自己包含的并不习惯MVC模型，虽然大多数人都知道，但由于开发人员伤亡（没有任何严重的技术原因），保持干净并不容易。所以从经验来看，我已经看到很多游戏框架都是以MVC开头的，但只有一对能够将它维持到最后。我的理论是MVC为小型一次性游戏增加了太多的复杂性和一点点好处（通常有一些开发者），并且很难将大多数游戏对象真正干净地分离到大型/复杂游戏的这些层中。由于游戏有发布日期，因此他们多次牺牲代码清晰度和性能可重用性以及快速的特殊解决方案（如果有必要，将会重写（如果有））。

然而，有了上面的警告，最好瞄准高，因为如果你成功它会更好:)如果你失败了，那就坏了。所以你应该尝试MVC，但不要担心如果它失败了，专业游戏开发人员已经多次在任务中失败了:)

Answer 2

我当然会投票支持模特对其观点一无所知。松散耦合是好的：更简单的模型代码，更容易测试，更多选择。

Answer 3

我知道这个问题可能已经过时，但我需要回复。 实际上，我开始在Lua编程游戏（使用L＆＃214; VE），我开始为它编写一个MVC - Framework。 首先，使用MVC实际上取决于你想要什么。 我知道我的游戏编程问题，当程序变得更大，而且大多数结构太复杂而无法维护。 接下来就是，我知道当我找到愿意为之工作的艺术家时，我会改变所有的图形。但在那之前，我将使用我自己的虚拟图形。 我希望艺术家能够随心所欲地做任何他想做的事情，而不依赖于任何分辨率或颜色限制。 这意味着，我可能不得不改变整个（！）演示代码。甚至可能是物体相互作用的方式（碰撞检测，f.e。）。 游戏逻辑在模型中捕获，因此我可以专注于此。我认为游戏逻辑是制作游戏最重要的部分。不是吗？ 希望你明白我的意思。

但是，如果你把所有东西放在一起：所有的图形，声音，整个事物;然后你可以直接编码。

我的MVC是一种超常规配置，可以减慢原型设计速度。 但是（！）迭代的开发可以更容易。测试，尤其是单元测试的速度要快得多。 我会说MVC将你的发展速度曲线（通常是反指数曲线）变成指数曲线。开头慢，但最后越来越快。

Answer 4

MVC非常适合游戏，至少对于我为跨平台设计的游戏而言。 这实际上取决于你如何实现它以获得好处。