Game engine structure question

Whether you're a newbie or an experienced programmer, any questions, help, or just talk of any language will be welcomed here.

Moderator: Coders of Rage

Post Reply
Blackflower-1996
Chaos Rift Newbie
Chaos Rift Newbie
Posts: 6
Joined: Mon May 07, 2012 2:25 pm

Game engine structure question

Post by Blackflower-1996 »

ok so i have a question about game engine development for example i have 2 classes:

Code: Select all

"graphics.h"
class graphics
{
    public:
             graphics();
             ~graphics();
            void DrawImage();
}

"engine.h"
class engine: public graphics; //that inherit from graphics class
{
   public:
            engine();
            ~engine();
}

and the question is, is okay to use the graphics constructor in engine.cpp that includes engine.h that inherit from graphics class instead than in graphics.cpp

Code: Select all

"engine.cpp"

#include "engine.h"

engine::engine(){}
graphics::graphics(){}
and in the graphics.cpp just define what the function draw image is going to do

Code: Select all

"graphics.cpp"

#include "graphics.h"

void graphics::DrawImage()
{
   SDL_BlitSurface(...);
}
so then in the main.cpp whan i call the function DrawImage(); i call it this way

Code: Select all

int main(int argc, char *argv[])
{
    engine engine;
   // son now i call tha function DrawImage() like this
   engine.DrawImage();
  //instead of
   graphics.DrawImage();
is ok to do it that way so every function in my graphics class i call it from my engine class that inherit them???
so if i do the same thing also with a sound class instead off calling each function from its respective class i call them from my engine class that inherit them.
and is there any way to have in the engine class a funtion called for example "StartEngine()" that initialize al the constructors from my other classes like sound, graphics input etc ?? thanx for your time
User avatar
JarrodParkes
ES Beta Backer
ES Beta Backer
Posts: 325
Joined: Thu Feb 25, 2010 2:39 pm
Current Project: Yes, iPhone Application(s)
Favorite Gaming Platforms: N64, PC
Programming Language of Choice: C++
Location: Mountain View, CA
Contact:

Re: Game engine structure question

Post by JarrodParkes »

In this case, I think you would want to steer away from inheritance and use pointers to your respective "sub-engines". You can still have functions defined in engine.cpp that can in turn be wrappers that call sub-engine functionality. That is just one simple approach, but I am willing to say some other people on this forum have delved way deeper into this issue.
User avatar
bbguimaraes
Chaos Rift Junior
Chaos Rift Junior
Posts: 294
Joined: Wed Apr 11, 2012 4:34 pm
Programming Language of Choice: c++
Location: Brazil
Contact:

Re: Game engine structure question

Post by bbguimaraes »

This is an example of inheritance overuse. Inheritance is meant to be used for polymorphism. You could pass the engine a pointer to a graphic class:

Code: Select all

class engine {
    engine(graphic * g) : m_g(g) {}
    graphic * graphic() { return m_g; }
    // ...
};

graphic g(parameter1, paramter2);
engine e(&g);
e.graphic()->DrawImage();
and is there any way to have in the engine class a funtion called for example "StartEngine()" that initialize al the constructors from my other classes like sound, graphics input etc ?? thanx for your time
That is not necessary for the method above (you construct your objects outside of the engine class), but just for completion: the constructors for the base classes (the ones you derive from) are called before the constructor for the class. If you need to pass parameters to it, you do it like this:

Code: Select all

//                   \/ base class constructor
engine::engine() : graphic(parameter1, parameter2) {
    // constructor body
}
And it's not good to define functions of a class in the same file you define those of another. graphic functinos should be in graphic.cpp, not anywhere else (except for graphic.h, in some cases). It doesn't make a difference to the program, but it keeps things organized.
Post Reply