BohemiaInteractive/CWR: the Operation Flashpoint engine source, now C++20 and CMake
Arma: Cold War Assault Remastered Source Code Repository.
At a glance
- What is it?
- Bohemia Interactive has published the Poseidon engine and game code behind Arma: Cold War Assault under GPL-3.0-or-later with Section 7 terms. The code is open, the brand is not, and the game data is a separate download.
- Who is it for?
- Adopt CWR if you want to read or port a 2001-era simulation engine that has already been moved to C++20, or if you are building a fork under a new name. Do not adopt it if you need an actively developed upstream: the README states the repository is locked, pull requests are not accepted, and it will not be continuously updated, so issues are limited to bugs in the official Steam builds.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 31 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What CWR actually is, and who the repository is aimed at
CWR is not a game download. It is the engine and game source code (the README gives the codename Poseidon) behind Arma: Cold War Assault, the 2001 release originally shipped as Operation Flashpoint: Cold War Crisis. The README frames the publication as a release to the community that has kept the game alive for more than two decades, to study, build on, fix, and create from it.
The audience that follows from that framing is narrow and technical. People who want to play need the retail game or the free Demo data on Steam. People who want to compile something, port the engine, or read how a large military simulation handled terrain, AI and vehicles in the early 2000s are the ones this repository serves. The README separates three things explicitly: the source code in this repository, the trademarks, and the game data. Confusing them is the most common mistake a newcomer will make.
How the repository is organized and how the build is wired
The layout is a normal multi-target CMake tree with a Rust workspace bolted alongside it. apps/ holds executable targets, engine/ holds engine libraries plus Rust Trident tooling, mserver/ holds a Rust service and CLI crates, tests/ holds test source trees, cmake/ holds presets, toolchains, vcpkg triplets and overlay ports, and thirdparty/ holds vendored headers and sources.
The Rust side is declared in Cargo.toml as a workspace with members engine/Trident, mserver/Archive, mserver/Client, mserver/CLI and mserver/MasterService. Three profiles are defined there: dbg inherits dev, rwdi inherits release with debug = true, and rel inherits release. The rwdi profile is the one that matches the CMake preset names, which tells you the intended build is a release binary with debug information rather than a debug build.
Two details in the layout matter for anyone planning work. packages/ is described as an ignored local game data staging area, so the repository expects you to place data there yourself rather than shipping it. And the README notes that CI currently compiles the tests only, which is a weaker signal than a passing test suite and should temper any assumption about test coverage.
Building CWR with the win-x64-clang-rwdi and linux-x64-clang-rwdi presets
The README's Quick Start is two commands. The first configures the project with a preset, the second builds it. On GNU/Linux you use the matching linux-x64-clang-rwdi preset instead.
cmake --preset win-x64-clang-rwdi
cmake --build build/win-x64-clang-rwdiThe preset name encodes the toolchain: Clang, x64, and the rwdi profile (release with debug info) that Cargo.toml defines. Dependencies come through vcpkg, with vcpkg.json at the repository root and triplets under cmake/. If configuration fails, the first place to look is the vcpkg setup, not the CMake files, because the preset assumes vcpkg is available and the triplet matches your host.
After a successful build you have binaries, not a playable game. The README is direct about this: the compiled binaries need game data to run. The free Demo data is on Steam, and the full data ships with the retail game. You stage that data yourself; the repository does not include it.
The licence split is the part that trips people up
Three licences apply to three different things, and the README is unusually blunt about the boundaries. The source in this repository is GPL-3.0-or-later with additional terms under Section 7 of the GPL. The thirdparty/ directory is excluded from the project's GPL and carries its own licences for vendored code such as glad and the RenderDoc API header. Dependencies pulled through vcpkg likewise stay under their own licences, documented in thirdparty/README.md and THIRD_PARTY_NOTICES.md.
Game data is not in the repository and is not GPL. Models, textures, sounds, missions and voices ship separately under the Arma Public License Share Alike, linked from the README to bohemia.net. Whatever you do with assets is governed by APL-SA; whatever you do with the source is governed by the GPL plus the Section 7 terms in LICENSE.
The trademarks are the third piece and the one most likely to cause a problem for a fork. The README states that ARMA, Operation Flashpoint and the logos are not granted, that a fork must be renamed, and that it must not present itself as Arma or as an official Bohemia Interactive product. This is a factual summary of what the repository says, not legal advice; read LICENSE and the Section 7 terms before you publish anything derived from this code.
The locked-repository policy and what it means for a fork
The most consequential line in the README is under Contributing: this is a locked repository, pull requests are not accepted, and it will not be continuously updated. Issues are restricted to bugs in the official Bohemia Interactive builds distributed on Steam. For ideas, development builds, ports and community work, the README points you at forking the code or joining the community continuation.
That policy shapes everything downstream. There is no upstream to send a patch to, so any fix you make lives in your fork or nowhere. The repository layout still contains the scaffolding of a maintained project (clang-format, clang-tidy, sanitiser suppressions for LSan, TSan and UBSan, a valgrind suppression file, a .github directory, a .trident.env.example), and the last push was on 2026-08-18. Those files tell you the code was cleaned up for publication, but the README's own statement about continuous updates is the authority on where development happens, and it says elsewhere.
Treat CWR as a snapshot with a licence attached, not as a project with a maintainer waiting for your pull request.
Where CWR is the wrong choice, and what to compare it against
CWR is the wrong tool if you want a modern engine to build a new game on. It is a 2001-era simulation codebase that has been brought up to C++20 and CMake, which is a different thing from being designed for current hardware and current tooling. If your goal is a new military simulation, an engine with an active upstream and current documentation is the better starting point; CWR's value is historical and archival as much as practical.
A fair comparison is with the engines that grew out of this lineage, Real Virtuality and its successors, which the README names as the technology line that began with this release. Those are proprietary and not published as source. The practical difference is stark: with CWR you get readable, modifiable, GPL-licensed C++ and no vendor support, no official binaries and no asset rights. With a commercial engine you get support, tooling and a licence that costs money and restricts redistribution.
If you only want to play the game, none of this applies. Buy it or take the free Demo on Steam and skip the repository entirely.
Frequently asked questions
The FAQ entries below are answered from the README and repository files only. Where the repository is silent, the answer says so rather than guessing.
Editorial conclusion
Adopt CWR if you want to read or port a 2001-era simulation engine that has already been moved to C++20, or if you are building a fork under a new name. Do not adopt it if you need an actively developed upstream: the README states the repository is locked, pull requests are not accepted, and it will not be continuously updated, so issues are limited to bugs in the official Steam builds. Before you start, confirm that your compiler and vcpkg setup satisfy the win-x64-clang-rwdi or linux-x64-clang-rwdi preset, and check the LICENSE Section 7 terms together with the APL-SA link, because the source and the assets do not travel together.
Frequently asked questions
What is Bohemia Interactive known for?
The README states that the 2001 release of Operation Flashpoint: Cold War Crisis launched Bohemia Interactive and began the technology lineage that later grew into Real Virtuality, Arma, and Enfusion. This repository holds the engine and game source behind that release, now titled Arma: Cold War Assault.
Is there a game where I can design my own car?
The repository does not describe vehicle design or any in-game vehicle editor. It contains the engine and game source code, and the README says game data such as models is not part of the repository and ships separately under the APL-SA license.
How do I get into a vehicle in Arma 3?
The repository does not document Arma 3 gameplay, and the README does not cover entering vehicles. CWR is the source code for Arma: Cold War Assault, a different title, and its documentation is limited to building the engine and licensing the code and assets.
How do I get a car in Arma Reforger?
The README does not mention Arma Reforger or vehicle acquisition in any game. CWR covers only the Arma: Cold War Assault engine source, so this question falls outside what the repository documents.
Community notes