File Type Backend, Project Site & Updates

I’ve had a busy night tonight working on the Mud Designer, and I’m not quiet sure where to start. I think I’ll start with the projects new site over at CodePlex. It’s been setup and is running pretty nice. I got the home page configured, setup the Discussions and Documentation tabs and finally created a 'Help Wanted’ ad, which it must be a new feature to CodePlex as I don’t remember it having that back when I was working on the Mud Creator. I requested help with the Networking side of the designer along with assistance in writing the documentation for the project. I also noted under the Documentation the requirements needed for downloading the source and compiling it.

Next up is the File Type Backend, which is a pretty clever idea that I ran across while browsing the web tonight. The engine contains an XmlSerialization class that saved and loaded all of the designers files to XML. Nice right? What happens though, if I wanted to offer SQL support? How about adding support for a scripting language? Saving and Loading of the files will need to be changed, and it will need to be changed across every editor within the designer. That would be a pretty big pain to mess with, and as I’ve mentioned several times already, I’m wanting to keep the code for the designer and its editors simple and clean. So how do I fix this situation? I created a backend class called FileSystem. The editors now call Save and Load from the FileSystem class at which point the FileSystem checks to see what File Type the project is using, XML, SQL ect., and calls the class necessary for saving it in that file type. For now I only have support for XML serialization, but if I offer SQL the editors wont know any different. They’ll continue to call FileSystem.Save() and the FileSystem class will handle switching between XmlSerialization.Save and SQLData.Save. One location to make the adjustments and that' saves a lot of headache.

I’ve done a lot of work to the Project Manager and the MUD Engine and it’s starting to make some headway. One of the most notable changes would be the finishing of the Project Manager and changing the Zone class to inherit from Realm and Rooms to now inherit from Zones. This allows me to create default properties such as Name and Description within the Realm class, and all Zones and Rooms will have the same property. No re-duplicate coding required.

What’s next, I guess I can begin working on the currency editor, and better refining how the engine will handle the currency.

del.icio.us Tags: Mud Designer,Codeplex,C#

Realm & Zone thoughts

Realms won't be to hard to program really as they're just acting as a container for Zones. A way of breaking up Zones into groups and make it easier to find a Zone when your project contains thousands of them. Realms will have a few Properties but not many, I think they'll only need a Name & Description Property, along with a List to hold a collection of Zones.

Zones won't really be much more difficult than the Realms, they will need to hold a large number of Rooms, and have some default settings that can be used on all rooms when first created. Things such as Always Dark, Always Light, Cycle Day/Night, Default Smell/See/Hear/Feel descriptions, a SafetyZone option that can ensure the player is never attacked by monsters and a collection of NPCs and Monsters that can roam the Zone.

I'm still debating on the NPC collection, I'm wondering if that should be something setup within the NPC editor instead of assign the NPC to the Zone, this way one NPC isn't placed in multiple Zones by mistake. Monsters is acceptable because users can fight the same monster across multiple Zones, but typically you won't see the same NPC in multiple Zones. While assigning an NPC to a Zone during NPC creation prevents duplicate placement within the world, it will require the engine to scan every NPC in the game during startup to place the NPC as needed. It would be faster to just load the NPC list from the Zone, and load only the NPCs needed. Leaving it to the developers responsibility to ensure duplicate NPCs aren't placed in their world, so in the end i'll probably end up having the Zone editor add NPCs to the environment.
Now that Im thinking about it, there could be thousands of NPCs in a game, I'll need to work on either a search feature or a grouping feature to reduce the amount of time spent searching through NPCs

-- Posted from my iPhone

Setting changes doesn't need code!

This was something I failed to mention in my previous blog, and that is the nice fact that PropertyGrids allow the editors to change properties and not need any code to do it. When I was using text boxes in the I i initial source code upload I had to write code to handle the text being changed and update the classes property. Using a PropertyGrid removed the need to write code updating class properties. It's handled by the Grid for me. This means a simpler approach and less code. Easier to maintain.


-- Posted from my iPhone

Thoughts on Scripts & design conepts

I've been putting a lot of thought into the idea of using my Managed Scripting engine with the Mud Designer. It would be a nice feature to have so MUD developers can extend on the engine, but I'm starting to not see the point in it. It's open source. Developers have unrestricted access to the toolkit source and so thus don't really need a scripting engine.
Another reason i think I will avoid it is due to the added level of complexity with coding the designer. The whole point of the re-write is to build the designer and the engine using clean simple code that can be easily read and modified when needed. Generating code during runtime within the editors for script engine compiling would create a mess internally.

