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

[Matt Chatterley]

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.
 
> 
> 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. :)
 
> 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).
 
> The two things I'm pondering now are binary flat files (one per object,
> a collection of objects?? I dunno) or a database.

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'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...
>
> I'd be interested to hear any suggestions you might have.. 

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).
 
> Also, as a java server, I don't think I can do a select on incomming
> data.  I think a thread for every player is a bit much...any suggestions
> here?

You're going to need one ServerSocket per player, aren't you?

If I am correct in this assumption, there is no problem - you can use one
thread to read from them, identifying connections by the socket they are
connected to.

If not, you can either use one thread/socket, and require a custom client,
which attaches an identifier to data sent (possibly using something like
DataGramPacket, where one part of the packet is the identifier), or just
use one thread per player - this doesn't seem overly excessive to me. :)

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html