[MUD-Dev] Introduction

[clawrenc at cup.hp.com]

In <Pine.SOL.3.95.970512072116.12466B-100000 at sun-cc203>, on 05/12/97 
   at 07:54 AM, Ling <K.L.Lo-94 at student.lut.ac.uk> said:

>On Sun, 11 May 1997, Dan Root wrote:

>> The other two code bases I was primarily interested in (UnterMUD and
>> UberMUD) were quite small as well, with most of the features I wanted,
>> but with quirky coding (MJR's code is beautiful... if you can
>> understand it) that made modifaction hard.

>Even more code bases I've not heard of, and I thought I knew most of
>the ones around.

There are a lot of older/unknown codebases about.  See the MUD FAQ in
r.g.m.announce for some details.  Another good source is whassisnames
MUD tree.  (URL at home)  He's got most everything from the IOWA
project games (Mirrorworld, Gods, etc), thru Uber, Under, Interlude,
Cool, Cold, ColdX, Yama, OxMud, etc.

>> > Disk based.
>> 
>> Definitely.  My initial code does everything from disk, no objects are
>> kept in memory for more than a single 'cycle' of the server.
>> Eventually I'll add some more intelligent caching, but my machine has
>> lots of memory which makes for a wonderful buffer cache right now. :)

>What's a cycle?  When I mean disk based, I was thinking along the
>lines of how present LPs work, load in object, hang around in memory
>until swapped out due to lack of activity (including everyone leaving
>an area) or destroyed.  Basically, I don't know of another method of
>doing it.  I wanna keep the ability in LPs to play around objects
>whilst online and crash the place. :)

Blech.  I have never liked the LP-ish trick of swapping out or
de-activating portions of the game on the pretense that they are not
active, are uninhabited etc.  (Yeah, I know Nathan does this for good
reason, but he has a rather unique model there (he calculates what
*would* have happened in the area when he re-activates)).

In my case it comes down to my basic model.  For me everything is an
object.  There are no master objects, or global objects, just objects. 
Objects are stored individually in a database (cf Tiny-*, MOO, ColdX). 
As objects are required by the game I read them in from the DB.  As
they are changed, or no longer needed by the game I write them back
out to the DB.

To maintain performance, as this constant reading and writing can be a
severe bottleneck, I have a thick cacheing layer between the server
and the DB.  The goal is to have as many requests as possible
satisfied by objects already loaded into the cache, and to minimise
writes to the DB.

A side benefit of this model is that you can more or less pull the
plug on your system at any instant, and then later restart it to have
it resume exactly where you left off.  Note: This does depend on how
you maintain your internal server state visavis your DB etc, and theu
our recent conversations on DB design, object IDs, DB transactions,
rollbacks etc.

Note also that under this DB model there really is no concept of an
area, or an area file any more.  They're all just objects in the DB. 
You can define an area if you wish.  Its pretty simple: say all
objects with an attribute set to AREA_BLACK_MARSH or some such
(actually I use containment here, not atttribute values, but that's
another thing).  

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...