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

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

1. GameObject只是的清单Components。
2. 有GameSubsystems。例如，渲染，物理等。每个都GameSubsystem包含一些指向的指针Components。GameSubsystem是一个非常强大且灵活的抽象：它代表游戏世界的任何部分（或方面）。

有在登记的机构的需要Components在GameSubsystems（当GameObject被创建和组成）。有4种方法：

• 1：责任链模式。每个人都Component被提供给每个人GameSubsystem。GameSubsystem决定Components要注册的内容（以及如何组织）。例如，GameSubsystemRender可以注册可渲染组件。

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

骗子 每次检查。效率很低。

骗子 Subsystems知道Components。

• 2：每个Subsystem搜索Components特定类型。

亲 性能比更好Approach 1。

骗子 Subsystems仍然知道Components。

• 3：在中Component注册自己GameSubsystem(s)。我们在编译时知道有一个GameSubsystemRenderer，所以让ComponentImageRender调用类似GameSubsystemRenderer :: register（ComponentRenderBase *）之类的东西。

亲 性能。没有像中那样不必要的检查Approach 1。

骗子 Components与...严重耦合GameSubsystems。

• 4：调解员模式。GameState（包含GameSubsystems）可以实现registerComponent（Component *）。

亲 Components和GameSubystems什么都不知道对方。

骗子 在C ++中，它看起来像丑陋且缓慢的typeid开关。

问题： 哪种方法更好，并且主要用于基于组件的设计？什么做法说？关于实施的任何建议Approach 4？

谢谢。

3号门...组件在GameSubsystem中注册

组件就位，可以保持从GameObject本身抽象的耦合。不知何故，实际上某些地方确实需要与子系统进行交互，这就是组件及其用途。

在这种情况下，耦合实际上并不是一件坏事。

性能基本上需要在这种情况下，如果你希望有任何在您的系统的复杂性，你只是不能搜索风格接近的其他选项。

最后，如果一个子系统需要对另一个子系统做出反应（渲染器，物理学，音频在发生某些事情时都需要做一些事情），则组件可以通过游戏对象相互促进，并保持这种特殊类型的跨系统耦合可通过组件。