MUD32 (.NET) Development Blog Notes on Coding and Design of the MUD32 Mud Client by Matt Owen JarMUD - Some Screenshots
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

201502231123530352 Mon, 23 Feb 2015 11:23:53 +0000
Complete Change of Direction...
"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.


I am now writing a MUD client. Something full of modern features such as:
  • Full ANSI Support
  • Proper TELNET negotiation
  • Logging
  • Button Bars
  • Triggers and Scripting
  • Filtered Output
It's still in very early stages of development at the moment, but it currently looks like this:

It also doesn't have a name... suggestions on a postcard please. :)

201501161332220994 Fri, 16 Jan 2015 13:32:22 +0000
Dynamic Locations
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.

201403141238050311 Fri, 14 Mar 2014 12:38:05 +0000
Combat and Mapping
What I have been doing is playing with ideas to procedurally generate areas. As I'm building this alone, creating each room manually is not achievable so the best option here is to write something that can build generic areas, and then all I have to do is focus on creating core rooms in those areas that have the real content in. This will give the MUD a feeling of size, and will also provide areas for roaming NPCs as combat-fodder.

Ultimately what I really want is a tool that lets me build areas like a Visio block chart - 100% drag and drop. It's a shame that Visio doesn't support a decent parseble export format as that would be ideal. It looks like I will probably just have to carry on developing the Mapping Tool I've written - as the old adage goes, if you want something done right, do it yourself...]]>
201401080930180712 Wed, 08 Jan 2014 09:30:18 +0000
NPCs are Alive! /r/mud over at Reddit for opinions on this).

The idea is that you talk to NPCs in natural language, and if the NPC detects certain keywords or phrases in your text, then you will get back an appropriate response, otherwise you'll get a generic random response in keeping with the NPCs character. The NPC responses are all kept inside a response file, so with a bit of effort, it's possible to create a set of responses for most of the relevant questions.

Ultimately NPCs will also optionally be quest-givers. This will require an update to the dialog parsing sub-system, and I'll have to consider the best way to offer, accept, and track quests. This will be a new feature that wasn't in the original MUD32, so is currently further down the to-do list, after the original feature-set has been re-implemented.

Which brings me onto combat. That's not done at all right now. It's probably going to be the next thing I tackle.

I've also updated the map walker tool I wrote - it's now a proper map editor, with the ability to click on empty spaces on the graphical map to create rooms and link exits. It's still a bit clunky to use but will continue to evolve as time goes on.]]>
201312111525380014 Wed, 11 Dec 2013 15:25:38 +0000
Levelling Up
Once the gameplay engine is fully working I intend to revisit the mechanics and ensure that the game is balanced. I also want to add some sort of basic achievement system.

Before I get to adding in new features, I need to complete the port of the original feature set, so the next things to tackle are NPCs. They need to be able to hold rudimentary conversations with players, move about on their own, and eventually be (optionally) aggressive and respond to combat. All this was implemented in the old version of MUD32, so needs to be in this version also.

201312031008030522 Tue, 03 Dec 2013 10:08:03 +0000
What's in the Bag?
201311200854350831 Wed, 20 Nov 2013 08:54:35 +0000
Item Management
The original game did not have persistent states for items. When you logged out of the game your player auto dropped all items. Whereas modern MUD players may find this odd, the reason for this was that MUD32 gameplay was based on the original MUD2/Shades gameplay model for items, where players simply wandered the land finding valuable items and depositing them in specific locations for XP. There was no need to keep items in the players inventories across logins. Items would then be unavailable once deposited until a specific re-spawn period had expired, at which tme the item would re-appear in one of a set of locations for each item. To stop people hoarding key items the game 'reset' every 45 minutes and moved players back to the starting locations and put all the items back in their original locations.

These days this sort of gameplay seems simplistic and almost odd - but back in the original days of MUDing this was the accepted way of playing (Before all the D&D players got involved and made everything SO complex. )

So, in order to get the .NET version playable, I'm going to re-implement in the same manner. I do intend to extend the game rules and code into a D20-lite style of gameplay, but that's for later on.]]>
201311180822280584 Mon, 18 Nov 2013 08:22:28 +0000
The Art of Recursion Cartography post.

The map-walker tool uses a a recursive function (Called WalkMap) that basically does the following.
  1. Load exits for Room X
  2. Using a static X/Y grid system, draw the room box on the map, and lines for each exit
  3. For each exit, if we've not visited that destination room before, call WalkMap with that destination room number; also update X and/or Y based on Exit name
  4. If no more exits to walk, exit function

Once you get your head around the recursive nature of the function, it's easy to understand that the walker, literally 'walks' the map, following every exit until it reaches a dead end, at which point the function returns one level back up the recursion, and looks for more exits in the previous room. The hardest part to get right was actually the mapping of the rooms on screen, as keeping track of the X/Y co-ords is quite tricky especially if you don't want to overwrite several rooms in the same place. I'm lucky in that the original map layout had hardly any overlapping rooms in the X/Y space - a later revision of the walker may gain the ability to extend an exit line to place on the map where there is not a room already there.]]>
201311180808130064 Mon, 18 Nov 2013 08:08:13 +0000
To this end, I spent a couple of hours last night knocking up a basic map walker tool. It starts in a predefined location, and by parsing all the location files, it 'walks' the map, keeping track of all the locations it's been to, and exits not yet followed. A wonderful coding exercise in function recursion. This tool is very basic, as it's merely a means for me to visualise the current map and identify any pathing problems.

Which it did. I then spent another hour or so moving some locations around. The screenshot below shows a small area of the map (the area I was fixing).

201311060928310852 Wed, 06 Nov 2013 09:28:31 +0000
Progress So Far...
It's at this point I can either just re-implement the item management as I had it in the original MUD32, or re-work it into something more expansive... Decisions, decisions.

See the screenshots below for a feel of how the codebase is looking at the moment.

201311051156180099 Tue, 05 Nov 2013 11:56:18 +0000
What is MUD32(.NET) ?
Even though I was happy doing this, I felt that the hobbyist community could benefit from a Windows-centric MUD codebase, complete with a set of GUI tools to build rooms, objects, and NPCs. So, MUD32 was born. Over the course of a few years, I worked on MUD32 during the odd bits of spare time when I found myself stuck in hotel rooms or on trains and airplanes and wanting to kill time.

Eventually MUD32 became feature complete, and completely playable. It had the same sort of feature-set and gameplay as MUD2 or Shades. It was featured in the book Build Your Own Games by Tom Ellard (although without my permission).

Recently, I've wanted to get back into MUD development, so I've started up a new project to initially port MUD32 to the .NET platform, and then to enhance the gameplay to reflect the tastes of the modern MUD player. This blog exists to track this project, to give it a home, and to give it visibility.]]>
201310292002160789 Tue, 29 Oct 2013 20:02:16 +0000