Persistent databases play an important role in an MMOG.

Just fooling around at this point. Probably need to do more work on distributed modelling architecture to help most of this along.

Data that needs to be stored:

; Passive objects: Astrophysical objects such as suns, planets, and asteroids, and perhaps also large artificial structures, are relatviely passive. This is not to say that they do not continually move in some way, but the simulation can be constrained in such a fashion that their movements are predictable and relatively simple. The initial states and parameters governing motion and position do not change; storing such data in a database is necessary only if that is an appropriate way to retrieve the data. This data can likely be replicated at each game node (server or client) that needs it, reducing network traffic.

Istvan Depending on the scope of the game, I'm still prepared to advocate modelling passive object motions using nothing more than stored orbital parameters, which depending on your chosen notation would condense to an array of something like five or six floating-point numbers. This obviously is easiest if we're only simulating one solar system at a time - but you've pointed out a 'branching' storage approach may rectify this in some way. Other simplistic parameters must include mass and radius, with one or more parameters identifying an appropriate graphic map (or more complex generation algorithm to use - but no way in heck am I going so far as to suggest we do simulated fluid dynamics to cough up visible atmospheric phenomena). I'm assuming that all object parameters would be stored in a central "universe" data structure, from which systemwide data would be squirted to the client on system arrival. System state would thus be a result of orbital parameters and time only. ; Active object parameters: Active objects, both physical (ships) and conceptual (players, organizations) have various defining parameters that change over time. Inevitably some state information will be volatile, but should be 'checkpointed' to a database as often as can be tolerated. The distributed system will lease ownership of objects to nodes; such leases must be recorded. Updates to persistent data will usually only be allowed by leaseholders (but also by administrative tools, of course).

Is there a single central database? Distribution of data is a possibility, but would make things much more complex.

Technology

PostgreSQL is Open Source and has a good reputation for reliability and speed. Portable to NT and Linux. (Are Win9x clients a target platform at all? I hope not, given our likely development timeframe.) No distributed database features that I know of.

DWM March 2002: A year or so ago I looked into Borland's Interbase DBMS, which had just recently gone Open Source. One offputting aspect of this system was some ongoing confusion over Borland/Inprise's plans regarding Open Source; the OS community was not pleased with some of the licensing games being played. I just noticed that a stable release of an independent, purely-OS version of Interbase is now available, named [Firebird]. Looks very interesting. Features are similar to PostgreSQL, possibly even more advanced. There are two versions, one file-based, the other client/server. Unlike PostgreSQL, Firebird is embeddable in applications. (I don't know if this is true of both versions, however.) Like PostgreSQL, the Windows NT line is explicitly supported, but probably not the Win9x line.