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 product. 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.
|
|
|
In a World of My Own
An early decision I made was that I should at all costs avoid looking at existing 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 very versatile.
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.
Feature Frenzy
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