Recently I started working at a game framework. The idea is to create a reusable framework that can be used across multiple platforms and libraries (I.e. Irrlicht, OGRE, SDL). Myself, I already have some experience with game programming (Entwined Worlds). However, all my previous game implementations were based upon the traditional deep hierarchy approach. At first sight this seems like a good idea, but I noticed that this approach always leads to very specialized entities. The true problem with this is that those entities often share various functionalities. And in order to prevent rewriting the same code over and over again, these functionalities are often put in a derived class from the base entity class. And the specialized entities then inherit from that class. The problem should become clear now: for every set of shared functionalities the programmer has to inherit from the base class (or maybe even an derived class). This can result in a gigantic unmaintainable tree of entities. Luckily, there is another approach called Component Oriented Entities.

The idea behind Component Oriented Entities is to make entities data-driven. In order to do this the functionalities are split in various individual components. As a result an entity is in fact nothing more than a collection of components. An added advantage is the ability to describe these components (and thus the entities) in XML or a similar mark-up language.

Yesterday I actually had a discussion with Nick about Component Oriented Entities. Initially he disagreed with me as I had some trouble explaining the “dangers” of the blob anti-pattern (a huge single class with a large amount of complex functionality). Later on, he agreed with me, but he also pointed out some things to keep in mind. One of those things was the implementation. And I really agree with that as these kind of things stand or fall based upon the implementation. Which brings me to my own implementation of Component Oriented Entities. Please note that all of the following code has been placed in the public domain and that I’ll take no responsibility or liability of any kind for any use that you may make of this code.

Read the rest of this entry »