I'm quiet pleased with the progress I made last night. The Project Manager started out with one design and ended the night with a different approach. The initial decision was to use text boxes for all of the project settings, but I was worried that would clutter the UI up and make it harder to add additional features in the future without re-organizing the UI to fit new things in. I decided instead to use a PropertyGrid control, which allows me to freely add or remove project setting options from within the Project Information class and not have to touch the UI to add the new feature. This was a feature used heavily in the Mud Creator, however I'm trying to avoid having the editors rely only on PropertyGrids. This time around the Grids will be used to help keep things clean, but will not be the only method used to create game content. Using it as an aid for various options rather than relying on it for everything is nice, as now I can build editors to generate game content in an easier manor than propertygrids allowed.
I'm going to spend this afternoon doing some thinking on how I want the Realms, Zones and Rooms to be designed internally and how they will interact with eachother so I can better plan my UI designs when I'm ready.


-- Posted from my iPhone

A night of coding

Spent a good chunk of tonight working on the re-design of the Mud Creator, and decided I am going to re-name the toolkit while I’m at it. It’s now called the Mud Designer, and I have created the Editor HUB and began work on the Project Manager. The Project Manager saves the project settings when the editor is closed, and loads them when the app is launched.

All of the apps are being wrote to be independent of each other, with a lot of care being taken with the HUB so that it is not a required component to run the other editors. Each editor can be launched on its own without any adverse effects on the project, since they are all kept separate from each other.

This time around I am focusing on reducing the amount of code needed to run the editors. Searching for ways to re-use code, so I can prevent a lot of re-work. The Mud Creator was riddled with duplicate code all over the place and it was clear that the project was a mess when I opened the designer and began scanning over 3,000 lines of code. I’m hoping with splitting the project up into multiple independent editors like I am, the source files will remain fairly small and light which will make it easier to maintain and update.

I also managed to get the project uploaded to a new CodePlex site tonight. It can be viewed HERE.

The source code for the project has been uploaded to the Codeplex SVN and since I uploaded it tonight I’ve commited 2 additional versions of it with modifications and bug fixes. I’m hoping to spend this weekend fleshing out the project manager and get the currency editor up and running, then it’s off to next week and the development of the Realm Builder, Zone Editor and Room Designer, all of which will take a few weeks to complete and will require some thought on how I want to build the UI for these apps.

del.icio.us Tags: Mud Creator,Mud,Mud Designer,C#,Codeplex

The MUD Tool Kit HOME app

The MUD Creator tool kit is going to feature a HOME application that can be launched. It will allow users to create a list of tasks that they need to complete with their MUDs and provide them with a proper workflow for how to build their MUDs. I will list all of the editors in the order that I feel would work best for creating your game, starting out at editor #1 and ending at edtor #14 and having the game ready to go.
The HOME won't offer any project specific options that can be edited, and won't tie into any of the tool kits tools so developers won't worry about an update to an editor breaking the HOME or a custom Room editor being used and breaking the work flow.
The task list will let developers create a list of tasks such as "Force the Elven Paladins to only start out in the Bekang Realm". It can serve as notes and reminders for the developer to make adjustments and changes. A possible log system might be put in place as well to monitor changes made to game objects and make note of the changes, developers can then scan the log and pull out what Ganges it would like to include in his/her release notes when they release a new version of their MUD.



-- Posted from my iPhone

Mud Creator Re-design. Revisited.

I have had several problems with getting the Mud Creator to commit to CodePlex's SVN over the last two weeks. It keeps erroring out and giving me a headache. It had been working fine for the last year or so, something happened that screwed up my repository and now I can't get it fixed. With that being said, it looks like a good time to sit back and re-look at how I want to design the engines tool kit. The re-design was already underway when this error occured, but I hadent really put much thought into it. I was flying blind. Today however, I took the time to sit down and right up how I felt the tool kit should be laid out.
I'm going to design the tool kit split into seperate programs. One program for designing rooms, another for creating skills ect.
I'll develop an application that will act as a HUB, displaying all of the editors that can be launched. I've jus spent about 30 minutes on the editor list and in what order they'll be laid out and came up with a decent list I think
1: Project Manager
2: Currency Editor
3: Race Builder
4: Class Editor
5: Realm Editor
6: Zone Builder
7: Room Designer
8: Equipment Builder
9: Item Designer
10: Skil Designer
11: Book Editor
12: NPC Manager
13: Quest Builder
14: Monster Creator

That's my basic list of editors for the moment, with the names and order of work-flow still pending. Most of the editors are self explaining as to what they're for, but I thought I'd clarify what the Zone and Realm editors will do.
A Realm can hold an unlimited number of Zones. Zones can hold an unlimited number of Rooms. Since rooms are what players traverse, you can think of them as a physical room. A zone could be a single house, a city street, an entire city/kingdom, a complete forest or what ever you want. A zone is how you will setup borders for the player. The player can easily find out what Zone they are in, and these can be used to inform the player as they move from city to city or something along those lines.
A Realm can be used how ever developers would like to use them, but the original intent was that they would act as a country or continent that contained several kingdoms/cities (Zones) that the player explored. This way a Race can be tied to starting out in a specific Realm, and each class for that race can have a seperate starting zone for the realm their race is tied to. Traveling outside of the realm into another realm can be done if the MUD developers allow it.
I'm planning on giving a brief overview of each editor over the next couple of weeks as I begin fleshing out the new design.

-- Posted from my iPhone