Sign in to follow this  

Unity Merits of a plug-in system.

This topic is 4225 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

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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
alternatively, you may want to consider using a scripting system instead of (or additional to) a plugin system.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

This topic is 4225 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this