Game Entities

I need a little help in the design aspect of my current game project.

Here are my thoughts:

My current project is a 2D RTS game. I started it roughly 3 years ago, and by the end of about 6 months of work I had a fairly good project coming along. After 6 months, however, I left to go on a church mission to Italy (as many of you already know). So I got back 10 months ago, and I looked at my code, and although it was well documented (because I document my code well), the code itself still wasn't too pretty. I wanted to re-do a lot of it. I was hindered in my progress because I had a lot of school work to get done, but now that it is summer time I have found a lot of time to work on it, so I have been getting a lot of work done on it, which I am excited about. It is coming along pretty well.

I am trying to approach the "entity" hierarchy as best as I can here. So, first things first, I was kind of wanting some examples on how you guys have structured your entities in your own projects.

One thing, however: I am trying to keep the "game" section of the project and the "engine" section of the project strictly separated.

Here is what I got so far:

Attachment 7335

I have my base Entity class which is the parent of all entities in the project. This will be on the engine side of things, for sure. It has two children: Animate and Inanimate entities. I figure that these classes will be on the engine side of the things as well.

I thought about making two other subclasses of the base Entity class: visible and invisible. In the end I decided that if I wanted to make an entity invisible I could simply use a boolean flag inside that specific entity. What do you guys think?

Off of the inanimate entity branch we have resource and structure. I figured that for any game project I will be making in the near future, it's a pretty good chance that any resources and structures in the game will be inanimate for the time being, although I know that in today's games these could easily be animated objects.

When it comes to resources and structures, I was thinking that I could keep those specific classes on the engine side of things. Their children, however, would be the actual resources and structures in the game. Therefore, "Barracks" would be a child class of "Structure". Structure would be a class in the engine, but Barracks would be a class in the game code...since it is more game specific. What do you guys think about that?

The toughest part of the entity tree is the animated branch. There are a few ways I have thought about approaching this branch of the tree.

The first way is to create an "Animal" child class, and a "Unit" child class. A Unit would be any player-controllable unit. They would both be on the engine side of things, and then their children would be on the game side of things.

Another thought process has led to the fact that in many games animals can become player-controllable, and therefore there is no need for an Animal subclass, but they could all be considered units.

I could also structure it something like this: Animate could have the following subclasses:

Land Unit, Air Unit, Water Unit, Animal.

This could break things down a bit more, but once again there could be units that fall into more than one category. In that case I guess I could use multiple inheritance. But also if I declared Land, Air, and Water units...that seems to be more game specific than a piece of the engine...leading me to almost believe that maybe every child of the "Animate" class should just be part of the game code and not the engine code???

So anyways...those are my jumbled thoughts. I'd like to hear how you guys have structured your own entity hierarchies in your game projects, so I can get a better feel for how I can do my own. What's your thoughts?

[edit]

Ah! I forgot! I have to fit some type of projectile class in there as well! I figure projectiles would fall under the Animate section of things because they will be animated and moving from one place to another.

[/edit]

Does an animal have anything that a regular Land unit doesn't? perhaps you could have a Unit class and have the different types of Units inherit from it. "Animal" seems game specific.

So how about this....2 classes may derive from the "Animate" class: Unit and Projectile. Do you think that covers all bases? Then all units, be they animals, humans, or other, derive from unit.

By the way, has anyone here ever heard of, or considered, the "component" based game-object design, in comparison to the "inheritance" based game-object design?

I had never heard of the component-based design until yesterday, when I was reading some articles that I found off of gamedev. Most games in the past, that I know about at least, have used the inheritance-based design, but this component-based design that the author discusses is pretty intriguing.

Read up on it:

Game Object Structure: Inheritance vs. Aggregation

I think any complete game design will make good use of both inheritance and aggregation.

As an example of combining inheritance and aggregation, in my engine each game object runs out of a single non-subclassed object class that defines convenient functionality (variable management, message pub/sub, serialization, scripting interface). Each of these objects then contains a list of aspects. Aspects are similar to an object subclass: they define init, update, destroy, onMessageReceived etc functions. Every time one of these events happens to the object, it runs through the aspects and calls the appropriate functions.

With this system I get two results. First, I have an inheritance tree for the aspects that allows me to do things like inherit models from scenenode. It also allows me to attach several different pieces of relevent c code to an object, like for a camera I attach the camera aspect, a physical aspect, and a control aspect. Or for a unit in game I attach a model aspect and a control aspect.

So I have been putting some thought into this aggregate design we are talking about...and an idea came to my mind.

This might seem crazy, but the whole "component-based" design actually seems very similar to a context-free grammar! So I thought to myself, I could try designing a very simple "grammar" in a sense, even though it's not actually a grammar. It can be used for the aggregate design. So here is what I got:

Quote:

---

Entity tree in CFG form
---------------------------

Entity -> <Component List>

ComponentList -> <Component> <ComponentList> | NULL

Component -> <Intelligence> | <Combat Ability> | <Building Ability> | <Travel Ability> | <Unit Creation Ability> | <Technology Upgrade Ability>

---

It is not complete yet, but tell me what you think. What other abilities/components/aspects might it be useful for an entity to have?

It looks like an entity can only be abilities, what about modelling the actual units themselves? They need physical characteristics like position and size, as well as housekeeping stuff like model and texture.

Variables holding the position of the entity would exist in the base entity class.

I failed to mention my thoughts about the graphics side of things in my last post. Once again, I am not really expecting to use any 3d models or anything. All the graphics are pretty much homemade 2d graphics.

I have them separated into 2 classes: sprites and animations. A sprite, according to my engine at least (although this is not true generally) is basically a simple image that I have stored in memory. An animation is an image that can be divided into many different frames.

I had 2 approaches in mind, using the method that I described in my last post with components. I could still branch off of the base entity class, and have 2 subclasses: Animate and Inanimate. Animate entities would hold an object of type Animation to describe the graphical representation of that entity. Inanimate entities would hold an object of type Sprite to describe the graphical representation of that entity. Then, each entity could add its proper components.

The other approach I had in mind was to consider all entities "Animate", and therefore I could have an Animation object declared in the base entity class. Therefore, if an entity wanted to be represented graphically, it would have to go through the Animation class.

So anyways, position would be stored in the base entity class. Size would in many cases, or at least in most cases that I can think of, really be a member of the Animation or Sprite classes, which would store the size of the image, or graphical representation of that entity.

I just read your link on the "aggregate" method. That appears to describe the system I've used before and am in the process of working out the bugs in a very new generation of. I've encountered all the limitations mentioned in that same article with a system too heavily laiden with inheritance.

A class hierarchy involving multiple inheritance may seem dynamic in terms of code alone, but i believe you will eventually find it cumbersome and limiting.

Theres possibly no need for a separate class of entity for Animate/Inanimate. Depending on the needs of your actual application. My engine has only a single Entity class (though it contains pure-virtual functions and must be inherited by the custom Entity defined by the Application using the Engine) which then contains (among other things) a pointer to its "Visual" member. In my case its a pointer to several possible classes, all derived from a base Visual. This allows any entity to of any type to be represented graphically in any way; In your case, that would be Sprite/Animation. Since this is transparent to the calling function, it reduces code overhead in your actual game segments.

Works for me anyways. :)