Incorporating Map Changes Into The World Save

[Praxiiz]

I'm building a system that allows the client maps to be altered while the game is running. The major obstacles in the client are out of the way now and I am starting to look at how to implement the system on the server end.

It occurred to me today that if a server using the system had to rollback a world save for some reason, I need a way to synchronize the maps to that world save. Does anyone have a guess on how big of a performance hit the world save would take if I simply made a copy of the current maps / statics files and backed them up along with the world save?

Also, should I only send out client updates when a client enters part of the map where there is a change, or should I send out all changes to all the clients when the changes are made? Should I synchronize the clients when they connect or try to transfer it in the background?

 

[floppydisc]

Regarding your last question(s):

The system I was thinking about in regards to CentrED would use checksums. Each block (the combination of a map block and statics block) would be hashed into a simple 4 byte hash. A client cashes all blocks it knows. If you connect to the game, you request the hashes of the surrounding blocks (that you want to show/render). If some are missing or the checksum differs, request the whole block and update the local map/statics cache.
The client also requests updates for surrounding blocks. The amount of "subscribed" blocks should be limited by the server - I think 64 or 128 should be a good amount. Whenever a block changes serverside, all subscribed clients will get the new block. The subscription should only be handled server side: whenever a client requests a block-hash, it obviously needs to render it --> add a subscription. If there already is a subscription to that block (from that client), move it to the front of the queue. If the maximum of subcriptions is reached while adding a new one, delete the last one. Therefore I suggest a linked list as ring buffer/queue here.

 

[conan-hybrid]

i wonder how minecraft does it..

 

[Jeff]

Minecraft is a series of amazing algorithms and complete compression...

 

[Praxiiz]

The system I was thinking about in regards to CentrED would use checksums. Each block (the combination of a map block and statics block) would be hashed into a simple 4 byte hash. A client cashes all blocks it knows. If you connect to the game, you request the hashes of the surrounding blocks (that you want to show/render). If some are missing or the checksum differs, request the whole block and update the local map/statics cache.
The client also requests updates for surrounding blocks. The amount of "subscribed" blocks should be limited by the server - I think 64 or 128 should be a good amount. Whenever a block changes serverside, all subscribed clients will get the new block. The subscription should only be handled server side: whenever a client requests a block-hash, it obviously needs to render it --> add a subscription. If there already is a subscription to that block (from that client), move it to the front of the queue. If the maximum of subcriptions is reached while adding a new one, delete the last one. Therefore I suggest a linked list as ring buffer/queue here.

A publisher/subscriber pattern does make sense. The hashing makes sense too. I think what you have posted will be a good approach to my second set of questions. Thank you.

As for the first part (synchronizing the maps with the world saves), does anyone know of a good strategy that would work similar to SVN? I.E. some way to track/save changes to a set of base maps that could be rebuilt on a world load.