[MUD-Dev] Re: PDMud thread summary

Adam J. Thornton adam at phoenix.Princeton.EDU
Thu Oct 22 12:30:21 New Zealand Daylight Time 1998


On Thu, Oct 22, 1998 at 02:04:00PM +0200, Niklas Elmqvist wrote:
> 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. 

So a) should basically be the specification of the client-server protocol
and the connection manager, right?  This would be the layer that specifies
how player connections talk to the central server--which can then
distribute those connections as it sees fit, or handle them all itself?  I
guess you'd also need authentication of connections and encryption routines
to also be hooked into this layer, although they can be implemented as
higher-level drop-ins.  That is, this layer needs to have an API it calls
to decode the bytestream before passing it on to the engines that sit at
level b).  Actually, I suppose you could just pass the raw bytestream up to
b.  But you would need to make sure that the connection was allowable via
some sort of authentication down here.

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

I've got some thoughts and some working but currently really ugly code for
a multithreaded/multiprocess design at level a).

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman




More information about the MUD-Dev mailing list