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

[Bruce]

On Monday, October 26, 1998, Ola Fosheim Gr=F8stad wrote:
>"Bruce Mitchener, Jr." wrote:

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


Well, a good server and the associated things like documentation, code
running on top of it to make it useful and so on do take time.  A lot of
time.  Many (most?) of us here probably aren't working on these systems i=
n
any type of full-time manner.  It is also somewhat hard to come by
volunteers who are both willing and capable of assisting with complicated
coding projects.  Cynbe has already said that he is pretty much the only
person working on Muq.  How many people work on the MOO server?  With Col=
d,
since I took it over from Brandon, it is mainly one other person and myse=
lf
doing development, and someone else working on the Windows port again (wh=
ich
I appreciate a lot since I don't know Win32 stuff at all (yet?)).   My li=
st
of projects that I want to accomplish, when viewed with the amount of tim=
e
that I have available, is probably something on the order of a year or so=
 of
work.  If I was doing this fulltime, it'd still be a fairly significant
amount of time.

>> 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 t=
he
>> real problems are to be solved.
>
>Uhu, but that is a big job.  Although there is nothing wrong with throwi=
ng


Writing an excellent server framework is a huge job.

>up ideas for technological solutions, it really should be mandatory to a=
sk
>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 project=
s


It may perhaps be more tedious and trying to work for months on a project=
 to
see it fail in the end due to a lack of up-front work in planning.

>fail to do a good job at it...  The basic goal for a commercially orient=
ed
>mud server development project is obviously to create a foundation which
>allows for the creation of enjoyable user experiences, with the addition=
al
>requirement of minimizing cost (time spent on building, maintenance and
>money spent on infrastructure).  The goal doesn't help implementation mu=
ch


Well, there are lots of assumptions in here.  What is the difference betw=
een
a 'mud server' and an 'application server'?  What about a general server
framework (where things seemed to be headed anyway)?  How does an 'enjoya=
ble
user experience' fit in at this level?  Minimizing costs via reducing the
time spent on building and maintenance is great.  How will you improve on
the current systems?  What problems do the current systems face?

One really big problem is for distributions of world-code and data.  When
you have a version out in distribution, and you seed a new version some t=
ime
later, managing merging of changes in the distributed version and changes
made by the people running a copy, is often a difficult process.  While t=
his
can be solved to some extent with modularization, that isn't a total
solution by any means.  I don't know how MOO has solved this, or if they
have at all.  Cold has to a minor extent with an upgrading utility, but t=
he
current ColdCore lacks the modularization and documented (and enforced
interfaces), which is one of the reasons behind my designing a new core f=
rom
scratch.  Sure, this can be solved, but it requires planning.

>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 detaile=
d
>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 wh=
ich
>allows for the efficient creation of MUDs.


So what is your desired system?

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


It is also something that could be very useful to people implementing the=
ir
own systems in the future despite the existence of DevMUD.

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


Don't forget really good documentation, FAQs, constant support, etc.  For=
 a
long time, the complaint of those visiting the Cold Dark was that the
documentation was inadequate.  Now, there are docs, but we still end up
answering most of the same questions.  Now, we need tutorials, etc.  I'm =
not
convinced that it ever will end. :)

 - Bruce