Component-based entities

(Sam, you were right - the blog is a good guilt-causing mechanism. I've not done any coding since before pyweek!)

At the moment I'm reading up on component-based entity systems. It seems like a much more flexible approach than the one we took initially. When you want to add some functionality it goes in as a standalone component, rather than being wedged into a possibly inappropriate place in the class hierarchy.

• This is a good post from a dude that worked on the Tony Hawks games discussing his experience refactoring their whole engine to use component-based entities. Pretty light on code though :(
  

• This other article discusses Dungeon Siege's system. They seem to have a mad hybrid going on. They have components, but they also have 'template' game objects which are like common archetypes. The components themselves seem to have some hierarchy going on: "The Attack component handles loading and launching ammo for projectile weapons. Requires the Common component. ".
  

• This one has some actual code but it's pretty bare-bones. It does match the way I'm thinking about it though, which is that an Entity is nothing but a collection of Components.

• Yet another one goes a slightly different route again. He's broken down all game objects into five classes - Entity, Space, Form, State and Action. Form is the visual representation and also holds State. Entities hold Actions (insantiated by game events). Space is stuff like view/world frustum, used for optimisation.
  Our components in this system become subclasses of Action and State. An Action operates on specific kinds of State objects (e.g. ItemPickup action interacts with Inventory state object). Here's an example from the article:
  
  • "Let’s say the car is a fast car and we want to make it go even faster. However, what we do not want to do is make the car faster. If we were to make the car faster, we could only affect the behavior of that car. Instead, we make the "fast" faster, and therefore ANY game token car that can go "fast" can be affected if we so choose. Much more importantly, not only could any token representing a car be affected, also, ANY game token with a "fast" behavior could potentially be modified regardless of what it is meant to represent."

I'm going to have a go at implementing the last one, starting with something pretty simple so we can get back to having monsters and bullets collide as quickly as possible. As always, let's hear your thoughts :)