Notes on Coding and Design of the MUD32 Mud Client by Matt Owen
JarMUD - Some ScreenshotsJust thought I'd share some work in progress screenshots of my new MUD client that I am currently writing.
The Connection Wizard:
Logged into the game, with the button bar visible:
The button bar editor:
The alias editor, and a 'navigation' window:
I'm currently working on the Trigger Editor, but I don't have screenshots of that I want to share at this time. The Trigger Editor will also drive development of spawn windows
Complete Change of Direction...A short while ago, I was reading one of my favourite forums for MUD discussion, and one of the posters said something like this:
"The last thing we need is a new MUD Codebase - there's already too few players as it is. We really don't want them to be fractured even further."
And it dawned on me. That poster is 100% right. We should be focusing on making access to the existing 1000s of MUDs easier, not adding more servers.
So, with immediate effect, I am no longer working on MUD32. It's done. I've learnt a lot of coding techniques since I first started writing a MUD server, so all is not lost. However, as a product there is no requirement for yet another MUD server. So it's done. No, I won't be releasing the source.
However...I am now writing a MUD client. Something full of modern features such as:
It also doesn't have a name... suggestions on a postcard please. :)
Dynamic LocationsI love thinking about mapping. I know it's sad, but even though I've not had much time to work on the MUD code recently, I've spent a bit of time thinking about how a one-person MUD Admin can easily expand his (or her!) world by 100's of locations at time, yet only actually directly build the key few that add real content.
So for example, your key areas are a small village with 3 to 4 'shops', an Inn, and a bank. Those locations need to be hand built, but the surrounding areas do not - The fields, woods, paths, rocky hills etc. can all be dynamically created as the initial part of building the area, leaving the MUD Admin just the tasks of tweaking a few descriptions and making sure the exit pathing works correctly.
The tricky bit is how to easily generate the locations without it all looking like a hideous mess of random junk? My solution is create a visual graphical app that allows you to 'draw' locations on a low-res grid (i.e. 50x50). Each grid point is a location, and the colour you place on that point would determine what sort of terrain is in that location. Descriptions can then be dynamically built based on this information and the information of the surrounding locations. The app can then spit it all out in a variety of formats for easy import into the MUD location DB.
For example, using the image below, a description could be:
You are on a gravel path, leading north and east. To the south is a small pond, and to the west are some buildings.
Just an idea at this stage, I'll throw some code together and see what comes of it.
About this BlogMUD32.NET is a small project to build a new unique MUD Client on the Windows platform, using the .NET framework, and modern gameplay elements.
For more information, please read this post.