Currently the game only saves when it terminates properly. If the game crashes you loose all your work of your current game session.
My goal is to change this by making the game save continously, so that you loose only the very recent work when the game does indeed crash. This also helps with memory consumtion, as currently unloaded chunks only get compressed. Once they get saved, their memory can be reused.
This is my current progress:
When a certain amout of time has passed since the last save, or when a certain number of chunks have been unloaded then the game triggers an auto save automatically.
The saving gets currently done in two phases:
If you are curious on how it looks code wise, you can have a look at my autosave branch:
https://github.com/flo/Terasology/commits/autosave
It is theoretically possible to reduce the time on the main thread further, but it's tricky to get right.
Once concept I am thinking about is to have the game fill two lists as entties get modified and deleted:
The change delta gets then applied to a copy of all persistent entties which is private to the saving thread.
Thus no entities need to be copied or encoded in phase 1. All that needs to be done for entities in phase 1 would then be the swapping of two lists which takes as good as no time.
There are a few details to it that makes it a bit tricky, but if the save pauses turn up to be annoying that might be a good way to solve them.
My goal is to change this by making the game save continously, so that you loose only the very recent work when the game does indeed crash. This also helps with memory consumtion, as currently unloaded chunks only get compressed. Once they get saved, their memory can be reused.
This is my current progress:
When a certain amout of time has passed since the last save, or when a certain number of chunks have been unloaded then the game triggers an auto save automatically.
The saving gets currently done in two phases:
- Phase 1: On the main thread a memory snapshot of the current game gets taken. This ensures that the game state is consistent and that it can not happen that the ongoing game confuses the save process. In order to reduce the memory usage for doing so, the chunk data does not get duplicated. Instead it gets flagged as "needs to be copied before write" until the save process is completly done. Then this virtual flag gets reverted and if there were no changes during the save no extra memory got allocated .
- Phase 2: In a separte thread, the previously taken snapshot gets written to disk. This is done in a semi atomic way: Even if the saving gets interrupted by a crash or instant shutdown, the save game folder will remain in a state which can be "repaired". The reparing gets automatically done at the next startup.
If you are curious on how it looks code wise, you can have a look at my autosave branch:
https://github.com/flo/Terasology/commits/autosave
It is theoretically possible to reduce the time on the main thread further, but it's tricky to get right.
Once concept I am thinking about is to have the game fill two lists as entties get modified and deleted:
- A list of all deleted entities since the last save
- A list of all added and changed entities since the last save
The change delta gets then applied to a copy of all persistent entties which is private to the saving thread.
Thus no entities need to be copied or encoded in phase 1. All that needs to be done for entities in phase 1 would then be the swapping of two lists which takes as good as no time.
There are a few details to it that makes it a bit tricky, but if the save pauses turn up to be annoying that might be a good way to solve them.
Last edited:
