可能会帮助您将模型视为一种游戏API。如果从一开始就没有针对该游戏的用户界面，那么您的游戏将沦为什么？您提到的是，您所想到的是RPG，因此在这种情况下，您可以想象拥有角色，他/她的库存，咒语，能力，NPC甚至是地图和战斗规则之类的东西都属于模型。就像垄断的规则和部分一样，没有最终游戏如何显示或用户如何与之交互的细节。就像《雷神之锤》一样，它是一组抽象的3D对象，它们在一个关卡中移动，并计算出诸如相交和碰撞之类的东西，但没有渲染，阴影或声音效果。

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

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

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

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

然后，如果经过60秒导致玩家的基地进行了一些维修，则该基地可能会进行维修，并立即通知与之相连的所有观察者该基地已经更新。视图可以作为观察者附加，请注意，由于其状态已更改，因此需要重新显示基础。通知本身可能已经包含了足够的信息来更新View，或者它可能必须转过身来咨询模型以进行更新，但是结果将是相同的。