Open-BFME-1: rebuilding a 2003 game executable byte for byte in C++

The acceptance test is identical bytes, not a similarity score

The goal is stated in one line and it is a strict one: rebuild the retail executable byte for byte from source, then use that source to fix and improve the game. The unit of work is deliberately tiny, because the project rewrites the game's code as C++ one small piece at a time, and the rule for a piece is that it must rebuild to the exact bytes of the original executable, identified as BFME 1 version 1.03. Only when every piece matches and links does the readme treat the game as open source, with bug fixes and mods as the payoff. The repository's own short description puts the intended result more precisely, calling it a one to one binary swappable recreation, which is the practical test: a rebuilt executable that can replace the retail one in an existing installation, rather than a reimplementation that merely behaves similarly. Three progress bars report that state separately, which is the part worth understanding: rebuilt from source counts anything that produces the original bytes including partly generated code and prebuilt libraries, game code in C++ counts only the game's own code with no libraries, and linking counts the part sitting in files that link cleanly, measured as a link census.

One roadmap item is finished, and it is the network delay fix

The roadmap is a checklist of nine items and only one carries a tick. The network delay fix is done. Everything else is open: the BFME 1 source code itself, a memory fix, better crash logs, 60 and 120 FPS support, multi CPU support, world builder source code, and 16 player maps. The attack and camera fix is the most interesting of the unfinished ones, because it is the only item carrying a status note. It is described as live-tested for the reported case and opt-in until other horde fights are tested, with the details held in a mod directory under a numbered feature path. That distinction between a tested case and an untested class of cases is the pattern the project uses throughout, and it is a reasonable one for a byte-exact rebuild where a wrong fix is worse than a missing one.

Source in game/ and worldbuilder/, ledgers in targets/, binaries in inputs/

The status section is a map of the repository in four clauses, and it explains the unusual layout. The source being rewritten lives in two directories, one for the game and one for the world builder, and each piece of it is tracked in a ledger under `targets`. The original binaries, the toolchains and the reference material sit in `inputs`, which is how the project can compare its output against something. Mods live in their own directory, which is where the opt-in attack and camera fix and anything else that changes behaviour without touching the rebuild lives. The separation matters for a contributor: the game source, the accounting of what has been converted, the evidence and the experiments are four different places, and a change that edits one without the others will not survive the next verification run.

A 2003-era toolchain is committed, so a plain clone is enough

The build story is unusual because the toolchain travels with the code. The MSVC 7.1 toolchain and the baseline executables are committed to the repository, and explicitly not through Git LFS, so a plain `git clone` gives you everything needed to compile. Two commands follow:

./tools/setup_hooks.sh   # enable the pre-commit byte-check (git won't do this from a clone)
./build.sh               # verify every tracked function against retail   (\.\build.cmd on Windows, same arguments)

The setup step exists because git does not install hooks from a clone, so without it the byte check simply is not running and a wrong commit looks like a right one. The build script verifies every tracked function against the retail binary, and the Windows entry point takes the same arguments. A full gate takes about half an hour on four cores, which is why the readme also shows how to check a single function by passing its file:

./build.sh game/Libraries/Source/WWVegas/WWMath/color.cpp

On Linux the build runs through Wine 11 with a 32-bit prefix

The Linux instructions are the most environment-specific part of the documentation, and they name a specific problem rather than a general requirement. The supported route is WineHQ's Wine 11, distributed as the stable channel, initialised with a 32-bit prefix through a `WINEARCH=win32 wineboot -i` step. The failure mode of getting it wrong is named too: the Wine 9.0 shipped with Ubuntu 24.04 hangs the compiler on a few files, which is a hang rather than an error message, and therefore a slow way to lose an afternoon. The combination of an old 32-bit compiler, a modern Linux distribution and a byte-exactness requirement is what produces that specific advice, and it is also why the project ships its own toolchain rather than asking you to install one.

One verified function per commit, and a prompt for agents

The contribution model is unusually specific, and the readme is blunt about why. It asks that an AI agent be given an exact prompt rather than a vague one, and reports that in six measured sessions a vaguer version produced zero progress. The loop it prescribes is: read the agent instruction file and follow it, take the served candidate's whole file, convert the bodies to byte-exact C++, bank each verified body as its own commit, and before stopping run the progress script against the origin branch. If the C++ exact figure has not gone up by at least zero bytes, keep going, and open a pull request once a few bodies have landed. The merge rule that follows is one line each: every commit in a pull request is a single verified function. The closing note is unambiguous that machine-generated pull requests are wanted here, and the invitation to take part is a Discord server rather than an issue tracker process, which fits a project whose contributions arrive as many small verified commits.

A Quake 3 sort function at the root, a hooks directory and a Pages report

The root of the repository contains a few things that explain how the project is run. There is a `build.sh` and a `build.cmd` side by side for the two platforms, a `tools` directory holding the setup script and the progress reporter, a `githooks` directory holding the byte check that has to be activated manually, an agent instruction file at the top level, and an attribute file for line endings. One entry is more memorable than the rest: a Quake 3 insertion sort source file sits at the repository root, its name carrying a memory address, which reads as the seed function the whole effort started from. Progress is also published as an interactive report on a GitHub Pages site rather than only in the readme. The project is GPL-3.0, it is not archived, it has no tagged releases, and the last push to the master branch is dated September 29, 2026.

Editorial conclusion

Use this repository if you want to study how a shipped Windows game is reconstructed from disassembly, or you want to contribute verified functions in a project whose merge rule is one byte-exact body per commit. Do not treat it as a playable release, since there are no tags and no builds published here, and do not assume the road map is close to done, because one of its nine items is finished. Before you start, run the setup script so the pre-commit byte check is active, since a clone does not install hooks, expect a full verification gate to take around half an hour on four cores, and check your Wine version on Linux, because an older packaged build is reported to hang the compiler on a few files.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases