The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!
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 shareware 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.
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.
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.
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 usage standpoint.
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.
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 issue.
October 1998 Imaginary Realities, the magazine of your mind.
© Copyright Information