Hieroglyph 3 :: The PluginsAfter a couple of hours of work, I have a basic framework for the next iteration of my engine put together. The basic idea is to have a core library with individual components loaded at runtime - essentially making my game engine a big fat plugin system. I am not an expert at making plugin systems, and there is likely better ways to implement the system but I am happy with the general idea so far.

The Interfaces
I have used a common IEngineComponent interface which is defined in the Core library. This interface provides methods for a plugin interface type, which can be a renderer, audio system, physics system, or whatever else. Currently all of the types are enumerated in the IEngineComponent interface, which can be added to as needed. There are also methods for getting a description of the plugin as well as a name for use in the plugin loading process. These methods are pure virtual to ensure that the subclasses provide an implementation.

The Implementations
The individual types of components each have an abstract base class that inherits from IEngineComponent. Then, each implementation of an IEngineComponent subclass resides in a separate dll project. The first one that I implemented was an IAudioComponent (residing in the core library), which was actually named DirectSoundComponent (residing in its own project). It is actually just a dummy implementation that can't actually play any sounds, but it did fill in the identifying information from the abstract base class.

The Plugins
For each of the plugin engine components, the dll implements and exports only two functions: CreateComponentInstance and DeleteComponentInstance. They return or take a pointer to IEngineComponent respectively. The delete function is to overcome the memory management issues of using dlls to create objects.

The Clients
Now at run time, the application loops through the files in its 'Bin' directory and tries to load any dlls present. The loading process is wrapped into a small class to handle the LoadLibrary and other functions involved in using a dll. Once the plugins are loaded, an instance of the component is created and queried to see if it is what the application wants. It chooses the best of the bunch and goes on it's happy way [grin].

This let's pretty much any type of application have access to the engine components. From the example above, loading and playing sounds will be accessible to whatever application needs it - but it doesn't have to link to all the other engine components if it doesn't need them. I have a few ideas for using this architecture to add in some non-traditional library components as well, such as a serial communication library for interacting with external hardware. We'll see where it takes me, but I like how it looks from here on out.