Jump to content

  • Log In with Google      Sign In   
  • Create Account


Proper way for server to save world data while active?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 belgreth   Members   -  Reputation: 132

Like
0Likes
Like

Posted 30 September 2012 - 10:53 AM

I'm not too sure how to go about this. I'd like to have the server save the game world and client data every so often but how would I do this while server is running and clients are connected to the server? Currently everything is saved in binary which I hope to keep doing. The world file + clients is roughly 160mb currently.

I'd rather try to spin off a thread to slowly save everything instead of stopping everything for a few seconds for it to do its thing, however I'm not sure if that's the best way or how I can do this without adding locks around every code that changes client/world data. Any tips?

Sponsor:

#2 hplus0603   Moderators   -  Reputation: 5187

Like
1Likes
Like

Posted 30 September 2012 - 12:23 PM

On UNIX, you can use fork() to spin off a "fixed" copy of whatever is in memory right now.

However, it sounds like you don't have the right data structures. The "modifiable" state of a world is unlikely to be 160 MB. Most games define "world data" as immutable state that doesn't need to get saved, plus mutable state for what the players can change. In addition, most MMO games will save all mutable state by each player, rather than in the world, which is why players can't affect the world like dig tunnels or cut trees etc. For games that allow the world to be mutated (Eve Online?) those games will still keep the amount of modifiable world state small, and sliced into sections (by system, by zone, etc.)

With this approach, the amount of data you need to save at any one time should be small, and can be done by collecting what you need into a memory buffer and doing an asynchronous write on that memory.

The main danger when saving players is one of item duplication and similar race conditions. For example, let's say my character is saved, then I trade a Flaming Sword of Fire to you, and then you are saved, and then the server crashes before it can save me again -- now there's an item duplication. Thus, things that matter for the economy (like trades) are typically implemented on a transaction-based database.

enum Bool { True, False, FileNotFound };

#3 belgreth   Members   -  Reputation: 132

Like
0Likes
Like

Posted 30 September 2012 - 01:06 PM

Hm, writing to a MemoryStream then sending that off sounds like a solution, thanks hplus.

As far as world data, it's split into cells and players can change most aspects of it so I have to save everything, at least the active cells.

You bring up a good point about item duplication...but I'm not at that hurdle yet. My server/client is small scale (think minecraft). It's aimed for 2-8+ people to play together in a persistent world. I'm trying to stay away from having to deal with databases like mySQL as I'm mostly illiterate in that area. If I can just keep everything saved in binary, that would be ideal.

#4 hplus0603   Moderators   -  Reputation: 5187

Like
0Likes
Like

Posted 30 September 2012 - 08:24 PM

players can change most aspects of it


Well, now you're starting to see why most games don't actually let you do that :-)

Those that do (such as Minecraft) design their worlds to be compactly and efficiently representable, because a new player entering the world needs to receive all the data needed to describe that part of the world before he/she can play.

enum Bool { True, False, FileNotFound };

#5 FlyingDutchman   Members   -  Reputation: 207

Like
0Likes
Like

Posted 22 October 2012 - 01:11 PM

On UNIX, you can use fork() to spin off a "fixed" copy of whatever is in memory right now.

However, it sounds like you don't have the right data structures. The "modifiable" state of a world is unlikely to be 160 MB. Most games define "world data" as immutable state that doesn't need to get saved, plus mutable state for what the players can change. In addition, most MMO games will save all mutable state by each player, rather than in the world, which is why players can't affect the world like dig tunnels or cut trees etc. For games that allow the world to be mutated (Eve Online?) those games will still keep the amount of modifiable world state small, and sliced into sections (by system, by zone, etc.)

With this approach, the amount of data you need to save at any one time should be small, and can be done by collecting what you need into a memory buffer and doing an asynchronous write on that memory.

The main danger when saving players is one of item duplication and similar race conditions. For example, let's say my character is saved, then I trade a Flaming Sword of Fire to you, and then you are saved, and then the server crashes before it can save me again -- now there's an item duplication. Thus, things that matter for the economy (like trades) are typically implemented on a transaction-based database.


Thats what Ultima Online actually day. Once an hour nobody could cross server boundaries, they forked all servers, wrote the whole RAM on disk and releases the boundaries. I had to laugh when i read it because i remember too good the in game messages but didnt know back then what they were actually doing. :-)

I open sourced my C++/iOS OpenGL 2D RPG engine :-)


See my blog: (Tutorials and GameDev)

http://howtomakeitin....wordpress.com/


#6 Rasterman   Members   -  Reputation: 206

Like
0Likes
Like

Posted 29 October 2012 - 02:19 PM

160MB isn't that much, just copy the memory, spin off a thread and write it to disk. worst case display 'saving world' to the players, if there are only 8 and it only takes a few seconds then no big deal. another option is to slowly copy all data to disk, tracking all changes after you started, then at the end apply all those changes together to the disk image, this is probably going to be a lot slower than just writing the whole file, but it won't use any memory.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS