[MUD-Dev] Re: My vision for DevMUD

[Jon Leonard]

On Tue, Nov 03, 1998 at 08:25:53PM +1100, Thandor wrote:
> On Tue, Nov 03, 1998 at 12:20:57AM -0800, Jon Leonard wrote:
[much stuff trimmed]
 
> > 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. ;)

A good place to start is that any time we get asked a question about how
something works, the answer should get copied into the source or
documentation.

Mostly I'm just asking contributors to think about documentation and clarity
when they write stuff, and to point out when things aren't sufficiently
clear.

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

The distinction I'd draw is that the bootstrap is the portion we do not
expect to change between MUDs, and that the config module is the portion
we do expect to change.

They're in different modules partly because we can separate them without
undue cost.  That makes it easier to look at one module or the other and
figure out what it's doing.

The other reason to separate them is to make reconfiguration easier.
What should someone do to configure a different collection of modules?  Edit
the config module.  Everything that needs to be changed should be there, and
little else.

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

There are lots of good demo MUDs I didn't list.  The two I mentioned don't
look like they'd be graphical, distributed, persistent, or any number of
other cool things.  We just need a place to start.

Jon Leonard