How studios lose their own source code

A game can remain playable forever as a shipped binary — the executable that sat on a disc or in a download — while the entire chain of source, tooling and licences that produced it has vanished. The archive holds the final artefact; the studio, in many cases, holds only the artefact. What gets called “lost source code” is rarely one missing folder. It is a build that can no longer be repeated because the surrounding ecosystem that made it build has collapsed quietly.

Buildability depends on the rest of the project

Code checked into a repository is not enough to produce a working binary. The project also needs its build files, its environment-specific project files, and every tool that touches the code before a compiler sees it. Unity’s developer documentation describes a small but instructive example. To build its Unreal plugin from source, a developer clones the plugin into a project, regenerates project files, and compiles the whole solution in Development Editor mode. The output is a set of DLLs sitting in the project’s Binaries folder — an ordinary, unremarkable result that nevertheless depended on a chain of steps. Miss one, and the DLLs never appear.

That chain includes components most teams treat as infrastructure. Visual Studio project files, for instance, are not handwritten; they are generated by the engine’s build system from metadata and platform definitions. If a studio upgrades its engine or loses the specific version of the generation tool, the files become ungeneratable. Code that compiles perfectly against one platform SDK will break against its successor. The same Unity documentation notes that a C++ project can be rebuilt by regenerating project files and compiling again, a phrasing that makes the process sound trivial. The difficulty is that regenerating project files requires the exact version of the engine, the exact compiler, and the exact supporting libraries that were current when the game shipped. Those specifics erode with time.

Binary assets and locked files

Art, audio and video assets introduce a second layer of fragility. Developers working on a game check in textures, models and sound banks that are not text at all — they are opaque binary blobs that no diff tool can meaningfully compare. A version-control guide for game development states plainly that binary assets cannot be merged automatically. Where two programmers can resolve conflicting changes to a C++ file line by line, two artists cannot merge two revisions of a 3D model. The solution is exclusive file locking: only one person edits a binary file at a time until it is checked back in.

This workflow imposes discipline but also creates a dependency on the central server that enforces the locks. If that server is decommissioned, the locking metadata goes with it, and the relationship between versions of a binary asset becomes uninterpretable. The same guide explains that Git LFS keeps large binary files on a separate server while storing lightweight pointers in the main repository. The pointer tells Git where the real asset lives; without the LFS server responding, the repository is a skeleton of references pointing to nothing. A studio that loses access to its LFS storage — because the server was shut down, because the subscription lapsed, because the organisation that ran it no longer exists — loses the actual art alongside any record of who changed what and when.

Preservation keeps the executable and its envelope

The Computing History website offers a terse definition of what it means to preserve a game: keep the manual, the packaging and the binary executable. The last of these is the one that matters for future playability. With a preserved binary executable, future users can experience the game through emulation — the executable is the final translation of every design decision, every shader, every gameplay rule, into a block of instructions a machine can run.

That definition also makes clear what preservation does not require. It does not require the original source tree, the build scripts, the licensed audio middleware, or the compiler toolchain. It does not require the project files or the asset pipeline. From a preservation standpoint, the executable is the artefact. But this same executable cannot be modified, rebalanced for new hardware, or reissued with updated textures. It can only be run, exactly as it was. The gap between what is preserved and what can be changed is the gap a remaster team must bridge.

When the source is missing, the binary is the start

When the source tree is incomplete or its build environment has rotted, the shipped binary often becomes the starting point for any new work — not because decompilation is trivial, but because the binary is the one technical artefact that survived the studio’s closure, the server migration, the expired licence, or the departed build engineer who understood the custom pipeline. The same Unity plugin rebuild cycle supplies the closest verified mechanism for what happens next. A team begins with a binary and works backwards to understand what structure it expects: what DLLs it loads, what calls it makes to middleware, what file formats it reads.

This is not the same as having source. It is the difference between being handed a furnished building and being handed the architect’s drawings, the soil survey and the contractor agreements. One lets you live inside the structure; the other lets you alter the foundations without the ceiling collapsing.

What a remaster team must reconstruct

Recreating a buildable project from a shipped binary means replacing every missing dependency in the original chain. The project files that told the engine how to assemble the game must be regenerated from whatever survives — configuration fragments, log output, directory layouts recovered from old hard drives. The source tree itself may need to be reconstructed file by file, with names and paths inferred from symbols baked into the executable. Build settings that controlled lighting quality, texture compression and memory budgets must be guessed at and compared against the behaviour of the shipped binary. Any missing binary dependencies — libraries, DLLs, plugins — must be either replaced with compatible versions or stubbed out sufficiently that the rest of the project compiles. The output of that rebuild, like the plugin DLLs that land in the Binaries folder in Unity’s own workflow, becomes the first new artefact the team can compare against the original executable. If the behaviour matches, the build chain is working again. If not, the mismatches are clues about which dependency remains missing.

The ordered reality is methodical, not magical. The following steps distil the rebuild sequence from the mechanisms documented in developer materials:

1. Regenerate project files from any surviving metadata or by reverse-engineering the structure implied by the shipped binary.
2. Reconstruct the source tree around those project files, recreating code files from decompiled or recovered fragments.
3. Identify all compile-time dependencies — compilers, SDKs, middleware headers — and locate versions that match the call signatures in the binary.
4. Place any recovered binary assets (textures, audio, models) into the asset pipeline, treating them as non-mergeable locked files with external pointers where LFS storage has been restored.
5. Compile the solution, inspect the DLLs and executable output, and compare their behaviour byte-for-byte against the original executable until the new build reproduces the old game’s responses.
6. Document every replaced component so that the next migration does not depend on a single engineer’s memory.

The sequence only works if the original executable itself survives. Many do not. Even when they survive, the gap between a shipped binary and a fully rebuildable project is not merely technical — it is the accumulated consequence of every licence that expired, every server that was switched off without a backup, and every build step that was understood only by the person who left. The practical difference, then, is not about source code versus no source code. It is about whether the institution side of a studio outlasts the engineering side long enough to hand over not just the finished work but the means to produce it afresh.