How Game Preservation Projects Work in 2026: A Guide for Players

Game preservation projects work by rescuing games while there is still something left to rescue. A project picks a title, confirms who owns the rights, buys or borrows the original hardware, captures the software as a raw disk or cartridge image, verifies the capture against checksums, stores redundant copies, and publishes documentation alongside whatever access the law allows. That loop is the whole job.

In 2023 the Video Game History Foundation reported that roughly 87% of games released in the United States before 2010 were not preserved in any capacity. Most ranking pages on this topic explain why games are fragile. Few bother to explain the actual mechanics, which is the more useful half of the story.

Table of Contents

1. 1What Is Video Game Preservation?
2. 2Why Do Games Need Preservation Projects?
3. 3What Does a Preservation Project Actually Save?
4. 4How Game Preservation Projects Work Step by Step
5. 5How Preservation Projects Choose Which Games to Save
6. 6Collecting and Verifying the Original Release
7. 7Preserving Files, Code, and Documentation
8. 8Restoring the Game’s Technical Environment
9. 9Providing Access Without Misrepresenting the Original
10. 10What Is the Difference Between Preservation, Emulation, and Access?
11. 11How Do Preservation Teams Handle Copyright and Lost Projects?
12. 12How Can Players Support or Participate in Preservation?
13. 13Frequently Asked Questions
14. 14Is video game preservation the same as emulation?
15. 15Is it legal to back up a video game I own?
16. 16What happens when a game’s online servers shut down?
17. 17Why is old source code so hard to find?
18. 18Who pays for game preservation projects?
19. 19What is abandonware, and does it count as preservation?
20. 20Conclusion

What Is Video Game Preservation?

Video game preservation is the practice of safeguarding games as cultural artefacts: capturing their software, source code, art assets, hardware, manuals and magazines so they stay readable, studyable and playable long after the platforms, companies and servers that carried them are gone.

It is not the same as making a backup of your own save file, and it is not the same as emulation. A backup protects your copy. Emulation lets a preserved image run on hardware that no longer exists. Preservation is the upstream act of capturing and documenting the artefact at all.

Games are unusually fragile objects. A novel survives on paper for centuries. A game depends on a disc that delaminates, a cartridge with a battery-backed memory chip that dies, a server that a studio switches off without warning, or a storefront that closes and takes the download entitlement with it.

Why Do Games Need Preservation Projects?

Every loss below has already happened to somebody, repeatedly, in public.

• Storefront closures. Digital-only purchases on shuttered eShops and storefronts became unredownloadable. The Wii U and 3DS eShops are the familiar example, and planned PlayStation Store closures follow the same pattern.
• Dead servers. An online game exists only while someone runs its back end. The day the publisher cancels the subscription, the game is gone even though the discs are on shelves.
• Media decay. Discs rot, tapes shed binder, floppy disks lose bit integrity, and flash-based consoles fail from wear far earlier than expected.
• Lost source code. Publishers close a studio and the build server with it. Even when the compilers and the engine survive somewhere, the project files are gone.
• Vulnerable dependencies. Old games leaned on operating systems, middleware and online services that now carry unpatched flaws. Nobody should host the original server, and the original server is gone anyway.
• Abandoned print. Manuals, strategy guides, magazines and box art go out of print and out of print means out of existence when the publisher drops them.

There is a gap people confuse constantly. Preservation captures. Access gives. A project can hold a perfect, fully documented archive of a game that no player outside the project is permitted to download.

What Does a Preservation Project Actually Save?

A serious project treats a game as a package, not a file. The usual contents look like this.

• Software images. Bit-for-bit disk and cartridge dumps, unedited, including the copy protection data that made the original disc work.
• Source code and build files. The rarest item by far, and the one remaster studios ask archives about most often.
• Art, audio and design assets. Separate files rather than the assembled build, so future projects can reference them.
• Patches and revisions. Every regional and revision variant gets its own entry, because a dump that matches retail doesn’t describe what players actually ran.
• Manuals, box art and magazines. Scanned at high resolution with the physical object photographed for condition records.
• Technical documentation. Engine internals, memory maps, format notes, disc structures and the awkward hardware quirks that stop the image from booting.
• Server data. Protocol notes, configuration files, client builds and whatever community documentation exists, collected while memories are still accurate.
• Provenance and rights records. Who owned the disc, who holds the licence, what permission the project has to keep or publish anything.

That last item is the one institutional archives care about most, and the one hobbyist projects most often skip.

How Game Preservation Projects Work Step by Step

This is the part almost no ranking article covers, so here it is in the order a project actually does the work.

How Preservation Projects Choose Which Games to Save

