Wednesday, January 13, 2010

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.

Saturday, January 9, 2010

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: ,,,

Sunday, January 3, 2010

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.