[MUD-Dev] Re: DevMUD module configuration

[Niklas Elmqvist]

On Mon, 26 Oct 1998, Jon Leonard wrote:

> A more complicated example, involving multiple games in the same server.
> The modules are:
> 
> 1) Socket, as above
> 2) Telnet, as above
> 3) ParserA, a command parser
> 4) ParserB, an alternate command parser
> 5) World1, a gameworld
> 6) World2, an alternate gameworld 
> 
> I want players to be able to use either gameworld, and for one run I
> want ParserA to go with World1, and ParserB with World2.  The problem
> is, the next time I set up the server, I may want ParserA/World2 and
> ParserB/World1.  There's no way that the loader can figure this out.

No, you'd have to have a config file, like .devmudrc or something. Yes, we
want DevMUD to be extremely powerful. No, we can't make it omniscient. :)
I think it is acceptable if the user has to write (or cut and paste in) a
config file, telling the server what modules he wants. And there is no
reasons that new modules cannot be loaded at run-time, forcing the
existing module framework to reforge their relationships.

> As a result, I have a new proposal.
> 
> In addition to the special Bootstrap module (the only module known to always
> be part of the server), there is a special Config module.  The Config module
> is like any other module, except:

I took a look at your prototype (nice work!) and liked what I saw. I guess
we can make this look good even if we don't use a C++ approach (of course,
that has not been decided yet). However, I am a little concerned about the
Bootstrap module: it is not a module, at least not in your prototype. It
is the "main program" of the server, right? (This may be due to the lack
of abstraction layer you mentioned.) So a better term for the Bootstrap
module would be that it is part of the core primitives of the server?

IMHO, and here I must reiterate what I have said before, the project can
be divided into three levels of which the lowest level is the driver. It
makes sense to make the driver a lean one. However, it *must* (and I
cannot stress this enough) provide *enough* functionality to make module
writing easy. Why would people use the DevMUD platform if it is just above
OS level with the services it gives modules? As I see it, the Bootstrap
module in your proto is what constitutes a driver, and this is not enough.
We should provide the following primitives:
	- event managing (all games need one)
	- threading (OK, you did not include this in your proto, so I
		won't hold you responsible :)
	- module management (cf your config and bootstrapping module)
	- inter-module communication
	+ anything I missed.

We want it lean. But we also want it to raise the abstraction level of the
services it provides so that module programmers can talk about what they
want to happen in terms of game issues, not nitty-gritty programming and
technical issues.

I apologize if I come on too strong here, but I feel this distinction is
necessary. And I am *not* critizing anyone, just voicing my opinion.

> In order to get a different perspective on how modules might fit together
> to make a MUD, I threw together a prototype.  (There's nothing quite like
> a segmentation fault to tell you that there's something wrong with a
> design.)

Good initiative. I was speaking vocally that "something should be done".
You did something :)

> 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