OpenBF2: A Battlefield 2 Engine Rebuild That Tells Its AI Agents to Stop Guessing

By Indie Kings | October 22, 2026

Updated October 22, 2026: OpenBF2, a project that rebuilds the Battlefield 2 1.50 engine from the game's shipped Windows and Linux binaries, has 161 stars three weeks after its repository was created and a contributor guide that is more interesting than most. It requires anyone recovering engine code to have IDA or Ghidra open with the original binaries loaded, and it forbids AI agents from opening pull requests or answering reviewers.

Image: GitHub repository card for B2BF/OpenBF2, a reconstruction of the Battlefield 2 1.50 engine.

What OpenBF2 is rebuilding

The README states the goal in one sentence: reconstruct the Battlefield 2 1.50 engine from the shipped Windows and Linux binaries, so that there is a stable and secure dedicated server, a client that works on modern operating systems, and a proper editor. It adds the standard the project holds itself to, which is that the result should be indistinguishable from retail and provide every feature retail did.

That is a larger claim than a mod or a patch, and the repository is structured like an engine project rather than a game project. It is C++ under GPL-3.0, created on 1 October 2026, with 26,826 KB of source and a default branch called main. At the time of writing it has 161 stars, 26 forks, 6 watchers and 15 open issues.

The name is new. The fourth most recent commit, made on 18 October, is titled "Rename project to OpenBF2 and revise description", so the project spent its first two and a half weeks under a different name. The same day's commits clarify a DirectX 9 SDK requirement for builds, which is the sort of dependency that tells you how close to the original toolchain this project is working.

The gap between compiling and playing

The most important paragraph in the README is the warning under the introduction. Parts of the engine remain incomplete, it says, and a successful compilation or a diagnostic executable does not establish a playable game.

That sentence does a lot of work. In a reconstruction project, a build that links is a milestone, not a product: it proves that the reconstructed translation units agree with each other, not that the game loop runs, that assets load, or that a client can join a server. Making the distinction explicit is unusual and healthy, because the usual failure mode in this genre is a screenshot of a compiling target followed by months of silence.

It also explains the shape of the work. The project is not porting a game; it is recovering an engine image by image, function by function, from two retail binaries, then validating each recovered piece against the original. The docs directory reflects that: architecture covers image boundaries, source layout and lifecycle; development covers recovery evidence, code conventions and validation; there is a separate recovery notes directory.

What is in the tree

The tree is small enough to read at a glance. At the root there is a CMake build, a licence, the README, and three agent instruction files named AGENTS.md, CLAUDE.md and GEMINI.md. Under Code there are nine directories:

The ABI directories are the detail that separates this from a decompilation with a nice README. Each name pairs an engine subsystem with an application binary interface: AI, audio, the Direct3D 9 renderer, the Flash player and the VoIP server. The README does not describe what those interfaces contain, so the claim a reader can support from the tree is narrower than it looks: the project has separate targets for the engine, for the interfaces it exposed, and for the tools. Pinning the renderer name to Direct3D 9 is still a useful signal, because it says the reconstruction aims at the API the original shipped with rather than at a modern one.

The docs also include an editor console reference and a CI releases guide. The release guide is there because the project already publishes builds through its own workflow, which the release page confirms.

The agent rules, which are the real story

AGENTS.md is the part of this repository that will be quoted elsewhere, and it is worth reading in full because the rules are stricter than most human contribution guides.

The first rule is evidentiary. Anyone working on recovered engine code must have IDA or Ghidra connected and accessible, with the relevant original Battlefield 2 1.50 binaries loaded. If the tool or the required evidence is missing, the instruction is to stop that recovery work rather than guess.

The second rule is about authorship. Agents must not create or submit pull requests or reply to reviewer questions. The human author must fully understand every submitted change, its evidence and its validation, and the human submits the pull request, answers the review and takes responsibility for the contribution.

The third rule is about scope. Non-retail fixes, improvements and features are welcome only when a linked issue already contains discussion of the proposed approach before implementation begins, editor-only work included. AI may assist with those changes, but the issue has to exist first, and any intentional departure from retail behaviour has to be distinguished from recovered code in the description, the documentation and, where needed, the source comments.

Our take: this is the most useful contribution policy this site has read in a project of this age. It does not ban AI assistance, which would be unenforceable and mostly performative. It does three things a ban cannot. It requires a specific tool with a specific binary loaded, which makes the evidence checkable. It locates responsibility in a named human, which is the only place it can sit. And it forces new behaviour to be argued in an issue before it is written, which stops an agent from turning a reconstruction into a redesign one plausible-looking commit at a time.

The three separate instruction files are their own signal. AGENTS.md, CLAUDE.md and GEMINI.md are read by different tools, and maintaining all three means the rules are meant to apply regardless of which assistant a contributor uses. The repository is also telling you, in the file listing, that AI assistance is expected rather than tolerated.

What has actually landed

The recent commit titles are small, specific and mostly fixes, which is what recovery work looks like when it is going well. In the ten most recent commits:

A VoIP server was implemented, pull request 49. The QR2 response stopped sending an AIBot_ value in place of the nn_groupid array, pull request 51, which is a protocol detail that would break server browsers rather than gameplay. The Linux server began reporting its OS as linux-64, pull request 52. Missing console commands were added with corrected signatures, pull request 46. Projectile and penetration bugs were fixed. Two more commits address invalid ticket and team values, though their titles are all the public record shows.

