Changing Blogging accounts

I’ve used Blogspot for the last year or so and I have recently decided to move over to Wordpress. There are several advantages to moving to Wordpress for me, one of them being having a better blog editor on my iPhone so that I can blog from my phone while I’m on the go. I’m wanting to start blogging on topics other than the Mud Designer, things such as mobile technologies, gaming news and various other tech information.

The new blog can be found HERE, I encourage those of you who subscribe to this blog to change your RSS Link to that of my new one as this one will no longer be posted to.

One GUI to rule them all…

It was just under a week ago that I discovered how to attach a custom control to a Class Property and allow the control to be shown when using the PropertyGrid via UITypeEditors.

It’s been quiet a week for the Mud Designer. I created a test editor so that I could mess around with using the UITypeEditor, and I found that it was actually really easy to implement. The more I worked on the test editor, the more I liked it. The current layout of the editor I have never really liked. It was really easy to maintain due to the code being segregated into multiple editors, but it made it difficult trying to get all of the editable Properties of each object into the editor. There wasn’t enough screen space to fit it all, so I started adding tab controls and really cluttering up the UI quiet a bit. I didn’t like it, as it made understanding the flow of the editors difficult.

The test designer had a simple work flow. Menu driven, and easy to understand what’s going on. The UI was designed much like Visual Studio, with a project explorer and object property editor off to the side of the GUI, and a large open workspace for a future designer that I would like to implement. Objects are created via the menustrip, and once created and saved, are displayed in the Project Explorer, where right-clicking on the object displays a couple of options including Editing it and Deleting it.

Realms and Zones can now be created truly independently of each other. Zones are stored in their own ‘Zones’ directory, and when a Realm is loaded and being edited, the user can select ‘Zones’ on the Realms Properties and it will open up a custom TypeEditor allowing users to move zones out from being within the independent ‘Zones’ directory and move the files and contents of the Zone into the Realm’s directory ‘Realm Name/Zones/Zone Name’. Users can create Zones and add their Rooms to it, without having to place it in a Realm if they don’t want to.

While the Test editor can’t create or link Rooms yet, it does several things that the current set of editors can’t do.

• Build Zones outside of a Realm
• Move Zones in and out of a Realm
• All Objects are now accessible at anytime, from within the same GUI.
• Objects are now Auto-Saved anytime a change is made to it.
• Object Management has been greatly simplified

I spent all day working on the creation, saving, loading and linking of Realms/Zones and was surprised at how fluidly everything worked together. There are several areas that I want to re-visit and refractor, but that will happen at a later date.

With the progress I’ve made over the last week, I’ve decided that the Test Designer will become the Mud Designer, and all of the current editors will be removed from the project. The latest SVN commit at Codeplex no longer contains the previous editor tools, and only contains the new Mud Designer. I’m hoping I can get the Room creation setup tonight, and the Zone/Room and Room/Room linking put together by the end of tomorrow.

Once all of the Environments are able to link to each other and work correctly, I will work on the visualizer, which is going to be a visual display showing all of the Realms in the project. Users can select a Realm in the visualizer and the visualizer clears out to show all of the Zones contained within the Realm, along with showing the user what Zones are linked to it. Selecting a Zone will reveal the ‘Zone Entrance’ room, and all of it’s doors, letting users click a door and travel through the zone door to door.

The visualizer is a planned concept, but has taken a back seat for the moment while I work on linking the environment objects together. I also need to take a look at some of my existing code, and do some clean up on it. Refractor some code from the designer into the engine classes and work on building a few helper methods within the engine to help simplify the actions that the designer needs to do.

del.icio.us Tags: Mud,Game engine,Mud Engine,C#

UITypeEditor implementation

As I continued to develop on the Designer tonight, I thought I’d re-visit an area of UI development that has always been difficult for me to grasp. The UITypeEditor and implementing custom editors for custom Types that the PropertyGrid can use. I thought about it tonight and began working on building a custom Script Editor to test out editing scripts inline from within the PropertyGrid with a custom editor. It had been over a year since I had visited this approach and I had learned a lot regarding C# over the course of the year and I was actually pretty surprised at how easily I was able to put together a custom UI editor for the propertygrid.

This opens up a whole new can of worms for me and my approach to designing the UI for the designer. Most of the UI was designed due to custom objects that couldn’t be edited from within the standard PropertyGrid due to it containing custom Types. I couldn’t edit a Rooms Doors from within the PropertyGrid as the Doors where a custom Type. The PropertyGrid couldn’t do it for me, that is until now, with my understanding how to implement a custom TypeEditor.

