MVC（模型-视图-控制器）游戏引擎体系结构-是或否？[关闭]

我正在阅读一本很棒的书《Game Coding Complete》，该书强烈建议使用MVC（模型-视图-控制器）方法，并具有三个关键层：

1. 游戏应用层
2. 游戏逻辑
3. 游戏画面

在我看来，这种方法似乎对移动计算机游戏来说是一个过大的杀伤力。

请问您对此有何看法？即使增加了模块之间所需的额外通信，实现这种体系结构是否值得？此设计是否会消耗大量CPU能量，以致最终结果会比未实现时慢得多？

我什至支持将MVC结构用于简单的移动游戏。如果没有别的，它可以解决一个困扰没有足够时间被开发者困扰的问题：将显示代码与游戏逻辑分离。

不过，我还要说，要记住，MVC与所有设计模式一样，可以使您的生活更轻松。这意味着，如果在任何给定时间遵守有关使用MVC时应该做什么和不应该做什么的一组规则，将会使您的生活更加艰难，请忽略它。将发生以下两种情况之一：1）您稍后会被咬，然后将理解为什么从头开始做不同的事情从长远来看实际上会让您的生活更轻松，或者2）没有任何后果。

从本质上讲，计算机程序设计吸引了许多规则制定者，他们重视遵循优雅原则而不是实际完成任何事情，并且他们喜欢提出自己的价值体系。不要让他们让你成为其中之一。您的游戏可能发生的最重要的事情是发布它。

除非您拥有令人难以置信的糟糕的编译器，否则编译时设计不会消耗CPU能力。面向对象的语言或方法的性能特征与过程语言没有什么不同。您不会为使用MVC调用任何其他开销。模块化存在于编译时，而不是运行时，一旦代码被内联和优化，就不会有任何区别。

许多现代游戏实际上在单独的线程上运行模型和视图，并在大多数平台上获得了巨大的性能优势。

最终，MVC是一个不错的设计，可让您免费获得更多的维护和更少的错误。没有理由不使用它。这就像问为什么要使用for循环而不是手写的gotos。除非您有出色的设计，否则肯定比没有更好。

编辑：编译时设计不消耗CPU能力。像继承这样的运行时设计显然可以做到。

在代码的清晰度和程序的技术要求（速度，内存等）之间，几乎总是要权衡取舍。面向对象的语言与过程语言相比具有开销，但是事实证明它们比过程语言具有许多优势，尤其是在代码的长期维护（错误等）以及开发速度方面。

因此，考虑到这一点，我建议MVC作为游戏程序员值得为您实现。您的代码将更好地遵循面向对象的原则，尤其是封装，并且可能会更容易维护（修复错误或添加新功能）。

另一方面，请确保实际完成游戏，不要花太多时间在“引擎”上工作，以至于永远无法完成。

有关更多信息，请阅读问题“为什么不在游戏体系结构中更多地使用MVC和TDD？” 我的回答很长。