为什么在游戏架构中不更多地使用MVC和TDD？[关闭]

首先，我不会看大量的游戏资源，也不会以游戏的方式构建游戏。

但是，由于试图在Web应用程序中采用“企业”编码实践，查看游戏源代码严重伤害了我的头脑：“这种视图逻辑与业务逻辑的关系是什么？这需要重构……重构，重构，重构也是如此吗？ ”

这让我很担心，因为我将要开始一个游戏项目，而且我不确定尝试对mvc / tdd的开发过程是否会阻碍我们或为我们提供帮助，因为我看不到很多使用此功能的游戏示例或在社区中推动更好的建筑实践。

以下是一篇有关原型游戏的精彩文章的摘录，尽管对我而言，这似乎正是许多游戏开发人员在编写正式游戏代码时似乎使用的态度：

错误四：构建系统而不是游戏

...如果您发现自己从事的工作无法直接推动自己前进，请就此停下来。作为程序员，我们倾向于尝试将代码泛化，使其变得优雅并能够处理各种情况。我们发现痒痒非常难，不会刮伤，但是我们需要学习如何做。我花了很多年才意识到，这与代码无关，而与最终发布的游戏有关。

不要编写精美的游戏组件系统，不要完全跳过编辑器，而将状态硬编码到代码中，避免数据驱动，自解析，XML疯狂，而只需编写该死的东西。

...尽可能快地在屏幕上获取内容。

而且永远不要使用参数“如果我们花一些额外的时间并以正确的方式进行操作，我们可以在游戏中重用它”。永远

是因为游戏（大多）是面向视觉的，所以有意义的是代码将在视图中占很大的比重，因此将内容移到模型/控制器中所获得的任何好处都非常少，所以为什么要打扰？

我听到过这样的论点，即MVC引入了性能开销，但是在我看来这是过早的优化，在担心MVC开销（例如渲染管道，AI算法，数据结构）之前，还有更多重要的性能问题需要解决遍历等）。

关于TDD也是一样。我很少看到游戏使用测试用例，但这可能是由于上述设计问题（混合视图/业务）以及难以测试视觉组件或依赖概率结果的组件（例如，在物理模拟中运行）造成的。 ）。

也许我只是看错了源代码，但是为什么我们看不到游戏设计中采用的更多“企业”实践呢？游戏的需求真的有如此大的不同吗？还是人/文化问题（例如，游戏开发者来自不同的背景，因此具有不同的编码习惯）？

引言说，许多程序员都犯了（试图）构建系统而不是游戏的错误。通常，该系统会不断膨胀，直到其变得如此复杂以至于理论上它无法处理任何事情为止，但实际上，您所拥有的只是一大堆代码。或更经常地，甚至在您还未进入工作阶段之前，您就会陷入无法运行的代码中，以至于您失去了注意力（如果有什么开始的话）和动力（因为什么都没有真正起作用）。

原型和迭代往往会更好地工作。最后，可能会产生出出色的设计，但通常会出现更简单，更精致的设计。想到KISS和YAGNI。

我个人认为需要保持平衡。如果您的游戏具有核心机制，请继续努力。您仍然需要进行迭代，但是您需要对其进行优化。提示：代码的组织不是游戏的核心机制。

例如：PopCap Games的Peggle。游戏的核心机制是球物理。他们完善了！我敢肯定，他们花了很多时间来确保它绝对完美，因为这正是游戏的源头。但是同时，我可以完全想象出他们游戏的早期原型，它可能只是将精灵绘制到屏幕上，并进行某种更原始的碰撞检测和弹跳，只是看游戏理念是否有趣。然后，一旦他们发现射击球并观看弹跳实际上很有趣，便会改进球的弹跳。_{（当然，这仅仅是猜测）}

它还取决于您的技术要求，您应该尽早确定这些要求（不是游戏设计，而只是技术要求）。游戏运行的平台不应该更改，或者如果应该允许更改，则需要确切知道计划允许更改的范围，不要多也不少。设计上。如果您正在为OpenGL开发游戏，并且不关心DirectX，那么实际上就不必关心它。这意味着，如果让每个实体自己绘制更为方便，而不用担心工厂和类似的其他设计模式，那么就可以这样做。可以，因为它符合要求。尽管您自己说了什么，也不必稍后再进行更改。真的，最坏的情况吗？稍后重构。，即使它不能同时自动在烤面包机上运行，​​也可以在一个平台上运行游戏。