What’s this mean for the designer? It means I’m going to look at re-designing the editors to support it. I might be able to finally merge all of my editors into a single editor like I wanted to from the beginning. It also allows me to look into dynamically generating the GUI content as I can store the TypeEditors within the Engine itself. So that as I make changes to the engine classes, those reflections can be made immediately within the designer, just make a couple adjustments to the TypeEditors within the engine and the designer will reflect those changes.

It also opens up an easier avenue for developers to write plug-in support, and extend off existing classes with their own. They can build a TypeEditor and have instant access from within the designer to their custom Types, without having to modify the original source code.

I see quiet a bit of testing and exploring over the next couple of weeks while I take a look at this, there is some serious potential here.

A New Year

Now that the holiday season is over I can spend more time focusing on developing on the Mud Designer, as I know that I’ve been slacking on it over the last two months. There are several things that I am wanting to work on over the next couple of months and I’ve started working on them today.

I setup a forum online so that people using the toolkit can communicate with each other and I can hopefully get some feedback from those using it. I can see that the source code is being downloaded and so I know there’s people checking it out, but I haven’t heard from anyone on it yet. I’m hoping this fixes that issue. It can be accessed HERE

Next I want to finish up the Zone builder, and flesh out the Room designer some. Button it all up to make it work good and get some documentation wrote on it. Once that’s done I’ll work on building an offline runtime for users to play test their mud environments, and then start working on a preview release that I can upload to the codeplex site.

There’s a lot of things I have planned over the next couple of months and I’m hoping that I can get them implemented and some feedback from the users using the software via the website.

Mud Designer Script Considerations

I spent all night last night messing around with the Unity3D game engine and I have to say I really like how they handle scripted objects in their engine. You place an object in the world, and then attach existing scripts to it. This is a nice concept, as it lets you re-use a script file over and over for several other objects.

Currently the Mud Designer allows each object to have a single script, and the script is owned by that object and not shared by any other objects in the game. After messing with the Unity engine’s scripting setup, I'm currently thinking about changing how the engine handles scripts. I’m considering a script repository that the Designer holds, and developers can drag and drop the scripts onto objects within the game. I’m not quiet sure how I want to go about implementing this concept, as it works great with a single IDE interface, that allows drag and dropping from object to object, but the Designer is broken up into several editors and thus making it a little more difficult to achieve.

Concord3D

I finally ran into a fellow developer on the Creators Club site that had interest in starting a 3D Engine project with me. While I have been fairly busy lately and unable to spend much time working on the Mud Designer or any other projects, I’ve managed to get things straightened up and release some free time to work on a couple projects. Hopefully development on both projects can progress smoothly.

Serious Design Flaws

As I began working on linking rooms together with the Zone Builder I ran into several issues with the design of the toolkit. Serious design issues, and it is forcing me to re-work a pretty large chunk of the editors and engine to fix the issue. One of them being that the filenames are not modifiable by the users, I have forced them to be read-only, with the engine assigning a filename to each object. This creates an issue with room names, as what if I want a Room called Bedroom but 4 different variations of it, I can keep the Room title as ‘Bedroom’ but have the 4 variations saved as different filenames.

The next issue I ran into is what if I want to have two Zones with the same name, but within different Realms? This isn’t possible as Zones are contained within their own Data directory.

Another problem is that Realms contain a collection of Zones. The collection contains the entire Zone class. Wait a second though… Zones contain a collection too. A collection of Rooms, holding the entire Room class. What’s this mean? It means that even though the Zones and Rooms are being saved out into separate files, the Realm files where also saving every Zone and Room it contained. Duplicate saving was happening, and having a Realm save every zone, with every room, is going to take a lot of time up during the loading and Saving process.

Lastly, the linking of Rooms was going to seem cumbersome with the installing and uninstalling of doors into Rooms. It was a neat concept at the time, but I have since decided to do things differently.

So what am I planning? I will allow for custom filenames, move the Zones data directory into the Realms directory that owns them, provide Realms with a link to their Zones, but not an actual copy of the Zone, along with removing the copy of the Rooms within the Zones collection, and providing Zones just a link to the Rooms. Lastly I am deleting the Room Designer from the project, and giving the responsibility of creating rooms to the newly renamed Zone Designer. This is a couple days worth of work to get ready and finished, along with adjusting my namespaces within the classes. Hopefully by the end of the week I will have the Zone Designer working fully, with the creation and linking of Rooms completed.