Preservation teams triage constantly, because supply is infinite and staff hours are not. The common criteria are historical significance, physical scarcity, cultural reach, technical uniqueness, and plain recoverability.

Museums formalise this. The Strong National Museum of Play uses a triage standard called RAVE, which sorts candidates on rarity, at-risk status, value and engagement potential. Hobbyists run the same logic informally: an obscure unreleased prototype on a dead format beats another survivor of a well-documented arcade board.

Recoverability decides a lot. If a cartridge exists in single-digit numbers worldwide and needs destructive teardown to read, the calculus is completely different from dumping a CD that survives a drive swap.

Collecting and Verifying the Original Release

Then the team sources material: retail copies from secondary markets and swaps, pre-release builds from developers, magazines and trade shows, manuals, and interviews with people who worked on the game.

Every item gets a provenance record. Who sold it, what region it came from, what condition the media was in on arrival. Without that, a decade of dumping turns into a pile of files nobody can vouch for.

Version identification happens here too. Disc mould codes, serial numbers, revision strings and region markings get recorded so the capture can be matched to a real release rather than an assumption.

Preserving Files, Code, and Documentation

Capture happens with the right hardware for the format. Consoles with optical drives need a drive that reads the specific disc generation, and console-locked titles need a modded or bypassed drive so the image reflects what the machine actually did.

Cartridges with internal flash memory need a flash programmer, sometimes two passes and a desoldering job, sometimes hardware bought specifically for one title. The output is a raw image that dumps byte-for-byte, including areas a commercial ripper would silently skip.

Then verification. A checksum such as MD5 or SHA-1 is calculated over the image and compared against a shared database of known-good dumps. Two independent dumper machines producing the same hash is the standard. This step is where an enthusiast decides whether to trust a project, and the culture around it is unforgiving of shortcuts.

Storage follows a fixity schedule, not a hunch. Projects that take this seriously run checksums over everything in their archive on a repeating cycle, because storage that has not been verified in years is only a hope. One volunteer running a 10.4 TiB archive described the real engineering problem: 1,044 earlier builds of one single game, across languages, architectures and development stages, all needing deduplication on BTRFS, careful handling of non-deterministic file ordering inside archive formats, and files split into extents that are still shareable.

Dumps get replicated across at least three copies on at least two kinds of media, with one copy off-site. Institutional archives add fixity checks and geographic separation on top of that.

Storage is where the maths stops being romantic. A disc image is small, but the surrounding documentation, lossless asset dumps and multiple regional revisions turn a single game into tens of gigabytes, and a serious collection runs into the tens of terabytes. At that scale deduplication is not a nicety, it is the difference between a collection that grows and one that stalls on a disk budget.

The recurring failure is quieter than losing a disc. It is letting a drive fail quietly for two years, then discovering that a third of the archive never got verified again after the first cycle. That is why fixity checks run on a schedule and why most institutional guidance treats verification as the job rather than dumping.

Restoring the Game’s Technical Environment

An image is inert until something runs it. Teams reconstruct the environment the game expected: the operating system version, the audio and input layers, timing behaviour, and often a specific display setup, because the original assumed a CRT’s refresh rates and scanline behaviour in ways a modern flat panel simply cannot match.

Some projects emulate the original environment rather than replacing it. Server-based titles get the harder version, where a project has to rebuild a back end that no longer exists anywhere, sometimes from packet captures and community recollection rather than documentation.

Providing Access Without Misrepresenting the Original

Preserved data does not equal published data. Projects release a mix of things, and the mix depends on rights.

The Internet Archive publishes a large catalogue of playable software through its Emularity platform, which packages browser-based emulators so an archived item runs on a normal web page. The Flashpoint archive took the same shape for browser games after a Flashpoint installer controversy pushed the project toward distributed, offline access rather than a single central download.

Hidden Palace and Project Deluge document preservation-focused disc collections with release notes and provenance detail, and they are careful about what they will and will not host. Ruffle, a Rust-based Flash emulator, exists because the runtime it replaces was shut down by its manufacturer and the games on it were never given another home.

Publishers increasingly run their own efforts. GOG’s preservation program backs up the installers for the catalogue it sells, and Sony has put a preservation team in place as physical disc production winds down, with the disc phase-out scheduled for January 2028.

When a project gives access, it says plainly what changed. A version running on a modern system with modern input is not the same object as the original release, and the honest ones document the difference rather than pretending otherwise.

What Is the Difference Between Preservation, Emulation, and Access?

These three get used interchangeably in forum threads, which causes most of the confusion. They are three different outcomes of the same capture.

