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

[Niklas Elmqvist]

[Greg Munt:]
> 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. 

It has already been proposed by list members that maybe DevMUD discussions
could be moved to a mailing list of its own. However, at the time, JCL
decided to keep the discussions on this list. I think that until we start
getting down and dirty with code, the DevMUD posts are on-topic to the
list (that may have happened already, though). 

Secondly, I can easily see a quite large portion of the members of this
list becoming involved in the project since it *should* cater to just
about any kind of MUD developer/designer. I would argue that a lot of the
discussions, while a bit technical in nature, certainly *are* relevant to
this list.

That said, I am seeing a disturbing trend -- the number of
non-DevMUD-related posts is decreasing. Hopefully, we're not driving
anyone away from MUD-Dev as a discussion forum. In that case, we'll *have*
to create a new list.

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

Well, the way I see it, those are technical prototypes of some important
aspects of DevMUD. It is quite important to ensure that the technical
foundation upon which the project rests is a stable one. All major
projects do this -- it is vital. 

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

If you've paid attention to current software engineering teachings in this
area, you may be aware of the concept of 'iterative development'. This
means that the development process is divided into smaller sub-projects
(or iterations) in which *all* the phases of analysis, design and
implementation are present. This is what experienced software
engineers recommend as the 'best' approach to software development. What
you are describing is essentially 'waterfall development', where we first
sit around doing analysis, then we do design, and *then*, when we've
mapped out every little detail and thought about every little
complication, we hand it over to the programmers to code. This doesn't
work very well (at least not for large projects) as per the famous axiom
of battle plans never surviving for more than a few moments into the
battle.

Note that I am *not* giving my support to chaotic development or a "code
before you think" approach. We still need to do some heavy analysis and
design. I am merely saying that it is *not* practical to try to anticipate
every little problem we might encounter. The best approach is to find a
middle way between these two alternatives and use iterative development. A
layered system like DevMUD should lend itself rather nicely to this
method. 

Naturally, we need some high-level discussions of the conceptual design of
the project, and I can agree with you that there has been very little of
that. However, it is not by far too late to start -- besides a few
prototypes, we have not made much more progress than these discussions and
a few webpages. Personally, I don't see implementation starting in the
near future -- we still have a lot of things to do before that. 

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

Whoa! Grumpy today, are we? You are being more than a little unfair, I
would say. I, for one, am *very* interested in design and analysis,
especially in the context of OO, and I am sure that other DevMUD
supporters are as well. Trust me, I *know* the importance of good design
and thinking before you code -- I've been in the situation of not having
done that and being stuck with the results.

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

The way I see it, DevMUD is a sort of kernel or development platform for
MUDs. It is *NOT* a MUD in itself! It is not even a codebase! Therefore,
we have quite different design goals than a fully fledged MUD. Our mission
(at least at this point, other things will follow later) is to make sure
that we create a powerful-enough server platform to allow for just about
any feature developers want to add. Social issues do not belong in the
kernel, they belong in the macro-design of how modules will work
together to form a game.

Of course, it is certainly useful to try to view DevMUD from the context
of different game types and with these social issues in mind to see what
might be required from the platform. 

[Diku rant snipped.]

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods