[MUD-Dev] Re: My vision for DevMUD

[Jon Leonard]

On Tue, Nov 03, 1998 at 03:05:17PM +0100, Niklas Elmqvist wrote:
> On Tue, 3 Nov 1998, 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.
> 
> Experimental MUD features? Good enough, but would it fuddle things if we
> added "next-generation MUD server"? At least as a secondary goal?

What would you put in a next-generation MUD server?  To me that sounds like
a server with expirimental stuff after it stops being expirimental.

> Another secondary goal (yes, we should remove the 'etc' and list these
> explicitly) should probably be "educational instrument" or something along
> those lines.

I think educational instrument follows fairly directly from being well suited
to experimental work.  It's definitely a goal.

These sorts of things can be goals without making it into the one-paragraph
summary, though.

> Also, we need to make a distinction between three different entitites: the
> DevCore (the actual platform/driver/engine of the project), the module
> sets which make up DevMUD as a fully-fledged MUD server, and the world DB
> which forms the actual game. It might be useful to define these three and
> discuss them briefly if only to prevent people from mixing them up and
> have a difficult time "getting a grip" on the architecture of DevMUD.

I'm inclined to break lots of stuff out of "the core" into modules.  I think
it would make it a little easier to understand.

A lib on top of a collection of modules is a separate layer.  We should work
on it when we have modules to put it on.

> > 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.
> 
> Hmm, I think we are needlessly limiting ourselves by saying this! Let's be
> a little more generic and say that the bootstrap loader loads all modules
> listed in a config file -- this could of course only be your config
> module. All up to the module developers and/or MUD administrators.

Limiting?  I think that "provide your own code" is the ultimate in
flexibility, while perhaps suffering in terms of usability.

A config module that reads modules listed in a file is perfectly feasable.
It's less useful for run-time reconfiguration, though.  But config modules
are one area where we know there will be alternatives.  By all means design
an alternate config mechanism.

> I have another important point here that should be included in this
> discussion as well: The DevCore plainly supplies all modules with a small
> API (used by simply #include:ing a header file) for the following
> functions: 
> 	- module management (loading and unloading modules)
> 	- inter-module communication (getting a function pointer of the
> 		desired interface to another module)
> 
> It is imperative that we include this, IMHO. 

That's exactly what it needs.

Jon Leonard