[MUD-Dev] Re: PDMud thread summary

[Niklas Elmqvist]

On Thu, 22 Oct 1998, Jon Leonard wrote:

> There's been enough discussion about collaboration on a MUD a that it's
> starting to get tricky to follow, so I thought I'd try to provide a summary.

Good initiative! This thread was becoming hard to follow. Oh, and I must
say that to me, this thread has easily been the most interesting on the
list since I joined (which you could probably tell by the frequency of my
earlier posts as compared to now). The way I see it, PDMud should just
about cater to anyone on this list, be they interested in game or social
issues, to more low-level development aspects, design viewpoints, and so
on. This is a many-faceted project where anyone with spare time could
contribute in their field of interest/knowledge.

[Structure:]
> It should be a collection of mix and match modules, reconfigurable
> even at runtime via dynamic linking.  Many of the pieces should
> behave like pieces of an OS.
> 
> This allows for lots of flexibility for individual MUDs, understandable
> pieces, and answering the question "Do we hardcode or softcode this?"
> with "Both".

The dynamically loaded modules allow us to get kind of a softcode (since
it can be added and removed to the server at run-time) but still with the
efficiency and speed of native code. I still like to keep the distinction
between the internal MUD language which is used for world/quest/puzzle
programming and the implementation language which is used to create the
modules (native code).  This allows us to delimit the compiler design
project (building a production-quality native compiler is a *lot* of work)
and tailor the MUD language towards game-specific stuff (which also would
make it easier for non-programmers to grasp). Is this something we can
agree on? Anyone not in favor?

> Possible modules so far:
> 
> Bootstrap (module handler)  
> Database storage/persistence (relational or Object Oriented)
> Telnet server
> Client/server messaging (for sophisticated clients than telnet)
> Client graphics control
> Magic system
> Movement
> Rooms & objects manager
> Coordinate based location
> Spatial data structures
> on-line building
> Event manager
> Command Parser
> Command Executor

Another valid question: Is the driver just a bare skeleton? That is, will
all functionality be dynamically loaded via the modules? 

IMHO, the driver should consist of a few primitives which provide the
minimal functionality of any game server. One such thing is an event
manager (c'mon! almost all games need one), a message hub/system/chain
another, the module manager a third. Comments, please. 

> Project home(s), project maintainer(s):
> 
> I'm volunteering to be project maintainer, keeping track of source code,
> releases and so forth.  If someone else wants to, thats fine too.

Fine by me. This is one project which might become huge in scope. (Just a
warning :)

A tentative attempt at work division:
 a) Driver/Core/Server: the base core, specifications, design,
	protocols, inter-module communication, etc. The foundation, in
	other words.
 b) Modules: language VMs, DB handlers, on-line building, etc
 c) Lib: world, quests, puzzles, mobs, etc

Everything below item a) should be designed to be "easily" replacable to
make a wholly different kind of game, meaning the driver should be
flexible enough to support *any* kind of game, from a high fantasy
text-based MUD to a cyberpunk 3D graphics MMPOG. The flavor and behavior
of the MUD should reside in the modules. That is, the driver should serve
as an OS upon which several programs (modules) can be built to constitute
a whole system (world). The driver does not necessarily need to consist of
a lot of code (actually, maybe it should contain as little and be as tight
as possible to improve efficiency, etc?), but must be extremely carefully
designed.  Most of the work is done by the modules, though.

Needless to say, development of these areas cannot start at the same time.
The inter-module communication and standard calling conventions must be
resolved before anyone can start building modules, for example.

If this is something we can use as a starting point, allow me to
immediately register my interest in the a) area (with the option of
getting on b later on). I'm especially thrilled about the design of a
flexible system like this. 

> 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