Savegame technical suggestions

[quinor]

Discission on IRC has lead us to some ideas about optimising game saving and autosaves:

1) Use copy-on-write to "duplicate" game state and then use this copy while saving (on another thread); it may enable autosaves without pausing the game

2) Add "disable replay" option in order to lower savegame size

I hope it helps.

[hoho]

Using copy-on-write for the game state would also make it easier to rewrite the game logic itself in multithreaded way.

[Ohz]

I was about to write a topic about.

Without replay, the savegame lost half of his size. When you play multiplayer on giant map after 20 hours of game, and experience some desync, sharing the map again and again can take the whole evening...

[ssilk]

Technically a snapshot is needed. Cause a save can represent a game only after one tick.

A copy-on-write would mean, that the game copies all chunks in one tick, then doing the save with the copy. While saving, it continues the game. With large maps, that copy will take a while.

Snapshot can work so: at time x all chunks cannot be modified anymore, only read access is possible. The save routine saves all chunks and some more, while the game engine continues. If a chunk then needs to be modified, it is copied first, then modified.
After save, the modified chunks are moved back over the old.

(In practice a lot more complicated)

[quinor]

What I meant is when you change game state, you apply these changes to two game state copies - current and "savegame" one. When you want to save the game, you stop applying more changes to "savegame" (instead queue them somewhere), save the game from "savegame" state copy (of course parallelly) and then apply all queued changes. It should be decently fast and allow 90% non-freeze savegame, maybye with slight FPS loss.

[starholme]

Disabled replay would be simple to add I think, and for most games it would be fine.

The copy on write stuff is fairly complex. Even the 'two copies' is more complex than you might expect, and requires a possibly significant amount of extra ram for the second copy. You also double the amount of time it takes to update the changes each tick(you only calculate once, but you need to update two copies now), because it needs to be done in both places.

[quinor]

I know the technical diffucities, but as far as I know only about ~20mb of ram is the game state itself and it's not that much. Also, write time is not very significant on UPS (belt and inserter updates are many times that), so copy-on-write shouldn't be significant on game performance. Only thing I'd consider is developer time it'd take to implement that, it's true it may take quite long.

[immibis]

Technically a snapshot is needed. Cause a save can represent a game only after one tick.

A copy-on-write would mean, that the game copies all chunks in one tick, then doing the save with the copy. While saving, it continues the game. With large maps, that copy will take a while.

Snapshot can work so: at time x all chunks cannot be modified anymore, only read access is possible. The save routine saves all chunks and some more, while the game engine continues. If a chunk then needs to be modified, it is copied first, then modified.
After save, the modified chunks are moved back over the old.

Um, that is copy-on-write.

[bobingabout]

I suppose one technical difficulty with the "copy-on-write" thing is you may still need to pause the game to perform the RAM copy so that it can compress it into a savegame in a thread afterwards.

[Tr1cKy]

Potentially super technical now - but basically btrfs and zfs filesystems work *very* efficiently doing copy-on-write on *everything*. It can be done efficiently. That doesn't mean it is easy though. :-/