The game object engine of Teemu

The way game object system is implemented in Teemu is similar to Kaduria where all game objects have a base class and derived classes for main object types (item, creature, door, etc.). The difference is that in Teemu the base class is a type-less class, without information about the game object's type. In Kaduria the base class knows the type of the object.

These two ways to implement the base class are not that different actually. The "pure abstract" version in Teemu is kind of what you should do when creating an abstract base class (aka ABC). When the base class knows the type it's possible to write functions in the base class that work with all object types, without having to write multiple virtual functions.

The current base class in Teemu has only the location of the object and a flag telling is the object destroyed. These two values are indeed abstract to the derived classes and for example the location doesn't need to know anything about the game world in the base class context. In derived classes you need to make decisions where the object can be placed and handle location according to that.

What I haven't explored is the possibility to use intermediate classes between the base and derived classes. These classes could include functions like moving the object and the container ability for an object.

There has been more development done in last two days than in this year combined. Not a joke. I've been checking out the game object system in general and found out the "usual suspects" which are creature and item classes. They always seem to get big and complex. I've also tried to refactor so called data type classes related to game objects and reduce the amount of getters. Each game object class has a static data type class with information about the object's name, frame, color and other functions. The more you can put functionality in those classes the less you need in elsewhere, but the static nature restricts some functions, which is what it's supposed to do. The reason for data type classes is that it's easier to handle static data that way and also it's possible to find out the basic data of the game object without creating an actual game object. This last one can also become a subtle source of bugs, because the type is decoupled from the actual object which can result to mismatch of types. It's possible to avoid that by watching out any external handling of game object data and bringing them back to the object by handling the situation through game object's member function.

The intermediate classes could be a good way to reduce the complexity of the creature and item classes and that's the next thing I'm going to try.