Merits of a plug-in system.
In the course of writing my C#/MDX rendering engine I was curious and made the actual renderer a plug-in. I honestly have no desire to write an OpenGL renderer, and frankly cross platform stuff isn't high my list, so please don't present that as a reason. And really, my 'engine' is crappy , so I don't expect a community to pop up around it and thus I don't expect anyone to write plug-ins for it. Now that the 'disclaimer' is out of the way...[disturbed]
So now because of all this I have this neat-o plug-in system to load assemblies dynamically. So are there any merits of using a plug-in system over just assigning the reference at design time*? I'm just wondering if I should bother with creating more plug-in DLLs or should I just keep things like the renderer tied to the library?
*Keep in mind that this is a .NET project so it's not the same as a static library vs. a dynamic library issue.
Quote:Original post by owl
Not having to re-link the library to the executable is something I find pretty useful.
What he said. And you can always re-use the rendering plugin for future games that use that plugin architecture.
Quote:And really, my 'engine' is crappy , so I don't expect a community to pop up around it and thus I don't expect anyone to write plug-ins for it.
Mm. Well, you've already expended the energy on writing the architecture (when presumably you could be working on a game using someone else's engine) and so you might as well use it. Please try to fight off the tool-lust in the future -- I've just barely pulled myself free of it. [grin]
alternatively, you may want to consider using a scripting system instead of (or additional to) a plugin system.
Quote:Original post by Anonymous Poster
alternatively, you may want to consider using a scripting system instead of (or additional to) a plugin system.
x2
I'm quite fond of a plugin architecture under .Net. The main advantage is that it makes the product extensible, either by you or your enormous support community (!), and all that needs to be distributed is the new plugin.
Plugin architectures are awesome, as long as they are applied to the right problem.
Software Engineering wise, if you do not need it, and do not forsee a need for it, then do NOT do it.
You are overengineering a solution that has no reason to be overengineered.
If you do not expect to write another renderer for your system, then you are probably get your abstractions wrong, which will work nicely with the renderer you are implementing but might not work so nice with another renderer.
Note that implementing a plug-in system is a good learning experience, so there is some educational value on doing it, but if your engine is probably never going to have another renderer then the value in that sense is very limited.
If you architect your renderer well (encapsulated, well defined data and code dependencies), then moving in the future to a plug-in architecture (when the real need arises) should not be very challenging
Software Engineering wise, if you do not need it, and do not forsee a need for it, then do NOT do it.
You are overengineering a solution that has no reason to be overengineered.
If you do not expect to write another renderer for your system, then you are probably get your abstractions wrong, which will work nicely with the renderer you are implementing but might not work so nice with another renderer.
Note that implementing a plug-in system is a good learning experience, so there is some educational value on doing it, but if your engine is probably never going to have another renderer then the value in that sense is very limited.
If you architect your renderer well (encapsulated, well defined data and code dependencies), then moving in the future to a plug-in architecture (when the real need arises) should not be very challenging
I'm sure it is both very useful to learn how to do this, and that it would be very satisfying to have a plugin system working.
So it probably depends if you're doing it for productivity, or for interest.
So it probably depends if you're doing it for productivity, or for interest.
Plug-in systems are very useful for lots of reasons. One of which is the file format problem. With hundreds of different file formats out there, it would be nearly impossible, let alone impractical in include every single one of them in your project.
So, say for images, all you want from an image is, 99% of the time, the raw image data, RGBA or whatever. What you could do is write an Image Loading/Saving API and have all image formats loaded/saved via plugins. This way, if you ever need a new image format in your game/engine or if you ever design your own image format for whatever reason, you can simply write a plugin for your engine and hey-presto, your engine/game can use that new image format with no recompiling or anything of the like easily.
I have done this. It works really well. Also, if you can get the API just right, you can do this for mesh formats, audio formats etc...
So, say for images, all you want from an image is, 99% of the time, the raw image data, RGBA or whatever. What you could do is write an Image Loading/Saving API and have all image formats loaded/saved via plugins. This way, if you ever need a new image format in your game/engine or if you ever design your own image format for whatever reason, you can simply write a plugin for your engine and hey-presto, your engine/game can use that new image format with no recompiling or anything of the like easily.
I have done this. It works really well. Also, if you can get the API just right, you can do this for mesh formats, audio formats etc...
I wrote an article on my site not too long ago going over the implementation of a plugin system in .NET that would load plugins from external DLL files. If you do plan to implement plugins into your application, you might take a look at it. Plugin Interfaces in .NET .
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
