Jump to content
  • Advertisement
Sign in to follow this  

Structure of classes in good Game Engine?

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

Hello everyone :)

Well I'm making a game with a friend, and we're having small problem with organizing our classes.
What we're doing is having main engine class, which creates all classes we use in it, then we pass the
classes into constructor that we want to use.. eg:
[source lang="cpp"]gameWorld = new ChunkManager(LogSys, gfxSystem);
gameCamera = new Camera(ScreenWidth, ScreenHeight, 0.0f, 0.0f, 0.0f, SDL_Key, events,joystick1, LogSys);
Time = new GlobalTime(LogSys);
Menu = new SDL_Menu(this,gameCamera,events,Time,LogSys);[/source]
The thing is, we pretty much pass in LogSys class to EVERYTHING!
Is there any easier way to distribute it to pretty much everything?
I was thinking of inheriting it to everything, but i heard inheritance is bad in some cases to game engines..?


Well thanks for help in advance, cant wait to see the answers! :)

Share this post


Link to post
Share on other sites
Advertisement
Inheritance is not bad. It can be bad if you do it wrong or too much. Inheritance is very good when you want substitutable behavior. Take a look at the C++ Faq on inheritance:

http://www.parashift.com/c++-faq-lite/proper-inheritance.html

On your LogSys case, I would go for a global as MajorTom suggested. Take a look at your sentence "[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]Is there any easier way to distribute it to pretty much everything?"

well, globals are for eveything everywhere.[/background]

[/font]

Share this post


Link to post
Share on other sites
Debug utilities (ie logging) is one of the very few things which I consider suitable for global access (ie global variable, global function, singleton, ..). If you have other stuff you need everywhere, that might indicate a code design/architecture problem.

Share this post


Link to post
Share on other sites
Personally I wouldn't bother with either.

There are already a bajillion existing logger systems out there, most are far more comprehensive than an individual would ever use. The better systems integrate with your debugger, allow multiple simultaneous output methods including logging across networks, provide graphical visualizations when comparing bulk logs, and do much more than simply output individual text blobs.

Why re-invent the wheel?

Share this post


Link to post
Share on other sites

Keep in mind that your logging system probably doesn't need to be a class at all. Consider using a simple free function instead, possibly in a namespace.


This.

If you still decide it needs to be a class, ask yourself: does it need to be instantiated? What benefit do I get for having two or more instances of logger class? If there's none, then you don't need a class.

Share this post


Link to post
Share on other sites
You can do something like this


class Log {
public:
static Log* Get() {
if( !m_pInstance )
m_pInstance = this;
return m_pInstance;
}
protected:
Log* m_pInstance;
};

Then use the log like this within your classes
Log* pLog = Log::Get();
pLog->Write( "Me and the Cap't make it happen!" );

Share this post


Link to post
Share on other sites

You can do something like this


class Log {
public:
static Log* Get() {
if( !m_pInstance )
m_pInstance = this;
return m_pInstance;
}
protected:
Log* m_pInstance;
};

Then use the log like this within your classes
Log* pLog = Log::Get();
pLog->Write( "Me and the Cap't make it happen!" );




This is the "singleton pattern" or as I like to refer to it "the greatest sin perpetuated by programmers with good intentions."

The singleton thing has been debated to death, so if you're interested, I invite you to go search around for any of the dozens of threads on the subject. For now, though, I will leave it at this: please, don't use that code. Ever.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!