So I'm currently working as part of a team that is building a game engine and I have been considering our current code structure. As a team we decided it would be a good idea to create a plugin architecture that allows additional functionality to be added by other users should they so desire. Here's the my opinion our current design is very limiting and may result in messy code.

e.g. There is a graphics manager class that works like a facade, i.e. you could do

graphicsManager.CreateCharacter("texture.gif", "model.3ds", "BadassMonster");

and this would call appropriate functions from a texture manager, model manager etc.
The problem is that (in this example) the texture manager and model manager are implemented as plugins so that different implementations can be used and even changed at runtime e.g. use XNA functionality, DirectX or OpenGL.
In theory this sounds great but currently the only way to call functions is through the graphics manager and thus, the plugins are restricted in what they can actually implement because the graphics manager has to know what function to call.
One solution would be to bypass the graphics manager and utilise a plugin directly. To me this seems like the whole point in the game engine is being defeated. Calling lots of functions from lots of different plugins would mean that the user is basically having to manage everything themselves anyway....

Does anyone have any ideas on a solution to this problem?

Thanks in advance!

The issue has now been resolved :)

Basically, the code has been restructured to include an event framework. An object fires an event which is caught by an event handler. The event handler then calls an abstract function for which the concrete implementation is determined by the plugin that is currently loaded. This means that, in most cases, functions don't even need to be called directly, thus resulting in much looser coupling.