However I wanted to use a resource manager and an entity system. I also had questions on how data would get between the logic and other systems. I suppose I could have a game state class.
Currently I am using no inheritance.
Any one have any suggestions or links to good articles on engine structuring.
Thanks.
Game engine classes question
Author
Rather than having long convoluted source files I am trying to organize my engine a little better. This is my first attempt at a from scratch class based engine.
Currently my code looks something like this.
However I wanted to use a resource manager and an entity system. I also had questions on how data would get between the logic and other systems. I suppose I could have a game state class.
Currently I am using no inheritance.
Any one have any suggestions or links to good articles on engine structuring.
Thanks.
However I wanted to use a resource manager and an entity system. I also had questions on how data would get between the logic and other systems. I suppose I could have a game state class.
Currently I am using no inheritance.
Any one have any suggestions or links to good articles on engine structuring.
Thanks.
And WHY aren't you using any inheritance? Seems just dumb to me (not saying I'm a pro, but it does save me a lot of time, in a lot of things). And a Game state class is what I've used for this sort of thing, makes it easy to test for a good deal of things.
Author
I should have said "I'm not using any inheritance yet" meaning none of the classes in the diagram derive from each other at this time. Still trying to figure out the organization.
1. Use inheritence only if needed.
2. Use singletons for Config, Console and other subsystems that don't need to have more than one instance.
3. Usually game logic is on top of the engine (uses an instance of the engine) and not a property of the engine itself.
2. Use singletons for Config, Console and other subsystems that don't need to have more than one instance.
3. Usually game logic is on top of the engine (uses an instance of the engine) and not a property of the engine itself.
Quote:Original post by Dekasa
And WHY aren't you using any inheritance? Seems just dumb to me.
That's a bit harsh isn't it? You're saying it's dumb for him to not use it, but don't explain why he should. As Rimio said, inheritance is just a tool - you don't use a screwdriver to hit nails.
Quote:Original post by Rimio
2. Use singletons for Config, Console and other subsystems that don't need to have more than one instance.
There's been a lot of arguments on here about singletons.
If something doesn't need more than one instance, but no harm will come from having more than one, then don't use a singleton. Only use singletons when there is a requirement that limits you to only allowing one instance.
An idea for your entities: make some interfaces for things that entities can do (such as be drawn), and then make a base entity class that implements these interfaces along with any functionality that would be common to all entities (such as position/rotation perhaps)...
Then your renderer class can have a list of pointers to "Renderables" and your logic class can have a list of pointers to "Updateables" etc...
This also lets you render things that arent entities, because your renderer just deals with any class that implements the Renderable interface.
class Renderable{ virtual void Render( const Renderer* )=0;}class Updateable{ virtual void Update( float time )=0;}class Entity : public virtual Renderable, public virtual Updatable{...}class MyEntity : public Entity{...private: Texture myTexture; Polygons myPolies;}It would be a good idea to use some kind of smart pointer for these entities though (because the renderer, logic and manager classes will likely all have their own pointers to shared objects.
I think a good question related to this topic is how do you establish the lines of communication from game object to engine parts. For example, a game object (or entity, actor, etc...) needs some particular resource, say a texture. How should the object say "Hey! I need a pointer to GoblinTexture" ?
Do you pass it a reference to the particular resource manager in its constructor? Do you give it a central point of access to the subsystems somehow? This is something I have struggled with. I can break down and do it the "easy" way, but I am always trying to find a "better" way to establish this communication.
Do you pass it a reference to the particular resource manager in its constructor? Do you give it a central point of access to the subsystems somehow? This is something I have struggled with. I can break down and do it the "easy" way, but I am always trying to find a "better" way to establish this communication.
class Entity{public: void setTexture (Texture * tex); void setModel (Model * mdl); /* alternatively */ void init (Texture * t, Model * m); private: Texture * m_Tex; Model * m_Model; }You should also think about using materials and such, and having textures assigned to them.
Then have Models that have the material assigned. Then all you need is setModel (modelManager->getModel ("animals.monkey")); or whatever.
ModelManager::createModel (Mesh * mesh, Material * mat);
Just some ideas.
If you are going to be making a reasonably decent game, you will need to use inheritance. If you don't, you will be programming the same lines of code over and over for very similar tasks.
The structure you propose looks good. What you will also need is a structure for lights (point, spot, directional inherit theses :) and also for objects in your game. ie Base object -> player, enemy, vehical etc. Lots to inherit here.
When designing the physics, your structure will play a big role.
The structure you propose looks good. What you will also need is a structure for lights (point, spot, directional inherit theses :) and also for objects in your game. ie Base object -> player, enemy, vehical etc. Lots to inherit here.
When designing the physics, your structure will play a big role.
Quote:
If you are going to be making a reasonably decent game, you will need to use inheritance. If you don't, you will be programming the same lines of code over and over for very similar tasks.
Inheritance is not the only way of solving the code-reuse problem, and it is certainly possible to make excellent games without using inheritance. You should not use it just because you think you have, you should only use it when it makes sense.
In the initial class diagram posted by the OP, there is nothing there that really needs to involve an inheritance hierarchy at all.
Do not go overboard with inheritance either. It's a fine line I say. Our engine/game actually uses very little of it. Just where needed. Hodgman has a pretty good use of inheritance in his code example of an entity.
Also like thre3dee said, don't think of textures, think of materials. Materials are made up of texture(s).
Personal note, drop the CGame thing. We now have intellisense, it will tell you it's a class ;-)
Honestly, write a game, not an engine. You'll get something completed (engines are boring, boring, boring) and learn more about how to build an engine when its actually time.
Also like thre3dee said, don't think of textures, think of materials. Materials are made up of texture(s).
Personal note, drop the CGame thing. We now have intellisense, it will tell you it's a class ;-)
Honestly, write a game, not an engine. You'll get something completed (engines are boring, boring, boring) and learn more about how to build an engine when its actually time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
