Game Objects

I just read something in AI Game Programming Wisdom 3 which sounded sooo familiar to me. Sergio Garces of Pyro Studios writes about game architecture regarding the game objects,

“… we often see examples of inheritance abuse, making the fundamental mistake of confusing behaviour (what objects do) with identity (what objects are)”

This is exactly one of the many mistakes I did in DVW, where the inheritance hierarchy is like Entity<-Unit<-Vehicle<-Constructor<-KPBConstructor or Entity<-Unit<-Building<-UnitFactory<-BunkerBarracks. It works, but this really is not the way I would do again.

Next time, I would use a part-based approach like sheijk|6S is doing in Velox3D, i.e. the game designer (not necessarily the programmer!) creates units out of several abilities, just like plugging and playing: plug in a motor, and the entity could move; plug in a weapon, and the entity could attack or fight back; plug in a brain (i.e. some AI) and it knows how to use its parts.


But we’re making good progress anyway.

Next Article

Coming and going

  1. The second approach seems to be interesting, but I cannot imaginge how to build a system that is that extensible and flexible, so you can just choose between arbitrary behaviours and mix them into one object.
    If you bring Velox3D to the Dusmania, I’d like to see the system and how it works (if you’re agreeing with that).