The search for identity
Letters to the editor
- Scatter ///\oo/\\\
Guide to Roleplaying
Waltzing on with the mud client
- Andy Lewis
Rule making of roleplaying
- Michael A. Hartman (Aristotle@Threshold)
Beyond Player Killing
The Writer's Block
- Daniel McIver
Enter your email to be informed when this site is updated.
Waltzing on with the mud client
by Andy Lewis
This article is the second in a series recounting the stages of my adventures in the world
of mud clients, from a quick program to its current full-blown shareware
In this article
I will cover some of the initial burst of serious development, through to the first heady moments of
it's initial test release.
What's in a name?
Odd though it may seem, one of the first things I had to do was to work out what to call
the project. I didn't find it easy, as I wanted it to be different enough to stand out, while
conveying some of the character of what the program did. I settled, in the end, on
"Rapscallion"; partly because of the medieval associations (it is the
original version of the word rascal), partly because of the
suggestion of someone going their own way, but chiefly because I just loved the sound
of the word.
When it was first released, a number of people asked my why I'd chosen a name which
didn't even hint at its basis in the mud world. My hope was that with time, and as more
people started to use it, the word would take on that meaning.
Since I have not
been asked that question in nearly a year, that appears to be
exactly what happened.
Fred Astair and Ginger Rogers, waltzing?
In a World of My Own
An early decision I made was that I should at all costs avoid looking at
clients. At first glance, this doesn't sound sensible - where better to look for ideas,
tips and inspiration than from other examples in the field? I was certainly tempted.
The reasons for avoiding this were more compelling. First off, I felt that I had more ideas
than I could easily handle and had no need for more. Second, I wanted to be original in
my approach and how better to do this than not to know how anyone else had done it?
Third, and perhaps more importantly, I didn't want to be discouraged by finding the
ultimate mud client when I was only part-way through development.
At the time, I was concerned with succeeding on my
own terms, not relative to the rest of the world.
Blood, sweat and Extreme Laziness
Looking back, the first three months were very hard work indeed. It didn't feel like it at
the time! I was thoroughly enjoying what I was doing, but I was spending most of my free
time (and more) working on it.
One problem was that my head was awash with ideas and plans,
all clamouring to be included in the final product. My initial plans were all very well,
but once development started, I began to see more and more possibilities on each of the chosen
features. I could be half-way through implementing a feature, and suddenly think of a better
way of doing it! Or I would think of a far more useful extension to it
which would require beginning again...
In reality, a mud client is nothing but a user
interface, designed to suit any number of back-ends (muds) and with very few standards that
can be depended upon. So it is essential that a client be as easy and efficient to use as
possible - if it isn't, one might as well go back to using Telnet. Designing and implementing
a good interface is a tough job at the best of times. I knew that while I probably couldn't create
something to suit everyone, but it would not be from lack of trying.
On the plus side, I had one big advantage.
I am, by nature, an extremely lazy programmer, and will go to great lengths to avoid disagreeable
work. This doesn't mean that I shy away from work, as
such: it simply means that I often will spend as much as a week trying to work out how to make a
five hour job take twenty minutes - if it seems that there's a quicker way of doing something
taxing. If there really doesn't seem to be a shorter way of doing the task, I try making changes
to my goals until there is. Just occasionally though, I am forced to grit my teeth, and sweat
for the five hours it takes to finish.
This all may sound more than a little daft, but it can often create a much
better end result. Following the KISS maxim, Keep it Simple Stupid.
If, for example, a user interface looks incredibly complex
to implement, the important question is: why? Is it simply becoming
far too cumbersome
for the user? What other way can the program produce the same result, without that
complexity? Elegance is the watchword, and I try to achieve it at all times, albeit
with varying results.
The journeying system in Rapscallion is a classic example of this at work. I wanted some kind
of mapping system, but the traditional grid-based systems are fraught with so many problems
and difficulties, that the idea of making one filled me with dread. So I took the problem
back to the stage of looking at what I wanted to achieve, which was a simple way of travelling
across large expanses of a mud with minimum effort. The end result is something that I'm still
proud of. It is a simple and easy to use menu based system for setting up
and remembering routes to various locations. It can handle connecting them
together and compiling composite routes and so on, very easy to use and
A Brief Moment of Exhilaration
In May of 1997, about four months after I'd started the project, I released the first test
version of Rapscallion. It was advertised only on one web page (albeit a popular one amongst
Mac mudders, and I had no idea what to expect, so I sat back nervously and waited for the responses.
To say that I was unprepared for what I got is the understatement of the year.
The first email I received was very brief and to the point, and began: "You are the GOD of the
mud Client Universe!", continuing in a similar vein. Most of the rest weren't quite so good, but
almost all were complimentary.
Bug reports came in thick and fast, as did feature requests.
Most people seemed to be taking
the stance that this was
a new and promising approach, well worth supporting and helping in every way they could.
The next week is a bit of a blur, and I don't remember very much of it - but by looking at my
notes, emails and version history, I can paint an unusual picture of it. During that week,
I released no fewer than six new versions. ANSI colour support was added in a day. It slowed down
after that, but all told,
between May and November, I released no fewer than eighteen versions.
Given the hassle that
it can be to upgrade software, it seems crazy that people didn't complain about this (I've recently
had such a complaint when I released two updates in three months).
Instead I would get emails
if there was more than a month's gap between releases, asking whether I was still working on it.
A Bug's Life
Bug-fixing a mud client is fraught with difficulties. Aside from the number of problems which
would crop up on machines other than my own (for the first time ever, I realised that having
an extremely stable computer is not always an advantage).
I still cannot understand
why many of these bugs could ever have allowed the client to work in the first place.
The client programmers' nightmare though, is the bug which is specific to one type of mud.
Because of individual quirks, this problem is more common than one might think, and even if
I logged on to one the muds in question, it could still be hard to recreate the bug. It
often required familiarity with the mud in question, or even use of a high-level character,
which of course I didn't have time to establish. Even when I've found the potential cause
of a particular problem, I am still reliant on others to test the solution out.
The feedback I had was intriguing.
I spent a lot of that time reading the feature requests, and sorting out the feature requests (of which
there were too many to count). I implemented many of these,
discarded some and shelved the rest for a later release.
By November, I'd added so many facilities which didn't conform to my original plans
that Rapscallion was bursting at the seams. I could now see an enormous number of flaws in the
program interface and architecture. I realised that there was no way I could overcome them,
and implement anything new with the program as it was.
Fred Brooks sums it up nicely in The Mythical Man-Month - a superb book on the logistics of
software projects. One of the decisions to be made when developing a new piece of software is
whether or not to first build a throw-away version as a trial run. Brooks points out that
this question is wrong - you'll always build a throwaway. The question is whether or
not the throwaway is the one you'll give to your customers.
I realised that I'd built the throwaway, and taken it as far as it could go. It was time
to start again from scratch and build the real thing.
To be continued...
November 1998 Imaginary Realities, the magazine of your mind.
© Copyright Information