Question

I’m building a game engine, and I’m trying to reorganize a few things; namely the EngineManager which manages the main components of the engine (audio, video, keyboard/mouse IO, etc.).

The main implementation idea for this clean up, if you will, is to use the EngineManager as a client which will send data via event-handling (in SDL) to these various components, which will in turn send messages back. To avoid insanity, I have the following implementation:

Config

    class Config
    {
    public:

        Config( const EngineManager* engine, const Controls* controls );

        ~Config( void );

        //More functions

    private:

        Controls** mControls;

        EngineManager** mEngine;

        //More functions/class members

    };

    Config::Config( const EngineManager* engine, const Controls* controls )
        : mControls( controls ),
          mEngine( engine ),
          mIsInitialized( false )
    {
    }

    Config::~Config( void )
    {
        delete mControls;
        delete mEngine;
    }

EngineManager

class EngineManager
{

public:

    EngineManager( void );

    ~EngineManager( void );

    //More functions/class members

private:

    Controls* mControls;

    Config* mConfig;

   //More functions/class members

};

EngineManager::EngineManager( void )
    : mControls( new Controls( this ) ),
      mConfig( new Config( this, mControls ) ),
      mEvent( new SDL_Event )
{
    Init();
}

EngineManager::~EngineManager( void )
{
    delete mEvent;
    delete mConfig;
    delete mControls;
    delete mScreen;
}

I’d post controls, but it basically does the same thing as the config class – though without a reference to config.

Still, something tells me that a good implementation MAY be a function pointer of some sort…

Any ideas?

Answer 1

The biggest design issue here is mutual dependency. If you use client/server, the client should depend on the servers and not the other way around.

If clients need to know about updates in servers, you should use the observer pattern.
If a reply on a message is needed and you don’t want to use a synchronized message (sender waits until receiver has processed message), then you should pass a callback with your message and here is where the functor comes in as the functor can contain a sort of reference to your client, so the functor can send a message back.
If there are a limited amount of clients which don’t change often, you can pass them to the server, but then you should use a callback interface implemented by your client.