Mud client tango
by Andy Lewis
In February of 1997, on a complete whim, I started to write my own MUD client.
I didn't know then why I began, and to be honest, I still don't. My rationale at
the time seemed simple: I wanted to get more out of mudding, I couldn't find a Macintosh client
that suited me, and I needed the programming practice.
Since I was at that time mudding about once a month, hadn't spent more than an
hour looking for clients on the web, and was engaged full-time on a piece of
contract programming work, I'm a little dubious about the truth of this...
And whichever way you look at it, I'm not, on the face of it, the ideal person to build a
MUD client. I'd only played two MUDs to any great degree, both very similar in style, and
what I couldn't appreciate was the enormous variety of MUD types,
philosophies, or styles
of play. On the plus side, I have an eye for interfaces, and am very picky
about little details, knowing what an enormous effect they can have on the simplest of
applications. I have also spent considerable time on both MUDs as a player, and
as a builder/admin member, and so have considerable experience on both sides of the camp,
so to speak.
Whatever the reason, and despite a marked lack of experience, I began what I intended as a two
or three week project.
After eighteen months, well over 3,000 hours of work, a quarter inch of receded hairline,
and an incalculable number of cups of coffee later, Rapscallion was launched as a full-blown
product, complete with a one-hundred page manual. This article is intended as
the first of a series which will try to convey some insights into the trials,
tribulations, and above all rewards of immersing oneself in the dark world of
client creation. This first article serves as an introduction to who I am, and how it all started.
From Humble Beginnings...
My original vision seemed very simple. I wanted something with a
separate input area, basic triggers and macros - nothing more. I wanted to tailor it to the way
I played - this was to be a simple tool for me, and I wanted to complete it
as fast as possible so I could use it to play.
When I'd got the rudiments working, with no real frills, but some unusual and
interesting ideas in place, I had the bizarre notion of showing it to a complete
stranger, on the grounds that as he maintained a web page on Macintosh MUD resources,
he might be interested. He had the equally bizarre notion of taking me seriously, and
took the time and trouble to mail me a four page critique of what was then a fairly
pathetic little program. To cut a very
long story short, this kicked
me out of a certain amount of complacency, and started me working with a vengeance.
The rest, as they say, is history.
The goalposts had now shifted. It was no longer a purely personal project - it was
now something I was going to release to the public - and it was time to do some serious
thinking. To write a good client, I decided, I had to work out exactly what it could do
for users, and how it should make those things as quick and easy to use as possible.
What's the Point?
Every time I start work a piece of software, I ask myself this question. If I can't
find a reasonable answer, I don't start - what it amounts to is: "what can I do with this program that
I couldn't do without it?" I had to take a very close look at why a client could be such
a Good Thing.
Time: Mudding involves a lot of typing, much of it extremely repetitious. A decent client
can save you volumes of typing, allowing you to use your time more effectively, and most
importantly, to enjoy more of the time you do spend.
Response: Tools like triggers and tickers allow you to respond more quickly and effectively
to things that happen on the MUD.
Information: Intensive mudding can often involve scanning enormous amounts of text, looking for
the parts that you need to see. Facilities like ANSI colour, hilighting of particular strings,
and many other wierd and wonderful features can make this much easier to do.
Establishing the Vision?
Based on these three points, a list of ideas for what a dream client could do was easy to come up with. The difficult part
was examining each of those possible features, and balancing them against the following criteria.
How useful is the feature?
How many people would want to make use of it?
How difficult will it be to implement?
What I was after was playing aids, rather than automation - a client that would help
people play more effectively, but not a client which would do everything for you.
This process was tricky, and included some notable mistakes - ANSI colour was one of the
more significant absences from the list (that decision changed
within three days of releasing the first beta - I simply hadn't *used* colour on MUDs, and had no
idea of how invaluable it was.)
The next stage was trickier - to take each feature, and look at it more closely from a
How would someone go about making use of the feature?
How far can the concept extend?
How will it integrate with the rest of the program?
Other factors included the look and feel of the whole program and its
interface. This was another tough one - I have something of a bee in my bonnet when it
comes to interfaces - getting the most out of one is of paramount importance to me.
I see far too many examples of software with tremendous potential, but which are
dragged down because their interfaces simply don't live up to their potential.
A MUD client is in reality nothing but a glorified user interface - there are very few things
a client can really do for you that you can't do by yourself (albeit much much slower.)
It boils down to the fact that the interface will make or break a client.
Bringing it to Life
So now I had the dream of what I wanted, the vision of how it would look and be used, and the
will to do it. All I had to do was write the program - which is a perfect starting point for the next
October 1998 Imaginary Realities, the magazine of your mind.
© Copyright Information