As I was working on adding scripting support to the Room Designer last night I began messing with loading content on the fly, and found that it was really simple. I liked how easily .NET has made loading .dll files into memory. I could do it with the Scripting Engine but it's not designed to load several assemblies into memory for plugin support. It's designed to hold a single script assembly. I fleshed it out and got a nice plugin feature implemented. It currently only works with the Room Designer, but that's just due to me testing it. Once I get it fleshed out all the way I will move it into the engine so that all editors can access the plugins if needed without re-writing the code for each editor.
I want to wait on moving the code into the engine until I figure out how I want plugins to be implemented. There are several ways I can do it, and I want to make sure the best way is selected. In the future it would be nice to build plugin support into the editors themselves so users can write editor plugins, extending the designers. It would be nice for users to create custom classes that add new functionality to the engine, then add that functionality into the editor with a custom plugin. Or perhaps build it all as a single item. A custom class and custom editor or extended editor, that the engine will jus load and use. The engine will load the class, the editor will load the custom editor plugin. All contained within the same plugin library.
Just some thoughts I'm floating around. Plugin support won't get any serious attention till later. As I'm wanting to focus on completing a few designers first, to get the editors useable and release a Preview release on codeplex.
- Posted from my iPhone