如何组织游戏的代码以适应 MVC 模式？

将模型视为一种游戏 API 可能会帮助您。如果从一开始就没有为游戏指定UI，您的游戏将简化为什么？你提到你想到的是RPG，所以在这种情况下，你可以想象玩家角色，他/她的物品栏，法术，能力，NPC，甚至像地图和战斗规则这样的东西都是模型的一部分。它就像《大富翁》的规则和片段，没有最终游戏如何显示或用户将如何与之交互的细节。它就像Quake一样，是一组抽象的3D对象，在关卡中移动，计算了交叉点和碰撞等内容，但没有渲染，阴影或声音效果。

通过将所有这些放入模型中，游戏本身现在与UI无关。它可以挂接到像Rogue游戏那样的ASCII文本界面，或者类似于Zork的命令行UI，或者基于Web的3D UI。根据游戏机制的不同，其中一些UI可能是一个可怕的契合，但它们都是可能的。

视图层是 UI 相关层。它反映了您使用的UI的具体选择，并将非常致力于该技术。它可能负责读取模型的状态，并以 3D、ASCII 或图像和 HTML 绘制网页。它还负责显示玩家与游戏交互所需的任何控制机制。

控制器层是两者之间的粘合剂。它永远不应该包含任何实际的游戏逻辑，也不应该负责驱动 View 层。相反，它应该将在视图图层中执行的操作（单击按钮，单击屏幕区域，操纵杆操作等）转换为对模型执行的操作。例如，掉落物品，攻击NPC等等。它还负责收集数据并执行任何转换或处理，以使 View 图层更容易显示数据。

现在，我上面描述它的方式是，好像有一个非常独特的事件序列驱动着游戏，这可能只适合网页游戏。那是因为这就是我最近花时间做的事情。在一个不受用户请求和服务器响应（如网络）驱动的游戏中（例如，在用户机器上运行的游戏），您可能希望确保模型层很好地实现了观察者模式。例如，如果由于时间流逝而在模型中发生操作，则您可能不希望视图层不断轮询模型以获取更新。相反，通过使用观察者模式，模型可以在发生模型对象更改时通知任何观察者。这反过来又可以用来提示立即更新视图以反映更改。

然后，如果 60 秒的过去导致玩家的基地发生一些维修，基地可能会影响维修，并立即通知任何附加到它的观察者基地已经更新。视图可以附加为观察点，并注意它需要重新显示基础，因为它的状态已更改。通知本身可能包含足够的信息来更新视图，或者它可能必须转身并查阅模型才能更新，但结果将是相同的。

你在那里相处得很好。基本上，问问自己一个问题：“如果我必须更改程序的某些部分，哪些代码会改变？

如果它在不更改基本数据的情况下更改其外观，则它位于视图中。如果数据可以通过多种方式查看，那就是模型。如果这是你的游戏方式，那么它就是控制。

因此，如果您用两个刀片还是一个刀片绘制“斧头”，那就是视图。如果是你用斧头造成多少生命值伤害，那就是模型。如果你是通过键入“s”还是通过右键单击来摆动斧头，那就是控制。