vladtrc/iw4L: a Rust and Bevy runtime for Call of Duty: Modern Warfare 2

What the project is, and what it is not

IW4L is an open-source runtime for Call of Duty: Modern Warfare 2 from 2009, written in Rust with Bevy. You point it at a copy of MW2 you already own, and it loads that installation's maps, models, textures and weapons into its own engine.

That sentence is the whole project, and it has three consequences that are worth stating plainly.

The first is that the engine is a reimplementation rather than a wrapper. The maps, models and textures come from your installation, but the thing that draws them, simulates them and moves the player through them is Bevy and wgpu, not the original Direct3D 9 code. The shaders are translated rather than reused, with retail Shader Model 3 bytecode converted to WGSL.

The second is that IW4L distributes no game assets, and it reads your installation without patching or replacing the files. That is what makes the project legally clean and it is also why you need your own copy.

The third is the state of the work. The README says gameplay remains incomplete and to expect missing behavior, bugs and desyncs, and the "What you can try" list is explore maps, fight bots, and record and replay demos. The asset readers also cover MW3 and Black Ops, so the scope is wider than the one title the name suggests.

There is also a line in the README that would be unusual to read in a README, which is that the whole project is written by an LLM. That is a material fact about how the code came to exist and it belongs in any honest evaluation of it.

The engine, area by area

The table of implementation areas is the clearest summary of the work, and it reads like a plan for a port rather than a list of features.

| Area | Implementation | |---|---| | Assets | Native FastFile readers convert game data into a shared intermediate representation. | | Shaders | Retail Direct3D 9 Shader Model 3 bytecode is translated to WGSL. | | Rendering | World geometry, models and effects feed one sorted draw-surface list. | | Simulation | Server authority, client prediction and replay share one simulation step over explicit Bevy ECS state. | | Networking | Custom UDP traffic; a QUIC master provides browsing and relaying. The host simulates the match. |

Three of those lines describe genuinely hard work. Reading FastFile containers, the format the retail game shipped its assets in, and converting them into one intermediate representation is the prerequisite for everything else, because a modern engine needs a modern asset model. Translating Shader Model 3 bytecode to WGSL is a compiler problem, and it is the kind of thing that silently breaks when a shader uses a feature the translator did not cover.

The simulation line is the most interesting architecturally, because it puts server authority, client prediction and replay on one simulation step over explicit Bevy ECS state, which means a replay is not a recording of inputs but a re-execution of the same code path, and that is how you get deterministic demos.

The networking line splits the problem in two, with custom UDP traffic for the game protocol and a QUIC master for browsing and relaying, where the host simulates the match. The master is a separate service because the browser side of it needs to talk to a server that knows about the sessions.

Running it with three bots and your own game data

The build and run section is short and it assumes you have what you need.

You need Rust through rustup and GNU Make, with the build dependencies documented in `docs/BUILD.md` covering the Linux C and C++ toolchain and system libraries and the macOS Xcode command line tools. Then you need your own installed MW2 Multiplayer data, and you point the project at it through an environment file, copied from the template and edited to set `IW4L_GAMES` to the folder containing your game installations.

cp .env.example .env
# Edit .env: set IW4L_GAMES to the folder containing your game installations.
make map mp_boneyard CMDS='wait world; spawn 0; force_match_start; bot add 3'

That builds the optimized `play` profile and starts a local match with three bots. The `force_match_start` command skips the warmup that otherwise freezes movement, which is the sort of detail that tells you the project has been run many times.

The environment file also carries a second variable, `IW4L_RELEASE_KEY`, pointing at a private CA directory used by `cargo xtask certs`, and the comment tells you to keep it outside the repository and never to commit the `.env` file. The Makefile includes the `.env` if it exists and exports it, so the machine local paths are not hard coded anywhere in the build.

Caches, demos and logs go under `iw4l-artifacts/`, and on Linux the settings use a separate configuration directory described in the run guide, so a debug run does not disturb your real configuration.

Multiplayer means everyone runs the same build

There is a warning in the README that is easy to skim and important to understand, and it has two halves.

The first is that APIs, configuration, caches and the wire protocol change between commits. That is normal for an experimental project, and it is stated plainly.

The second is that multiplayer peers must run the same build. This is a consequence of the design, because the custom UDP traffic carries the game protocol, and a peer running a build with a different protocol expectation will not interoperate. So the network is not versioned, it is assumed identical.

