Is this a sensible class hierarchy for a video game?

[hyperfine]

Hi. I'm pretty new to programming, and not entirely sure I'm grasping the concepts of OOP perfectly. Therefore, I'd like to check to make sure that this class hierarchy I've come up with is sensible or not. I'll do my best to explain my reasoning.

class InteractingObject
{
//Object that can interact with other objects, e.g., the Player can open a Door
};
   
   class InactiveObject: public InteractingObject
   {
   //Object that only does something when a special event occurs
   };

      class Door: public InactiveObject
      {
      //Door that will open if a Projectile collides with it
      };

   class ActiveObject: public InteractingObject
   {
   //Object that has a behavior protocol called every time the physics updates
   };

      class Player: public ActiveObject
      {
      //The character class that the player controls
      };

      class Enemy: public ActiveObject
      {
      };

         class BadGuy1: public Enemy
         {
         //Some type of enemy
         };

         class BadGuy2: public Enemy
         {
         //Some other type of enemy
         };

      class Projectile: public ActiveObject
      {
      //A Projectile
      };

         class Rocket: public Projectile
         {
         //A Rocket that some BadGuy can shoot
         };

At first my class hierarchy was more complicated and had a greater number of tiers, but when I got around to making it I realized that some of the distinctions I was making were artificial and that the code doesn't really know the difference.

To have my objects interact with one another I was going to have several global vectors containing the different object types. Objects that deal damage will check for collision with the objects that they can deal damage to. For example, a Player controlled Projectile can deal damage to a Door or any type of BadGuy, so the Projectile will check for collisions with all Door objects, contained in a vector of class Door, and all BadGuy objects, contained in another vector.

Am I headed in the right direction? Any suggestions?

Thanks!

[turtlesavage]

I'm fairly new so don't take my advice too seriously, but based on my limited experience it seems to me you don't quite understand classes.

A class can be thought of like this...

// this class represents the main character
class Hero
{
public:
    Hero();
    ~Hero();

    DrawHero();

private:
    int health;
    int attack;

    SDL_Texture fireArmor;
    SDL_Texture waterArmor;
}

as you can see, the class represents the hero and his qualities. suppose your hero can case a spell. you could make another class for spells. for example...

class Spell
{
public:
    Spell();
    ~Spell();

    int CalculateDamage();

private:
    enum elementType;
    int range;

}

So classes don't really hav a hierarchy in the way I believe you think, until you get into inheritance. Any questions?

[Computergeek01]

_{turtlesavage said:}

Any questions?

I have one, how did you miss all of those semicolons in OP's post? He is already talking about inheritance :p

@ OP: It's impossible to tell without seeing your implementation, you seem to be on the right track. If I had to guess, I'd say that this:

... I realized that some of the distinctions I was making were artificial ...

Will happen two or three more times at least. It's not you personally, it's unavoidable at this level of experience. CRITICAL_NOTE: These re-writes will eventually hit you at the point where you need to completely tare down large parts of your code and re-write them. ALWAYS BACK UP EVERYTHING BEFORE YOU DO THIS! This means you should back it up separately from your regular backup process. It will be tempting not to, you'll think to yourself "Oh this is simple, I can always just rewrite it if I need to". Ignore that thought and copy the set of ~100 KB text files to another directory.

Also ahead of you will be the point where you try to over simplify and you end up with classes with components that don't make any sense together, but their status updates share a similar timing mechanism in your design loop. This should be avoided as well but it's one of those things you have to figure out first hand.

[hyperfine]

Great, thanks for the advice. I'm actually going to do some rewriting right now, so I'll make sure to create a backup.

[Z e r e o]

Like Computergeek01 said from what you have posted you seem to be doing just fine with a typical entity hierarchy design though you are a bit heavy in your branching in my opinion.

Though I do have a suggestion. You might want to try out a component based design for your entities instead. In my honest opinion a component based design for your entities in a game is probably the best route to go.

Yes it may seem more complicated at first if you are not familiar with the style but it will make your code much more manageable and open up some nice possibilities that are hard to do with a traditional hierarchy based design.

For example in an traditional hierarchy design it usually starts out quite neat with functionality seperated neatly in your tree, but as time goes on and more entities are added that need to share functionality you will end up pushing more and more of that functionality up the tree and you will end up with a very top heavy hierarchy and possibly a "god class" at the very top.

Component based entity systems do a great job at avoiding this problem along with other problems. Now if you don't have any idea what a component based system is it would take far too long to explain it here but here is some good articles on the subject.

http://www.gamedev.net/page/resources/_/technical/game-programming/understanding-component-entity-systems-r3013

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://www.gamedev.net/page/resources/_/technical/game-programming/case-study-bomberman-mechanics-in-an-entity-component-system-r3159

There is also good a great chapter on the subject in the game programming book "Game Coding Complete 4th Edition".

Here is also a example of how a component based entity system might be structured that I wrote awhile ago.

https://github.com/bjumbeck/AsteroidsClone/tree/master/Source/ComponentSystem

Enity - The container class that manages all the components of a entity
EntityFactory - A factory class which uses XML documents to create a entity made up of certain components
EntityComponent - The base class all components inherit from.

Anyways I will end this very long suggestion post ;p, in my mind component based systems are far superior to traditional hierarchy systems for game entity systems.

Wish you the best of luck with your game you are working on and if you have any questions about my post or even just game development in general I would be glad to help.

[hyperfine]

Hi Zereo, thanks for taking the time to respond.

though you are a bit heavy in your branching in my opinion.

I agree. Initially I didn't have Enemy, Projectile, or Player subclasses; each type of projectile, enemy, and the player class were directly under ActiveObject. The reason for breaking them up as I did above is that not all the objects interact with one another. For example, a Player controlled Projectile only interacts with two types of objects (for now): Door and any of the different types of Enemy. To check for collisions between a Player controlled Projectile and any of these objects, I put all active Door objects into a vector, and all Enemy objects into another vector (really, pointers to each of those classes). This makes it easy to check for collisions, because I just need to run through the two vectors and see if the Projectile's hit box interacts with any of the objects'. Although, thinking about it now I see a way around this. Maybe I can get rid of the Enemy and Projectile subclasses, since they more or less are the same type of object.


I looked into the entity component design originally, and while the idea of it made sense I had ZERO idea of how I would implement the concept. Maybe I'll take another look at it now that I've become more knowledgeable over the past few months working on this game, and since you highly recommend it.

Thanks again for the reply! I'll let you know if I have any more coding questions.