[MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Ben Greear]

On Mon, 30 Mar 1998, Orion Henry wrote:

> This is where you can have a little fun.  These records are people...
> places.. things... whatever you need to use for your mud.  Each contains
> references (unique ID's, not pointers) to other records.  Lets say that the
> back end process ( the one that holds the "snapshot" ) holds a huge number
> of records and the ones it dosnet have RAM for (if you dont have enough)
> are written to disk.  Your front end process (the MUD) holds less, say
> MAX_RECORDS.  Each time a refrence is dereferenced it checks the local
> cache and if its not there its requests it from the back end process.  When
> the number of local records exceeds MAX_RECORDS it drops the oldes ones (
> LRU or Clock algorithms will do nicely).  Now dont panic... I see the
> problems with this too.  There's more.
> 
> 1) Whenever a record's reference is dereferenced, the front end process
> fetches all the recrods associated with it... Thus, when you dereference
> Boffo the Half-Troll you also bring over his moth eaten shirt.  His deadly
> tree branch.  His manky underwear and the room he's in.  (because you will
> proboly reference all of this very shorty after looking at Boffo) This way
> when you make a reference its (probobly) always there...  
> 
> 2) Whenever a record is changed it is marked as dirty and schedueled for
> upload back to the back end... otherwise its just forgotten when it falls
> off the LRU list.

This model would work fine for a MUD, but my game will have every object
in motion of some kind.  I'm using F=MA, and all the fun that goes with
it, including a partial gravity computation (I'll re-compute every now and
then, and adjust orbits accordingly.)

Basically, with the AI, the game should remain at almost constant levels
of computation/action, regardless of the number of ppl logged on.  Of
course, many things will be just estimated, for example, a battle between
two AI clans won't do a lot of the details if no one is watching...but
the end results should be about the same.

> Sockets and pipes would work well for this but (I'm not sure) but I think
> that unix messages will be very fast for this implimentation.

I'm using Java, so probably going to use sockets, as that seems to be
the least common denominator across platforms.  The DB itself will just
be an object I instantiate in the server program...(and clients too I
guess.)

Thanks for the input,
Ben


Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444
http://www.primenet.com/~greear/ScryMUD/scry.html