Page 1 of 1

Component Based Design (C++)

Posted: Tue Feb 08, 2011 6:39 pm
by JesseGuarascia
So I've been racking my brain around figuring out a decent way to design a base game engine. The thing has to be able to deal with images, sounds, physics, and map loading/rendering. I'm using SFML, if that interests anyone.

I'm sort of wondering what most people consider a decent way of interfacing different parts of the engine. Say the user of the engine (normally myself, but sometimes a fellow developer) wants to be able to load an image, and use it for a character. What's the best way to do something like this? The way I currently do it for the loading "sf::Image"s, is that I loaded them in the render system, and then an integer index is returned, which is then used to access the image. Using the actual image requires the use of another class, the DrawObj. This is where I kind of think I'm doing it weird. Here's a quick example of how I do it from outside of the engine:

Code: Select all

class TestModule : public Module{
public:
    TestModule (int screenW, int screenH);
    void OnRender();

private:
    DrawObj obj;

};

TestModule::TestModule() : Module (screenW, screenH) {
    // Set the draw objects properties
    obj.SetX(0);
    obj.SetY(0);

    // Load an image, and use it as the image for the DrawObj
    obj.SetImage(Render().LoadImg("image.png"));
}

void TestModule::OnRender(){
    // Display the draw object
    obj.Display();
}

int main(){
    TestModule module (640, 480);

    // Module's run loop
    while (module.isRunning()){
        module.Update();
    }

    return 0;
}
Basically, a module deals with all of the update events that could happen in SFML. A DrawObj is used to display sprites, which use sf::Images. Passing an integer value - the value returned when the Render System loads an image - attaches that image from the Render System to the DrawObj's sprite. I'm just wondering if this would be a good way to do things for the user of the engine. I kind of like it, because it's the way another language, Turing, did things.

I kind of learned about the Component Based Design, but can't decide if this is even remotely correct. I like this way, but I have a pretty good feeling it'd be weird for someone else to use :/

If there's a better way or another design suggestion, that would be appreciated :).

Re: Component Based Design (C++)

Posted: Wed Feb 09, 2011 10:04 am
by BugInTheSYS
Well, I personally do like SDL's approach. It has a base class (SDL_Surface) which holds the image data. Every function that loads an image returns a pointer to the created Surface which can then be used to pass it to functions used for stuff like drawing.
So it's just about the same except for that it uses "real" instances instead of integers (which I think are the index of an array entry?) but it has the feature that you may actually use it in different instances of SDL. But for the use of only one instance, I find your way good.

And let's be honest, who would use two instances of an engine in one program?^^

Re: Component Based Design (C++)

Posted: Wed Feb 09, 2011 12:32 pm
by pubby8
I do not suggest you use public inheritance for this.

Say you have 2 derived modules:
GraphicModule and SoundModule

You will find that graphics will never need to be sounds, and they will always be seperate in code. All the benefits of inheritance are lost - you will never
find yourself converting from sound modules to graphic modules, and it end being clunky and unnecessary.


I do not have knowledge of SFML, but these are some suggestions:
1. use private/protected inheritance and public inheritance to derive from derived classes
or
2. Take advantage of SFML and use templates + enums. I have had great success with this method and openGL, but I do not know if it carries over to SFML.

Re: Component Based Design (C++)

Posted: Wed Feb 09, 2011 6:43 pm
by JesseGuarascia
I actually have a different module for sounds. The SoundSys (Sound System) deals with loading sf::SoundBuffers (the actual sounds). It works just like the Graphics - DrawObj instance, except with SoundSys - SoundObj. MusicObj's are just completely separate. I've actually been using SFML, I believe, to it's full extent. I plan to have an actual usable version of this soon enough. I just want to add maps and other useless junk :P.