What Are Game Save Systems?

The Core Concept of Game State

A game's state is the complete set of data that defines its current condition at any point in time. This includes the player's position, health, inventory, level progress, unlocked abilities, score, settings preferences, and every other variable that would need to be recreated to resume the game exactly as it was. Game state does not include rendering information (what is currently drawn on screen), audio playback position, or runtime objects like physics bodies and animation controllers. Those are reconstructed from the saved state when the game loads.

The distinction between state and runtime is critical for save system design. A player character in a Phaser game has a sprite, a physics body, an animation controller, event listeners, and dozens of other runtime properties. None of these belong in a save file. What belongs in a save file is the data needed to recreate them: the character's x and y coordinates, current animation name, health value, velocity, and which items they carry. When the save loads, the game creates a fresh sprite, positions it at the saved coordinates, sets the health value, attaches the physics body, and the player cannot tell the difference from an uninterrupted session.

State complexity scales with game complexity. A simple puzzle game might have a state of 50 bytes: the current level number, which tiles are solved, and a move counter. An open-world RPG might have a state of several megabytes: the player's position in a large world, the state of every NPC, quest flags, inventory contents, world modifications (destroyed buildings, opened chests, placed items), crafting progress, and relationship values. The save system must handle both extremes efficiently, and the game's state model should be designed with serialization in mind from the beginning.

Types of Save Systems

Manual save systems let the player choose when to save, typically through a menu option. The player selects a save slot, the game captures the current state, and it writes the data to storage. This gives players full control over which moments they preserve, enabling strategies like saving before a boss fight to retry it without replaying the entire level. Manual saves are common in RPGs, strategy games, and adventure games where progress is nonlinear and players want to experiment with different choices. The downside is that players can forget to save and lose significant progress.

Checkpoint saves trigger automatically at specific locations or events in the game. Walking through a doorway, reaching a new area, completing an objective, or defeating a boss triggers a save without any player input. Checkpoint saves are the standard for action games, platformers, and linear narrative games because they ensure progress is preserved at natural breakpoints. The game designer controls the pacing of saves, which prevents save-scumming (repeatedly saving and loading to brute-force difficult sections). For web games specifically, checkpoints work well because they save at clean state transitions, reducing the risk of saving during an inconsistent or glitchy state.

Auto-save systems save continuously or at regular intervals, typically every 30 to 120 seconds. The player never needs to think about saving because the system handles it automatically. Idle games, simulation games, and sandbox games rely heavily on auto-save because there are no natural checkpoint moments in continuous gameplay. Auto-save can use a single rotating slot (overwriting the same save repeatedly) or maintain a history of recent saves that the player can roll back to. The challenge is performance: saving every 30 seconds must not cause frame rate drops, which pushes the implementation toward asynchronous storage APIs like IndexedDB.

Password and code systems are a historical approach where the game encodes its state as a short string that the player writes down and enters later. Early console games like Mega Man used passwords because cartridges had no writable storage. In the web context, code systems are occasionally used for shareable game states: a player generates a code for their puzzle solution or level design, shares it with friends, and friends enter the code to load that state. This is more of a sharing mechanism than a practical save system for modern games.

Session-only persistence uses JavaScript variables in memory. The game state persists as long as the browser tab stays open but is lost completely when the tab closes. This is technically not a save system, but it is the default behavior of any web game that does not implement persistence. Some very short games (games meant to be completed in a single sitting) use session-only state intentionally, but for any game with replayability or sessions longer than 10 minutes, real persistence is expected.

Why Web Games Need Save Systems

Web games face unique persistence challenges that native games do not. A native game installed on a computer or phone has access to the local filesystem, which provides essentially unlimited persistent storage. A web game runs in a browser sandbox with limited, managed storage that the browser can clear without asking the user. Mobile browsers routinely evict LocalStorage and IndexedDB data when the device is low on storage, and private browsing modes may limit or disable persistent storage entirely. This means web game saves are inherently less durable than native game saves unless they are backed by cloud storage.

Browser tab behavior creates a specific pressure for auto-saving. Users close tabs constantly, sometimes accidentally, sometimes to free memory, sometimes because a mobile OS kills the browser. If a web game relies on manual saving, a significant percentage of players will lose progress to unexpected tab closures. The beforeunload event provides a narrow window to save on tab close, but it is unreliable on mobile and does not fire when the browser process is killed. This makes frequent auto-saving essential for any web game that values player retention.

Cross-origin storage isolation means that the same game served from different URLs has completely separate storage. A game at https://game.example.com cannot access saves from https://www.example.com/game. If you change your game's domain or URL structure, existing players lose their saves unless you implement a migration path. This is a common and painful mistake in web game development, and the solution is either to never change the origin after launch or to implement cloud saves that are independent of the browser's origin-based storage.

Storage quotas vary across browsers and are not always predictable. Chrome allows up to 60% of disk space for a single origin when granted persistent storage permission, but without that permission, data can be evicted under storage pressure. Safari limits total storage to around 1 GB per origin but has historically been more aggressive about clearing data from sites that have not been visited recently. Firefox allows up to 2 GB per origin by default. These numbers change with browser updates, so relying on specific quota amounts is risky. Games with large save data should implement graceful fallbacks when storage is full.

Designing a Save System from Scratch

Start by defining your game's state model as a plain JavaScript object. List every piece of information that needs to persist between sessions. Organize it hierarchically: player data (position, stats, inventory), world data (level state, object positions, flags), meta data (settings, keybinds, total play time), and system data (save version number, timestamp). Make sure every value in the object is a primitive type, array, or nested plain object. No class instances, no functions, no DOM references.

Choose your storage backend based on data size and performance requirements. For save data under 1 MB with infrequent writes (manual saves, checkpoint saves), LocalStorage is simple and reliable. For save data over 1 MB or with frequent writes (auto-save every 30 seconds), IndexedDB is the correct choice because of its asynchronous API and larger capacity. For games that need cross-device persistence or protection against browser data clears, implement cloud saves backed by a server database. Many games use a layered approach: LocalStorage for instant reads on startup, IndexedDB for the primary save, and cloud sync for durability.

Implement versioning on day one. Store a version number in every save file. Write migration functions before they are needed: when version 1 of the game state adds a new field in version 2, the migration function adds that field with a default value. When version 3 renames a field, the migration function copies the old value to the new key and removes the old one. Chain migrations so that a version-1 save can upgrade through every intermediate version to reach the current one. Skipping versioning is the single most common save system mistake in web game development, and retrofitting it after launch is painful.

Test save/load early and test it often. The most insidious save system bugs are silent: data is stored but a field is missing, a number is stored as a string, a nested object reference is not deep-copied, or a migration function has an edge case that corrupts old saves. Automated tests that serialize a game state, deserialize it, and compare the result to the original catch most of these issues. Manual testing should include saving in every possible game state (mid-combat, in menus, during transitions, with empty inventory, with full inventory) and verifying that loads produce identical gameplay.