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:
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?
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.