I hit the need for a game object system when I wanted to have enemies that you can shoot. The physics system could do a ray cast, but the result of that needs to be linked somehow to the game logic. I decided to do this by storing a handle on the physics object. Given a generic handle, I could pass it a message telling it that the object was damaged.

This is the Actor Model of programming, originally designed for concurrency, but I’m using it just because it decouples objects much more than standard OO. There’s no need to expose an interface because any message can be sent to any object. If the object that gets shot is not damageable, it doesn’t have to process the message.

It’s useful to put the actors together from components:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Using this system, actors can even be composed at runtime.

There are some downsides. It’s more work to declare a message than a function. There’s some overhead, too. And the code isn’t as strongly checked at compile time, which could lead to more bugs. I think overall it’s a win, though, given that the alternative was nightmare inheritance hierarchies and virtual functions everywhere.

 

 

Advertisements