A History of the Externalization of Game Experience and the Reappropriation of Memory

1. A History of Game Saves and Screenshots

When digital games first appeared, they were not something to be played at length over several days. The arcade games of the 1970s ran on a business model that required coins to be inserted again and again within a short span of time, so play, too, was best kept short and intuitive. Home computers and console games, however, stood on different ground. Arcade boards could use dedicated hardware specialized for a single game, which made for superb graphics and sound, whereas home computers and consoles had to pursue general-purpose designs and so long lagged behind the arcade in sheer expressive power. If they could not compete on spectacle, they would compete on time and complexity — that was the home game’s alternative strategy.

Games on these platforms accordingly developed toward genres demanding far greater complexity and longer play time, such as the role-playing game and the adventure; and as the need arose to divide a game across multiple days, the save function emerged as a serious problem in its own right. For the first time, games began to implement the ability to remember the course of play and bring it back out for the next session.

* The Apple Disk II and a 5.25-inch floppy disk

As games supporting long-form play appeared in the late 1970s and early 1980s, attempts to preserve a game’s progress began in earnest — but they unfolded differently on the PC and on the console. The PC could use a general-purpose storage device, the floppy disk drive, and so could save games with comparative ease. Zork, the early text adventure whose development began on MIT’s PDP-10 in 1977 and whose commercial version for personal computers arrived in 1980, was one of the era’s representative games that could save its progress to a floppy disk.

The reason a categorical word like “first” is hard to use here is that Colossal Cave Adventure, which preceded Zork — not in its earliest version, but in the 350-point edition that Don Woods expanded and released in 1977 — already offered the ability to preserve the state of the game and resume it later[1].

Saving in those days, however, differed from today’s method of serializing the variables that make up a game state into a separate save file. It was closer to preserving the core memory image of the program running on the PDP-10 and loading it back later. As these text adventures were then ported from mainframes like the PDP-10 to personal computers like the TRS-80 and the Apple II, floppy-disk saving became possible in games like Zork as well. Amusingly enough, a single 5.25-inch floppy of the kind used on the TRS-80 or Apple II held, depending on format, only about 100KB.

Console games presented a more complicated picture. Through the early-to-mid 1980s, console games mostly shipped as cartridges, which had no variable space inside the physical medium for storing a save file. The cartridge was fundamentally read-only ROM, and the console itself had no general-purpose storage like a floppy drive.

Developers therefore labored to solve the problem by various means. One was the password. When play was interrupted, the game converted its current state — the stage, the character’s stats, the items and weapons acquired, the bosses defeated — into a combination of letters and numbers displayed on screen, and the player copied it down on paper by hand. Enter the password at the next session and the game would decode the string, restore the information it carried, and let the player resume from roughly where they had left off.

For example, possession of a given item might be marked 0 or 1, the current stage or a stat converted to a fixed numeric value, and these values encoded into a single string. The password’s length, of course, had to stay within what a player could write down and type back in, so it could not carry all the information of play.

The game therefore had to select and compress only the information strictly necessary to resume, and information left unsaved was sometimes returned to its initial value on restart. In this sense the password was less a save file in today’s sense than a kind of compressed blueprint for reconstructing the game state. Rather than storing data inside the game, it converted the minimum information needed to restore the game’s state into symbols and set it down outside the game. The function of saving was entrusted not to the machine but to the player’s own hand and paper.

* The password screen of Metroid

One decisive moment in the password’s consolidation on consoles came when Nintendo’s North American NES games adopted it in earnest[2]. It is especially interesting how the save methods of games at the core of Nintendo’s franchises — The Legend of Zelda, Metroid — diverged according to the release environments of Japan and North America. In February 1986, Nintendo launched the Famicom Disk System in Japan.

This was a peripheral that connected to the existing Famicom and allowed it to read and write rewritable “disk cards.” The Disk System’s launch title was The Legend of Zelda. The Japanese The Legend of Zelda was designed to save progress directly to the disk card, and Metroid and Kid Icarus followed on the Disk System in the same manner. Because a rewritable disk medium existed, the games could naturally record the state of play to the same medium.

* The Famicom Disk System and the Disk System edition of The Legend of Zelda

The problem came when these three titles were exported to North America. The Famicom Disk System was never released for the North American NES, so Nintendo had to choose a different solution for each game. The North American The Legend of Zelda, released in 1987, shipped as a cartridge — and an ordinary ROM cartridge could not record the player’s save data. Nintendo’s answer was battery backup: an SRAM chip and a battery mounted inside the cartridge, keeping the SRAM’s data alive after the console was powered off.

