• Advertisement
Sign in to follow this  

Game Design Question

This topic is 4716 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Here is a question... should I design my game so that everything inherits from a base class? Example:
CEntity
  + CGraphic
  + CSprite
    + CShip
  + CEntityManager?
    + CSpriteManager
    + CGraphicManager
  + CController
And so on... and if I do so, won't that let me pass anything as type CEntity ( which seems good to me... )? Are there any downsides to this, recommendations, or anything?

Share this post


Link to post
Share on other sites
Advertisement
but then wouldnt you need to cast back again, when you want to use it?

Share this post


Link to post
Share on other sites
hmmm i guess you're right.

Any other thoughts on the format? Is it typical? I see the UT scripting uses the same sort of hierarchy...

Share this post


Link to post
Share on other sites
Currently im using a hierarchy tree similar to yours, but to avoid casting everything to the inherited class, i use controllers to some key types.

Example, i have a Camera class that inherits from Entity, but also a CameraController that group all the cameras-related work so i benefit from the base class algoritm but using strongly-typed objects.

The only drawback i can see is wrong class design. If you make some mistake, you have to traverse the entire class hierarchy fixing it. But i think the flexibility pays off.

One question, why CEntityManager should inherit from CEntity? It IS an Entity or its job is just MANAGE Entities? The same applies to CController.

Share this post


Link to post
Share on other sites
Q: whats the purpose is in having camera and sprites inherit from the same base?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Q: whats the purpose is in having camera and sprites inherit from the same base?


Yep, making the Player and a Monster (for example) inherit from a same class is ok, but there's no point in making too diferent things inherit from a single class...

Share this post


Link to post
Share on other sites
Yes, good point Kaze. IMHO you would only want to have such relationship between those classess if you would like to keep them on the same list (ie. std::vector<CEntity*>) so that you could further call virtual functions ie. to render them, update. Will you ever want to Render your CController on screen? :-)

Hmmmm, as for Update - ok, you could want to do that, but then you would end with other problem - how to create base interface for all of them, so that you won't need to cast too much? and - how to avoid bloating of CEntity?

Personally, I'm keeping managers absolutely separated from the rest of stuff... in fact, I've moved them to general engine, which I could (theoreticaly) use later in any game I like :-) Thing which makes it possible, is that I don't make too strict assumptions and try to write everything to be as flexible as possible.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kaze
Q: whats the purpose is in having camera and sprites inherit from the same base?


A sprite is updated each frame. So is the camera. This is their relationship. And thus this is why they should inherit from the same class. With polymorphism, and a good class design, the game could store cameras and sprites in the same list, going through and updating them all, regardless of their actual type. This makes maintenance very easy and quick, and adding new entities is a breeze.

Share this post


Link to post
Share on other sites
I wouldn't use a full top down class hierarchy for that purpose. If you start adding more and more stuff to the base class, then it becomes cluttered and pointless. It can also mean that every objects will have extra data attached to it that won't be necessarly used. Like extra empty virtual functions that serve no purpose for that entity. It's just weighting the code.

The basic CEntity should be kept simple, and you have to think carefully of what you need as a base entity class. What's the most basic entity for a game object? What would be the smallest atom of information shared by all entities?

Rather, I'd think of composition instead. If you need serialisation (saving / loading / networking / streaming data) for your entities, attach a serialising object to the base entity instead of making extra methods. Idem for smart pointers and things alike. Like tools objects that manage the object in your editor.

Getting a class hierarchy right is well tricky. By manager, I guess you mean resource managers. They can be of great help to handle all the dirty work for you. Have a look at the enginuity design, it's quite interesting.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement