Objects, Entities and other things

Well... I now spent almost two days on researching which way I possibly could use to a) make most (all) of my game objects entirely data driven and b) keep it in a simple way to use.

Let's develop the two points:

When I say "Entirely data-driven", I'm not just talking about having some key values defined within a human-readable file format. I'm more into: how to handle data and object configuration. This includes the way specific tasks are handled.

Example: You have to implement 2 different things in your game: a tree and an enemy. While the tree can more or less be interpreted as being a static object, the enemy definitely is not. The enemy move, has to search for you, attacks you, etc.

Both have some information such as graphical representation, sound information, etc. In most cases, one would implement two different classes to handle those two types of game objects: a static game object and an entity game object. Each of those two game objects would have distinct functions and distinct variables. You would implement those functions and variables specifically for each class.

My target was/is to be able to define from within a human-readable text file the composition of the different game objects. After some skipping through the books on my shelves I stumbled upon two interesting articles: "Component Based Object Management" by Bjarne Rene (Game Programming Gems 5) and "Flexible Object-Composition Architecture" by Sergio Garces (AI Game Programming Wisdom 3).

Both articles take almost the same approach: Instead of implementing the different capabilities of the game objects directly into some kind of specialized class, they use the component based approach. In this approach, the different capabilities are components which can be added to a game object dynamically. The health of an entity is one of those components (interestingly both articles just pick up this example, too :) ).

Rene introduces a (IMO) rather complicated way to handle and maintain the components. Via additional interfaces between the component interface and the final implementation of the component, the access to different parts of the component itself are "hidden". IE. the interface for the health component only has one function called "GetHealth()". There's nothing else. This implies that the interface itself keeps things easy.

Now, the component interface introduces another idea: messaging. If one wants to alter the content of the health component (IE. increase/decrease the health), one must inject a message into the component. The idea is tempting: Define a new message and only the component which is really interesting by the message, will receive and handle it. Unfortunately, this means, that you have to create, update and maintain an ever growing list of messages.

Garces on the other side (in addition to the component based idea) uses the idea of archetypes. I would call this "Templates", but whatever :) Basically, you can define a template for a game object containing some component templates. Only if a game entity of a specific template type is needed, the template is "transformed" into a real entity. I like this idea because it let's you define and maintain a rather small list of templates to which any entity which is placed in the world might reference to for creation. Garces uses the fact, that this approach easily enables the developer to "overload" any component. IE. you can use three times the same template for IE. an archer and specify for one of those three archers that his firing rate is twice as high as the normal one.

What I like in the Sergio Garces' approach is the way he handles the interaction between the components. Instead of having a messaging system to alter data within the components, he implicitly states that some components "know" how to handle other ones. IE. a component of a weapon knows about the health component implementation and thus directly can use the functions of that health component. This makes the usage of the component approach slightly easier.

Now, for my implementation I was shuffling around a bit the two approaches. Remember: I like easy to use interfaces. I finally came up with a system that is template based as Sergio Garces introduced it. I also used the Rene's idea of components (I consider Rene as the originator since the GPG5 first ed. has been printed in 2004 while AI GPW3 has been printed in 2006). Specific templates know about other specific templates but still can handle the lack of those (means, they're doing nothing or reporting/logging an error). Templates hold basic information thus pure data in text form and can transform them into "real" instances once it's needed. This kept the templates themselves quite slim (and stupid) while still holding all data they should hold.

The component system as I currently have it in mind is able to define everything from simple properties such as health, xp points distribution, gfx information, sound information etc. But also is able to define components which can hold AI information (my game ai is based upon my SCXML implementation).

What's also interesting is the fact that you easily can hold 2 sets of data: one for the game client and one for the game server. In most cases the game server doesn't need to know about the gfx or sound stuff, so you simple "export" your data from whichever DB you have without exporting the data the server doesn't need.

Well... I'll talk more deeply about my implementation (with some examples) another time.

Have fun,
Stefan