Clarifications & Concepts

I wanted to take a few minutes to clarify a couple things.
First, the Mud Designer is a complete IDE for developing Mud games. It's currently composed of several editors, such as the Room Designer and Project Manager. A new edition to the Mud Designer is a tool called the Visual Designer. This is a test editor, that will replace all of the currently existing editors if it goes right. What's different about it? It contains editors for every object, with a single designer. Instead of launching the Room Designer, and the Zone Explorer, you will have a single designer. The Visual Designer will replace every editor with a single editor that manages everything.

Now, I remember saying I didn't like this approach originally, as it creates a mess with the code. It's an even bigger mess when you start generating objects and building the editor dynamically during runtime. So why am I still pursuing this as a viable option for the Mud Designer? I've figured out a way to keep everything dynamic, and keep the code easy to maintain.

With that being said, what are some of the pros and cons between the current setup, and the future Visual Designer? Let's take a look at them individually.

The current setup is pretty static. Each editor was originally planed to be independent of each other, but that ended up not being the case as keeping things simple, required cross-editor interaction. Not a bad thing though, and the code to add it was small and easy to implement. The editors have a generic look, and if a new object is created within the engine, I will have to go build a new editor for it. That's not a big deal either, but I will have to go to every editor that will need interaction and add the support. Again, this is not to big of a deal, however what if 3rd party members want to add onto an existing editor? They will be required to modify the source. What if they want to create new assembly project and build custom objects that inherit from the standard engine classes in order to make managing Mud Designer updates easier. None of their code is overwrote. This isn't possible with the current setup and I don't think it ever will be due to how it was designed.

Enter the Visual Designer. This designer loads the engine and builds a list of all game objects. Those objects are displayed in a toolbox that users can have access too. The engine will have the plugin support implemented, allowing for developers to create their own libraries containing their own objects and having it loaded into the engine. The designer will then place all engine and plugin objects into the toolbox without any extra code needed for the 3rd party addons. This also removes the need for me to keep going back to the editors and adding the new objects to the editors manually. The Visual Designer handles it for me. If I create a new class called NPC, the designer adds it to itself automatically. I don't have to touch it.

How will I design the editors for each object? I've Created a base control called VisualContainer, and given the BaseObject class that as a Property called Control. Developers can build their own user control that inherits from VisualContainer, and the editor will automatically place the control in the designer. Developers can have access to the control by accessing the property
"Room.Control.Title = My Control"
This let's me focus on building editor controls for each object in a modular fashion, and the designer generates all of it's content during runtime.

It's a concept still being worked on, and mostly works, I just need to work out a few of the kinks before deciding this is acceptable, and removing the current set of editors from the solution.

- Posted from my iPhone