With this, players could save their progress directly inside the cartridge without writing down passwords. The Legend of Zelda was the landmark early case that brought battery-backup saving to the North American NES market in earnest. That one small battery made it possible, even in cartridge games, to continuously preserve the state of play unfolding over long stretches of time.

Metroid and Kid Icarus, released in North America in the summer of 1987, shipped by contrast as cartridges without battery backup, restoring progress through password systems instead. The same games, in the end, were saved to rewritable disks in Japan and transformed into two different forms — battery-backup cartridge and password — in North America.

Even within one company, in one period, three solutions to saving — disk, battery backup, password — were thus in contention at once. The choice was determined not by pure technical superiority but by economic and industrial conditions: cartridge manufacturing costs, regional hardware environments. The technological history of this externalization of the save was not a linear march of “password → disk → battery” but a process in which multiple solutions competed in the same period, different methods were chosen according to platform conditions, and a particular method gradually settled into a standard.

* The PlayStation memory card

The consoles’ embrace of CD-ROM in the 1990s raised yet another problem. That this technical advance dramatically expanded games’ expressive power — 3D graphics, full-motion video, extended soundtracks — is well known. But CD-ROM, for all its capacity, was a read-only medium, and consoles adopting it had to provide separate storage for saves. Sony’s PlayStation gave the console a dedicated memory-card slot, letting players store their save data on a memory card separate from the game software. The PlayStation memory card held 128KB in total, its usable space divided into 15 blocks. Some games needed a single block to save; others used several, and players had to manage the card’s limited space themselves.

The memory-card approach carried over to the PlayStation 2, with capacity greatly expanded from 128KB to 8MB. Yet ordinary game saving on the PS2 still centered on the memory card. A separately sold 40GB HDD was supported on some models and games, but it was never the universal save medium for PS2 games[3]. By contrast Microsoft’s original Xbox, a console of the same sixth generation, built an approximately 8GB hard disk into the unit as standard and saved games to that internal disk by default. Players no longer had to keep a separate memory card just to hold their save data.

As large internal storage became standard on consoles and network connections became constant, save files began to be kept not only on local HDDs and flash memory but on remote cloud servers. On the PC side, Valve first introduced Steam Cloud in November 2008. Early Steam Cloud, though, was closer to synchronizing configuration — keyboard and mouse settings — than save files themselves, and its coverage later expanded to save data.

On the console side, Sony moved a little earlier. In March 2011, the PS3’s PlayStation Plus online save storage allowed subscribers to back up as much as 150MB and up to 1,000 files of save data to the cloud[4]. With cloud saves, the very notion of a physical place where the save resides finally lost its meaning. The password lived on paper, the cartridge in the hand, the memory card in a wallet or a drawer, the hard disk at least inside the console in the living room. A cloud save, by contrast, belongs not to a device but to a user account.

Even if the console you played on breaks or disappears — even if you cross platforms — the memory persists. Saving finally reached the point of complete separation from its material base in hardware, bound only to the user’s account. With a save file in the cloud, a game played on one device can be continued on another; and in some games and services, cross-save came to share the same progress even across different platforms.

This history of save technology cannot be read simply as storage growing larger and saving growing more convenient. To play a game is to perform countless choices and actions at every moment, but the save file does not preserve all of that experience. It extracts and records only particular states: the player’s position, the items acquired, the quests resolved, the character’s stats, the changes in the game world. The save file, in other words, is not the play experience itself but a recording, on an external physical memory device, of the partial information the game system has selected so that the experience can later be resumed.

If the early password compressed that state to an extreme — a few lines of symbols entrusted to the player’s paper — then battery backup, the memory card, the hard disk, and the cloud were a progression in which the machine came to remember more and more of the game’s state in our place. In this sense the history of save technology is also a history in which the memory of play has been gradually transferred — externalized — from the player’s head and paper to the machine’s storage.

Meanwhile, the screenshot capture and video recording so effortlessly supported in today’s games did not arrive simply because large hard disks did. Even on the seventh-generation PlayStation 3, screenshots could be saved only after a system software update, and only in certain supported games[5].

In fact, game screens had been recorded as images since the 1980s, quite apart from games’ own save functions. Home consoles of the day, such as the Famicom or the Sega Master System, had no screenshot capability, so game magazine editors photographed CRT screens directly with film cameras. To avoid scan lines and flicker, the camera had to be fixed in a darkened room and shot at slow shutter speeds; later, the console’s video output would be recorded to VHS or other videotape, the needed frame selected, and a still extracted with a video printer.

