基于混合组件的设计和模型-视图(-controller)模式
我正在开发一个2D游戏，我想将游戏引擎从图形中分离出来。我决定以如下方式使用模型-视图模式:游戏引擎拥有实现接口(敌人，子弹，爆炸)的游戏实体(EnemyModel，BulletModel，ExplosionModel)。
视图在创建实体时接收事件，获取指向接口的指针:在这种方式下，视图只能使用接口方法(即请求信息来执行绘图)，而不能更改对象状态。视图有自己的onw类(EnemyView、BulletView、ExplosionView)，这些类拥有指向接口的指针。(还有一个基于事件的模式，这样Model就可以通知视图实体的变化，因为纯粹的查询方法是不实用的，但我不会在这里讨论它)。
*模型类使用编译时组件方法:它们使用boost::fusion库来存储不同的状态组件，如PositionComponent、HealthComponent等。
目前，视图还不知道基于组件的设计，而只知道模型视图部分:为了获得敌人的位置，它调用Enemy::get_xy()方法。实现该接口的EnemyModel将此调用转发给PositionComponent并返回结果。
由于bullet也有位置，因此我必须将get_xy方法也添加到Bullet中。然后，BulletModel使用与EnemyModel类相同的实现(即，它转发调用)。
这种方法会导致有很多重复的代码:接口有很多类似的方法，而*模型类充满了转发方法。
所以我基本上有两个选择：
1)公开基于组件的设计，以便每个组件也有一个接口: View可以使用此接口直接查询组件。它保持视图和模型的分离，仅在组件级别而不是实体级别。
2)放弃模型-视图部分，转向纯粹的基于组件的设计:视图只是一个组件( RenderableComponent部分)，基本上可以完全访问游戏引擎。
根据您的经验，哪种方法最好？
回答 3
Stack Overflow用户
发布于 2010-09-22 18:44:39
我认为我的两分钱是值得的。从你描述的问题来看，在我看来，你需要一个抽象类来执行所有类中常见的操作(比如get_xy，它应该应用于子弹、敌人、爆炸等)。这个类是一个游戏实体，它完成基本的任务。如果需要，继承类可以重写它。
这个抽象类应该是所有接口的核心(幸运的是，您在C++中，类、抽象类和接口之间没有物理区别)。因此，视图将知道特定的接口，并且仍然具有泛型实体方法。
我有一条设计经验法则--如果多个类具有相同的数据成员或方法，那么它可能应该是它们继承的单个类。
无论如何，公开Model类的内部结构不是一个好主意。说你想用其他东西替换boost？你必须重写整个程序，而不仅仅是相关的部分。
Stack Overflow用户
发布于 2010-09-22 18:36:10
MVC对于游戏来说并不容易，因为当游戏变得更大时(包括菜单，敌人，关卡，图形用户界面...)和过渡，它会崩溃的。
组件或实体系统对于游戏来说是非常好的。
对于您来说，更简单的情况是，您可以考虑使用HMVC。您仍然会遇到转换的问题，但至少您的代码将以一种更干净的方式组合在一起。您可能希望您的坦克的代码(渲染和逻辑)接近在一起。
Stack Overflow用户
发布于 2010-11-11 04:10:13
已经有专门为基于agent的系统设计的表示体系结构，例如表示-抽象-控制。设计这样一个系统的困难之处在于，您最终会硬连线代理之间的协作序列。
您可以这样做，但不要使用OO继承来建模消息传递层次结构。你会后悔的。如果你仔细想想，你真的对使用OO继承关系不感兴趣，因为定义的接口实际上只是对象可以响应的“函数记录”。在这种情况下，您最好对通信协议进行正式建模。
如果你有问题，请问--这不是一个显而易见的解决方案，很容易出错。
https://stackoverflow.com/questions/3768339
复制相似问题
腾讯云开发者
