Game Design Question

but then wouldnt you need to cast back again, when you want to use it?

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

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.

Q: whats the purpose is in having camera and sprites inherit from the same base?

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) 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.

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.

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.