Why don''t you just compile into .lib/.a libraries. These act like a dll, but are compiled within the executable. It allows you to work in the same way as a dll (keeping different pieces of code seperated) but less easier to hack (dll calls could be intercepted, hacked, etc; dlls would make your game easily cheatable/patchable).

"My basic needs in life are food, love and a C++ compiler"
[Project AlterNova] [Novanet]

quote:Original post by Vich
Why don''t you just compile into .lib/.a libraries. These act like a dll, but are compiled within the executable. It allows you to work in the same way as a dll (keeping different pieces of code seperated) but less easier to hack (dll calls could be intercepted, hacked, etc; dlls would make your game easily cheatable/patchable).

Because then he only has to change and redistribute a single DLL as opposed to the whole app.

What I would do is make abstract interfaces (pure virtual classes) for each class I want pluggable. Each DLL would be required to provide a common getInstance() function. Then I would use a config file (lua script, ini file, text file, whatever) to configure which interfaces point to which DLL. When the dlls are loaded, you point the appropriate functions (newRenderer(), for example) to the newInstance funciton of the DLL.

So at the very least you would only need ti call one function from the game to load the DLLs and set up the function pointers, and possible a mechanism for switching out the dlls at runtime. There''s no need to make a DLLManager class, really. The publically available functions could be global (or wrapped in a namespace) and all of the dll handles could be local static variables in that source module.

Of course, you could go further and have all of the pluggable interfaces inherit from a common base class (IPluggable for example), but unless your needs are super generic, that wouldn''t make much sense. For example, you would never load a Scenegraph in place of a Renderer. So it makes much better sense to have all of the newInstance functions return a pointer to the appropriate interface (IRenderer, IScengraph) rather than an IPluggable.

If your game does not require all of the interfaces to be loaded, then the only complexity you have to deal with is deciding which are required, and guarding against trying to get an instance of an interface that has not been loaded. It''s a safe bet that an IRenderer and an IScengraph will be required, but an IAudio might not be. So you might want something like this:

typedef IAudio *(* NEWAUDIO)();static HANDLE s_audioDLL;static NEWAUDIO s_newAudio = NULL;static void loadAudio(const char *name){   s_audioDLL = LoadLibrary(name);   s_newAudio = GetProcAddress(audioDLL, "newInstance");}// global InitPlugIns functionbool initPlugins(){   // parse the config file, ensure required plugins are loaded,   // load optional plugins   ...   char *audioName = ConfigGetValue("IAudio");   loadAudio(audioName);   return true;}// global NewAudio functionIAudio *NewAudio(){   if(NULL != s_newAudio)      return s_newAudio();}

Simple. And again, a more generic, flexible system could be designed - but if you don''t really need a more flexible or generic system then it''s overkill.