Register Game Object Components in Game Subsystems? (Component-based Game Object design)

Question

I'm creating a component-based game object system. Some tips:

1. GameObject is simply a list of Components.
2. There are GameSubsystems. For example, rendering, physics etc. Each GameSubsystem contains pointers to some of Components. GameSubsystem is a very powerful and flexible abstraction: it represents any slice (or aspect) of the game world.

There is a need in a mechanism of registering Components in GameSubsystems (when GameObject is created and composed). There are 4 approaches:

---

• 1: Chain of responsibility pattern. Every Component is offered to every GameSubsystem. GameSubsystem makes a decision which Components to register (and how to organize them). For example, GameSubsystemRender can register Renderable Components.

pro. Components know nothing about how they are used. Low coupling. A. We can add new GameSubsystem. For example, let's add GameSubsystemTitles that registers all ComponentTitle and guarantees that every title is unique and provides interface to quering objects by title. Of course, ComponentTitle should not be rewrited or inherited in this case. B. We can reorganize existing GameSubsystems. For example, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter can be merged into GameSubsystemSpatial (to place all audio, emmiter, render Components in the same hierarchy and use parent-relative transforms).

con. Every-to-every check. Very innefficient.

con. Subsystems know about Components.

---

• 2: Each Subsystem searches for Components of specific types.

pro. Better performance than in Approach 1.

con. Subsystems still know about Components.

---

• 3: Component registers itself in GameSubsystem(s). We know at compile-time that there is a GameSubsystemRenderer, so let's ComponentImageRender will call something like GameSubsystemRenderer::register(ComponentRenderBase*).

pro. Performance. No unnecessary checks as in Approach 1.

con. Components are badly coupled with GameSubsystems.

---

• 4: Mediator pattern. GameState (that contains GameSubsystems) can implement registerComponent(Component*).

pro. Components and GameSubystems know nothing about each other.

con. In C++ it would look like ugly and slow typeid-switch.

---

Questions: Which approach is better and mostly used in component-based design? What Practice says? Any suggestions about implementation of Approach 4?

Thank you.

Answer 1

Door number 3... Component registers itself in GameSubsystem(s)

The component is in place to keep the coupling abstracted from the GameObject itself. Somehow, somewhere something does in fact need to interact with the subsystems and this is the component and its purpose.

The coupling isn't actually a bad thing in this case.

The performance is essentially required in this case if you expect to have any complexity in your system, you just can't afford the search style approaches of the other options.

Finally if one subsystem needs to be reactive to another (renderer, physics, audio all need to do stuff when something happens) the components can facilitate this with each other through the game object and keep this particular type of cross system-coupling managable through the components.