Choosing between static libs and dynamic libs/plugins?

Question

I have been throwing stuff together in a small test game over the past 6 months or so, and right now everything is in the one project. I would like to learn more about creating an "engine" for reusability and I am trying to figure out the best way to do this.

Static Libs are obviously a tiny bit faster, as they are compiled in rather than loaded at runtime, but that really does not matter to me. The advantages of DLLs over static libs seems rather large. So im wondering what the best approach/most used approach is for a "game engine".

I am using Ogre3D (rendering engine) which supports dll plugins that it loads and what not, but I would like to write my dlls where I could basically use them anywhere. So would my best bet be to write individual DLLs for each portion of my sample engine, such as sound.dll, gui.dll, etc? Or would I be better served by creating one large dll, deemed engine.dll or something? I am assuming the best approach would be to write something like...engine.dll for the general structure, then compose it of other dlls such as sound/gui/input/etc.

Would it be silly of me to write my dlls independently of Ogre's Plugin system? My Sound relies on the FMOD library, my GUI relies on the CEGUI library, and so on. I mainly just want to create my engine to a point where it is easily usable with the functions I need from the individual librarys.

Answer 1

If you are creating DLLs for re-usability it makes sense to split it up into self contained units of functions. Thus, if you have a general sound library that, for example, plays wav files, that could be separated out as sound.dll if you think lots of other programs might make use of that particular library. Likewise for anything you think would be re-usable elsewhere.

However, if it is mostly the case that the only people using your sound routines are those who will also load the rest of your game engine (or most of it) dll, I see little point in having so many separate libraries. I can see the sense in having engine.dll so that many games can be created from a single engine but not from splitting up the rest unnecessarily.