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

[Ben Greear]

On Sun, 22 Mar 1998, Matt Chatterley wrote:

> On Sat, 21 Mar 1998, Ben Greear 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.
> 
> Well, this sounds intruiging. I've also been wanting to write a server in
> Java to see how well its object-orientated model maps to the purpose (very
> well I should imagine, particularly if any 'on-line' coding can also be
> done in Java - although it sounds like you will not have anything of
> this sort). Actually this project sounds like one of the popular
> 'strategy' or 'warfare' type games, and very interesting indeed.

It will indeed be strategy/warfare game.  It will be up to the players
to decide the atmosphere though..I will just build a universe for
them to play in :)

>  
> > 
> > The game will need to update it's persistant storage very often
> > to make this feasible. 
> 
> Yeah, I can imagine. This is going to be your main problem, I think. :)

Yep, I've got the rest mapped out pretty well, but I just can't get
a happy answer for the persistant storage...

>  
> > In my current game, I use ascii based flat files.  I don't think
> > this will work so well for the space game.
> 
> I doubt it. You could end up with very large files, plus, I find that
> ASCII is awkward to work with when loading in data on a large scale. An
> advantage is that if the file layout is predictable and constant, you can
> update bits easily in java (RandomAccessFile).

There will be much data.  I'll need to do updates very often, and
considering the dynamic nature of the game, I will almost have to do
a complete write, all at once, in order to make sure the state is
sane.  (Consider a ship moving between two quadrants, write one quadrant,
move ship, write the other...now we are all hosed up!)

The other idea would be to write on every change, and just write what
changed.  If this was done by another thread, and cached decently..it
might work...  The problem then becomes one of mapping data into files,
which I absolutely fear :P


> The former depends on the design structure of the server - if you can
> sanely order it into a series of binary files and it won't be too
> inconvenient to work with them, maybe, otherwise a database might be a
> good move. I think your own binary files or ASCII files would be the best
> bet (perhaps ASCII if it were kept compressed, since the amount of data
> should be large).

I'd wrather deal with binary than compressed stuff.  The objects will
have to be able to migrate between servers (each server will encompass one
solar system, and hopefully there will be many solar systems linked
through sockets, either on one machine, a cluster of work stations, or
indeed, across the net..).  The point of this last sentence is that
I will have to make it write binary to a stream anyway...

> A point to remember: Have the game *constantly* saving *small* amounts of
> data. Don't attempt to do what bases like PennMUSH do and dump a large
> amount of data at a regular interval - this causes quite a few problems
> (or rather, will if you are saving more than a few megabytes).

There are problems with both to be sure...


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