Engine
System
Console(dev console, right now just writing to a log file)
Settings(for accessing and changing settings)
Support(bad naming, but houses math and windows generic functions)
Renderer(obvious)
SceneManager(obvious again)
Classes..
Author
Alrighty, I have a simple problem with most likely a simple solution that I might even already know, I'm just wondering if there's a better way to go about it. So I'm working on the basic structure of a game engine, and here's how it goes:
(indentation implies inheritance)
Inheritance means "A is a B", which means anywhere you could use a 'B', an 'A' will do just as well.
E.g. an apple is a fruit, and a banana is a fruit.
Anywhere you need a piece of fruit (e.g. MakeFruitSalad), you could pass in either a banana or an apple, as they are both fruit.
With your hierarchy, I don't see any such relationship. Would it ever be ok for something to ask for a "system", and be passed either a console or a scene manager? They seem unrelated to me.
As for instantiating the "shared" class (i.e. console), and then passing references to that instance to the constructors of other objects -- yep, that's a great way to go about sharing a class like that.
An alternative to this way of doing things would be to use "Singletons"/global-variables, but they make for less reusable code in the long-run IMO (and are a dirty word around here) ;)
I would best describe the relationship between scene-manager/renderer as "has a" (composition), not "is a" (inheritance) -- just like the console.
The scene manager handles all your meshes/lights/etc, and then makes use of a separate renderer object to actually draw these things.
The scene manager could be made to be unaware of whether you're using DX9/10/OpenGL/etc... Only the Renderer object interfaces with the graphics API, the Scene manager just organises your scene data for you.
E.g. an apple is a fruit, and a banana is a fruit.
Anywhere you need a piece of fruit (e.g. MakeFruitSalad), you could pass in either a banana or an apple, as they are both fruit.
With your hierarchy, I don't see any such relationship. Would it ever be ok for something to ask for a "system", and be passed either a console or a scene manager? They seem unrelated to me.
As for instantiating the "shared" class (i.e. console), and then passing references to that instance to the constructors of other objects -- yep, that's a great way to go about sharing a class like that.
An alternative to this way of doing things would be to use "Singletons"/global-variables, but they make for less reusable code in the long-run IMO (and are a dirty word around here) ;)
I would best describe the relationship between scene-manager/renderer as "has a" (composition), not "is a" (inheritance) -- just like the console.
The scene manager handles all your meshes/lights/etc, and then makes use of a separate renderer object to actually draw these things.
The scene manager could be made to be unaware of whether you're using DX9/10/OpenGL/etc... Only the Renderer object interfaces with the graphics API, the Scene manager just organises your scene data for you.
class SceneManager{ SceneManager( Console&, Renderer& );private: Console& m_Console; Renderer& m_Renderer;};
Author
Yeah, that's what I meant, I don't know why I said inheritance. They are member variables, not inherited classes. Thanks for the reply.
None at all, I had described it wrong, sorry for the confusion.
Quote:Original post by Telastyn
What shared behavior do all of those pieces gain from engine and/or system?
None at all, I had described it wrong, sorry for the confusion.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
