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

EN

将Model看作一种游戏API可能会对您有所帮助。如果游戏从一开始就没有用户界面，你的游戏会变成什么样子呢？你提到你脑海中的是一个RPG，所以在这种情况下，你可以想象玩家的角色，他/她的库存，法术，能力，NPCs，甚至地图和战斗规则等东西都是模型的一部分。这就像大富翁的规则和碎片，没有详细说明最终游戏如何显示它，或者用户将如何与它交互。它就像Quake一样，是一组抽象的3D对象，通过一个级别移动，计算交集和碰撞，但没有渲染、阴影或声音效果。

通过将所有这些放入模型中，游戏本身现在是UI不可知的。它可以连接到ASCII文本界面，比如Rogue游戏，或者类似于Zork的命令行UI，或者基于web的3D UI。根据游戏机制的不同，其中一些UI可能不太适合，但它们都是可能的。

视图层是依赖于UI的层。它反映了您对UI的具体选择，并将非常专注于该技术。它可能负责读取模型的状态并将其绘制为3D、ASCII或web页面的图像和HTML。它还负责显示玩家与游戏交互所需的任何控制机制。

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

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

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

你在这方面做得很好。基本上，问问自己这个问题：“如果我必须更改程序的某一部分，哪些代码会更改？”

如果它可以在不改变基本数据的情况下改变外观，那么它就在视图中。如果它是可以从很多方面查看的数据，那就是模型。如果是你怎么玩的，那就是控制力。

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

集中用户交互逻辑的MVC概念是一个很好的游戏开发模型。

我做了一些Flash游戏开发的工作。Here是一篇关于闪存中对象池的文章。这个概念是跨平台的，可能会给你一些启发。

你一次关心所有的事情是正确的。根据您的游戏设计，您的游戏循环可能有很多需要处理。这是您将学习所有肮脏的优化技巧的地方，通常是很难的方式:)

有许多方法可以组织您的代码-一种方法可能是将GameManager类编写为单例。所有游戏对象都绑定到它以进行管理和用户交互。GameManager处理所有用户输入，并将消息分派到其对象池。您可以使用接口来定义游戏对象和GameManager之间的通用通信模式。

就性能优化而言，线程是非常强大的。异步操作可以确保您不会浪费这些宝贵的周期。