[MUD-Dev] Re: My vision for DevMUD
jleonard at divcom.slimy.com
Tue Nov 3 13:47:33 New Zealand Daylight Time 1998
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
> 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
> - 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.
More information about the MUD-Dev