Game Preservation Techniques: Fixity, Metadata, and Usable Copies

Preservation begins with a verifiable transfer

A disc image arrives on a storage device, a researcher deposits a development build, or an archive receives a directory of source files. The first task is not to launch the game. It is to establish what arrived, where it came from, when the transfer happened, and whether the files remain unchanged afterward.

That sequence separates a preservation master from a working copy. The master is the retained, unaltered object as received or created through a documented capture process. A working copy is made for inspection, emulation, analysis, or testing. If a researcher changes configuration files, extracts assets, or patches a build to make it run, those changes belong in a derivative—not silently in the master.

For each transferred file, an archivist can calculate a SHA-256 checksum. A checksum is a fixed-length value generated from a file’s contents; even a small alteration usually produces a different value. Recording it at intake establishes a reference point for later comparison. If the file is copied to new storage months later, a fresh checksum can be compared against the original. A match is evidence that the bits are identical.

It is not evidence that the game is complete, authentic, or playable. A checksum cannot tell whether a disc image omitted a track, whether a program depends on a missing server, or whether the submitted file was already damaged before arrival. Fixity answers a precise question—“Are these bits the same as the recorded bits?”—and should not be asked to answer broader questions about quality or meaning.

Build an intake record before the evidence goes cold

Transfers are easiest to describe while their circumstances are still known. An intake record should identify the source, acquisition date, transfer method, person or organization responsible for the deposit, and any conditions attached to it. It should also record the files received, their sizes, and their initial checksums.

Provenance is more than a name in a spreadsheet. A build supplied by a developer, a file copied from a retail disc, and a disk image created by a researcher may contain identical software but have different histories and evidentiary value. Record what is known and label uncertainty plainly. “Source reported as a 1998 development backup; original medium unavailable” is more useful than a confident-sounding but unsupported claim.

For physical media, document the item before handling or imaging: platform, title, publisher, catalog or product number, region markings, disc or cartridge identifiers, condition, and any accompanying notes or packaging that are part of the deposit. If a disc is imaged, record the drive and software used, the date of imaging, and any read errors. If a cartridge is dumped, describe the equipment and method. These details can help another researcher assess how the digital object was produced.

Preservation copies should not erase evidence of the transfer process. Keep the original received object where policy and storage capacity allow; create a verified preservation copy; and use a separate derivative for analysis. If an intake process produces a repaired, decrypted, converted, or otherwise transformed file, describe the change and retain the earlier state when legally and technically feasible. A tidy collection that hides its transformations is difficult to trust.

Fixity checks and BagIt packaging

One useful way to carry files and their fixity information together is BagIt, a packaging specification standardized as RFC 8493. A BagIt package—often called a bag—organizes content in a data directory and includes manifests listing files and their checksums. The package also contains small “tag” files that describe the bag and its manifest.

That structure makes a transfer more auditable. A receiving institution can validate the manifest and compare each listed checksum with the corresponding file. If the checksums match, the payload has not changed relative to the manifest. The package does not certify who created the files, whether rights are clear, or whether the contents will execute. Those questions require separate records and review.

A practical workflow is to create a bag after intake documentation is complete, generate a SHA-256 manifest, validate the bag, and record the outcome. When moving the package to new storage, validate it again. A failed check should trigger investigation, not an automatic overwrite. Compare copies in other storage locations, preserve logs, and identify whether the problem lies in one damaged copy, an incomplete transfer, or an error in the recorded manifest.

BagIt is a packaging and transfer approach, not a substitute for an institution’s storage plan. A single valid bag on one drive remains vulnerable to hardware failure, loss, or environmental damage. Archives generally need multiple managed copies, separated by location or failure domain, plus routine monitoring and documented recovery procedures. Whatever the storage arrangement, the manifest provides a repeatable way to check whether the files still match their recorded state.

There is a further distinction between fixity of a package and fixity of its contents. Repacking files or changing a bag’s administrative tags may alter the package as a whole even when the game files themselves remain unchanged. Decide which objects need to be monitored—the original payload, the full package, or both—and state that policy in the preservation record.

Metadata that explains how a game can be read

Checksums help answer whether files changed; metadata helps explain what those files are. A useful record connects each file to its platform, software version, media format, language or region, and known dependencies. Depending on the object, relevant details may include an operating system, firmware revision, controller, display mode, installation sequence, configuration file, or online service required for a particular feature.

Game files rarely arrive as self-explanatory objects. A directory might contain a launcher, several data archives, a patch, and a text file describing an installation step. A disc image may represent only one disc in a multi-disc release. A build could require a specific version of DirectX or a license key that was not included in the deposit. Record these relationships rather than treating every file as an isolated, equally understandable item.

The PREMIS Data Dictionary for Preservation Metadata offers a framework for recording preservation events and their outcomes. An event could describe imaging a disc, checking a checksum, migrating a file, or creating an emulation access copy. A useful event record identifies what happened, when it happened, who or what carried it out, and what resulted. If a migration created a new file, record the relationship between the source and the result, along with the tools and settings used when those details are known.

Metadata need not become a technical diary of every mouse click. It should be detailed enough to support accountability and future interpretation. For example: “Created a raw disc image on 13 October 2026 using [recorded imaging tool and version]; two read errors were reported at the noted sectors; SHA-256 recorded in the intake manifest.” The example is only useful if the tool, version, and error details are actually recorded—not filled in later from memory.

Separate facts from interpretation. “The image contains files labeled version 1.2” is an observation; “this is the final retail release” is a conclusion that needs evidence. Metadata can link to supporting documentation, such as a manual, release note, catalog record, or deposit agreement, without treating every claim in those sources as definitive. Where cataloging standards are already used by an institution, map game-specific details into the existing system rather than inventing an incompatible schema for each collection.