但是，测试驱动的设计是一个比较固执的话题。我相信游戏开发人员应该做更多的事情。我还认为游戏开发人员有一些最严格，最严格的时间表，他们认为仅想让一款游戏发展时，他们就无法花时间在TDD上。同样，出于这种动机，TDD的运行速度要慢得多，而且您会发现运行正常的游戏要少得多（至少在开始时如此）。这可能会对程序员的动机产生严重的负面影响。

我认为这也是普遍缺乏知识和实践的地方。我也不认为TDD在其他领域也很普遍，但是像敏捷开发一样，我认为它正在传播。您可能会说它提前了（或者可能不是，因为现在可能要几年了）。比TDD更重要的是“ RDD”-需求驱动开发。_{我只是编造的。}你的目标是什么？做游戏。其他一切都排在第二位。如果您可以证明TDD可以提高生产率并帮助团队按时完成任务，那么您不认为每个人都会使用它吗？也许是这样。但是现在，我们的行业比以往任何时候都更具竞争力，有越来越多的最后期限，而且工作还需要解决。建筑工人不首先建造脚手架。他们打基础，然后抬高墙壁和地板，然后才建造选择性的脚手架，以完成特定的任务，从而使脚手架更加方便。我认为软件开发也是如此。

抱歉，这么长的帖子。希望您从中获得一些智慧。我只是一个学生，在谈论我的观察结果时，只有非常有限的行业经验，但很多行业专家都在阅读。所以，我一言不发。

嘿，做您认为可行的事情。您可以随时对其进行更改或报废并重新开始。对于任何形式的工程来说，这都是很酷的事情。如果一开始您没有成功，请尝试其他尝试。（或者类似的:-P）您不是在浇混凝土；软件具有延展性。

顺便说一句，我一直在问同样的问题，并研究了这类设计原则已有一段时间了。在这里和堆栈溢出中，有一些可能与您相关的问题：

• “如何组织游戏代码以适应MVC模式？”
• “如何设计易于单元测试的游戏软件？”
• “基于组件的游戏引擎设计”
• “是否有任何好的教程或资源来学习如何设计可扩展的，基于“组件”的游戏“框架”？”
• “游戏和渲染逻辑的分离”
• “单元测试在游戏编程中是否可行？”
• “是用于商业计算机游戏的MVC设计模式”
• “测试驱动开发是游戏开发中的常规方法吗？”
• “你们中有人使用Scrum进行游戏开发吗？”
• “游戏架构-情侣还是不情侣？”
• “ OO游戏设计问题”

这是我对SO上类似问题的最初回答，至少与您问题的MVC部分有关：

在游戏中很少使用。我花了一段时间才弄清楚原因，但这是我的想法：

MVC的存在是为了区分两种表示形式。模型是数据的抽象表示。这是机器查看应用程序状态的方式。视图（和控制器）以对人类有意义的方式表示该系统的更具体的可见实例。

在大多数商务应用中，这两个世界是完全不同的。例如，电子表格的模型只是一个二维值网格。不必考虑单元格在像素中的宽度，滚动条的位置等。同时，电子表格视图也不知道单元格值是如何计算或存储的。

在游戏中，这两个世界彼此更接近。游戏世界（模型）通常是位于某个虚拟空间中的一组实体。游戏视图也是位于某些虚拟空间中的一组实体。界外的体积，动画，位置等，您认为属于“视图”的所有内容也直接由“模型”使用：动画会影响物理和AI等。

最终结果是，游戏中模型和视图之间的界限是任意的，无济于事：您最终将在它们之间复制很多状态。

取而代之的是，游戏往往会沿领域边界解耦：人工智能，物理，音频，渲染等将尽可能保持独立。

因为MVC不适合游戏的体​​系结构。游戏的数据流与Enterprice应用程序的数据流完全不同，因为它不是受事件驱动的，并且通常有（非常）毫秒的预算来执行这些操作。有许多事情需要在16.6毫秒内发生，因此拥有“固定的”刚性数据管道来处理恰好在那时所需的数据更为有益。

