[MUD-Dev] Re: Missing the point: OpenMUD, Gamora, Casbah, etc.

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Bruce Mitchener, Jr." wrote:
> Good evening all,

Depends... on where you live :)

[ list of codebases for muds... ]

> Many of the people associated with these projects have a strong sense of
> what the problems with the current (and previous) implementations are, and
> how they would do things if they were to start from scratch.  In some cases,
> there are _years_ of work invested in those systems, getting them to where
> they are today.

Yes, and that leads to another question, why did it take years?

> Is there a reason that implementation must begin so soon?  Is there a reason
> that implementation must begin from scratch?  Why not take the time to learn
> about the existing projects, have people look into what has been done and
> where it failed and where it succeeded?  Even more than having an existing
> base of code, it might be very profitable just to have a survey of the field
> like that done to assess what the real state of the art is and where the
> real problems are to be solved.

Uhu, but that is a big job.  Although there is nothing wrong with throwing
up ideas for technological solutions, it really should be mandatory to ask
the question "what is the  question which we just have answered with our
solution???".  What really should be required from all software projects,
professional or hobbyist is an ANALYSIS of the problem you are facing. 
Before you can do that, you do in fact have to define the problem space, and
then start identifying entities, relations, problems and desired properties.
This can be a  boring, tedious and trying process and almost all projects
fail to do a good job at it...  The basic goal for a commercially oriented
mud server development project is obviously to create a foundation which
allows for the creation of enjoyable user experiences, with the additional
requirement of minimizing cost (time spent on building, maintenance and
money spent on infrastructure).  The goal doesn't help implementation much
though, so you basically have to come up with something more amenable to
analysis. One possibility is to come up with a set of relatively detailed
descriptions of desired example systems, then try to find common
requirements that these systems imply. One will probably have to exclude
some of these systems from the problem space in order to reach a base which
allows for the efficient creation of MUDs.

Not only is this a more structured approach than jumping at technical pet
projects, but it would also make the link between the OpenMUD project and
the resulting end user MUD systems more visible. I believe this could fuel
motivation, which is critical for a volunteer project: "OH yeah, this is the
first step towards MY dream".


Some (I believe well documented) common mistakes in software engineering: 

1. Forgot to define the basic philosophy of the system and formally accept
it. This is the basic contract for the system, it is important!

2. Ended the analysis too early or skipped it altogether!

3. Got too excited about the initial design, and jumped to implementation.

4. 1+2+3 = spent way too much time in implementation and debugging.

5. 2+3+4+5 => inconsistencies and patches which makes the system unusable.

6. Didn't define a single person as responsible for progress and correction.

7. Didn't discuss the process to be used and how to deal with problems and
unexpected events before the project started.

8. Didn't make smaller exploratory prototypes.

9. Didn't involve the end user in the process.

10. 5+8+9 => incomprehensible model and interface.

11. The design team was more eager to protect their own self-esteem and
explain how impossible the situation was and that they couldn't have done
better given the lack of resources and therefore failed to say "This was a
huge mistake, I did this and that, it was a mistake which should not have
happened. We need to analyse the situation and make some major changes."

12. 11 = They continued the implementation of a bad design, although they
should have known and acknowledge the problem earlier and redesigned the
system when the problem first surfaced. 

13. The team members were acting too democratic, avoided conflicts which
should have been resolved at an early stage, and let unqualified people
perform critical tasks due to some idea of fairness. => Socializing was more
important than the product.



There are some properties the definition of the system philosophy should
contain. I'll look it up later.  It is always a good idea to write down
several competing philosophies and then try to reach an agreement on one of
them.  This is a very small, but important step to take. At least if you
want to reduce some of the upcoming conflicts and problems.

An important observation: a smaller, more coherent and well defined problem
space simplifies all development stages and makes a more useful result more
likely. Nobody will use OpenMUD if it doesn't bring them _substantially_
closer to running a mud than using plain C++ and Unix...

(I haven't yet seen anyone question whether the data structure and content
is expected to be mostly static or extremely dynamic?)
--
Ola