在游戏子系统中注册游戏对象组件？(基于组件的游戏对象设计)

Question

我正在创建一个基于组件的游戏对象系统.一些技巧:

1. GameObject只是一个清单Components.
2. 有GameSubsystems.例如,渲染,物理等.每个都GameSubsystem包含一些指针Components.GameSubsystem是一个非常强大和灵活的抽象:它代表了游戏世界的任何片段(或方面).

有在登记的机构的需要Components在GameSubsystems(当GameObject被创建和组成).有4种方法:

---

• 1:责任链模式.每一个Component都提供给每一个人GameSubsystem.GameSubsystem做出Components注册(以及如何组织它们)的决定.例如,GameSubsystemRender可以注册可渲染组件.

亲.Components对它们的使用方式一无所知.低耦合.答:我们可以添加新的GameSubsystem.例如,让我们添加注册所有ComponentTitle的GameSubsystemTitles,并保证每个标题都是唯一的,并提供按标题查询对象的接口.当然,在这种情况下,ComponentTitle不应该被重写或继承.B.我们可以重组现有的GameSubsystems.例如,GameSubsystemAudio,GameSubsystemRender,GameSubsystemParticleEmmiter可以合并到GameSubsystemSpatial中(将所有音频,发声器,渲染Components放在同一层次结构中并使用父相对变换).

CON.每一次检查.效率很低.

CON.Subsystems知道Components.

---

• 2:每次Subsystem搜索Components特定类型.

亲.比以往更好的表现Approach 1.

CON.Subsystems还是知道的Components.

---

• 3:Component注册自己GameSubsystem(s).我们在编译时知道有一个GameSubsystemRenderer,所以让我们的ComponentImageRender会调用类似GameSubsystemRenderer :: register(ComponentRenderBase*)的东西.
  观察者模式.Component订阅"更新"事件(发送者GameSubsystem(s)).

亲.性能.没有不必要的检查,如Approach 1和Approach 2.

CON.Components很糟糕GameSubsystems.

---

• 4:介体模式.GameState(包含GameSubsystems)可以实现registerComponent(Component*).

亲.Components并且GameSubystems对彼此一无所知.

CON.在C++中,它看起来像丑陋和慢速的typeid-switch.

---

问题: 哪种方法更好,主要用于基于组件的设计？实践说什么？关于(数据驱动)实施的任何建议Approach 4？

谢谢.

Answer 1

投票支持第三种方法。

我目前正在研究基于组件的游戏对象系统，我清楚地看到这种方法的一些额外优点：

• 组件是越来越自给自足的子实体，因为它仅依赖于一组可用的子系统（我假设这组子系统在您的项目中是固定的）。

• 数据驱动设计更适用。理想情况下，通过这种方式，您可以设计一个系统，其中组件完全用数据而不是 C++ 定义。

编辑：我在 CBGOS 工作时想到的一个功能。有时，具有设计和构建无子系统无源元件的能力会很方便。当你想到这一点时，第四种方法是唯一的方法。