KisakCOD: a buildable open source rebuild of the Call of Duty 4 engine

A from-source rebuild of a 2007 game engine

KisakCOD is described as an open source fully-buildable reimplementation of Call of Duty 4, and the stated audience is mod developers and COD4 enthusiasts.

Fully buildable is the operative phrase. This is not a set of patches or a wrapper around the shipped game. It is source code that compiles into an executable that replaces the original engine, and the readme's build steps make that concrete, since they end with copying the original game files into the build output directory and running the resulting binary.

That arrangement is why the requirements list includes Steam with a copy of Call of Duty 4. The reimplementation provides the engine and the tooling; the game content, the maps and the assets come from the retail release, and the readme is explicit that you should not cherry-pick them because small files like the localization file are also needed.

So the project is a clean-room-ish engine reimplementation in the sense that the code is public and buildable, but it is not a content reimplementation. You still need to own the game.

The build requirements are a Windows host with Visual Studio 2022, CMake 3.16 or newer, the DirectX SDK 2010, and Steam with the game. The DirectX SDK 2010 requirement is a period detail that tells you what era the code targets, and it is the kind of constraint that makes a project like this awkward to build on a current machine.

The primary language is C++, the licence is GPL-3.0 with the logo image in the repository, and the last push was on 2026-10-02. The single tagged release is v0.1 from July 2026, so the versioning is young.

The build is a generated project, not a checked-in one

The build procedure is eight steps and the second one is the one that matters, because the solution files are not in the repository.

2) Open a terminal and run `generate-project.bat`
3) Open .sln projects that are generated in `build-sp`, `build-mp`, and `build-dedi` respectively. 
4) Copy COD4 Game files to `bin/(BUILD_TYPE)/*` (Don't try to cherry-pick them, small files like localization.txt are needed)
5) Copy `deps/binklib/binkw32.dll` as well ^^
6) Copy all files in `deps/msslib/dlls/*` ^^ 
7) Copy `deps/steamsdk/steam_api.dll`  ^^
8) Run the game via Visual Studio play button or just the .exe

Step two runs generate-project.bat from a terminal, and step three opens the .sln projects that are generated. So the build inputs are produced rather than stored, which is why there is a build-win.bat and a generate-project.bat at the top level rather than a set of .sln files, and why the CMakeLists.txt sits alongside a scripts/ directory.

The repository layout backs that up. There is a src/ directory for the source, a deps/ directory for the third party pieces, a scripts/ directory, a milesEq/ directory for the sound system code, and the CMake configuration at the root.

The deps directory is the part to look at first, because the readme tells you exactly what has to be copied out of it. You need the binkw32.dll from the binklib directory, everything in the msslib/dlls directory, and the steam_api.dll from the steamsdk directory. Those are the Bink and Miles Sound System libraries and the Steam API, which the original game shipped and which cannot be redistributed here.

That is why the copy step exists at all. The licences on those libraries do not permit redistribution inside an open source repository, so they are pulled in from the retail installation at build time. The build-win.bat script and the deps/ directory together are the shape of a project that has to work around what it cannot ship.

The three generated project directories named in step three, build-sp, build-mp and build-dedi, correspond to the single player, multiplayer and dedicated server configurations, and the copy instruction in step four puts the game files under a bin directory keyed by build type.

The warning about exploits is the most useful thing in the readme

There is a fenced block in the readme that is not code at all, and it is the part of the document that a new contributor should read first.

Keep in Mind: This is a ~20 year old game with some known exploits. We will try to fix these as we become aware of them.
However, there is a non-zero chance of some type of binary exploitation when playing online. Use a sandbox (Sandboxie?) for peace of mind. 

The point is that this is a roughly twenty year old game with some known exploits, that the project will try to fix them as they become known, and that there is a non-zero chance of some kind of binary exploitation when playing online, with the suggestion to use a sandbox such as Sandboxie for peace of mind.

That is an unusual thing to find in a readme and it is the honest thing to find. A reimplementation of an old engine inherits the assumptions the original made about its own memory layout and input handling, and those assumptions have had two decades to be found and weaponised. The project is telling you that running it against other people on the internet carries a risk that has nothing to do with the quality of the reimplementation.