In the 1990s, as video capture cards for computers spread, magazine editors could convert a console’s video signal directly into digital images, and packing strategy articles with masses of screenshots became far easier. Visual records of game screens existed early, in other words — but for a long time the capacity to produce them was confined to those with professional shooting and capture equipment: game companies and game magazines.

This began to change, little by little, from the late 2000s. The PS3 supported system-level screenshot saving in some games, and on the Nintendo Wii a few games could save images to an SD card on their own — but nothing was universal across the seventh generation. The decisive shift came with the eighth generation and after, beginning with the PS4 and Xbox One. Screenshot and video capture were absorbed into the operating system as standard features, and later — as with the dedicated capture button on the Nintendo Switch’s controller — players could preserve the particular moments of their experience in images and video without any specialized equipment[6].

Here an important change occurs in the character of the “memory” games preserve. If the save was fundamentally a device for preserving game state — how far have I progressed? — the screenshot and the play video preserve traces of the play experience itself: what did I see, what did I live through? Further, as captured images and videos came to be shared through social networks and platforms, game memory expanded beyond personal record into a social memory shared with other players. We are now in an era when anyone can easily capture their play in images or video and share it, or broadcast their play live. What the game remembers no longer stops at the minimum state needed to resume play. The traces of what the player saw, did, achieved, and failed at are being externalized and accumulated as digital data.

2. Modes of Reappropriating Game Memory

From its invention to the present, the save function has passed through a process of ever-greater invisibility. The password copied out by hand onto paper became a battery inside a cartridge; the memory card held in the hand became a hard disk inside the console; finally it became data on a cloud server that cannot even be touched. Yet interestingly, the more save technology receded into the background and became infrastructure, the more games began to appear that drag that infrastructure back into the foreground as material for narrative and feeling.

The save file, then, was long treated as a functional device for suspending play and resuming it. But as saving, loading, and resetting settled into the player’s everyday repertoire, some games began to pull these functions themselves inside the game’s narrative and world. The representative work is Toby Fox’s Undertale.

In Undertale, saving and loading are no longer mere system commands existing outside the game. They are treated as real powers that shake the time and causality of the game world, and the player’s manipulation of the save file becomes part of the narrative itself. Within the game, the power to save is explained as a force granted to the being of strongest will; when the protagonist enters the underground, Flowey — who had wielded that power until then — loses control over saving and loading. The act of saving the player had been performing outside the screen is translated into a power inside the game world.

What makes Undertale interesting is that it does not stop at explaining the save function as a piece of lore. In an ordinary game, when the player loads or resets, prior events become things that never happened. Only the player remembers the earlier timeline; the characters in the game know nothing of it. In Undertale this convention wavers. Flowey remembers what happened in previous timelines and recognizes the player’s repeated saving.

Other characters, too, without retaining full memory, sometimes respond to events of earlier timelines with something close to déjà vu. The reset, then, is no longer a clean initialization. Traces of what the player did in the previous world seep into the present one. The save file becomes a device that reveals that the past one thought erased has not entirely disappeared — rather than a device that erases the past so one can choose again.

* Meeting Flowey again after a save reset in Undertale — he remembers something

This structure produces its strongest effects in combination with the player’s ethical choices. In an ordinary role-playing game, the player can test other options out of curiosity and reload without a qualm if the result displeases. Killing an NPC and loading, or choosing another line of dialogue and rolling back, is regarded as experiment permitted outside the game.

Undertale draws this player’s privilege inside the world and attaches responsibility to it. That the player killed someone and turned time back does not mean the act is wholly nullified. Flowey, at least, knows; and the game, too, responds differently according to the routes the player chose before. After the genocide route is carried to its end in particular, traces of that choice remain in the world thereafter, so that no simple reset can wipe every consequence clean. Undertale converts the save file from a device granting the player limitless freedom of trial and error into an ethical memory device — one that remembers the player’s choices and returns them.

Here Undertale runs in exactly the opposite direction from the history of externalization we have traced. The development of save technology was, for a long time, a process of making the machine remember what the player once had to. In the days of writing passwords on paper, players had to preserve part of the game state themselves; through battery backup, memory card, hard disk, and cloud, the game system came to remember the state of play automatically. Undertale pulls that externalized memory back inside the game’s system of meaning. The save file is no longer transparent storage data but a narrative device that asks: who remembers the past, does erased time truly vanish, is the player free of responsibility for choices undone? Undertale, in other words, is a work that reappropriates the save system — once outside the game — as a problem of time and memory within it.

