Jump to content
  • Advertisement
Sign in to follow this  
aqez

Classes..

This topic is 3182 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

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)
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)
So here's my question, and another while I'm sitting here thinking. I need the console to be accessible by all other classes inherited by System. So.. the way I was taught would be to instantiate Console first, and pass it by reference to the constructors for all other classes. So I just want some feedback on that, and if anyone has any better ideas about it. Also the other question is about the SceneManager, I've had decent experience with d3d9 and 10, and I'm usually caught at 10 when it comes to loading meshes and managing shaders. So my question is should I have the Renderer class(which will have the device pointer, input layouts, etc in it) inherit the SceneManager( which will likely house mesh loading, light management, etc ), or should it be the other way around? This is my first real attempt at an engine, and I've yet to use any scene management. I do realize this is the wrong forum for the second question, but hey, I'm already here. Anyway, if you guys could point me in the direction of some good scene management reading material, it'd be appreciated. Thanks! edit: Didn't realize spacing wasn't saved in non code sections.. also added a little bit more information.

Share this post


Link to post
Share on other sites
Advertisement
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.
class SceneManager
{
SceneManager( Console&, Renderer& );
private:
Console& m_Console;
Renderer& m_Renderer;
};

Share this post


Link to post
Share on other sites
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.

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.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!