[MUD-Dev] Re: My vision for DevMUD

[Robert Woods]

-----Original Message-----
From: Thandor <thandor at donut.dhis.org>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Tuesday, November 03, 1998 5:12 AM
Subject: [MUD-Dev] Re: My vision for DevMUD


>On Tue, Nov 03, 1998 at 12:20:57AM -0800, Jon Leonard wrote:
>> I'm interested in building a MUD server which is well suited to
development
>> of experimental MUD features.  Support for commercial use, optimized
>> implementations, etc. are secondary.
>
>Ah, finally someone has said what they want DevMUD to do and some sort of
>priority oirdering. And reasonable goals to boot.
>
>> 2) The licence should by default be public domain.  This provides the
least
>>    impediments to using the code for experimentation.  Allowing some
modules
>>    with different licenses is useful for reusing existing code.
>
>Hmm, I would argue that a LGPL style license where people are "forced" to
>contribute back should they make changes would be of more benefit if the
>goal is to learn from this experiment. I say LGPL because this leave no
>barriers to someone using the modules and linking them with their own to
>make a commercial product. That seems to me to be a more logical way of
>doing things, but I could be wrong. :)
>
>> 3) The code should be well documented, and where possible easy to
understand.
>>    This is also for ease of making expirimental modifications.
>
>Ah yes, glad that this is a key point. How do you plan on enforcing that it
>be well documented though? Human (or at least programmer :P ) nature seems
>to be only do documentation when there's some external force. ;)


Well, there are two ways to accomplish it.  One is to require that any code
submitted for approval must be well-documented.  This will be a pain for the
"benevolent dictator" to moderate, because he/she must then check all code
to make sure it is documented, and must send back code, no matter how good
or necessary, for documentation.

Another possibility is to have a few people whose job is primarily to look
at and document code.  These people would be given the code and would review
it, doing whatever documentation is necessary.  If they have any questions,
they bug the programmer.  Of course, these people must be familiar with
programming, and if they're able to understand what's going on with the
code, they would be better used in MAKING code.

A third option, although difficult, is to brainwash programmers..."I want to
make well-documented code."  Of course, one would think that people trying
to work on a project such as this would already have that ingrained...or at
least we would hope.

>> 4) There should be more than one example collection of modules, as not
all
>>    expiriments would use the same starting point.
>
>Good idea, although I think it's more important to finish one set of
>example modules before worrying about a second.
>
>> There are a few other decisions that affect modules in a project of this
>> type.  In particular, I prefer:
>
>All sounds pretty reasonable here. And at least some decisions being made
>rather than complete generica.
>
>> General DevMUD structure:
>>
>> There should be a generic bootstrap loader, whose responsibility is to
>> provide module loading facilties and little else.  It is responsible
>> for loading a more specialized config module, which has responsibility
>> for loading and configuring the rest of the modules in the system.  A
>> typical config module will probably qickly delegate control to a script
>> in an in-mud language.
>
>If the bootstrap module is always going to be loading a config module no
>matter what, is there really any point in them being seperate modules? Even
>if you want the possibility of different config modules, why not make the
>bootstrap code a library which can be linked into any config module someone
>decides to build? I just see no reason in having a seperate module that we
>know is going to be loaded anyway.
>

Well, the bootstrap module should more or less not be changed.  So, either
method would work for me.  Of course, being an LP guy, I'm used to seeing a
separate bootstrap module :)

>> I envision at least two demo MUDs:
>
>Since both demo muds are non graphical, may I suggest that a graphical demo
>mud might be a good idea at some stage?


I don't think that Jon is saying that we'll make something that looks
exactly like an LP or a Diku...I'm sure that one of the concepts could be
easily translated into a graphical MUD.

>
>> I have more thoughts, of course, but that's generally where I'm coming
from.
>> I'm volunteering to be project maintainer for such a project (including
>> hosting on my server), including writing some usable collections of
modules
>> if necessary to jumpstart the project.
>
>Well, since you're the only one who's volunteered so far, you've got my
>support at this stage. ;)
>
>Seriously though, I'm liking what you've writen as it seems to at least be
>more of a vision than a game server which does everything, it actually
>states some more specific goals - though I would like to see them clarified
>further. Even skeptical little me can see some hope of a useful system
>coming from this.


Well, I'll use whatever knowledge I have to help out...no guarantees :)
And, since Jon Leonard seems to have a clear vision that I agree with, and
he seems to be volunteering, I nominate him as the benevolent dictator of
DevMUD.

As regarding the LP-style module, I'm all for that!  I'm currently working
on an LP mud and might be able to help out a bit more in a realm like that.

>
>- Shane King.
>
>--
>MUD-Dev: Advancing an unrealised future.