基于混合组件的设计和模型视图（ - 控制器）模式

Question

正在开发2D游戏，我希望将游戏引擎从图形中分离出来。我决定用以下方式使用模型视图模式：游戏引擎拥有实现接口（敌人，子弹，爆炸）的游戏实体（EnemyModel，BulletModel，ExplosionModel）。

视图在创建实体时接收事件，获取指向界面的指针：以这种方式，View只能使用界面方法（即询问信息来执行绘图），并且不能更改对象状态。视图有它的onw类（EnemyView，BulletView，ExplosionView），它拥有指向接口的指针。 （还有一个涉及事件的模式，以便模型可以通知视图关于实体的变化，因为纯粹的查询方法是不稳定的，但我不会在这里讨论它）。 *模型类使用编译时组件方法：它们使用boost :: fusion库来存储不同的状态组件，如PositionComponent，HealthComponent等等。

目前，视图并不知道基于组件的设计，而只知道模型视图部分：为了获得敌人的位置，它调用Enemy :: get_xy（）方法。实现接口的EnemyModel将此调用转发给PositionComponent并返回结果。

由于子弹也有位置，我也必须将get_xy方法添加到Bullet中。 BulletModel然后使用与EnemyModel类相同的实现（即它转发呼叫）。

这种认识会导致有很多重复的代码：接口有很多类似的方法和*模型类充满了前向方法。

所以我基本上有两种选择：

1）暴露的成分，它为基础的设计，使每个组件都有一个接口，以及：查看可以使用此接口直接查询组件。它保持视图和模型分离，只在组件级别而不是实体级别。

2）放弃模型视图部分，进行纯基于组件的设计：View只是一个组件（RenderableComponent部分），它基本上完全访问游戏引擎。

根据你的经验，哪种方法最好？

Answer 1

我会给我两美分的价值。从你描述的问题来看，在我看来，你需要一个抽象类来完成所有类中常见的操作（例如get_xy，它应该适用于子弹，敌人，爆炸等）。这个班级是一个完成基本工作的游戏实体。继承类可以覆盖它，如果他们想要的话。

这个抽象类应该是所有接口的核心（幸运的是，你在C++中，类和抽象类和接口之间没有物理差异）。因此，视图将知道具体的接口，并且仍然有通用的实体方法。

我有一个经验法则 - 如果不止一个类具有相同的数据成员或方法，它应该可能是它们继承的单个类。

无论如何，暴露你的Model类的内部结构不是一个好主意。假设你想用别的东西替代增强？你不得不重写整个程序，而不仅仅是相关的部分。

Answer 2

MVC对游戏来说很不容易，因为当游戏变得更大时（包括菜单，敌人，关卡，图形用户界面......）和转换，它会中断。

组件或实体系统对于游戏非常不错。

作为一个更简单的情况，你可以考虑使用HMVC。您仍然会遇到转换问题，但至少您的代码将以更干净的方式组合在一起。你可能希望你坦克的代码（渲染和逻辑）靠得很近。

Answer 3

已经有专为基于代理的系统设计的演示架构，例如演示抽象控制。设计这样一个系统的难点在于您最终最终会在代理之间进行硬连线的协作。

您可以这样做，但不要使用OO继承来模拟消息传递层次结构。你会后悔的。如果你仔细想想，你真的不想使用OO继承关系，因为定义的接口实际上只是对象可以响应的“函数记录”。在这种情况下，您最好对通信协议进行正式建模。

如果您有任何问题，请询问 - 这不是一个明显的解决方案，容易出错。