[MUD-Dev] Re: My vision for DevMUD

[Niklas Elmqvist]

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?

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

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.

> 3) The code should be well documented, and where possible easy to understand.
>    This is also for ease of making expirimental modifications.

*Very* important, IMHO. This ties in nicely with the "educational" goal.
We probably need a standard document format which can be easily converted
to HTML, PostScript, info, etc... I'm far from familiar with this area but
maybe a SGML DTD could be used? And how about source code documentation?

> 4) There should be more than one example collection of modules, as not all
>    expiriments would use the same starting point.

Agreed. This is also fertile ground for a "componentization framework"
discussed by the MS guy in the Halloween document -- a monolithic project
is *very* hard to develop in parallel, but if there is a way to divide it
into components (modules, in our case), parallel development is very much
feasible. Also, since we're all MUD developers, we could even say that we
almost have an "implicit componentization framework", just like
Linux-hackers building Linux in the image of UNIX (sort of, at least). 

However, before that, the MS guy notes that the component framework must
be established, meaning that key API:s and structures are defined. Hence,
we need to iron out these specifics for the DevCore *before* anyone starts
doing serious modules development.

> Implementation Language:  C for maximum portability and flexability.  To the
> 	extent that modules in other languages can intermix with C modules,
> 	other languages should be usable.

I tend to agree with you here, despite my earlier differences. At least I
am convinced that the glue between modules should be C bindings. Doing the
whole core in C sounds at least *reasonable* to me, not only for
portability (I don't agree with flexibility, though), but also for
simplicity. Object-orientation and C++ tend to add a secondary threshold
for newbie programmers.

> Threading:  The minimal inplementation should not be threaded.  Not all
> 	target platforms support threading, and requring thread support
> 	from all modules makes the system significantly harder to
> 	understand.  If a particular collection of modules is thread-safe,
> 	they should be usable as a threaded server.  Note that a threaded
> 	virtual machine model does not require a threaded server.

I have very little expertise in this area, and will thus leave it in the
capable hands of other members of the project. We *do* need thread-support
in DevMUD as a whole, but this might possibly not be applicable to the
DevCore.

> Module interfaces:  Modules should export a predictably named array of
> 	function information structures, and a separate verifier program
> 	should be available to check the accuracy of type information.
> 	Modules should be dynamicly loadable (on platforms with support)
> 	for maximum flexability.  There should be a method for describing
> 	interfaces for interface inheritance.

Very good. These C bindings can of course be used to negotiate
higher-level message protocols. I'm still a bit confused about how to
allow for the addition of new interfaces, but this could possibly be
resolved by using some kind of OO-like inheritance mechanism. No
interfaces would be hard-coded into the core, though, except maybe for a
few householding functions for checking version numbers, module names and
documentation strings. 

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

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. 

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

Very good effort! And my vote's for Jon Leonard as the benevolent dictator
as well! 

Oh, I would like to officially add myself into the member list of the
DevMUD project while I am at it (not that we have a *real* member list or
anything...).

> Jon Leonard

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods