Savegame System - Grisgram/gml-raptor Wiki
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 over sessions, be it a running level or just the players' profile, level, and how many stars he collected in each level.
All this data wants to be:
- 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, even the randomizer will continue with the same sequence of random numbers that he 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, whatever.
There are many things,
Savegame needs to take care of, one of them being the 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.
With that 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
|Savefile structure||What is saved, and how|
|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?|