rov*_*ghn 10 oop components visitor game-engine
我想这个问题或它的变化会传递很多,所以如果我说的是重复的,答案在其他地方,请通知我.
我一直在研究游戏引擎设计,并且遇到了基于组件的实体模型.这听起来很有希望,但我仍在努力实施它.
我正在考虑一个系统,其中引擎安排了几个"子系统",它管理一些方面,如渲染,声音,健康,AI等.每个子系统都有一个与之关联的组件类型,就像健康的健康组件子系统."实体",例如NPC,门,某些视觉效果或播放器,简单地由一个或多个组件组成,这些组件一起为实体提供其功能.
我确定了四个主要的信息传递渠道:一个组件可以广播到其当前实体中的所有组件,一个组件可以广播到其子系统,一个子系统可以广播到其组件,一个子系统可以广播到其他子系统.
例如,如果用户想要移动他们的角色,他们会按一个键.此按键将由输入子系统拾取,然后输入子系统广播该事件并由播放器子系统拾取.然后,播放器子系统将此事件发送给所有播放器组件(以及这些组件组成的实体),并且这些播放器组件将与其自己的实体的位置组件通信以继续并移动.
所有这一切对于一个关键的新闻似乎有点啰嗦,我当然愿意改进这种架构.但无论如何,我的主要问题仍然存在.
至于事件本身,我考虑了事件在访客模式中的行为.我想要的重要性是,如果一个事件遇到它不支持的组件(因为在移动事件中没有与AI或健康直接相关),它将忽略该组件.如果一个事件没有找到它正在追踪的组件,那就没关系了.
访客模式几乎可行.但是,它需要我为每种类型的组件(即visitHealthComponent,visitPositionComponent等)提供虚函数,即使它与它们没有任何关系.我可以将这些函数留空(所以如果遇到这些函数,它会被忽略),但每次添加一个组件时我都要添加另一个函数.
我希望能够添加一个组件而不必将东西添加到其他地方,并添加一个事件而不会弄乱其他东西.
那么,我的两个问题:
我一直在考虑在我自己的一个项目中使用实体系统，并且经历了类似的思考过程。我最初的想法是使用观察者模式来处理事件 - 我也最初考虑过某种访问者模式，但由于您提出的原因而决定反对它。
我的想法是，子系统将提供子系统特定的发布/订阅接口，因此子系统依赖性将以“半松散”耦合的方式解决。任何依赖于另一个子系统的事件的子系统都会知道该子系统的订阅者接口，因此可以有效地利用它。
不幸的是，这些订阅者如何获取他们的发布者的句柄在我看来仍然是一个问题。在这一点上，我赞成某种动态创建，其中每个子系统都被实例化，然后使用第二阶段来解决依赖关系并将所有子系统置于“就绪状态”。
不管怎样，我对你的成果以及你在项目中遇到的任何问题非常感兴趣:)