The practical consequence is that the project is a place to experiment rather than a service to join. If you want to play online, you need an operator with a master, because the `.iw4l-server` file comes from a server operator and the game finds that master and updates itself on launch.

For the Windows build the README is specific. You download `iw4l-windows.zip` from the releases and extract it into an empty writable folder, and the archive password is `t.me/contextrot`. You launch `iw4l.exe`, it finds MW2 in your Steam libraries and creates a `Modern Warfare 2.lnk` shortcut next to itself, and for an install outside Steam you create that shortcut to your MW2 folder yourself. The `docs/WINDOWS.md` guide covers the arrangement of a portable folder.

Provenance, attribution and the licence

The acknowledgements section is unusually careful, and for a project that reimplements a commercial game it is the part that tells you how the work was done.

OpenAssetTools and its iw4x-x64 fork informed the asset layouts, IW4x informed asset and protocol behaviour, and KisakCOD informed the engine structure. Ghidra was used to inspect the original binaries.

Then there is the line about movement. The movement implementation history and the source boundaries are recorded in a provenance note at `docs/provenance/movement-iw4.md`, and the fact that the project publishes a per system provenance document is a strong signal about how the authors think about reimplementing proprietary code.

The licence position is equally clear. The source is Apache 2.0, and when redistributing you have to preserve the required attribution and the bundled font licence texts, with the `NOTICE` file as the reference. Original game assets and trademarks belong to their owners and IW4L is unaffiliated with them.

The repository backs this up with the paperwork: a `NOTICE` file, a `THIRD-PARTY-LICENSES.txt`, a `SECURITY.md` for reports, a `CONTRIBUTING.md`, a `CONTEXT.md` and an `AGENT.md` at the root, which is presumably the working notes for the LLM that wrote the code. There is also a `flake.nix` and `flake.lock` for a Nix development environment, a `rust-toolchain.toml`, `rustfmt.toml` and `clippy.toml`.

Where this is the wrong thing

The first wrong case is playing the game. The feature list is a research surface, explore maps, fight bots, record and replay demos, and the README warns about missing behaviour, bugs and desyncs. If your goal is to play Modern Warfare 2 in 2026, this is not the way.

The second is a production base. The wire protocol changes between commits and multiplayer peers must run the same build, which is the opposite of what you want from a dependency, and the version numbers say the same thing, since the tags are v0.1.0-demo.20, v0.1.0-demo.21 and v0.1.0-demo.22, three demo builds in three days.

The third is a legal misunderstanding. The source is Apache 2.0 and the game is not. If you were planning to ship something built on this, the assets are not yours, the trademarks are not yours, and the project is explicitly unaffiliated with the rights holders. The licence covers the code, not the content, and the `NOTICE` file and the third party licence list are there because redistribution has obligations.

The fourth is an expectation of a finished engine. The asset readers, the shader translation, the simulation and the networking are each a large piece of work, and a reimplementation of a 2009 game is not a weekend project no matter how the code was written.

On the state of the project, the recent tags are demo builds from 2026-10-12 and 2026-10-14, the last push was on 2026-10-14, and the repository is not archived. The workspace is large, with dozens of crates, one per system, from asset readers and animation to rendering, replay, the launcher and the master, and the workspace manifest even carries a patch pinning quinn-proto to a specific git revision because the released 0.11.17 panics under relay backpressure, with a comment saying to remove the pin when a crates.io release includes the upstream fix. That is a small detail, and it is a good summary of what kind of project this is.

Editorial conclusion

Adopt iw4L if you are interested in how a 2009 shooter actually works, if you want to modify its movement, bot or rendering behaviour, and if you can accept a runtime that is explicitly experimental, that distributes no game assets and that you must feed with an installation you own. Do not adopt it as a way to play the game, since the feature list is a research surface rather than a game, and do not treat it as a stable base to build on, because the APIs, configuration, caches and wire protocol change between commits and multiplayer peers must run the same build. Verify first that you have a legitimate Modern Warfare 2 installation with the Multiplayer data, that the FastFile asset readers cover the titles you want, since they also cover MW3 and Black Ops, and that you read the provenance note in `docs/provenance/movement-iw4.md` before treating the movement implementation as your own.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. vladtrc/iw4L on GitHub