jMonkeyEngine.org

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

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.

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.

@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.

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:

http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

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.