Jump to content
  • Advertisement
Sign in to follow this  
GenuineXP

Managing Plugins, Libraries, and Dependencies

This topic is 3658 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm reevaluating the plugin system I'm currently using for several reasons, including it's lack of robustness (we're talking C++ here, so plugins are not trivial!). With some online help, I've worked towards a more stable framework, but I'm not sure how to manage plugins. To sidestep this dilemma entirely, I originally decided that my engine would load a sort of super plugin called a module. A module would implement a large set of well-defined behavior. Only one module is ever loaded at a time. With this approach, an entire myriad of issues were left behind. Now that I'm reconsidering my previous design, these issues have raised their ugly heads, especially since I'd like to make things even more modular. My question is, how are plugins typically managed to prevent collisions or absence of features? The plugin system is part of an engine, so some plugins may implement an imaging library, others drawing operations, and still others input, for example. If this is the case, what happens when an SDL based input plugin is used? How do I ensure that all other plugins are SDL based (or compatible), such as an OpenGL/SDL based graphics plugin? Even if I can pull this off, which plugin then becomes responsible for shutting down these APIs (i.e., which plugin calls SDL_Quit)? I know there must be some plugin based engines out there. How do they handle this? Really, it's a question of managing the underlying APIs and any compatibility/interoperability requirements they have. I thought some sort of dependency system could be built, where plugins specify the plugins they rely on and thusly act as a set/subset. For example, an imaging plugin could be implemented using DevIL or GIL. So long as the interface allows exports/importing image data, that shouldn't interfere with operations by libraries like SDL or DirectX. So, this plugin would have no (or few) dependencies. However, a graphics plugin may have numerous dependencies. (Unfortunately, I could see this leading to counterintuitive dependencies as well, such as a graphics plugin that depends on otherwise unrelated plugins like input/audio/events simply because it requires SDL-friendly plugins to function). It just doesn't make sense to load an OpenGL/SDL graphics plugin, followed by a DirectX based font rendering plugin! :-) Any thoughts? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
I am doing a plugin system for an app (not a game - caveat emptor) and this summarises my present approach. my main problems come from c++ and the lack of first class reflection and static initialisation issues, though ive found some good c++ support for configuration in some xml/xpath/xquery libraries. sorry that its probably
a bit general and i probably have a more relaxed need toward being able to do my own components rather than having to adapt existing libraries (such as game engines).

1) distill the elements that can be modelled purely reactively - eg a collision detector only needs to hook or listen to a main message bus that will receive a subsytem's broadcast of an entities on_move event - it
does not need to know the concrete interface of any other objects or plugins. alternatively another example might be a logger can be modelled so that it only has a dependency on a main message bus/pump where it can catch anything from all other subsystems. this is the loosest coupling possible and should make this type of plugin implementation simple and very loosely decoupled.

2) where the plugin must interact with another known plugin for state querying or to assert some action on it, then there is no avoiding an interface or at least some form of interface discovery mechanism. perhaps a strategy type implementation works here. an example would be that a renderer must query the window state to see if its minimised or maximised before it can decide whether it has to draw. (maybe this is a bad expample - because this could also be modelled reactively and therefore avoid any dependency - by designing the window object so it just broadcasts its max/min state change event to a singletonish message pump where it is caught by the renderer)

3) for config use an xml file. on app start the loader should consult a static xml file to see which objects and which types should be instantiated (subsystems, factories, even lower level objects) - plugins are then dlls or so's. the xml could also be used to configure object sources and sinks (ie object.inbox connected to main message bus in pure actor model or else monster.factory.log_event delegate is bound to the logger substem receive method if using fatter interfaces. I believe this is how spring web framework manages to loosely connect the hetrogenous components (such as webserver, db, logger, business logic) in a plugin type arrangement - an approach i suspect might have general application to game architecture.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!