I have a few ideas about how I would like to do this, and planned appropriately when developing the core of the game. However, before I start to tackle this aspect (or what is left to do on it), I wanted to run this by smarter people than me and get a consensus on the best approach (more than likely, one I haven’t thought of yet).
All entities in the game consist of collections of Serializable objects… minus the actions/refresh timers… which have a save state. All action/refresh timers exist independently of their counterparts on both client machines and the server, leaving the notification of timer states to the server to manage.
On to the question…
Should I be saving game objects directly to a directory structure that exists somewhere on a server dedicated to data storage?
Should I be saving game objects directly to a database?
Should I be doing both?
Is their a benefit to storing just save state info and recreating objects on client load? This could get interesting… but it is doable, of course.
Are their any known data corruption issues when writing/reading Serializable objects in Java that go beyond normal expectations/precautions that anyone is aware of?
Yeah… open to personal opinions/likes/dislikes. But… that’s what I am looking for!
Me
I added a SaveGame tool that can save any Savable (Spatial etc.) in a location in the home folder of the user. Theres a test example for it as well however the version in stable is currently only meant for small amounts of data and is not compatible to the one in svn (you cannot load games saved with one version with the other). If you look at the code of SaveGame.java in svn you can see what it actually does.
Also, not sure what this has to do with networking. Just in case it comes up, you should definitely NOT use SpiderMonkey’s serializer for long term storage.
I guess I should have mentioned that this is not SpiderMonkey… it’s a a roll-your-own solution. The reason I chose networking is that it does have to do with a server/client based-game. Just looking for brilliant ideas from brilliant people.
With a database like hypersqldb you can kind of get the best of both worlds. An aggressively cached in process database will act very much like an in-memory DB until you get too large to fit into RAM. There are even table modes in hsql that support always loading the table into RAM.
Edit: Still, this doesn’t really have anything to do with networking. 
I bet your game will have a GUI also but you didn’t post it there. No harm done, though.
If the post needs to be moved, I’m not overly concerned about where it ends up. Is there a more appropriate forum for this? General maybe? I assumed networking, seeing as Serializable objects are for the specific purpose for transporting objects over a stream (including… and more so… specifically in my case… networking streams).
And thanks! I’ll take a look at hypersqldb. Are you saying dB storage is the way to go exclusively? Or?
@t0neg0d said:
If the post needs to be moved, I'm not overly concerned about where it ends up. Is there a more appropriate forum for this? General maybe? I assumed networking, seeing as Serializable objects are for the specific purpose for transporting objects over a stream (including... and more so... specifically in my case... networking streams).
It's fine. I was just busting your chops a little. :) Still, don't be fooled... the requirements of a network stream for a game are entirely different than those of long term persistence. For networking, you want the data as absolutely tight as possible because you almost always want to send more state than the connection will allow. For persistence, the most important thing is that today's data be readable tomorrow, the next day, next year, and so on.
@t0neg0d said:
And thanks! I'll take a look at hypersqldb. Are you saying dB storage is the way to go exclusively? Or?
It depends on how much data. You were asking about potentially doing something in memory or using a database. With hypersqldb you can do both since most of the database is in memory.
Without knowing more specifics about your needs, I can't really comment further. Mythruna uses binary files for the world terrain data, a simple JSON database for player data, and an SQL database for nearly everything else.
@pspeed said:
It depends on how much data. You were asking about potentially doing something in memory or using a database. With hypersqldb you can do both since most of the database is in memory.
Ooops... must have misspoke myself. not in RAM, if that's what you mean. I meant to flat-files.
I'm assuming that player information will be saved on a timed basis... or when something significant happens.
World or (in my case) zone specific items, that need to be persistent (i.e. not native to the area), would be saved/removed as created or destroyed.
I'm trying to figure out whether or not to use a database for global snapshot storage and perhaps flat-files as a mainstay for changing information. If I use a dB for snapshots, I can localize data import to the database alone, and just keep direct communication via the server out of the picture all together. The only drawback here (that I see right away) is ensuring data integrity prior to taking a "snapshot"... One of the benefits to this approach is, the dB schema can be completely open-ended, not really caring what the data is related to, seeing as the only time data will be extracted, is when a storage server server (and any/all backup storage servers) crash happens (to the point of corrupting all data).
Loading data may take a bit of a performance hit, but I'm only reading back in player specific data on a consistent basis as they log in/choose a character.
I'm not trying to take up anyone's time with this, I really am trying to bounce ideas off of other people before just blindly choosing a direction and assuming that I am doing the right thing.
Yeah, these days I tend to skew towards “entity systems”. And in that case there is no real distinction between “in memory” and “in database”. You get the data when you need it and don’t care how it got in your hands.
If you are curious about that you can read this set of articles:
Entity Systems are the future of MMOG development – Part 1 – T-machine.org
If you aren’t familiar with entity systems then it will be quite confusing… it’s important to read the comments and follow-on material.
That is the technique one would use to create fully scalable servers, though.