Would a plugin framework ever be implemented?

17 replies [Last post]
Posts: 164
CP: 0

I would love to see MEF or something similar. (extensibility framework, kind of like plugins)

I remember OGRE was a plugin based framework. (it was a graphics engine though...) That way when people ask for game-specific functionality, people could make plugins that integrate easily into NetGore. I'm not really sure on how this would be done, but I thought it would be nice.

Posts: 1647
CP: 26119

Probably not, no. How it is now is likely how it will stay, unless someone else does it. Doing stuff like extensive plugins or scripting is a ton of work on my part, but doesn't offer much of anything new since everything is already available since its open source.

Using the NetGore.Features projects already accomplishes this well enough.

Posts: 531
CP: 967

Yeh, it's probably not worth the effort because of the the Features projects. Plus Reflection is slow and it would have been easier if Netgore had been designed from the beginning with extensibility as one of its features. At the moment i'd say it kinda is already pluginable Tongue in terms of adding features in the features projects.. Its just not quite a plugin becasue you still have to do some extra work to your game. however eventually i guess we'll try and abstract the Core engine from the demogame so you should rarely need to edit the core netgore assemblies.

There are 10 types of people in this world - Those who understand Binary and those who don't.

Posts: 1647
CP: 26119

I guess you "could" do a plugin system with the scripting, since you're basically just injecting the code that way. But then you lose the convenience of all the compile-time checking. To me, that'd never be worth it since its not like C# is slow at compiling.

Posts: 531
CP: 967

I was thinking about this today, because it would be interesting if it was that easy to create new features. Spodi are you familiar with AppDomains in the .NET library? (http://msdn.microsoft.com/en-us/library/system.appdomain.aspx)

Only problem is you can only get data from other AppDomains in the same process by using a MarshalByRefObject. But this means that a third-party assembly could be loaded in a thread safe manner (as it would be in a separate AppDomain) and therefore not compromise the code security of the default AppDomain. The third-party assembly could then communicate using the MarshalByrefObject and act as a direct plugin to the NetGore engine.

It might not be possible as i've only been thinking about it at work but not put anything into practice. I might do some experiments and test the speed and whether it's as easy as it sounds Tongue. I'll post some results here. Wink

There are 10 types of people in this world - Those who understand Binary and those who don't.

Posts: 1647
CP: 26119

Like I mentioned, the scripting system would already work, and I am pretty sure it would accomplish mostly the same as you are mentioning. That way, you could theoretically have NetGore just as it is now, but for those who prefer to, load the NetGore.Features stuff as a separate DLL (or even just the code) at runtime and it is injected into their assembly.

But again, basically all you are doing is complicating the build process and removing a lot of your compile-time checking. If this was a closed-source engine, or built from the start for plug-ins, then sure, it'd be worth it. But its open source and I just didn't have the time or care to make adding stuff so modular.

Posts: 164
CP: 0

Spodi wrote:
Like I mentioned, the scripting system would already work, and I am pretty sure it would accomplish mostly the same as you are mentioning. That way, you could theoretically have NetGore just as it is now, but for those who prefer to, load the NetGore.Features stuff as a separate DLL (or even just the code) at runtime and it is injected into their assembly.

But again, basically all you are doing is complicating the build process and removing a lot of your compile-time checking. If this was a closed-source engine, or built from the start for plug-ins, then sure, it'd be worth it. But its open source and I just didn't have the time or care to make adding stuff so modular.

Um... Yeah, I agree. The features assembly works quite well.

Posts: 143
CP: 0

I was under the impression the Netgore.Features section was where I stuck things that you may call a plugin.

I get what your saying. You want so others can develop a feature and put for download and then others can easily load it into there game and have it work.

I wouldn't mind if Netgore.Features became some sort of psuedo-plugin system where you could drop someones feature code in and add an include line somewhere in the main netgore and have it work. If that is not how it already works...

But really we shouldn't bother ourselfs with .dll and other things. Netgore was never intended to be a "super easy no programming needed" engine anyways like playerworlds or whatever.

While having an engine be that easy to use does bring more people... I think it brings the wrong type of people (like me 7 years ago in junior high. HALP ME PLX PLAYERWRLDS CODE ME A GAME 4 FREE NAW)

Posts: 164
CP: 0

I like plug in (modular) programming. I wasn't asking because I have no programming experience... Simple curiosity is all.

Posts: 1647
CP: 26119

A better 3rd party plugin system was one of those things I would have liked, but just seemed to be too much work for something that wouldn't really result in much. If we had a ton of plug-ins being developed, then maybe. Though I personally like just using the code directly since then you get all the benefits of compile-time checking and intellisense. And I am definitely not against adding other people's stuff to NetGore.Features (I actually really hope others do write stuff for it) as long as it is of good quality.

Maybe, just maybe, I'll write a program that can "manage" the stuff in NetGore.Features by letting you add/remove the code by ticking a single box, display the description, able to perform remote updates, etc. But that'd require that others are writing a lot of code so it could be utilized.

Posts: 143
CP: 0

Once I get past the prototyping stage and into actual development you may see a bunch of features from my team. We are just never sure when to stop messing around with netgore and actually start using it. Well I mean months ago it was changing way too fast.

Also have no idea how to compare my changes in an old version to the current svn and port my work over. So im literally copy and pasting a ton of stuff every time I update to the latest svn (yes im a noob)

Posts: 11
CP: 0

In that aspect, I agree that the code does change drastically when used. The projects may become whole other sources where the code a team may be running will be completely different from the orginal, thus making it hard to port work over. However, I believe if the .Features project is used well and designed in a modular way it would work the same, if not better than a plugin system. (I have not yet checked out the internals of the Features project)

Posts: 1003
CP: 7799

Instead of copying over your stuff to the svn, do it the other way around like we do with SVO. It's a lot easier Wink

Posts: 143
CP: 0

What do you mean because I don't use svn at all. I mean I get how to edit the base netgore and commit to the netgore svn. For myself I had my own svn but it got too messed up and now I don't even keep backups (yes thats terrible)

Posts: 1003
CP: 7799

We have our own "SVO SVN", and we copy over the useful stuff from the Netgore SVN to ours.

Posts: 143
CP: 0

Gotta say that sounds really complicated. Guess i'll have to add SVN to one of the many topics I need to read up on.

Posts: 164
CP: 0

Helix wrote:
In that aspect, I agree that the code does change drastically when used. The projects may become whole other sources where the code a team may be running will be completely different from the orginal, thus making it hard to port work over. However, I believe if the .Features project is used well and designed in a modular way it would work the same, if not better than a plugin system. (I have not yet checked out the internals of the Features project)

That's more of what I meant. I don't want some plugin manager or some BS like that. It's just another place for stuff to go wrong. I don't even remember starting this topic. >.>

Posts: 143
CP: 0

Omnio wrote:
I don't even remember starting this topic. >.>
I want some of what your smoking dude...