下面章节顺序是按照我看到这些文章的顺序安排的

文章一：探讨：为什么在游戏开发中不使用 MVC？

->原文

游戏开发不同于传统互联网产品。传统的互联网产品因为其有着长生命周期，因而追求更稳定，不同模块间具有高度解耦的，从而更易于维护的，设计模式或者框架，并且具有一定程度的复用性。游戏的生命周期大家也都心知肚明，有的开服暴死，有的苟延残喘，有的长线运行，有的在生与死之间反复横跳。

同时也要考虑基于传统开发而诞生出的这些经典的设计模式，设计框架，是否真的适合当前的游戏开发需求？

MVC 的核心，是解决一个 M 多个 V

那么，在游戏开发中，这种需求是否是强需求？需求多不多？到底是根据框架进行填充而开发游戏？还是根据游戏开发搭建框架？别人的框架能直接拿来复用吗？不同游戏之间呢？

作者强调要“根据需求，随机应变”，传统设计模式和框架不一定适用于游戏开发，但不可否认这些传统经典能够给游戏开发过程中带来更多的灵感思考和方向指引。

但不能一味的局限于这些模式和框架而束手束脚，也不能不经思考就直接将框架拿来使用，思考这些经典的提出，核心是为了解决什么问题，是否适用于当前需求。

多点思考和提问。

文章二：Is the MVC design pattern used in commercial computer games?

->原文

第一条回答是那个写《游戏设计模式》这本书的大佬

MVC 框架目的是分离两种形式的 representation

  • 一种是抽象数据：也就是 M，纯纯的数据部分
  • 另一种是直观的数据可视化形式：也就是 V（C 更多的还是和 V 绑定在一起，毕竟提供给用户交互的一般都是以 UI 为主的可视化逻辑引导）

在大部分商业 APP 中，这两个模块可以说是完全不同的。以表格举例，数据就是二维表格数据，它不需要关心被显示在屏幕上时需要用多少像素，也不关心滚动条到底位于哪个位置。对于要展示的部分，这个可视化的二维表格，它也不需要关心这个数据会如何与另一个数据进行加减乘除。两个部分可以说是高度解耦的。

但在游戏中不同，有些时候 M 和 V 就是强相关的，就必须要进行内聚。比如游戏场景中的物体，它的外观，碰撞体积，动画等 V 部分，往往会直接和 M 本身做绑定。

如果强行将二者解耦分离，容易导致二者之间出现大量的 duplication。在游戏中，M 和 V 的边界真的很难区分

不过，可以按照具体的领域进行划分，比如：AI、物理、音频、渲染等等，要尽可能将这些进行明确的区分。

一条评论补充：

  • 如果 view 部分对于时间的要求并不严格，可以将 model 和 view 进行分离
  • 如果对时间要求很严格，出于效率考虑，最好将二者放在一起

大佬对该评论的回复：

  • 对性能的高要求可能会导致实际架构的解耦程度比原本的架构更低

文章三：

->原文

（已加入阅读记录）提问者提到的一篇文章：Prototyping: You’re (Probably) Doing It Wrong

两个原则：

  • K.I.S.S.: Keep it simple, Stupid!
  • YAGNI: You aren’t gonna need it

MVC 本质上是事件驱动程序的 GUI 模式，而游戏一般不是 GUI 主导的，也不是事件驱动的，所以 MVC 的适用性不如 Web 应用程序或其他基于表单的应用程序那么大。

并且，MVC 通常是观察者模式，而游戏通常没有等待观察的奢侈（数据流耗费时间的要求），必须要对每一帧的内容进行更新，无论是否有人点击了任何内容

以及游戏中，M 模块往往需要不断访问 V 模块，这导致了 MVC 的模式架构不再适用