You play for two hours, quit, and come back tomorrow. Your character is exactly where you left them, with the same gear and the same score. The game didn't remember any of that by magic. It wrote a small file, and read it back.
When a game saves, it picks out the facts it needs to rebuild your session and writes them down. Where is the player? How much health is left? Which chests are already open? Which quests are done? This collection of facts is called the game state.
The save does not store a picture of the screen, and it does not store the game itself. The graphics, music and rules already live in the game's install files. The save only holds what is different about your playthrough, which is why a save file is often tiny compared with the game.
Below is a miniature game. Move the hero and grab the coins. Press Save to write the current state into the save file shown underneath, keep playing, then press Load to jump back. Then try Damage the file and load again.
The game
Coins 0 / 6 · Steps 0
Save slot 1
(empty: nothing saved yet)
Loading is the same trip in reverse. The game starts as if it were a new game, reads the file, then overwrites the starting values with the saved ones: put the hero here, mark these coins as taken, set the counter to this number. If you tried Damage the file above, you saw the other half of the story. A game can only rebuild your session if the file is complete and in the shape it expects.
A save file is written to storage, and anything can interrupt that: a crash, a power cut, a full drive. If the write stops half way, you get a file like the damaged one above. Careful games protect against this in a few simple ways:
Backups. The game keeps the previous save next to the new one, so one bad write doesn't destroy everything. Check values. The file includes a small number calculated from its contents, so the game can tell it has been cut off or changed. Version numbers. Notice "version": 1 in the file. When a game update changes what it stores, the version tells the game how to read older saves instead of rejecting them.
Games choose when to write the file. A manual save happens when you ask for it, so you can keep several slots. An autosave happens in the background, for example when you enter a new area. A checkpoint is a fixed point in the level where the game saves for you, which keeps the design simple but means you may replay a stretch after a failure.
Each choice is a trade-off. Saving anywhere gives players freedom but needs the game to describe its whole world at any moment. Saving only at checkpoints is easier to build and to keep reliable.
Most saves sit on the device that ran the game: the console's storage, or a folder on your PC. Many platforms can also copy saves to an online account, so a second device can pick up where you left off. This depends on the game and the platform's settings, so if you care about a long playthrough, check that your game supports cloud saves and that the option is switched on before you need it.
Saving is one of the first systems worth adding, and the lesson from the demo is the practical one: decide which few facts describe a session, write only those, and add a version number from day one. Start with one slot and one piece of state, such as the player's position, and grow from there.