Why to use a component based design?
Yeah right, that is a good question. Most game programming tutorials start with considering inheritance hierarchies, how objects should inherit from other objects (Is-a Relation). At the beginning this makes sense and everything is fine and clear. But while the game complexity grows, the inheritance structure becomes larger and larger and at least nothing is clear anymore. This tends to some problems:
- Maintaining and Extending is difficult
- Debugging/Testing makes you crazy
- Naming of methods and members
So the first thing to do, as every modern software design book tells, is using composition over inheritance. This is one fundamental of component based architecture, but its very low level. Let us go a step further.
Not only complex class hierarchies are a problem, connected package dependencies are too. If you make a game, the game grows over time and your first consideration, how you package functionality is far from practical and mostly changes often. While you deal with different problems, sometimes architecture things seem not that important, what ends in indivisible package dependencies. Starting with the intent of a component based architecture will force you to stick to it.
Not only the game world with entities can be divided into components. The engine itself consists of different parts, which can maybe act independent from others. (AI, Rendering, Collision, Physics, GUI). Maybe not independent, but as a logical unit. In this case you can activate/deactivate your engine subsystems, as you want. This is helpful for debugging.
And not to forget, with component-based design its much easier to make subsystems multi-thread capable.
Next chapter will be about engine subsystems and entity components.