Introduction

Dan Root dar at thekeep.org
Sun May 11 12:55:51 CEST 1997


<waves>

Dan Root here, and like Oliver Jowett, I offered to set up a design
list during the rgm.* reorganization debates the past couple weeks. At
least until I was told that this list already existed. :)

I've primarily been a MUSH player and admin for the past two years,
having run a small, but moderately successful, social/RP Mux for about
9 months before hardware failures killed the machine.  It was during
this time that I started into mud design, making slight modifications
to the Mux codebase to make it more internally secure (mostly a couple
of new locks and some flags relating to privacy).

When the machine came back up I decided not to put the Mux up
immeadiately, but instead look at the options for what variety of
server to run.  I had been less than impressed with the performance
and expandability of the MUSH-derivatives from within, so I went
looking for something better.  Unfortunately all I found were old
abandoned projects and new, unfinished projects.  Nothing I found
quite fit my needs.  (ColdX and Muq both came close, but I wanted a
mud, not a generic network server, MOO was okay, but horribly coded
and not that great performance-wise).  I considered CoolMUD, SMUG,
UnterMUD, and UberMUD as well, but all of those were lacking some set
of features I really wanted.

So, figuring I'm a decent enough coder, I'll write my own.  My
goals are probably a little ambitious, but I'm hoping to see the
following:

A small footprint in memory (under 300k for the binary, plus object
and attribute caches for a total on the order of 1.5M resident in a
medium sized database).

A "mechanism not policy" setup, such that all the rules about the
'game' are kept internal to the database as opposed to hardcoded into
the server/driver.  By extension, an internal language that's
powerful and efficient enough to code the game rules and secure
enough for day to day use.

A *small* codebase (ideally also under 300k) that's well documented
and cleanly coded such that it's easy to extend if necessary.


At this point I've finished most of my db layer, and a good portion of
my networking code.  Now I just need to design and implement the
internal language.  (I'm leaning towards a Forth/MUF-like stack-based
language at this point)


	-DaR
--
Dan Root - dar at thekeep.org



More information about the mud-dev-archive mailing list