[MUD-Dev] MUD-Dev's DevMUD: a word of caution
greg at uni-corn.demon.co.uk
Sat Oct 31 14:52:45 New Zealand Daylight Time 1998
I have not followed discussions too closely, so forgive me if I'm
repeating what has been discussed before. (If it has been, it would seem
to have been ignored, so I can still claim some validity for this post..)
Firstly, I am somewhat concerned about the impact that the DevMUD (only a
programmer could have thought that name up, but that's by the by - and
yes, I do consider myself to be a programmer) thread has had on this list.
We are in danger of MUD-Dev becoming a mailing list for the development of
a single mud project. That's sort of bad, really - and quite definitely
not what this list was set up to achieve.
Secondly, I am disturbed by what is being discussed. Already we have
decided on the implementation language (people are even posting code!),
and on various really low-level technical/implementation issues.
Admittedly, I have not paid too much attention to the thread (to be
honest, it's NOT the sort of thread that I subscribe for), but I have not
seen any discussion of the purposes of developing this software, of what
requirements it is being designed to meet, of ANY high-level design at all!
If the project is to move forward into something more than the discussion
of ideas, (I actually have reservations about whether that is actually a
good idea - these are described below), it needs to have a concrete
foundation. A foundation which minimally consists of a full requirements
analysis, and full documentation of EVERY facet of the software, and of
every decision made and why it was made.
This project is in danger of becoming nothing more than some hacked-up
piece of junk that is the exclusive property of the more code-oriented
list members. I have seen little or no input from the designers on this
list - and that must change if the project is to become more than a pipe
dream. Think to yourselves: why do I want to do this? When it's finished,
what will it be used for? Will people want to use it? Why? It's all well
and good to say you are doing it for the fun and enjoyment of doing it -
but it won't result in anything worthwhile unless you have some strict
rules in place. The importance of analysis, design and documentation is
so high that it cannot be measured - particularly in a team effort, and
particularly when the team is potentially large. The way that things are
going, these important elements are going to be ignored, because those
involved just do not want to do those things. Many contributors to the
thread seem more interested in how it will be implemented than whether it
will be usable, whether it will satisfy the needs of anyone outside those
developing it, and whether anyone else will be able to work out what the
hell is going on.
Simply: if you want to develop a mud for your own pure selfish pleasure
(most of us are doing that, and it is probably the main reason for most
of us subscribing to this list), develop your own mud. This so-called
DevMUD project needs to be handled in a more professional (some would say
boring, I'm sure) manner - at least initially. When you have the firm
foundations, then you can start thinking about cool things to put in, and
maybe relax the rules a little.
But until then, think about what you are doing a little bit. The
consideration of social issues (relevant to ALL muds, since ALL muds
cause the development of a community) needs to be an integral part of this
Ok, here's the next part of a post that will probably be mostly ignored
(and this is a part that will almost definitely be ignored most of
all!).. I want us to think about what will happen to the product of all
this development (hard, because we have done no requirements analysis,
and certainly no documentation of it). From what I have read in the
thread, it appears that the project will produce modules for other mud
developers to use in their own endeavours. While a noble goal, I feel it
is a rather naive one.
Looking at the history of the free mudding field, we see a flagrant
disrespect for the intentions of the original developers of a mud branch
(cf Keegan's Tree). Mud developers release code to the Internet in the
hope that it will help and assist further development of new muds, and
indirectly, the field itself. As we all know, in the majority of cases,
this just does not happen. (Yes, we are coming to my pet topic.) Let's
use an easy example. Let's look at DIKU. In its day, I'm sure it was
good. But its reputation today is very poor - having been sullied by the
ignorant. I assume I do not need to explain further here?
As an endnote: I've been given unpaid leave to go to the Bahamas (where my
fiancee lives) to see if I have any chance of finding employment there.
I'll be married with children before you know it.. (Hmm, is that good? :-o)
More information about the MUD-Dev