Component-based systems (part 1)

As I previously described, the use of complex and big inheritances does not work for me, I need the system to be easy to change and not resistant to it, and that is what happens when you have everything tightly coupled (that is exactly what occurs with unmanageable class hierarchies). Extend classes when there is a good reason for it and to be honest, I believe in most scenarios functionality can be added through composition or aggregation.

The approach that I will try to apply in the game we are building is based on components, creating reusable modules that can be changed on the fly altering behavior of specific objects. Not to mention that each node in an external file could be mapped directly to a component, creating the best possible solution for games, a completely data-driven application.

Basically, the idea is to have a GameObject that acts like an empty shell and is only a collection of GameComponents. These components could be anything from rendering, controllers, pyshics, state machines... what the object needs to work.

I remember a great document I read some time ago from the GDC Canada that explained this in a very descriptive and accurate way. It also says that it is not easy to see the benefits right from the start.

At the end I think it is worth it and I will try to demonstrate that is the case.

- MR