此外，还有分离。大多数情况下，它的接线方式与MVC模式不同。有一个渲染引擎（视图），用户输入处理（控制器）和其余的，如游戏逻辑，人工智能和物理（模型）。考虑一下；如果要获取用户输入，运行ai并每秒渲染60次图像，那么为什么在模型和视图之间需要一个Observer来告诉您发生了什么变化？别以我所说的那样解释您在游戏中不需要观察者模式，但是在这种情况下，您确实不需要。无论如何，您正在做所有工作，每一帧。

尽管TDD很少在开发工作室中使用，但我们确实将敏捷实践用于软件开发，而SCRUM似乎至少在欧洲是最受欢迎的选择。原因很简单，变化无处不在。艺术家可能需要更多的纹理预算，更大的世界，更多的树木，而设计师可能需要更丰富的故事（磁盘上的更多内容），流媒体世界，而发布者希望您按时完成工作，并且营销部门也是如此。除此之外，“最新技术”一直在迅速变化。

这并不意味着我们也不进行测试，大多数工作室都有大型的问答部门，运行大量的回归测试并定期进行单元测试。但是，几乎没有必要进行单元测试，因为大部分错误是与艺术/图形相关的（单元网格无法覆盖的漏洞（碰撞网格中的孔，错误的纹理，视场着色器深度的毛刺））。除了有效的代码外，任何游戏中最重要的因素是它很有趣，并且没有任何单元测试。

还请记住，在控制台世界中，这甚至仍然有所不同，因为您要为硬件而不是其他任何东西进行更多编程。通常（PS2 / PS3）意味着在几乎每种情况下，数据流比代码流更重要。由于性能方面的考虑。在大多数情况下，这会使TDD作为体系结构工具的使用无效。良好的OOP代码通常具有不良的数据流，使其难以向量化和并行化。

为什么在游戏架构中不更多地使用MVC和TDD？

警告：前方意见。

不使用MVC的原因很多：

1. MVC是一种相对较新的方法，游戏通常基于旧代码构建。制作MVC应用程序的大多数人每次都一无所有。（我知道MVC本身实际上已经有几十年历史了；新的东西是对它的广泛兴趣，这基本上来自像RoR这样的Web应用程序）。在我开发的基于遗留代码的商业软件中，MVC也没有用。这是一种文化，但不是特定于游戏的。
2. MVC本质上是事件驱动程序的GUI模式。游戏既不是GUI主导也不是事件驱动，因此适用性不如Web应用程序或其他基于表单的应用程序那么大。MVC通常是具有一些知名角色的Observer模式，游戏通常没有奢望等着观察有趣的事物-他们必须在每一帧（或其上的某些变化）中更新所有内容，无论是否有人单击任何内容。

这并不是说游戏不能从MVC中学到很多东西。我总是尝试将模型与我制作的游戏中的视图分开。尽管视图和控制器是同一（小部件）对象的两个部分的传统想法实际上并没有奏效，所以您必须对此稍微抽象一些。我同意您的看法，在这里性能不太可能是一个真正的问题。如果将可视化内容和逻辑内容分开保存会提高性能，因为它更适合缓存一致性，并行性等。

未使用TDD（很多）是因为：

1. 在游戏中使用确实很尴尬。同样，对于事件驱动的软件来说，输入和输出都很好，您可以将看到的内容与期望的内容进行比较，然后将其打勾为正确。对于具有大量共享状态的模拟，它要尴尬得多。
2. 没有无可争议的证据表明它可以帮助一切。仅有很多主张，一些数字通常基于自我报告和对权威的诉求。也许它可以帮助贫穷的程序员变得平庸，但却阻碍了优秀的程序员。也许花时间编写测试可能比花更多的时间学习SOLID原理或首先设计正确的界面更好。可能通过测试通过而没有任何真实证据证明您有足够的测试来确保您的对象做正确的事情，这给人一种错误的安全感。

再次提醒您，我认为单元测试很棒，但我认为“先测试”既无益也不明智。当每秒有很多次共享状态变化很多时，我也认为测试主仿真是不切实际的。通常，我将测试限制在我的底层代码和库代码中。

