# GameFrame

> An agentic framework for reverse engineering games: a method, skills and tools for AI agents and people who rebuild games exactly.

GameFrame is an agentic framework for reverse engineering old games from the copy you own and rebuilding them exactly in new code. It gives a method in steps, one skill per step for AI coding agents, and tested tools around Ghidra, Unicorn and REA. It ships no game material. Every page below is plain Markdown. All of them together are in [llms-full.txt](https://tanepiper.github.io/game-frame/llms-full.txt).

- [Home](https://tanepiper.github.io/game-frame/index.md): An agentic framework for reverse engineering games.

## Start

- [GameFrame](https://tanepiper.github.io/game-frame/overview.md): GameFrame is an agentic framework for reverse engineering games.
- [Documentation](https://tanepiper.github.io/game-frame/guide.md): GameFrame is an agentic framework for reverse engineering games.

## Game preservation

- [Game preservation](https://tanepiper.github.io/game-frame/preservation/index.md): Many older games can no longer be bought.
- [Why games disappear](https://tanepiper.github.io/game-frame/preservation/why-games-disappear.md): A game can be lost in several ways.
- [What GameFrame does](https://tanepiper.github.io/game-frame/preservation/what-gameframe-does.md): GameFrame helps one person study a game they own and rebuild it in new code.
- [Your own copy and the law](https://tanepiper.github.io/game-frame/preservation/law/index.md): Most countries let a person who owns a game study how it works.
- [Treaties](https://tanepiper.github.io/game-frame/preservation/law/treaties.md): International treaties set minimum rules that most countries share.
- [United States, Europe and the United Kingdom](https://tanepiper.github.io/game-frame/preservation/law/us-europe-uk.md): Norway applies the EU Software Directive through the European Economic Area.
- [East Asia](https://tanepiper.github.io/game-frame/preservation/law/east-asia.md): South Korea and China have written software exceptions.
- [South and Southeast Asia and Oceania](https://tanepiper.github.io/game-frame/preservation/law/asia-pacific.md): Australia, New Zealand, Singapore and India have software exceptions for study and for decompiling.
- [The Americas](https://tanepiper.github.io/game-frame/preservation/law/americas.md): Canada has interoperability exceptions both for studying a program and for locks.
- [Africa, the Middle East, Other Nations](https://tanepiper.github.io/game-frame/preservation/law/africa-middle-east.md): Most of these countries have a software exception on the EU model.
- [35 countries compared](https://tanepiper.github.io/game-frame/preservation/law/compared.md): "OST" means observe, study and test.
- [AI and reverse engineering](https://tanepiper.github.io/game-frame/preservation/ai.md): GameFrame is written for AI agents working with people.
- [Built on others' work](https://tanepiper.github.io/game-frame/preservation/others-work.md): GameFrame learns from projects that kept games playable long before it existed.
- [For developers and publishers](https://tanepiper.github.io/game-frame/preservation/rights-holders.md): We respect the people who made these games.

## Kinds of games

- [A taxonomy of games](https://tanepiper.github.io/game-frame/games/index.md): Games are not all reverse engineered the same way.
- [Who drives: the game or the player](https://tanepiper.github.io/game-frame/games/interaction.md): Before you read a game's code, decide what kind of control system you are rebuilding.
- [Arcade action: shoot 'em ups, platformers, beat 'em ups, fighting](https://tanepiper.github.io/game-frame/games/arcade-action.md): Games where things come at the player every frame and the player steers, jumps, fires and dodges.
- [First-person and 3D action](https://tanepiper.github.io/game-frame/games/first-person.md): Shooters and action games seen from the player's eyes or just behind them: Wolfenstein 3D to Half-Life, and the immersive simulations (System Shock, Thief).
- [Racing and sports](https://tanepiper.github.io/game-frame/games/racing-sports.md): Driving games and simulations of sports: the player controls a car or a team, the game runs physics and AI opponents.
- [Vehicle and space simulations](https://tanepiper.github.io/game-frame/games/vehicle-sims.md): Flight simulators, space combat and space trading games: the player flies something through a large world simulated in 3D.
- [City building and management](https://tanepiper.github.io/game-frame/games/management.md): City builders, tycoon games and colony simulations: a world that runs on its own, slowly, and a player who arranges it through windows, menus and clicks.
- [Strategy: real time, turns and tactics](https://tanepiper.github.io/game-frame/games/strategy.md): Games where the player commands many units against opponents: real-time strategy (RTS), turn-based empire games (4X), and squad tactics.
- [Role-playing games](https://tanepiper.github.io/game-frame/games/rpg.md): Games where the player builds characters and explores a world: computer RPGs, dungeon crawlers, roguelikes and Japanese RPGs.
- [Adventure and story games](https://tanepiper.github.io/game-frame/games/adventure.md): Point-and-click adventures, text adventures, interactive fiction and visual novels.
- [Puzzle, board and card games](https://tanepiper.github.io/game-frame/games/puzzle-board.md): Falling-block and logic puzzles, board games, card games, and the small games that shipped with operating systems.
- [Online games](https://tanepiper.github.io/game-frame/games/online.md): Massively multiplayer games and other games where a server owned by the publisher holds the world.

## Platforms

- [Home computers and the PC](https://tanepiper.github.io/game-frame/computers/index.md): This section covers the home computers, the PC and the Mac that games were written for.
- [CPU families](https://tanepiper.github.io/game-frame/computers/cpu-families.md): Eleven CPU families cover almost every game platform: the 8080/Z80/SM83 line, the 6502 line, the 6809, the 68000, the TMS9900, the CP1600, x86, ARM, MIPS, SuperH and PowerPC.
- [Sinclair ZX81 and ZX Spectrum](https://tanepiper.github.io/game-frame/computers/sinclair.md): The Sinclair machines use the Z80 (CPU families).
- [BBC Micro and Acorn Electron](https://tanepiper.github.io/game-frame/computers/acorn-8bit.md): Acorn's 8-bit machines use the 6502 family (CPU families).
- [Commodore VIC-20 and C64](https://tanepiper.github.io/game-frame/computers/commodore-8bit.md): Commodore's 8-bit machines use the 6502 family (CPU families).
- [Amstrad CPC](https://tanepiper.github.io/game-frame/computers/amstrad-cpc.md): The Amstrad CPC uses the Z80 (CPU families).
- [MSX, PC-8801 and Sharp X1](https://tanepiper.github.io/game-frame/computers/msx-and-japan-8bit.md): These machines use the Z80 (CPU families).
- [Atari 400/800, XL and XE](https://tanepiper.github.io/game-frame/computers/atari-8bit.md): The Atari 8-bit computers use the 6502 family (CPU families).
- [Apple II](https://tanepiper.github.io/game-frame/computers/apple-ii.md): The Apple II uses the 6502, later the 65C02, and the 65C816 in the IIgs (CPU families).
- [Other 8-bit computers](https://tanepiper.github.io/game-frame/computers/other-8bit.md): This page covers three smaller families.
- [Commodore Amiga](https://tanepiper.github.io/game-frame/computers/amiga.md): The Amiga uses the big-endian 68000 line (CPU families).
- [Atari ST family](https://tanepiper.github.io/game-frame/computers/atari-st.md): The Atari ST uses the big-endian 68000 line (CPU families).
- [Acorn Archimedes and Risc PC](https://tanepiper.github.io/game-frame/computers/acorn-32bit.md): Acorn's 32-bit machines use ARM (CPU families).
- [Japanese 16-bit and 32-bit computers](https://tanepiper.github.io/game-frame/computers/japan-16-32bit.md): The X68000 uses the big-endian 68000 line.
- [The IBM PC and compatibles](https://tanepiper.github.io/game-frame/computers/ibm-pc.md): On the PC, identify the executable format first.
- [The Macintosh](https://tanepiper.github.io/game-frame/computers/macintosh.md): The Mac has had four CPU families, each with its own code format.
- [Engine-era PC games](https://tanepiper.github.io/game-frame/computers/modern-pc-engines.md): In engine-era PC games much of the logic is outside the native executable.
- [Console games](https://tanepiper.github.io/game-frame/consoles/index.md): A home console game runs on fixed hardware with little or no operating system.
- [Early consoles](https://tanepiper.github.io/game-frame/consoles/early-consoles.md): The first and second generation consoles have tiny ROMs, no operating system and well-known CPUs.
- [Console platforms](https://tanepiper.github.io/game-frame/consoles/platforms.md): Each console has its own CPU, video chip, sound hardware and conventions.
- [CD add-ons](https://tanepiper.github.io/game-frame/consoles/cd-add-ons.md): These add-ons give the base console a second CPU or a BIOS.
- [Jaguar and 3DO](https://tanepiper.github.io/game-frame/consoles/32-bit-oddities.md): The Atari Jaguar and the 3DO do not belong to the main console families.
- [Seventh generation onward](https://tanepiper.github.io/game-frame/consoles/modern.md): From the Xbox 360 on, every platform ships signed executables in a vendor format such as XEX, SELF or RPX.
- [Tools for console work](https://tanepiper.github.io/game-frame/consoles/tools.md): GameFrame's playbook works for consoles, but some tools change.
- [Routes to a port](https://tanepiper.github.io/game-frame/consoles/porting.md): There are four ways to bring a console game to other systems.
- [Matching decompilation](https://tanepiper.github.io/game-frame/consoles/matching-decomp.md): A matching decompilation is C or C++ source code that, compiled with the original compiler and settings, produces a program identical byte for byte to the original.
- [Handhelds](https://tanepiper.github.io/game-frame/handhelds/index.md): This section covers the handheld game machines, from the mask-ROM LCD games of 1979 to the PC handhelds of today.
- [Handheld practices](https://tanepiper.github.io/game-frame/handhelds/practices.md): Handhelds keep state in battery-backed RAM and real-time clocks.
- [LCD games and Game & Watch](https://tanepiper.github.io/game-frame/handhelds/lcd-games.md): On Game & Watch, Tiger LCD games and the Microvision, the program is mask ROM inside a 4-bit microcontroller.
- [Game Boy family](https://tanepiper.github.io/game-frame/handhelds/game-boy.md): The Game Boy family has the most mature tool chain of any handheld.
- [Sega, Atari and SNK handhelds](https://tanepiper.github.io/game-frame/handhelds/sega-atari-snk.md): The Game Gear, Lynx and Neo Geo Pocket are 8-bit and 16-bit cartridge handhelds.
- [WonderSwan](https://tanepiper.github.io/game-frame/handhelds/wonderswan.md): Bandai's WonderSwan family runs a CPU compatible with 16-bit x86.
- [Virtual Boy and Pokémon mini](https://tanepiper.github.io/game-frame/handhelds/nintendo-oddities.md): The Virtual Boy and the Pokémon mini are Nintendo handhelds outside the Game Boy line.
- [Game.com](https://tanepiper.github.io/game-frame/handhelds/tiger-game-com.md): Tiger's Game.com is a touchscreen handheld on a Sharp SM8521.
- [Nintendo DS and 3DS](https://tanepiper.github.io/game-frame/handhelds/ds-and-3ds.md): The DS and 3DS run ARM code from cartridges.
- [PSP and PS Vita](https://tanepiper.github.io/game-frame/handhelds/psp-and-vita.md): Games for Sony's handhelds come as signed and encrypted executables.
- [Switch family](https://tanepiper.github.io/game-frame/handhelds/switch-family.md): The Switch, Switch Lite and Switch 2 run AArch64 code.
- [ARM-OS handhelds](https://tanepiper.github.io/game-frame/handhelds/arm-os-handhelds.md): The N-Gage, Gizmondo, GP32 and GP2X run ARM code on an operating system.
- [PC handhelds](https://tanepiper.github.io/game-frame/handhelds/pc-handhelds.md): The Steam Deck and the other PC handhelds are x86-64 PCs with a built-in screen and controls.
- [Phones](https://tanepiper.github.io/game-frame/handhelds/phones.md): Before smartphones, phone games ran as J2ME or BREW apps.
- [Arcade games](https://tanepiper.github.io/game-frame/arcade/index.md): This section covers arcade boards from discrete logic to the PC-based systems.
- [Practices for arcade work](https://tanepiper.github.io/game-frame/arcade/practices.md): This page covers the practices that apply to every arcade board.
- [Encryption and protection](https://tanepiper.github.io/game-frame/arcade/protection.md): Arcade encryption was usually built into a custom CPU and keyed from battery-backed RAM.
- [Discrete logic and the 8080](https://tanepiper.github.io/game-frame/arcade/discrete-and-8080.md): The first arcade games of 1972 to 1978 come in two kinds.
- [Z80 and 6502 boards](https://tanepiper.github.io/game-frame/arcade/z80-and-6502-era.md): The boards of 1979 to the mid-1980s run Z80 or 6502 programs, often with several CPUs on one board.
- [Williams and Midway](https://tanepiper.github.io/game-frame/arcade/williams-and-midway.md): Williams built 6809 boards for Defender and Robotron.
- [Atari coin-op boards](https://tanepiper.github.io/game-frame/arcade/atari-coin-op.md): Atari moved from the 6502 to the 68000 family and to other CPUs.
- [Sega 2D boards](https://tanepiper.github.io/game-frame/arcade/sega-2d.md): Sega's 68000 boards of the late 1980s ran beat 'em ups and sprite-scaling games.
- [Capcom CPS](https://tanepiper.github.io/game-frame/arcade/capcom-cps.md): Capcom's CP System boards ran from 1988 to 2004.
- [Neo Geo](https://tanepiper.github.io/game-frame/arcade/neo-geo.md): SNK's Neo Geo ran as an arcade board (MVS) and as a home system (AES).
- [Other 2D makers](https://tanepiper.github.io/game-frame/arcade/other-2d-makers.md): This page covers the 2D boards of Namco, Konami, Taito, Irem, Data East, Toaplan and Cave.
- [Early 3D boards](https://tanepiper.github.io/game-frame/arcade/early-3d.md): Every early 3D board has a general CPU and one or more DSPs or custom geometry chips.
- [Console-derived boards](https://tanepiper.github.io/game-frame/arcade/console-derived.md): From 1994 to about 2009 many arcade boards reuse a console's CPU, GPU and sound chip.
- [PC-based boards](https://tanepiper.github.io/game-frame/arcade/pc-based.md): From 2004 arcade boards are x86 PCs with custom I/O, a locked OS image and a hardware key.

## Technology of the era

- [Hardware of the era](https://tanepiper.github.io/game-frame/hardware/index.md): A PC game from 1985 to 2005 uses its hardware far more directly than a modern program.
- [CPUs and floating point](https://tanepiper.github.io/game-frame/hardware/cpus.md): The CPU a game was written for sets the number formats and instructions it uses for arithmetic.
- [2D graphics](https://tanepiper.github.io/game-frame/hardware/graphics-2d.md): DOS games drew straight into video memory.
- [3D accelerators](https://tanepiper.github.io/game-frame/hardware/graphics-3d.md): From 1996, PC games could draw 3D with a separate graphics card.
- [Sound](https://tanepiper.github.io/game-frame/hardware/sound.md): Sound hardware in DOS games is programmed directly.
- [Memory, storage, input and networks](https://tanepiper.github.io/game-frame/hardware/other.md): This page covers memory beyond 640 KB, CDs, joysticks and networks, and how to recognise each in a game's code.
- [Software engines and middleware](https://tanepiper.github.io/game-frame/engines/index.md): Most games from the 1980s and early 1990s were written from scratch.
- [Recognising an engine](https://tanepiper.github.io/game-frame/engines/recognising.md): A game built on an engine usually shows it in its files: archive formats, file extensions, DLL names, version strings, copyright notices and debug paths.
- [The id Software engines](https://tanepiper.github.io/game-frame/engines/id-tech.md): Many first-person games of the 1990s ran on id Software's engines.
- [Build, Jedi and other 2.5D engines](https://tanepiper.github.io/game-frame/engines/build-2-5d.md): Between Doom (1993) and true 3D engines (Quake, 1996), several engines drew 3D-looking worlds from 2D maps with heights.
- [Unreal Engine 1 and 2](https://tanepiper.github.io/game-frame/engines/unreal.md): Epic Games' Unreal Engine 1 (Unreal, 1998) and Unreal Engine 2 (2002) were the main competitors to the Quake engines.
- [Other licensed 3D engines](https://tanepiper.github.io/game-frame/engines/licensed-3d.md): Besides the id engines and Unreal, several engines were sold to other studios in the late 1990s and early 2000s.
- [Studio engines for 2D and isometric games](https://tanepiper.github.io/game-frame/engines/studio-2d.md): Strategy games, role-playing games and adventures of the 1990s mostly ran on engines a studio built for itself and reused across its games.
- [Middleware](https://tanepiper.github.io/game-frame/engines/middleware.md): Middleware is a library that a game licenses for one job.

## Crates

- [Crates](https://tanepiper.github.io/game-frame/crates/index.md): Clean Rust implementations of hardware and runtime pieces that many old games need.
- [gameframe-opl2](https://tanepiper.github.io/game-frame/crates/opl2.md): An emulator of the Yamaha YM3812 (OPL2), the FM synthesis chip on the AdLib card and the Sound Blaster family.
- [gameframe-wma](https://tanepiper.github.io/game-frame/crates/wma.md): A decoder for Windows Media Audio version 2 (WMA v2, format tag 0x161), written in Rust.
- [gameframe-msvc-crt](https://tanepiper.github.io/game-frame/crates/msvc-crt.md): Parts of the Microsoft C runtime (MSVC CRT) that a game's results can depend on, rebuilt in Rust so a port gives the same numbers as the original program.
- [gameframe-turbo-pascal](https://tanepiper.github.io/game-frame/crates/turbo-pascal.md): The parts of the Turbo Pascal and Borland Pascal runtime that a DOS game's results depend on, rebuilt in Rust so a port gives the same numbers as the original program.

## Observing the original

- [Observing the original](https://tanepiper.github.io/game-frame/observe/index.md): These pages describe how to run the original game, watch it, drive it and capture what it does, so each claim about the port can cite a measurement.
- [Running the original](https://tanepiper.github.io/game-frame/observe/running-the-original.md): A run of the original shows what the code does with real inputs.
- [Inputs: everything that comes from outside](https://tanepiper.github.io/game-frame/observe/inputs.md): A reimplementation is exact when it gives the same results as the original for the same inputs.
- [Capturing the interface](https://tanepiper.github.io/game-frame/observe/ui.md): A game's interface is usually written for that game alone.
- [A model to query: the game's object model and its entry points](https://tanepiper.github.io/game-frame/observe/object-model.md): A web page has a document object model: a tree you can query ("the button called Save"), read ("its text") and act on ("click it"), from scripts, tests and tools.

## Working on a project

- [Working on a project](https://tanepiper.github.io/game-frame/working/index.md): These pages describe how to organise the work of reverse engineering a game, for agents and the people who direct them.
- [Working well as an agent](https://tanepiper.github.io/game-frame/working/agents.md): This page is for AI coding agents doing reverse engineering with GameFrame, and for the people who direct them.
- [Linux, cloud and container environments](https://tanepiper.github.io/game-frame/working/environments.md): GameFrame runs on macOS and Linux, on a desktop or headless.
- [Writing findings and documents](https://tanepiper.github.io/game-frame/working/writing.md): Everything in GameFrame is written to be read by agents and people, and to be translated.

## Reference

- [Patterns you will meet in game code](https://tanepiper.github.io/game-frame/game-patterns.md): Most games are built from the same few parts.
- [DOS and 16-bit games](https://tanepiper.github.io/game-frame/dos.md): Most of GameFrame was built on a 64-bit Windows game.
- [Calling conventions, data layout and floating point](https://tanepiper.github.io/game-frame/abi.md): This page lists what you need to read a game's machine code correctly and to call its functions under the emulator.
- [What a project can ship](https://tanepiper.github.io/game-frame/outputs.md): This page lists what a project can give to players and to other developers, and how to build and publish each one.
- [Setup](https://tanepiper.github.io/game-frame/setup.md): To install and check everything:
- [Working within the law and with respect for the original](https://tanepiper.github.io/game-frame/legal.md): These are GameFrame's defaults and the reasons for them.

## Case studies

- [Case studies](https://tanepiper.github.io/game-frame/case-studies/index.md): Three reimplementations built with GameFrame, of three different kinds of game, on three different platforms.
- [Case study: Un-Banished](https://tanepiper.github.io/game-frame/case-studies/banished.md): Un-Banished is a 1:1 reimplementation of the city-building game Banished (Shining Rock Software, 2014) in Rust, running on Windows, macOS, Linux and in the browser on the player's own game files.
- [Case study: Tyrian 2000](https://tanepiper.github.io/game-frame/case-studies/tyrian.md): Tyrian 2026 is a clean-room, 1:1 reimplementation of Tyrian 2000 (version 3.0, DOS, 1999) in Rust, for Windows, macOS, Linux and the browser.
- [Case study: Frontier: Elite II](https://tanepiper.github.io/game-frame/case-studies/frontier.md): A 1:1 reimplementation of Frontier: Elite II (DOS, 1993) in Rust and wgpu, for native platforms and the browser, on the player's own copy of the game.

## Skills

- [Set up the toolchain](https://tanepiper.github.io/game-frame/skills/re-setup.md): Install and check the reverse-engineering toolchain (Ghidra, JDK 21, Python with Unicorn/pefile/capstone, objdump, Node for REA, Zig for the sample) and register the REA MCP server for the agent. Use at the start of a project, when a tool is missing or fails to start, or when REA tools do not appear in the session.
- [Reverse engineering a game: start here](https://tanepiper.github.io/game-frame/skills/re-start.md): Entry point for reverse engineering a game (or any closed program) with GameFrame, an agentic framework for reverse engineering games. Use first, whenever a task involves understanding, documenting or reimplementing a game from its shipped binaries and data files. Gives the rules, the loop, a first-session checklist, and routes each kind of task to the right re-* skill.
- [Inventory a game](https://tanepiper.github.io/game-frame/skills/re-inventory.md): First look at a game's files (Windows PE, or DOS MZ/NE/LE executables) - which binaries hold the game's own code, which engine and middleware it uses, whether it is native, managed, scripted or packed, which data containers and save files exist - and record it in docs/FINDINGS.md. Use at the start of a project, or when a new binary or file type turns up.
- [Observe the running original](https://tanepiper.github.io/game-frame/skills/re-observe.md): Run the original game where it can be watched, driven and captured - GameFrame's emulators, DOSBox-X, Wine, a Windows machine or a streamed PC, console emulators - and capture frames, state, inputs, calls, file reads and sound as measured evidence. Also list every input from outside, inventory every interface screen, and build a queryable object model of the game with entry points for tests and agents. Use after inventory, before porting a system whose behaviour you need to see, and whenever a question can be settled by running the original.
- [Investigate with REA](https://tanepiper.github.io/game-frame/skills/re-rea.md): When and how to use REA (Reverse Engineer Anything, the rea-agents MCP server) alongside GameFrame - quick evidence-backed inspection of binaries, archives, Android/iOS/.NET/Electron/browser targets, focused decompilation and call graphs through Ghidra, and runtime observation. Use for targets the text export does not cover, for a fast first answer about one function, or when a claim needs a citable Evidence record.
- [Decompile with Ghidra](https://tanepiper.github.io/game-frame/skills/re-ghidra.md): Decompile a game's binaries with Ghidra in headless mode and work with the result as text - the full export (decomp.c, functions, strings, imports, exports), queries with decomp_query.py, one-off decompiles of functions Ghidra missed, vtable and reference listings, constants read from the binary, and checks against the disassembly. Use whenever you need pseudocode for a native binary, including 16-bit DOS (MZ) and NE programs.
- [Trace a behaviour](https://tanepiper.github.io/game-frame/skills/re-trace.md): Find and understand how the original game implements something - from a string, a resource name, an import, an export, a C++ class name or a known caller to the function, its inputs, the fields it reads and writes, the constants it uses and the loop that calls it - and write the result down as evidence. Use for any "how does the game do X?" question before reimplementing or documenting it.
- [Decode a data format](https://tanepiper.github.io/game-frame/skills/re-format.md): Decode a game's data files - package/archive containers, compressed entries, resource and asset formats, save games - by finding the code that reads them, prototyping a decoder with tools/formats/reader.py, proving it against every file of its type with validate.py (all bytes consumed), then porting it. Use when a file type is not yet understood or a decoder fails on some files.
- [Emulate original code for ground truth](https://tanepiper.github.io/game-frame/skills/re-emulate.md): Run individual functions from a game's Windows x64 binaries (tools/emu/pe_emu.py) or 16-bit DOS/NE programs (tools/emu/dos_emu/) under the Unicorn emulator to capture exact ground truth for chosen inputs, and record the calls they make (random draws) with call_trace.py. Use for anything a reimplementation must match bit for bit - random number generators, maths, procedural generation, simulation steps, pathfinding, parsers - instead of trusting the pseudocode.
- [Reimplement, exactly](https://tanepiper.github.io/game-frame/skills/re-port.md): Reimplement traced game behaviour in new code that behaves exactly like the original - mirroring its structure, numeric types and order of operations, random draw order, iteration order and integer semantics, citing the original function on every item and marking every intentional difference as a Deviation. Also how to shape the reimplementation (an exact core, commands, digests, a headless runner) and keep additions such as multiplayer or mod code apart from it. Use when writing the reimplementation of anything traced (re-trace) and measured (re-emulate).
- [Verify against the original](https://tanepiper.github.io/game-frame/skills/re-verify.md): Prove that a reimplementation matches the original - bit-exact parity tests against emulator ground truth (bitcompare.py), random-draw order (seqdiff.py), determinism of two identical runs with digests at checkpoints and on every platform, recordings and replays, round trips of real save files, picture comparison against the original game, comparison between two versions of the reimplementation, and test tiers. Use after every reimplemented slice and before committing it.
- [Document, label, commit](https://tanepiper.github.io/game-frame/skills/re-land.md): Finish a slice of reverse-engineering work - write findings into docs/ in the evidence style, add function and field labels, update the checklist, then commit only your own files (never game material or decompiled code) and push, safely alongside other sessions. Use at the end of every trace, format, emulate, port or verify slice.

## Examples

- [DOS sample](https://tanepiper.github.io/game-frame/examples/dos-sample.md): A tiny 16-bit program for testing GameFrame's DOS tools.
- [The sample game](https://tanepiper.github.io/game-frame/examples/sample-game.md): A tiny Windows x64 game, written in C for GameFrame, to practise on and to test the tools.