The Mud Creator Beta 1 is currently in the planning stages, with a revised user interface planned, an improved in-editor testing setup, a re-write of the way objects will be created and stored and a scripting engine implemented.
Currently the engine supports either hard-coding the objects within the developers game source code, or pre-creating the objects and serializing them out to XML files that the engine can load during runtime and use, similar to how the Tool Kit handles it.
Mud Creator Tool Kit utilized the XML serialization/de-serialization features of the engine, storing all of the games objects as XML files. It worked out very well, but I have since developed a managed scripting engine that supports C# and VB syntax and I’ve decided to implement it into the Mud Creator engine, and I’m considering re-writing the internals of the Tool Kit to support it as well. I’m not sure if this is a good route to go or not, and will need to do some looking into it.
Beta 1 will introduce a scripting engine that will let developers create their game objects via scripts, that the engine will load during runtime. The scripts can be stored server side while the client just receives the text needed to inform them of their current location and surroundings preventing any object modifications. If the project is a single player/local only game, then the scripts can be compiled into a standalone .dll file in order to prevent the end users from having access to developers scripts.
Finally the Tool Kit will be overhauled a little bit as well, working on improving the user interface and adding all of the missing elements. Development on the Tool Kit will resume once the engine has been updated with the changes I have scheduled, and these changes can’t take place until the Managed Scripting engine is updated to support the features I need such as dynamic re-compiling of scripts during an applications lifetime.