[MUD-Dev] Re: PDMud, Gamora and Casbah

[Niklas Elmqvist]

On Sat, 24 Oct 1998, Jon Leonard wrote:
> On Sat, Oct 24, 1998 at 07:19:46AM +0200, Niklas Elmqvist wrote:
> > (Small voice: I still want to do it O-O. Wanto! Wanto!!! :)
> 
> Those look like reasonable architectures, albiet ones that are fairly far
> from the design I envisioned.  It may be that we can't all agree on an
> architecture (or implementation language, or mudlib, or...) and the
> project will have to fragment at some point.

Right. As it should, seeing that so many people with differing interests
are interested in the project. The way I see it, the DevMUD effort is a
project to accomplish the following basic goals:
 - raising the average MUD technology level in the community (i.e.
	advancing an unrealised future :)
 - give newbie MUD developers some good education material 
 - providing a high-level platform ideally suited for MUD development (and
	indeed *any* kind of internet game server)

I don't believe in creating "just another codebase" like Circle, Diku and
so on. DevMUD should be a friendly environment for MUD development.
Possibly the different module sets could be called "codebases". 

With these objects in mind, I am sure we can find a minimal set of
primitives which allows us to do all this without limiting ourselves and
the flexibility of the system. While I think Gamora seems to be extremely
flexible, it is probably too flexible for our purposes. We need a "generic
internet game server abstraction" not a "generic server abstraction". I am
sure we can narrow down the specifications and lower the abstraction level
(as well as the ambition level) to improve ease of implementation and
efficiency. 

Of course, I realise that my own vision is likely to be different from
most people's. :) Just my $0.02. 

> Some amount of fragmentation is good:  We certainly don't want all MUDs to
> be identical.  The real question is where does DevMUD development fragment:
> 
> Implementation language?

Hopefully not as early as here. We are all above religious language wars.

> Module format?
> Module connection architecture?
> Modules used?

This is the point where I believe (and hope) development may defragment,
but this is not an all-or-nothing step. Some of the modules (like network
I/O, traffic directors, etc) are likely to be usable in just about any
internet game server, while others (magic modules, on-line building,
room-based movement, etc) are specific to MUD types.

> In-game language?
> Mudlib?

These two we should at least provide examples for, such as a Diku-lib, a
more modern coordinate-based model, perhaps, and, hopefully, also a
graphical implementation. Of course, these are game world which will
reflect in the module level, too. 

> Only in gameworld details after install?

Perhaps we could introduce a "tech level" concept denoting how high or low
a concept in the DevMUD project is located. That is, the driver would be
at level zero, system modules (VM, module manager, garbage collector, etc)
at one, game modules at two, etc. Just a thought.

> What I'm trying to find is an architecture acceptable to a reasonably large
> number of developers (including me!), so that we can more quickly build our
> ideal MUDs.  If there are people who don't like that design, and they form 
> an alternate development team, that's great.  We'd wind up with more good
> examples of MUDs, and it's still less total effort expended than without
> collaboration.
> 
> I'd be shocked if we all used the same collection of modules, and if we
> fragment before that, at least we can still port code back and forth.
> 
> So by all means, describe your ideal design.  You may yet convince a design
> team, and the rest of us probably want to see it anyway.

Okay. I'll give a shot at describing it. It is a little rough around the
edges and probably heavily flawed in some points. This design stems from
my current project (MoleMUD, which I'll probably abandon/port if this
comes to anything) and has taken form over a few months time with a lot of
input from the list.

 - Implementation language is C++.

 - Design and analysis performed using OO A & D methods and notation.
Use-cases, design patterns and UML strikes me as suitable (mainly because
I'm reading a UML book right now :) Use-cases are especially useful when
trying to come up with an adequate interface/mechanism for inter-module
communication. I strongly recommend we use this even if we don't go for an
O-O approach (I'm not talking Rational Rose here, plain pencil and paper
has always worked fine for me). 

 - Low-level core consists of a few basic primitives which are shared
among virtually all types game servers:
	event manager - handles events (duh!)
	module manager - loads/unloads modules
	inter-module communication manager

 - The core defines a few very basic skeleton classes for redefinition in
modules using external inheritance.
	Event (Execute(), IsRipe() methods, for example)
	Module (Connect(), Update(), HandleRequest(), Disconnect())

 - Modules are, in fact, object instances of an externally inherited
Module subclass. That is, when a shared lib is loaded by the module
manager, it calls a factory function in the lib and gets a pointer to a
Module object (which, in reality, is a subclassed Module object, such as
class MagicModule). The module is provided with context by passing an
instance of a Core class to it (which contains methods for using the event
manager, the inter-module communication mechanism and module management).

 - Events, which are created by modules and passed to the event manager's
scheduler, are externally inherited versions of the original Event class.
This allows the event manager to treat them as Events, but to exhibit
their own behavior when Event::Execute() is called.

 - Modules are boot-strapped by file name (from .devmudrc or whatever),
and more may be added by sending signals or using in-game commands (and
some kind of remote administration, but that's all contained in the
modules).

 - Inter-module communication is carried out using a decoupled mechanism
(cf Gamora Buses). IOW, modules do *not* know of each other at the
beginning, but broadcasts their presence on a server-wide channel.
Interested modules may create pipes or channels to the new module and use
this for message passing. Pipes may be implemented in terms of a C++
class (neatest), function pointers (most efficient), or network sockets
(for distributed systems). Possibly, all three could be supported.

 - Messages passed between modules are serialized according to a
specification provided by the receiving module. That is, the magic module
might say: "I first want a byte containing the spell code, then an int for
the level of the caster, then a DB index for the target and caster." The
parser module would follow this format when passing messages to the magic
module. 

I'm not gonna go further up in the hierarchy than that, since this is the
design I'm most interested in :) The lib, module sets and world I leave to
others, at least for the time being (I'm still thinking about a graphical
MUD using the Golgotha renderer...)

> 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