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

[J C Lawrence]

On Sat, 21 Mar 1998 21:52:10 PST8PDT 
Ben Greear<greear at cyberhighway.net> wrote:

> I'm contemplating a space based game, where once started, it will
> never again resemble it's starting state (unless the starting world
> image is saved of course.)  It will be written in Java.

ie the sort of persistant would which is commonly discussed on this
list.

> The game will need to update it's persistant storage very often to
> make this feasible.

There are several possible models:

  Periodic backups of the DB state (eg once a day the entire game
state is written to disk, allowing the old state file to be made into
a backup)

  Periodic checkpoints to update the DB to current state (eg every 10
minutes the DB is updated with the current state)

  Continuous updating of the DB (write-through).

Plus all the combinational flavours of the above and the forms of the
above.

I've done all of these at various times.  Its worth noting that almost
the entire Tiny-* and MOO clan (into which latter camp fall Cold,
Cool, and Interlude) use one of the first two forms (Yes Brandon/Miro,
I know that's a little sloppy for Cold).

Write-through is expensive purely duie to bandwidth and disk latency
concerns.  Yet, its essentially what I am working on now.

> In my current game, I use ascii based flat files.  I don't think
> this will work so well for the space game.

It could be done, but it would pose problems.

> The two things I'm pondering now are binary flat files (one per
> object, a collection of objects?? I dunno) or a database.

File IO is your biggest killer.  File opens are incredibly expensive.
File closes aren't far behind.  Minimise them.

Pretty well everything that has inherited from Marcus' Ranum's UberMUD 
(eg all the Tiny-* clan) devolves to a DB with a text processing front 
end.  Its a highly successful model with thousands of them out there
running large complex worlds (cf LambdaMOO's Rube Goldberg machine).  

That said the choice of a DB as a backing store for a MUD world is not
automatic.  Its easy to argue against it.  Ever server model I've
worked on prior to now has used a DB (initially homegrown, more
recently based on tdbm, YOODA and LINCKS).  Currently I'm using a
persistant store-type approach (cf Arjuna, Texas Persistant Store,
Persist++, ObjectStore) as it promises to be a lot lighter weight and
much less design-invasive than the classical DB approach.

See the Free DB list at http://solar.flare.net/FreeDB/ for other
possibilities.

> I'm a little concerned about the performance hit on a DB, as I
> expect this game server to bring a machine to it's knees anyway...

No need.  Well written (!) disk-backed MUD servers can (often/usually
do) out-perform in-RAM MUD servers due to decreased page fault rate.
Marcus Ranum demonstrated this rather conclusively years ago with Uber
and Unter.  Cold continues to demonstrate this point.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...