Game Entities Inheritance Hierarchy Suggestion

[MasterGod]

O.k I want to create the following classes that will describe a game entity.
What do you think of that inheritance hierarchy?

[Halifax]

Hmm, well that diagram is definitely a little simplistic. As my first suggestion, I would say you should rename 'character' to 'actor'.

Second off, a building should not only be static. And also depending on your definition of mountable, a building can be "mountable". Also 'movable' implies 'flyable' so I would just implement a 'moveable' class in which constraints could be set to make the entity 'flyable'/'drivable' etc.

Those are just my suggestions/ideas.

[FuzzYspo0N]

i say its too complex. unless u are making a huge multiple title project, why abstract so much?

i REALLY dont wanna go into this debate here, but if i were gonna follow the horribly complex methods, agree with halifax.

[Saturn]

To little info to give specific advice, so it has to be more general. I tend to agree with FuzzYspo0N in that it is probably unnecessarily complex.

But if you want specific help, you need to tell us what actual game entities there are in your game, what kind of game it is and what interaction there is between the game entities among each other.

You have a single multiple inheritance here for vehicle. I'd try to eliminate it, not worth the bother, if it is only applicable for a single instance.

The question is, what the functional difference between these classes? What specifically do you need to distinct movable and item for, for instance?
What is a movable anyway? It seems to me that you try to press everything into a class hierarchy, that can be more generally solved with composition.

[MasterGod]

Hmm, well that diagram is definitely a little simplistic. As my first suggestion, I would say you should rename 'character' to 'actor'.
Second off, a building should not only be static. And also depending on your definition of mountable, a building can be "mountable". Also 'movable' implies 'flyable' so I would just implement a 'moveable' class in which constraints could be set to make the entity 'flyable'/'drivable' etc.

Those are just my suggestions/ideas.

Agreed.

And about the complexity, I think it's not that complex and I'll need that freedom to define stuff.
"huge multiple title project" - Not that big but check my site (sig) to see how big it is.


O.k, I've made some changes. Now what do you think?

[MasterGod]

To little info to give specific advice, so it has to be more general. I tend to agree with FuzzYspo0N in that it is probably unnecessarily complex.

But if you want specific help, you need to tell us what actual game entities there are in your game, what kind of game it is and what interaction there is between the game entities among each other.

You have a single multiple inheritance here for vehicle. I'd try to eliminate it, not worth the bother, if it is only applicable for a single instance.

The question is, what the functional difference between these classes? What specifically do you need to distinct movable and item for, for instance?
What is a movable anyway? It seems to me that you try to press everything into a class hierarchy, that can be more generally solved with composition.

It seems you've posted that while I was writing my post or something so my response to that is that its not a game but a game engine hence needs to be as generally/generically as it can.

"that can be more generally solved with composition." - what do you mean?

Now the "big" question of why that complex? Well, to give me the freedom to define how most objects will behave and ease the work of the user (of my engine) so if for example he want to make a vehicle, He just inherit vehicle and his additions will make it different from any other vehicle.
I'm basically trying to do two things:
1 - Add any custom info to the objects without manipulate the ISceneNode class.
2 - Having a parent for most (if not all) game objects lets me later on add a behavior like physics to everything.

But again, if you have any improvement suggestion or any other good/bad suggestion I'd like to hear it as soon as possible

[MasterGod]

My friend suggested this. What do you think?

[Halifax]

Yeah, I have to agree with Fuzzy and Saturn. It is a little complicated, unless you are expecting to extract this into something like the Unreal Engine 3 where everything is edited visually, and it is easier for the programmer of the tools to write it this way.

Although for any run of the mill programmer who just wants to use the engine, it is too complicated. I believe you should only implement an entity, as Irrlicht implements scene nodes, then just build your entities on top of that and make them available to the user.

[MasterGod]

I believe you should only implement an entity, as Irrlicht implements scene nodes, then just build your entities on top of that and make them available to the user.

Are you talking about the way the scene graph works or just about having a simple One class to describe an entity? (and that's for you and JP: , )

[Halifax]

Haha. And no, I'm sorry, I didn't mean to imply implementing a scene graph to go along with that. I actually meant the latter, in which in is just one class that is used to describe an entity. It should provide modifiers along with it, like moutable/movable/etc. instead of abstracting those classes on top of it.

[MasterGod]

It should provide modifiers along with it, like moutable/movable/etc.

Maybe it's because I just woke up but sorry, I still don't get you.

[MasterGod]

Nevertheless, my best advice to new programmers are to keep it simple. It looks like I need to start listen to it myself

I think I'll go with just one carefully designed game entity class and maybe make a little decoration system using the Decorator pattern.

[Halifax]

Okay my basic meaning is this:

Code: Select all

IGameEntity
IGameEntityModifier

Basically you create an IGameEntity, and then add modifiers to it as you please. I don't know how to explain it any better, as I don't know the low-level needs of your program. So yes, it is just best that you pick your own.

[Trefall]

I'd go with the decorator pattern, where the entity class is simply a container of components with an uid attached. If you add an event system on top of that to handle communication, it should be able to handle whatever your entities will require.