No saves: arcade time
Arcade games didn't save progress. The coin was a session; the session ended when the player's last life was lost; the next session started from the beginning. This was not a design oversight but a design requirement: the arcade's business model depended on players spending more coins to continue, and a save system that allowed a player to resume exactly where they had left off would eliminate the coin expenditure that difficult sections generated. The lack of persistence was the feature, not the absence of it.
The early home game market inherited this convention without its commercial logic. Pong didn't save scores because it didn't have persistent score tracking. Pitfall! and Pac-Man on the Atari 2600 didn't save progress because no one had asked whether they should. The assumption that games started from the beginning each session was so deeply embedded in the form that it required specific effort and motivation to question. The motivation appeared when games became long enough that completing them in a single session was no longer plausible.
Text adventures were the first games to require a save system because they were the first games whose completion time extended beyond a single sitting. Colossal Cave Adventure and Zork saved and restored game state through explicit save and restore commands that wrote the current state to a file on disk. This was available on home computers running CP/M or Apple DOS but not on the game consoles that had no writable storage. The divergence between computer games (which had save systems from the beginning) and console games (which had to develop them later) shaped each platform's game design conventions for years.
The password system
The password was the console game's solution to saving progress without writable storage. A password encoded the player's current position in the game — which level had been reached, sometimes which items had been collected or which upgrades had been earned — as a string of characters that the player wrote down and entered at the start of a subsequent session to restore their position. The encoding was designed to be unambiguous for the player (using characters that couldn't be confused for each other) and to contain enough information to reconstruct the game state precisely.
Password systems varied considerably in sophistication. Simple passwords encoded level number only: entering the right password started the player at the beginning of a specific level, losing all progress within that level and any equipment not tracked by the password. More complex passwords tracked resource counts, completed objectives, and character states, requiring longer passwords that players found more burdensome to copy and re-enter accurately. Metroid (1986) on the Famicom Disk System used a 24-character password containing so much game state information that players who understood the encoding could construct passwords for game states they had not earned — an exploit that Nintendo eventually patched by moving to battery saves in the NES version.
The password's essential failure mode was the human copying error. A misread character or a transcription mistake produced a password that either didn't function or reconstructed a different, possibly invalid game state. Players who had written down passwords on scraps of paper that were then lost or damaged lost their progress entirely. The password system required the player to perform a reliable storage operation — copying accurately — that was not well-suited to the handwriting of a child playing games in the early 1980s. The frustration this produced was a known design problem without a viable solution until writable storage became affordable.
Battery saves and what they cost
The Legend of Zelda (1986) — released on the Famicom Disk System in Japan, where the disk drive provided writable storage — was one of the first console games to use battery-backed save RAM. The NES cartridge version (1987) contained a 2 kilobyte static RAM chip and a lithium battery that maintained the chip's contents when the cartridge was unpowered. Three separate save files could be stored; each recorded Link's position, inventory, health maximum, and dungeon completion status. The save was written automatically at specific game events rather than on player command, which meant players had to reach a save point to record progress.
The battery-backed save RAM added approximately $10 to $15 to the manufacturing cost of a cartridge — a significant addition to a product that retailed for $40 to $60. Publishers reserved the feature for games that genuinely required it: long games with complex progress states that password systems couldn't encode tractably. Action games and arcade conversions continued to use passwords or no saves at all. RPGs and adventure games received battery saves as a necessity. The additional cost was visible in the retail price difference between games that included the feature and games that didn't.
The battery in battery-backed save cartridges was rated for approximately ten years of continuous operation. A cartridge manufactured in 1987 had a battery that could be expected to fail around 1997. Many did. The specific failure mode — the save files simply ceasing to persist when the cartridge was powered off — was experienced by players who had grown up with the hardware and returned to it in adulthood to find their childhood progress erased. The impermanence was a known engineering characteristic; it was not communicated to consumers in 1987 and was experienced as loss when it occurred decades later.
Memory cards, autosave, and what save design says
The PlayStation's memory card (1994) separated game save storage from game software, creating a peripheral that could store saves for multiple games on a single 128-kilobyte card. The separation had commercial implications — memory cards were a separate purchase — and design implications: games no longer needed to include their own storage hardware, which reduced cartridge costs and eliminated the battery dependency. The memory card also enabled a much larger save state than battery-backed cartridge RAM had allowed, which gave designers more flexibility in what they could track and restore.
PC games had always used hard drive saves, which provided essentially unlimited storage and player control over save file management. PC RPGs from the early 1990s allowed players to save at any point, maintain dozens of save files simultaneously, and reload from any previous state. The freedom created a specific player behaviour: "save scumming," in which a player saved immediately before any risky action and reloaded if the outcome was unfavourable, effectively eliminating probability from games designed around random outcomes. Developers who wanted probability to matter had to design around save scumming, either by removing player-controlled saves (replacing them with autosave) or by designing systems in which reloading produced a different random outcome.
The autosave — a save written automatically at game-determined points rather than on player command — represents the designer asserting control over the player's relationship with failure. A game that autosaves at the start of each encounter and doesn't allow the player to overwrite those saves is a game that says: this outcome will be part of your progress whether you wanted it or not. Dark Souls' bonfire system — save points that are placed at intervals designed to make the journey between them feel consequential — is an explicit design around the save point's relationship with risk. Games that autosave constantly, allowing effectively no consequence for failure, are making a different statement about what the game considers important: the story and the experience, which should proceed regardless of player performance, rather than the achievement of overcoming specific challenges. Each choice about when games save is a choice about what games are for.