[MUD-Dev] Re: MUD-Dev's DevMUD: a word of caution

[Thandor]

On Sat, Oct 31, 1998 at 02:52:45PM -0100, Greg Munt wrote:
> 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. 

Yes, I agree that it would be bad if the only thing that ever got discussed
was a single mud project. On the other hand, it's the only thread of any
length on this list that has really managed to grab and hold my interest.
I'm sure there are other people who are equally enthused by it.

> 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.

I agree that this is A Bad Thing (tm).

> 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.

Again, I agree. I think this is what I have been touching on with my posts.
Such a formal design process as you suggest is probably going to be hard to
regulate in a project of this nature, I'm thinking. But you're right in
that there should at least be a high-level design process of some
description. 

> 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.

Heh, I don't think being code-oriented and being a designer are mutually
exclusive. I consider myself to have a foot in both camps (and maybe that's
why I do neither as well as I'd like toi *shrug*). I do think the coming in
with the heavy technical and difficult to understand details from the start
has scared anyone not particuarly interested in coding the DevMUD system
away though. So you may be right (even if I do resent the suggestion that
coders can't be designers).

> 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?

That's exactly what I've been asking of the list. I'm not sure I like the
answer from many people that it should be so generic as to not even be
recognisable as a mud. I get the feeling that if you try to make it
universally useful, you're more likely to make it universally useless.

> 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.

*cheers in applause* Yet again someone else has said what I was trying to
say but managed to confuse in my verbosity!

> 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. 

Pure selfish pleasure? Hmm, would anyone even put their mud up on the net
if it was only intended for their pure selfish pleasure? Not to mention
release the source code. No, I think the intentions are good, but are just
a little ill-directed at the moment.

> 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 
> thinking.

Social issues? I'm a fan of considering the social issues when deciding how
things are handled in a running mud. But I'm not sure how you mean to say
they apply when making a mud framework/library or whatever it is DevMUD is
supposed to be doing. Do you mean social issues as in interactuion between
list members?

> 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!)..

Well, I've replied this far, I'm not about to start ignoring you now. Hang
in there. :)

> 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.

I think I might agree with you. I'm not sure if I'm understanding what
you're saying, or I'm reading it the way I want to read it. Making modules
that will work in the DevMUD framework and that can be mixed and matched
seems a reasonable enough goal to have. Making modules that will be useful
outside that framework seems to be a pointless one. That's my feeling on
the matter, and I'm not sure if that's what you're trying to say, or
whether you're trying to say making a generic platform for others to use is
naive. I'm assuming it's the first, since building on other's platforms is
how 99% of the muds out there today were built.

> 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 

You think so? I don't see it as such. If I released a mud today and in 8
years it grew to even 1/10th of what diku has, in terms of both the number
of people using it and what they've done with it, then I'd be damn proud.

> (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?

It's reputation amoungs the "Joe Sixpack" mudder is very good. It's only in
elitist circles (such as this) that diku has a poor reputation. I don't
think it has at all been sullied by the ignorant - sure, the number of
stock muds probably hasn't been good for it, but on the other hand, the
newer releases of diku derivatives have ensured that diku has lived on as a
great mud base. Very little of that 8 year old diku code is in the
diku-derivative muds being released today, but diku still gets much credit.

I think releasing the source code to your mud is the best possible thing
you can do for your mud's reputation. It attracts people to come and play
your mud, if only because it's the "reference" implementation of the code.
It promotes goodwill - what goes around comes around and all. And perhaps
most importantly, it gives you a shot of longer lasting fame, long after
your mud is dead. If diku never released their code, do you think people
would remember it? Probably not.

I think releasing the source code does a great service to the mudding
field. In fact, if I was the one to chose the DevMUD licence, I'd have a
clause requiring that you release your source code (that doesn't
necessarily mean you have to release your database and the like). Simply
because I don't think people should be reinventing the wheel 100 different
times on 100 muds.

- Shane King.