If Undertale draws the traces left in save files back into the game world and holds the player answerable for their choices, NieR: Automata goes a step further and asks players whether they will surrender, of their own accord, the memory they have accumulated so far. In NieR: Automata, released in 2017, save data carries more than systemic meaning from the outset. For the game’s androids, the body is a replaceable mechanical device; what sustains an individual’s continuity is rather the memory data backed up to the server. That is why, early in the game, 2B and 9S can be destroyed mid-mission and revived in new bodies. But memories after the last backup are not restored. For the characters, the storing and restoring of memory is nothing less than the question of death and resurrection — of continuity as the same being. The act of saving the player performs to suspend and resume the game overlaps with the act of backup the android performs to sustain its own existence.

The structure continues through repeated play. NieR: Automata does not end with a single ending; the full narrative comes into view only by continuing the story through the distinct perspectives of 2B and 9S and beyond. The hacking 9S performs, in particular, is a process of intruding into the data of machine lifeforms and other androids, through which the player accesses characters’ memories and hidden information. In this world, memory is not an abstraction dwelling only in an individual’s interior; it exists as data that can be copied, backed up, intruded upon, damaged, and deleted. The world of NieR: Automata is itself already the result of pushing to an extreme the problems that can arise once human memory is externalized as digital data.

But the relation between save data and memory is most direct in the final Ending E. Having passed through the several endings, the player performs a kind of shooting game — a battle against the game’s credits. The difficulty climbs to a point practically unmanageable alone, but through repeated failure an option appears: help, arriving with messages left by other players. Accept it, and other players’ craft appear around yours, absorbing attacks in your place; through their sacrifice, the player finally reaches the ending. What matters is that this help is not presented as mere NPCs or stagecraft. After the ending, the game asks the player whether they, too, will help someone else — and whether, to do so, they will delete the save data of everything they have played.

* The save-data deletion scene of Ending E in NieR: Automata

This choice inverts, head-on, what save data means in an ordinary game. The save file is the accumulation of the time and effort a player has invested. Inside it are the items and levels acquired over dozens of hours, the quests completed, the endings seen. To delete one’s save data is thus not to erase a few megabytes but to relinquish, oneself, the traces of the time one has spent in this game. What is more, the player cannot know who the future recipient of their help will be. And yet the player knows that they themselves passed through the final moment on the sacrifice of other, nameless players before them. Deleting one’s own save data becomes a kind of testimony — passing that help on to nameless players of the future.

Here the save data of NieR: Automata is reappropriated in a different way from Undertale. Where Undertale attached ethical responsibility to saving and resetting by having the game remember a past the player believed erased and undone, NieR: Automata attaches ethical meaning to the opposite act: not preserving memory but deleting it oneself. In the traditional game, the save was a device protecting the player’s time and effort from failure and loss. To store more, and to back it up more safely — that was the basic direction in which save technology developed. NieR: Automata presents the discarding of that accumulated memory as a choice. Memory becomes valuable not only because it must be preserved, but because it can at times be given up and handed on to another.

More interesting still, in this scene the game’s narrative and the player’s actual data become nearly indistinguishable. If the memory data of 2B and 9S was the condition sustaining their existence within the game, then outside it the player’s save file is likewise the data sustaining the player’s own history of living in the world of NieR: Automata. And at the last moment, the game does not end with a fictional character’s memory being sacrificed; it demands that the player beyond the screen hand over their real save data. The moment the player consents, the deletion of the save file no longer remains a representational experience — an event watched within a story. It becomes a performative act in which the player actually loses the game memory they have accumulated.

If NieR: Automata demanded that players delete their own externally stored memory, Outer Wilds overturns the relation of save and memory in a still more fundamental way. In Outer Wilds, released by Mobius Digital in 2019, the player becomes a space explorer surveying a small solar system. Not long after exploration begins, the sun goes supernova, the entire world is destroyed, and the player opens their eyes again before the campfire where they first awoke. The same thing keeps happening. However far the player has traveled, whatever dangers they have broken through, the world returns to the same point in time. If the save in an ordinary game is a device preserving the states a player has achieved, the time loop of Outer Wilds operates like a device that continuously removes them.

The game does, of course, record what the player has discovered in the ship’s log and display the clues in connection. But this record does not substantively raise the character’s capacities the way levels or equipment do in an ordinary RPG. In Outer Wilds the player acquires no new weapon, raises no stat, unlocks no new mode of movement. From the moment the ship is first acquired, virtually every physical capacity needed to finish the game is already given. What changes is the knowledge the player holds about this world. Learning, one thing at a time, what lies where on which planet, when a particular region can be entered, why the solar system keeps perishing — that process is itself this game’s system of growth. Between a player of dozens of hours and one just beginning there is almost no difference in character capability; between the two players’ knowledge of the world, the difference is enormous.