The master, the derivative, and the usable copy

An untouched master may be the most faithful retained representation of a game, yet still be impossible to use on current hardware. A usable copy is prepared for a defined purpose: examining a menu, studying a level, verifying a particular behavior, or demonstrating an interaction in a research setting. The copy might run in an emulator, on original hardware, or in another documented environment.

Keep the route from master to access copy visible. Record the source object, emulator or conversion tool, relevant configuration, and any patches or transformations. If a researcher modifies a configuration file to change a display setting, retain that file with the access copy and describe the change. If a game is migrated from one format to another, preserve the source where possible and record both the method and the result. A derivative is not a failed master; it is a separate object with a separate purpose and history.

Emulation can help researchers examine software without repeatedly handling fragile media, but it does not make every dependency disappear. MAME, for example, is a long-running emulation project focused on documenting and recreating the behavior of historical computer and arcade systems. Its use may help test software in a relevant environment, but an emulator’s availability does not guarantee that a particular game is supported, that every peripheral behaves correctly, or that the experience is identical to the original hardware.

Record the emulator version, system configuration, ROM or firmware dependencies where applicable, and any settings that affect behavior. Note what was tested and what was not. A game reaching its title screen is not the same as a complete verification of gameplay, audio, saving, network features, or controller response. A concise test log can make the limits of an access copy clear to future researchers.

Usability is also a research question. Does a copy preserve timing, sound, input behavior, or network interactions that matter to the study? A test environment may make a title accessible while changing the very characteristics under investigation. Preserve observations about those differences rather than presenting an emulated run as an exact substitute for the original platform.

A worked example: a disc image enters an archive

Imagine an archive receives a disc image from a researcher who created it from a privately held retail copy. The donor identifies the title, platform, and approximate date of imaging, but cannot provide the original disc. The archivist should retain that qualification: the file is a researcher-created image, not a direct transfer from the publisher or a verified master supplied by the rights holder.

1. Document receipt. Record the donor or source, date, transfer route, stated title and platform, file name, file size, and any available details about the original disc and imaging process.
2. Calculate fixity. Generate a SHA-256 checksum for the received file and preserve the value in the intake record. Do not rename, patch, or convert the only received copy during inspection.
3. Create and validate a package. Place the file and appropriate documentation in a BagIt package, generate a checksum manifest, and record the validation result. If validation fails, investigate the cause before treating the bag as a reliable transfer package.
4. Describe technical context. Record the platform, region or product identifiers where known, image format, imaging details supplied by the donor, and any known gaps or uncertainties. If the image’s format is not recognized, document the identification attempt rather than guessing.
5. Test a derivative. Make a working copy and test it in a documented environment. Record the emulator or hardware used, its version or configuration, and the behaviors checked. Keep test notes distinct from claims about completeness or authenticity.
6. Review rights separately. Record the copyright and permissions status, any agreements governing access, and the basis for any permitted use. Do not infer permission to distribute from the fact that the archive can preserve or test the file.

At the end of this process, the archive has several distinct things: a received object, a checksum record, a packaged preservation copy, an access derivative if one was made, and a description of legal and technical status. Keeping those roles separate makes the collection easier to audit and less likely to misrepresent what the institution actually holds.

Custody is not permission

Digital preservation and copyright address different questions. Preservation asks how an object can be retained, described, checked, and interpreted over time. Copyright and related agreements govern rights in the work and may restrict reproduction, distribution, adaptation, or public communication. An archive’s possession of a file does not, by itself, establish a right to offer it for download.

U.S. law provides a limited example of this distinction. Section 108 of Title 17 contains exceptions for qualifying libraries and archives under specified conditions, including provisions concerning preservation and replacement copies. Its requirements are not a universal permission for every organization, every format, or every kind of public access. Other countries have different copyright laws and exceptions, and licenses, contracts, and technological protections can raise additional issues.

Likewise, “abandonware” is a colloquial label, not a legal category that automatically places a game in the public domain or licenses it for redistribution. A title may be unavailable commercially while still protected by copyright. When rights are uncertain, document that uncertainty, restrict access as policy and law require, and seek qualified legal advice for decisions with legal consequences.

Preservation records should therefore include rights information separately from technical metadata: known rights holders, source of the rights statement, license or agreement, access conditions, review date, and unresolved questions. A checksum can confirm that a file has not changed; it cannot confirm that a collection has permission to publish it.

Keep the evidence useful to someone who was not there

A good preservation workflow leaves another researcher able to follow the object’s history without relying on an archivist’s memory. Use stable identifiers for records and files, preserve event logs with the relevant object, and document dates consistently. Store checksums in more than one appropriate record or location so a damaged manifest does not become the sole reference for a collection.

Make uncertainty legible. State when an original medium is unavailable, when a version number is inferred, when an emulator test was limited, or when permissions remain unresolved. Avoid turning a plausible reconstruction into a fact simply because later catalog users are unlikely to question it. A record that admits what it cannot establish is stronger than one that smooths away its gaps.

Finally, revisit preservation decisions. Storage systems change; software dependencies become harder to obtain; formats and documentation may lose context. Scheduled fixity checks, periodic review of access copies, and documented migration decisions give archives a chance to respond before a failure becomes a mystery. Every change should leave a trace: what was done, why, to which object, using what method, and with what result.

A game preserved this way is not merely a functioning program or an intact set of bits. It is an object with a traceable chain of custody, measurable fixity, recorded technical context, and clearly stated rights status. Those records allow future researchers to distinguish the original evidence from the tools used to encounter it—and to know what can responsibly be done next.