It also explains why the troubleshooting section exists in the form it does. One entry is for not being able to connect to a dedicated server, and the advice is to check net_ip and net_port, with the detail that the server will increment the port if the preferred one is not available but the client will not sweep upwards. So a port conflict resolves on the server side and leaves the client pointing at nothing, which is a specific and useful thing to know.

The other entry is for a DLL error upon launch, and the cause is that you did not copy over the necessary runtime DLLs. That is the deps/ copy step again, failing in the least obvious way.

For a project aimed at mod developers, the practical use case is local: building the engine so that the game can be run with modified content, with the online case carrying the caveat above.

Credit where the code came from, and a physics engine that is not stock

The credits section is a short list and two of the entries are about code rather than about people.

The first is the Jedi Academy fork from PJayB, credited for the .sln setup, which is the same project generation problem KisakCOD faces and therefore a natural thing to borrow from. The second is the CoD2rev server, credited as useful yacc code for the gsc scripting here.

That second entry is a good indicator of the kind of work this is. The gsc scripting in Call of Duty is a Quake-style scripting language, and the compiler for it is a yacc grammar. Finding that grammar work already done for an earlier Call of Duty title, rather than writing one, is the difference between a project that exists and one that does not.

The third code credit is BO3Enhanced, credited as having been viewed as reference code for some of the Steam API auth. So the Steam authentication path is informed by another open source project rather than written from scratch.

The two library credits are RAD Game Tools for the Bink and Miles Sound System libraries, and ODE Physics, where the readme notes that COD4 uses a modified version of this physics engine. So the physics is not stock ODE, which matters for anyone who wants to understand the simulation and for anyone who wants to change it.

And then the first line of the list, credited to all the original COD4 developers for creating one of the best games of all time, which is the credit that a reimplementation project cannot avoid and that the licence terms make it important to state.

The combination tells you something about how the project was assembled. The engine behaviour comes from the original game, the tooling patterns come from other open source reimplementations of related games, and the physics and audio come from third party libraries that were themselves modified for the original game.

A development blog, and an explicit invitation to use AI

Two smaller things in the readme are worth noting because they say something about how the project runs.

The first is the development blog, which is where the work is written up, at the Duty-Of-Kisak site. For a project that started recently and is at version 0.1, a public log of the development is how a contributor finds out what is being worked on without reading the issue tracker.

The second is the FAQ, and there is only one question in it: can AI be used in this project. The answer is yes, but you are still responsible for whatever you commit, and in general the AI should be assisting you and not carrying you. It adds that the project has started using AI to help de-bug, and that it has been extremely helpful.

That is a more nuanced position than a blanket yes or no. The answer draws a line between assistance and authorship, and it puts the responsibility on the person committing the code rather than on the tool that produced it.

The project also has a Discord for discussion, and a known issues section that points at the GitHub issues tracker rather than listing them in the readme, which is the normal arrangement for a project with active bug reports.

Taken together, the shape of this repository is a from-source engine reimplementation for a 2007 game, aimed primarily at mod development, that expects you to own the game, that builds on Windows with an old DirectX SDK, that pulls its audio and physics libraries from a retail installation rather than shipping them, and that tells you plainly that running it online carries an exploitation risk inherited from the original engine.

For a modder who wants to run modified content locally, that is a workable and honest set of terms. For anyone looking for a general purpose engine, the DirectX 2010 dependency and the copy-from-retail step make it a specialised project rather than a foundation.

Editorial conclusion

KisakCOD suits a modder who wants to run modified content against a real engine rather than a mock-up, since the whole engine is in source and the build produces working single player, multiplayer and dedicated server configurations. It does not suit you if you want a modern engine, since it needs Windows with the DirectX SDK 2010, and it does not suit you if you do not own the game, because the content has to come from your Steam install. Before you play it online, take the readme's own advice and run it in a sandbox, because the exploitation risk it describes comes from the original engine's memory assumptions and not from anything the reimplementation added.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SwagSoftware/KisakCOD on GitHub