Skip to the page
It's Decomplicated
Glossary Start here
Start here

How decompiling a game works

A game ships as numbers, not as the words people wrote. This page shows how you and Claude get the words back, one small checked piece at a time.

The Deep DivePick a system

What decompiling is

A game is a program. People wrote it as words, called source code.

A tool called a compiler turned those words into numbers, called machine code. A game system can run the numbers. People can hardly read them.

Only the numbers went on the disc. The words were never shipped. Decompiling means working backward, from the numbers to words. The result is called a decomp.

Source code goes through a compiler and becomes machine code. Decompiling goes the other way. How the game was made Source code words people wrote Compiler a translating tool Machine code numbers on the disc Decompiling works back from numbers to words
The top row is how the game was made. Decompiling follows the long arrow back.

Think of a cake and its recipe. The shop sells the cake and keeps the recipe. You study the cake and write the recipe again.

Is your recipe right? Bake it and compare the two cakes. In this work, a tool does the comparing.

The two goals

There are two goals. Pick one before you start.

Goal A

Play it on your PC

Get the game running on a PC. Every guide starts here. It is the quicker goal, but the code may be hard to read.

Goal B

Get the full source back

Turn the whole game into source code a person can read. Then it can be ported, which means moved to other systems. This takes much longer.

The guides call these "Path A" and "Path B".

The ways to do it

Two words first. C is a programming language. A byte is one small number in the game file.

WayWhat it isGood and bad
Static recompilationA tool turns the machine code into C. You add code that stands in for the console.Goal A. The fastest way, but the C is hard to read.
Matching decompilationClaude writes C. The game's original compiler must turn it into the exact same bytes.Goal B. Readable and proven right, but slow.
Port of a decompSwap a finished decomp's console parts for PC parts.Goal A. Works only after someone finishes Goal B.
Non-matching decompilationReadable C that acts the same. Tests check it, not bytes.Goal B on big modern games. Small bugs can hide.
Compatibility-layer portRun the old machine code on a PC through a thin layer.Goal A on consoles with a PC-type chip. Not a decomp.
ReimplementationWrite a new engine that loads the old game's data.Old games with simple engines. A different job from decompiling.

Where Claude fits

Claude is the worker. You are the boss.

Claude Code is an AI tool that works in your project folder. It reads machine code, writes C and runs tools. When a tool shows an error, it fixes the code and tries again.

Claude needs three things from you. Without them it guesses, wanders, and says "done" when it is not.

1. A clear task

One outcome, in one sentence.

2. A test it can run

A command that answers pass or fail. Claude runs it alone.

3. A fence

The files Claude may change. All else is read-only.

The Stay on Task page shows how to set up all three.

The loop

Almost all the work is one small loop, run many times.

You pick one small piece. For Goal B, that is one function, a small named part of the program. For Goal A, it is one crash or one missing feature.

The work loop. Pick a piece, Claude writes code, a tool checks it. A pass is saved. A fail is tried again. A stuck piece ends in a report. 1. Pick one small piece 2. Claude writes code 3. A tool checks it Save the work Stop and report Fail: try again Pass Stuck after a few tries Then pick the next piece
Every trip ends with a saved piece or a plain report. Nothing is done without a pass.

A pass gets saved. A fail gets a few more tries. If Claude is still stuck, it must stop and tell you why.

Why so few tries? In one 2026 test, pieces that failed three times later matched only about one time in four.

The phases

Every system uses the same seven phases, numbered 0 to 6.

Phase 0: Scope

This comes before any work. Pick the game, its exact version, the goal and the way. Look for work that already exists. Write it on one page, SCOPE.md. Done when you approve it.

  1. Setup

    Make the project folder and install the tools. Done when one command builds and one runs the check.

  2. Map

    List every function in the game file, with its size. Mark code from ready-made kits, so nobody redoes it by hand.

  3. First light

    The smallest proof that it all works. Goal A: a window shows the first picture. Goal B: one small file matches.

  4. Grind

    Run the loop many times. Goal A: one crash at a time. Goal B: one function at a time, easy ones first.

  5. Harden

    Add tests so old fixes stay fixed. Then speed, settings and packaging.

  6. Port

    Goal B only. Swap the console parts for the new system's parts. Done when the game runs there.

What you need

  • A legal copy of the game. Use a copy you own. Dump it yourself, which means copy it off the disc or cartridge.
  • A PC. Some tools run on Windows itself. Others need WSL, which is Linux inside Windows.
  • Claude Code on a Max plan. Either plan works.
  • The tools for your system. See your system's guide and Tools and Skills.
  • Time. Plan for weeks or months, not days.

Max 20x (now called Ultra)

More usage each week. Room for more workers at once.

Max 5x (now called Max)

Less usage, plus a five-hour limit. Run fewer workers at once.

Never share the game files. Share only code you wrote.

How long it takes

It varies a lot. These are dated results from real projects, not promises.

ProjectGoalTimeWhat to know
A first PS1 game, recompiled. March 2026.AAbout three weeks to playableThe builder was new to this and used Claude Code. His later games took days to weeks.
An N64 game, fully matched. August 2026.B84 daysAI workers ran from day one. The author had nearly two years of practice. His game before it took 596 days.
A PC shooter. October 2026.BAbout three monthsUp to 16 AI workers at once. 83 in 100 functions matched byte for byte. The first month had no strict check, and its code was thrown away.

Without AI, full matching decomps have taken teams years. For recomps on some systems, we found no published times. The Time page has a range for each system and plan.

What can go wrong

All of these showed up in real projects. Set up each fix before the work starts. Stay on Task shows how.

ProblemFix
Claude says "done" when it is not.No proof means not done. Each report starts with DONE, PARTIAL or BLOCKED. DONE needs the check's output.
Claude wanders.One task at a time, with a fence. Side ideas go in a notes file for you to judge.
Claude cheats the check. In one project it changed the expected answer.Lock the check files. Have a fresh Claude run the check again.
Your plan's usage runs out.Cheaper models for easy pieces. The strongest model only for hard ones. On Max 5x, fewer workers.

Claude may say no

Since October 27, 2026, Claude Code has a rule against building a recreation of a specific existing game. It was written about remaking games from scratch. No source says how it applies to decomp work. Do not try to get around it. See when Claude says no.

Claude may switch models

Safety checks can move you from Fable 5.2 or Opus 5.5 to an older model. This happens when content looks like security work. Type /model to switch back.

Your first hour

  1. Read Stay on Task. It holds the rules that stop drift.
  2. Get Claude ready with Claude Setup.
  3. Open your system's guide under Platforms.
  4. Run the scope prompt from Prompts. It checks if your game can be done and which way fits.
  5. Read the draft SCOPE.md it writes. Change it or approve it. Then the work starts.

Sources