Method	What it preserves	Accuracy	Cost to deliver	Legal risk
Emulation	Hardware behaviour, reproduced on new hardware	High, close to original, occasionally imperfect	Ongoing software development	Moderate, depends on hosting
Migration or porting	The design, rebuilt natively for current platforms	Low to medium, changes creep in	Large, often studio-scale	Low, rights holder usually involved
Source-code archiving	Code, art and build files in a readable form	Exact, if the archive is intact	Storage plus careful repository hygiene	Low
Hardware conservation	The physical object	Exact, subject to decay	Display, climate control, housing	Lowest, ownership is provable
Documentation digitisation	Manuals, box art, magazines, interviews	High, scanner resolution limited only by budget	Scanner, storage, cataloguing time	Low
Server emulation	The online services around a game	Medium, community-built from memory	Ongoing engineering, rising over time	Medium to high

The practical difference shows up in failure. If an emulator project gets shut down by litigation, preserved data survives even though the way to play it does not. If a port gets abandoned, the original still exists untouched.

Preservation is the base layer. Everything else sits on top of it, and anything on top can fall off without taking the archive with it.

How Do Preservation Teams Handle Copyright and Lost Projects?

Three project models do this work, and they are not interchangeable. A hobbyist project has reach and speed but no legal standing. An institutional archive has a budget, a collection policy and permission to hold material, but it moves at staff speed. A community project sits in between, pooling labour and often funding.

Project model	Typical funding	Scale	Legal standing	Public access
Hobbyist dumpers	Personal income and donated hardware	Thousands of titles, one or two people	None beyond personal backup rights	Documentation public, images usually private
Community archives	Donations, sponsorship, volunteer labour	Large catalogues, uneven coverage	Varies, often conservative	Selective, with provenance notes
Institutional archives	Public funding, philanthropy, licensing revenue	Curated collections with acquisition policy	Strongest, can hold under exemption	Study access, museum exhibition, some downloads

The trade-off is coverage against rigour. Hobbyists reach formats no institution will fund a drive for. Institutions produce the condition surveys, cataloguing standards and fixity schedules that keep an archive alive for decades, but only for what fits their acquisition policy.

Rights are the reason a lot of well-documented material never reaches a public download button.

Published works get the clearest treatment. A commercial game has an identifiable rights holder who can be asked, and often the answer is yes. Projects without a permission slip archive the files privately, document them publicly, and leave the playable copy out.

Unpublished and orphaned material is harder. A cancelled game may sit under a studio that no longer exists, a work-for-hire clause that assigns rights to a publisher, or a contract nobody can produce. Preservationists call this rights in limbo, and it is a recurring frustration rather than a rare edge case.

The law permits some backup copying, and museums have pursued specific exemptions through the Library of Congress. In 2024 the U.S. Copyright Office rejected the museum exemption request that preservation advocates had argued for, which pushed more of this work into private hands and informal agreements.

Rights holders can also change their minds, or take down access they previously allowed. Projects built on one permission have been stranded when that permission was withdrawn. The forums are full of people who distrust any archive that looks like piracy, and that distrust is not unreasonable given how often preservation and piracy get deliberately blurred for publicity.

How Can Players Support or Participate in Preservation?

You do not need a clean room and a soldering iron. The genuinely useful contributions are the boring ones.

• Donate physical media you already own. Duplicate discs and common cartridges are the least glamorous and most requested category of donation there is.
• Back up what you legally can. Keeping your own disc image on your own storage, for your own use, is the personal version of the whole practice.
• Document community history. People who worked on a game, ran a fan server, or ran a fanzine hold context no archive can invent. Write it down and hand it over.
• Contribute technical skill. Emulator debugging, checksum database work, server reconstruction and catalogue metadata are all volunteer-labour bottlenecks.
• Record interviews. Oral history is the part that degrades fastest, because it disappears when people do.
• Fund storage. Archive capacity is a recurring cost, not a one-time purchase, and it is the line item most likely to end a project.
• Report broken links. An archive page that 404s is as much a loss as a lost disc, and nobody notices unless a reader tells them.

If you want to know whether a specific game is already covered, search the archive catalogues and the community scene first. Duplicate dumping is wasted effort, and enthusiasts will tell you so.

Frequently Asked Questions

Conclusion

Game preservation projects work by repeating one loop with more rigour than most people expect: choose a title worth saving, establish who holds the rights, acquire the original hardware, capture a raw image, verify it against checksums, store redundant copies with scheduled fixity checks, document everything, and publish only what the law allows.

Start with one game you actually care about. Search the major archive catalogues and the community scenes to see whether it is already covered, and if it is not, that is where a volunteer hour is worth more than another saved copy of something safe.