Many developers struggle with saving and loading the game state in a way that lets them resume exactly where they left off.
This is one of the most critical parts of your game if it needs to persist data across different sessions, whether it is a running level or just the players' profile, level, and how many stars he collected in each level.

All this data must be:

• Persisted
• Protected from cheating (encrypted)
• Plain readable for debugging during development

It gets even more complicated if you generate procedural levels and need to persist the entire level and all objects in it. This is where the random seed comes into play. The Savegame system also persists the seed of the current session, so, after loading a savegame file, the randomizer will even continue with the same sequence of random numbers that it would have generated if the game would not have been saved at this point.

This is a very useful, small feature that prevents players from "save/load cheating" where they just keep loading the same savegame until they get that perfect setup of monsters or loot in the next room, when the next chest opens, or whatever.

Savegame must take care of many things, including performance. As far as I can tell, at the time of writing this, Savegame is as performant as it can be. Files are read and written through SNAP utilizing buffers for fast processing and not simple string concatenation.

To get an idea, how complex creating a savegame is, look at these workflows:

With this introduction, let's step ahead and take a look at how Savegame works.

Save and Load your Game	So, what do I need to call to save or load?
The Saveable Object	How to work with Saveable
Savefile structure	What is saved, and how
Planning your Savegame	Half of the solution is a good plan!
Savegame Versioning	How to work with game patches and updates
Workflow and User Events	Why User Events are used and why they are needed
Savegame functions	What else is available to support saving and loading data?