Which is why, in the extreme case, even a player starting Outer Wilds for the first time can reach the ending in a very short time — if they already know the solution. There is no need to wait for the game system to unlock new capacities. It is enough to already know what must be done. Here the game’s real progress comes to reside not in the save file but in the player’s head. Even if the save data disappears, the knowledge the player has gained does not disappear with it. Starting over from the beginning, one who knows which planet to fly to and in what order to operate the devices can reproduce most of the progress of prior play. The most important “storage device” in the game turns out to be the player’s own memory.

At this point Outer Wilds produces a strange reversal in the history of save systems. Under the early consoles’ password systems, the lack of storage forced players to record and preserve the game’s progress on paper. How far the game has gotten, which items have been won, which choices made — the player no longer needs to remember any of it, because the game remembers it instead. But Outer Wilds returns to the player the most essential portion of the game memory that had been migrating, for decades, to external storage. What the player accumulates here is not capability or items but understanding, and what drives play forward is not stored data but knowledge held in a person’s memory.

* A scene from Outer Wilds, the game behind the catchphrase “I’m buying a brain that’s never played this game.”

None of this means the history of save technology is being wound backward. Outer Wilds, too, uses save files in practice, storing discovered information, settings, and so on. What matters is that the division of roles between save file and player memory has been inverted. In the ordinary game, the player can move forward because the save file preserves past achievement. In Outer Wilds the save file exists for the player’s convenience, but what actually moves the game forward is what the player already knows. The save file draws closer to a supplementary record that assists memory rather than constituting progress itself. The game repositions itself not as a substitute for the player’s memory but as an external memory device supporting it.

The history of the game save was, in the end, also a history of games remembering in our place. But a growing quantity of storable memory does not mean experience itself can be preserved whole. A save file can record the player’s position and items, choices and achievements, but not everything of what one struggled over and failed at on the way there, or what one felt at a particular moment. The more finely games store human memory outside us, the more important, paradoxically, the question becomes: what cannot be stored, and what still remains with the player?

In that light, the recent phenomenon of games beginning to look at the save file with fresh strangeness is a compelling one. The save was once a convenience born of technical limits; it has become a rhetorical device expressing the game’s time and identity, responsibility and sacrifice.

Just as players decades ago wrote passwords in the corner of a notebook, what lasts longest in a game today is not necessarily the data recorded on a server or a storage device. There are experiences that remain in the player’s own memory: the moment a scene was first discovered, the rule grasped after repeated failure, the characters and events that keep surfacing after the game is done. Game save technology has ceaselessly moved human memory outward; recent games, drawing that externalized memory back in as material for expression, are paradoxically asking once more where the final place is that remembers a game.

[1] The 350-point edition of Colossal Cave Adventure, Don Woods’s expansion of Will Crowther’s original, was released on the PDP-10 in 1977, and that version already included the ability to suspend the game and resume it later. On DEC systems of the day, such saving was performed not by serializing the variables of the game state into a separate save file, as today, but by preserving and restoring the core memory image of the running program. Mike Markowski, who ported the original FORTRAN IV source to modern systems, likewise explains that in the original environment the SUSPEND command left the game as a memory image, which had to be dumped to a file for long-term preservation. Eric S. Raymond, “A Brief History of Colossal Cave Adventure,” The Colossal Cave Adventure page; Mike Markowski, “Colossal Cave Adventure,” University of Delaware.

[2] Mark Christian, “Saved, But Not Forgotten: The evolution of saving in video games, from the password to the cloud, and nearly every obscure memory card format in-between”, Tedium, 2019. 02. https://tedium.co/2019/02/21/video-game-save-state-history/ 

[3] "Sony ships PS2 hard drive, Final Fantasy XI" - GameSpot, https://www.gamespot.com/articles/sony-ships-ps2-hard-drive-final-fantasy-xi/1100-6092076/  

[4] Susan Panico, “Online Storage for Game Saves Coming to PlayStation Plus,” PlayStation.Blog, 2011. 03. 09.

https://blog.playstation.com/2011/03/09/online-storage-for-game-saves-coming-to-playstation-plus/  

[5]  Chris Faylor, “New PS3 and PSP Firmware Brings PS3 Screenshot Capture, PSP Online Store Later This Month,” Shacknews, 2008. 10. https://www.shacknews.com/article/55281/new-ps3-and-psp-firmware 

[6] My Nintendo News, “Nintendo Switch Joy-Con Has A Capture Button,” January 13, 2017.https://mynintendonews.com/2017/01/13/nintendo-switch-joy-con-has-a-capture-button/