Save Game overhaul

Immortius

Lead Software Architect
Contributor
Architecture
GUI
I am just about finished overhauling the saved game system in the multiplayer branch. I thought I'ld take a moment to explain the new structure.

The primary goal of the restructure was to allow the saving and restoring of entities in a chunk along with the chunk. Secondary goals were:
  • Set up the saved game structure to be ready for multiple world support in the future.
  • No longer load all chunks into memory during load (even compressed)
  • Pull the management of saves together into a centralised system. This will easy adding support for in-game saves (without quitting)
  • Deal with the issue of unloaded entity stores having references to entities that may be loaded and may be deleted.
  • Adding in-game saves without quitting (not yet complete)
  • General future proofing
  • Removal of remains of Java object serialization (I know this has independently been done in develop)
This is a breaking change, but since multiplayer is already a breaking change I went whole-hog.

The new structure looks like this:

/saves - The new saved games directory. No longer called worlds to future proof against saves containing multiple worlds.
/saves/<GameName> - Currently continues to be named after the title the player enters, but in future may just be a generated thing (game named will be stored in manifest instead)
/saves/<GameName>/manifest.json - Contains the small amount of information needed to list the save in menus, as well as the information needed early in the load process (mods used, block mappings, game time, list of worlds for supporting multiple worlds in the future)
/saves/<GameName>/global.dat - Main entity system information and storage for entities that are not stored with a chunk or player.
/saves/<GameName>/worlds/<WorldName> - Chunks are now stored in a subdirectory under worlds, to support multiple worlds.
/saves/<GameName>/worlds/<WorldName>/0.0.0.chunks.zip - A zip file containing a group of saved chunks. I initially had one file per chunk, but this proved too slow to save. Instead a chunk zip is used to save a group of chunks. 0.0.0 stores all chunks in the region (0,0,0) -> (31,31,31), and there are similarly named zips to hold chunks in other regions.
/saves/<GameName>/players - The subdirectory for player stores
/saves/<GameName>/players/<playerId>.player - A player store. Each player has a separate store. The local player has the special id "local".

The storage manager itself replaces the old chunk stores system, and when a player or chunk is unloaded their data is held in the storage manager until the storage manager is flushed - all save information needs to be written together to prevent inconsistencies.

As part of this update the Multiplayer branch has been moved to using NIO.2 from Java 7.

Remaining work:
  • Support in-game saves without returning to main menu.
  • Change game folders to not be named after the game name necessarily.
  • Background thread parts of the saving. This is in addition to the existing background threading of chunk compression.
 
Top