但是，您可能会猜到，我对“企业”编码实践有很大的偏见，因为企业以超支的时间规模和预算而闻名。“游戏开发商也是如此！” 我听到你说-好吧，是的。我认为现在还没有人真正知道开发软件的最佳方法，而且我也不相信主流软件中采用规范的做法与娱乐软件中的自由做法完全没有任何距离。实际上，我怀疑对那些依赖商品Java程序员的人来说，这主要是有益的，因为这些方法不是爬上更高台阶的阶梯，而是防止他们跌落过低的安全网。

正如Kylotan指出的那样：“在游戏中，您不能将表示方面视为可分离和可替换的概念（例如HTML和CSS）用于Web应用程序”。使用简单的MVC模式（不是大型框架）构建了几款游戏之后，我发现主要的问题是您的模型需要了解您的视图。您很有可能需要使用艺术品资源中的精灵位图数据，命中盒数据或3D几何数据来帮助进行碰撞检测（或其他类似任务）。这意味着每个模型都需要引用其视图，这将打破经典的MVC模式-例如，您不能再为现有模型创建新视图等。

您在Unity3D中看到的组件模型是组织游戏代码的最佳方法。

在某些级别上，MVC已用于游戏开发中。它由OS强制执行，它具有用于输入和图形的不同接口。大多数游戏中还包含其他一些MVC实例，例如，将物理层分离，渲染和输入线程。这很好。MVC的现代想法似乎是，应该分次重复该过程，直到没有人能再理解该代码为止。幸运的是，游戏无法做到这一点。

未使用TDD，因为在您多次迭代原型之前，很少有人会“假设要做”游戏。TDD的实践，例如连续测试或集成测试，经常用于游戏开发中。

游戏系统正在逐步向更好的做法发展。诸如XNA之类的框架提供了使代码更通用/更干净的见解，而又不会增加设计或执行时间的开销。但总的来说，我想说的是，游戏系统的主要目的是优化复杂性和执行速度，同时保持紧迫的开发进度并保持积极性。在这样的环境中，应用软件工程概念和系统设计并不是第一要务。

在我的个人游戏项目中，我尝试注释代码或至少使其可读性，并且我将一些系统组合在一起，以便在以后（即通用性）尽可能多地灵活一些，但最终要是您尚未将游戏向前推进，只是感觉不太好。

同样，通常到完成游戏时，您就如何改善底层机制，核心系统等至少有了1000个想法，以至于很少有“可重用”代码会真的可以使用。每天我都从事常规的SE工作，尽管我们使用的系统可能非常庞大，但老实说，与游戏的复杂性相比，我认为它们显得苍白。

我对MVC并没有什么特别的看法，因为通常情况下，视图会与逻辑分离，因为一个简单的事实，即渲染循环将一堆东西打包起来供某些硬件处理，而那不是您想要的“游戏”逻辑”同时发生。“控制器”也被硬件分隔开，但是不幸的是，如果不是大多数游戏开发人员，很多游戏开发人员都会在控制器处理程序中进行“有趣的”工作。（IMO管理员应该正在阅读按钮和操纵杆，并为游戏观看创建“演示文稿”，但是我的肥皂盒并不是那么强大。）

另一方面，我对TDD的看法非常强烈。它只是改变开发方式，以产生易于构建的软件。毫无疑问，这很难做。当然，由于很难做到，所以没有完成。有些人抱怨TDD（或更笼统地说是单元测试）没有价值，因为“游戏就是测试”，但事实是，在TDD中，测试几乎是无关紧要的。TDD的重点是过程中出现的软件设计和体系结构。

拥抱TDD确实会改变一个人的编程方式。在踏上TDD道路之前，我对什么是对，什么是错有一些感觉，但是当我用双脚跳进去时，我真的变得更加了解我正在做的事情是如何帮助或阻碍了未来的发展。确实，这是代码室帖子TDD背后的要点，没有。

回到为什么它在游戏中没有得到更多使用的原因，不仅仅在于努力，它还使人们意识到，过去一直以来的做法不必要地使自己的工作变得更加困难，对于程序员来说，尤其是，这甚至是一个痛苦的药丸，少吞咽。

我坚信拒绝接受TDD的人根本不想成为更好的程序员。他们已经认为他们在编程，设计或体系结构方面“出色”，而实际上他们的代码却说完全不同。