None of those is a headline feature, and all of them are the kind of thing that has to be right before a server is usable. The ticket fix is the clearest example of where a reconstruction has to make a decision the original never documented: the original engine trusted its own data, and a rebuilt one has to decide what to do with a ticket count that cannot be valid. The commit title, "fix: invalid tickets", closes issue 58, but the public metadata does not say whether the value is now rejected, clamped or ignored. That is a detail worth reading the diff for before relying on it.

The pull request numbers in the forties and fifties, two weeks after the repository was created, are their own measure of throughput. This is a project with a review process that is being used.

Four test releases and no playable client

The release page is where the project is most careful and least impressive, in the sense that matters. There are four releases, all marked prerelease, and the most recent one, published on 18 October 2026, has no downloadable assets at all. Its tag name is stored as tags/release-18102026, with the prefix included, which is the kind of detail that suggests the release process is being learned in public.

The earlier test-release-3 is more informative, because it shows what the build produces:

Every artifact ships with a separate SHA-256 file, which is the right minimum for unsigned build output. The download counts are in the single digits, which is consistent with a project whose releases are tests rather than products. Calling the client and editor builds diagnostic is the same honesty as the README warning: a binary that starts is not a binary that plays.

The size gap between the Linux and Windows server archives, 45.8 MB against 2.7 MB, is worth a note. A Linux build that large usually carries debug information or a differently linked runtime, and without the archive contents the reason is not something a reader should guess. What can be said is that the two are not equivalent packages, and anyone testing should read the CI releases document rather than assume they are interchangeable.

The legal and practical position

Our take: this is a serious technical project with an unresolved legal question, and the project is honest about the technical half.

OpenBF2 reconstructs an engine from binaries that Electronic Arts and DICE shipped. It is GPL-3.0, and it does not appear to ship game assets, but a reconstruction of a proprietary engine's code occupies a different position from a clean-room reimplementation, and the difference is what a court would examine rather than what a README can settle. The project's own framing, that the result should be indistinguishable from retail, is exactly the goal a compatibility project needs and exactly the claim a rights holder would test. We are reporting on the code, not offering a legal opinion.

The practical warning is narrower. The releases are prereleases, the client builds are diagnostic, and the latest release has no binaries. If you want a Battlefield 2 server today, this is not it yet. If you want to contribute, the barrier is not enthusiasm: it is a licensed copy of the original binaries, a Windows toolchain with the DirectX 9 SDK, and enough reverse-engineering experience to load an image in IDA or Ghidra and defend what you recovered.

There is also a supply-chain point that applies to any unsigned diagnostic build. Verify the SHA-256 files that ship alongside each archive, and do not run a client or server binary from a mirror that does not publish them.

FAQ

What is OpenBF2?
A C++ reconstruction of the Battlefield 2 1.50 engine, rebuilt from the game's shipped Windows and Linux binaries, aimed at a stable dedicated server, a modern client and a working editor.

Can I play Battlefield 2 with it now?
Not from the releases. The project says parts of the engine remain incomplete and that a compiling build or diagnostic executable does not establish a playable game. The latest release has no assets, and the client builds are labelled diagnostic.

Is it affiliated with EA or DICE?
The repository does not claim any affiliation. It is a third-party reconstruction of a proprietary engine, released under GPL-3.0, and the legal position is unresolved.

Why does it need IDA or Ghidra?
Because recovered code is validated against the original binary. AGENTS.md requires the disassembler to be connected with the relevant 1.50 binaries loaded, and says to stop rather than guess when the evidence is missing.

Can AI agents contribute?
AI may assist, but agents may not open pull requests or answer reviewers. A human must understand every change, its evidence and its validation, and that human submits and defends it.

What is in the test release?
Test-release-3 carried Linux and Windows x64 server archives, plus 32-bit diagnostic server, client and editor builds, each with a SHA-256 file. The 18 October release carried no assets.

Bottom Line

OpenBF2 is the most disciplined reconstruction project to appear in this batch, and the discipline is procedural rather than technical. The technical plan is sound: recover the engine image by image from the shipped binaries, reproduce the ABI surfaces that content and plugins depend on, and validate each piece against the original. The commit history shows that plan being executed in small increments, with protocol fixes, console command signatures and input validation landing before anything resembling a feature.

What makes it worth watching is AGENTS.md. Requiring a disassembler with the original binary loaded, banning agents from submitting pull requests or answering review, and forcing new behaviour through a linked issue before implementation is a better answer to AI-assisted reverse engineering than either a ban or uncritical enthusiasm. It makes the evidence checkable and the responsibility human.

The caveats are real. There is no playable client in the releases, the newest release has no binaries at all, the Linux server archive is much larger than the Windows one for reasons a reader cannot verify, and the legal question around reconstructing a proprietary engine is not answered by a GPL-3.0 licence. If you are a Battlefield 2 server operator, this is a project to follow rather than deploy. If you are a reverse engineer, the contribution rules tell you exactly what standard your work will be held to, which is more than most projects offer before you spend a weekend on a patch.

Sources

• OpenBF2 repository README and AGENTS.md, B2BF/OpenBF2, accessed 22 October 2026
• Repository tree listing and documentation index, B2BF/OpenBF2, accessed 22 October 2026
• Commit history and release assets for B2BF/OpenBF2, accessed 22 October 2026
• GitHub repository metadata for B2BF/OpenBF2, accessed 22 October 2026

Related: Halo 2 Decompilation: 9,383 Functions Match Byte for Byte on Original Xbox | Zelda Wind Waker HD Recomp: A World Editor and 20 Releases in 16 Days | Bloodborne PC: One Port, Two Forks, Two Ideas of a PC Version