OpenNox: an open reimplementation of the Nox engine, without the game data

An engine reimplementation, not a game release

OpenNox describes itself as an open-source community collaboration project extending the Nox engine. That distinction is the whole project in one sentence, and it is the same distinction the legal section makes later on.

What the project claims is compatibility with the original. OpenNox supports all vanilla Nox features, and the expectation stated in the documentation is that you should be able to complete the campaign and play online with it. If something does not work, the instruction is to open an issue. There is also a separate documentation site with a page listing the new features added on top of the vanilla game, at opennox.github.io/docs.

The primary language is C, and the repository layout confirms it: a src/ directory for the engine sources, an app/ directory for the application layer, res/ for resources, and a scripts/ directory alongside them. There are also docker/ and snap/ directories for the two packaging routes the project supports, and a docs/ directory with the build instructions for each platform.

What is not in the repository is the game. No assets, texts, artwork or other media from the original games is included, and the project says so in the legal section without hedging. That is what makes it a preservation and modding effort rather than a redistribution, and it is also why the engine can be licensed under the GNU General Public License version 3 while the game itself cannot be.

The project is explicit that it is unofficial and has no affiliation with Electronic Arts or the Nox brand, and that Nox is an Electronic Arts brand with Westwood Studios holding the copyright.

The legal position is the design constraint

The legal section of the project documentation is short and unusually specific, and it tells you how to think about the rest of the project.

Four statements carry the weight. The project is an unofficial community collaboration project for preservation, modding and compatibility purposes. It has no direct affiliation with Electronic Arts Inc. or the Nox brand. No assets, texts, artwork or other media from the original games is included. And the project does not condone piracy in any way, shape or form, and encourages users to legally own the original game.

So the deal is straightforward. You build the engine yourself from the source in this repository, and you supply the game data yourself from a copy of the game you own. That is why the repository can be GPLv3: the code is the community's own work, and the content stays with the rights holder.

There is a second licence layer worth knowing about. The project additionally follows the C&C Remastered Modding guideline published by Electronic Arts, and the documentation states that all changes to the project must follow those rules. So a contribution to OpenNox is subject both to the GPLv3 in the repository's LICENSE file and to a separate set of modding rules from the publisher. The OpenNox logo was created by CCHyper under a CC0 licence, so the trademark of the project itself is separated out from the game trademarks.

The one licensing question the documentation does not answer for a reader is the practical status of the original game's assets on a modern system. If the retail release of a 2000 game no longer runs on current hardware, the engine work here does not by itself solve that, and the project does not claim otherwise.

Releases come from the dev branch, and the tags lag the source

The distribution arrangement is simple to describe and slightly awkward in practice.

All release builds are made from the dev branch, which is also the repository's default branch. Recent releases are published on the GitHub releases page. There is a Snap package for Linux, with the stable channel carrying Linux releases and the edge channel carrying nightly builds. The AUR carries three Arch Linux packages: opennox, opennox-bin and opennox-git.

The nightly channel is worth reading carefully, because the wording is precise. On each commit, an automated build of the dev branch is uploaded. These builds contain all the latest merged features, but are not yet considered stable for release. They exist to provide an insight into what the next release will contain and should only be used for active playtesting purposes only.

That last phrase, said twice in one sentence, tells you the project treats nightly as a preview channel rather than a supported one.

The release history is where the arrangement shows its cost. The three most recent tags are v1.9.0-alpha13 from 2024-01-27, v1.9.0-alpha12 from 2024-01-01 and v1.8.12-alpha11 from 2023-11-23. All three are alphas, and all three are more than two and a half years old, while the last push to the repository was on 2026-09-21. So the source is moving and the published binaries are not following it at the same pace.

The practical reading is that the Snap edge channel and the AUR opennox-git package are the only artefacts tracking current work, and that a person who installs the stable channel is installing code from the start of 2024.

Building the engine and the client is two different targets

The build documentation is split by platform, with separate pages for Linux, Windows, and Windows built on Linux. The Makefile at the root of the repository shows what the targets actually are.

The server and the client are built separately, and the tooling is a Go program rather than a plain compiler invocation:

build-server:
	cd ./src; \
	go run ./internal/noxbuild server

build-client:
	cd ./src; \
	go run ./internal/noxbuild client client-hd

build-client-win:
	cd ./src; \
	go run ./internal/noxbuild --os=windows client client-hd

The noxbuild tool takes a target argument, and the client-hd variant is the high definition client. The third target passes --os=windows to cross-build the Windows client from a Linux machine, which is why there is a separate Windows-on-Linux document at all.

The Docker targets show how the images are assembled. The server image uses docker/Dockerfile_server with the server target and is tagged ghcr.io/opennox/opennox:dev, and a second variant produces a demo image tagged ghcr.io/opennox/opennox:dev-demo. The client target uses docker/Dockerfile_client and produces ghcr.io/opennox/opennox-client:dev, then extracts the built binaries out of the image with docker create and docker cp into a local ./build directory, so the client can be run from the host rather than from inside the container.

Both the server and the client images pass GIT_SHA and GIT_TAG, derived from git rev-parse and git name-rev, as build arguments, so the binary can identify the commit it came from. There is also a build-docker.sh script at the repository root and a cxgo.yml alongside cxgo_h.yml, which are the configuration files for the cxgame cross-compilation toolchain.

Code formatting is handled by a Makefile target that runs clang-format over the source tree with the project's own .clang-format file.

Where OpenNox is the wrong tool

The first limit is the most obvious one. This is an engine, not a game, and the distinction is not a technicality in the README but a legal necessity. Without a copy of the original game you own, there is nothing for the engine to display, and the project is explicit that it encourages users to legally own the original game and includes no assets of its own. A person looking for a download that just runs is looking for something this project deliberately is not.

The second is the release line. The published tags are alphas from late 2023 and early 2024, while the source has moved on through 2026. A person who wants the current state of the code has to build it, or take a nightly or edge channel build, and the documentation says nightly builds are for playtesting only. There is no stable, recent, curated binary.

The third is that the game itself is from 2000 and the work is compatibility work. Online play depends on services and protocols that were designed for the era, and the project's own framing, that it exists for preservation, modding and compatibility, is an acknowledgement of that. A new feature page exists on the documentation site listing what has been added on top of vanilla, which is a good sign of activity, but it also tells you that the baseline is a game that needs help.

The fourth is the licensing interaction for contributors. Any change must follow both the GPLv3 and the C&C Remastered Modding guideline from the publisher. That second constraint is unusual for an open source project and a contributor has to satisfy a ruleset published by a rights holder with no obligation to keep it stable.

The fifth is the size of the build. Compiling requires the C toolchain, the Go toolchain for noxbuild, and the cxgame cross-compilation setup, and the documentation pages for Linux, Windows and Windows-on-Linux each carry their own prerequisites. This is a build-from-source project, and the packaging channels exist precisely because the build is not small.

A project funded by its community, and how to reach it

The community infrastructure is worth a short mention, because for a preservation project the community is the actual asset.

There is a Patreon link in the project header under the badge for supporting the project, a Discord server, and a Matrix room at the nwca.xyz homeserver under the opennox name. Three separate platforms for the same conversation is a deliberate spread, and for a project with an ageing audience it reduces the cost of staying in touch with the people who still play.

The contributing guide is a separate CONTRIBUTING.md at the repository root, and the top-level entries include a CONTRIBUTORS file as well as a CHANGELOG.md, so the history of who did what is tracked in the repository rather than only on a wiki. The .github/ directory holds the workflows, and the badge at the top of the readme points at the build-and-release workflow on the dev branch, which is the same branch the releases are cut from.

The homepage is the documentation site rather than a marketing page, which is a reasonable choice for a project whose main audience arrives already knowing the game.

One more practical detail for anyone evaluating the project: all release builds are made from the dev branch, and the nightly build runs on each commit of that same branch. That means the repository's default branch is the trunk for both, and the tags are the branch snapshots rather than a separate curated line.

Editorial conclusion

OpenNox is worth installing for a player or modder who wants the 2000 Westwood game running on a current system with community fixes on top of it, because the project supports the vanilla feature set including campaign and online play, because the release and nightly channels are automated rather than hand-assembled, and because the code carries no game assets, so there is nothing in the repository you have to license to use it. It is the wrong choice if you expect a current, documented game or a stable release train. Before you commit to it, check the three things the project itself tells you: that all release builds are cut from the dev branch, so the tags are the branch rather than a curated release line, that the most recent tags are alphas from January 2024 even though the last push was on 2026-09-21, so the published binaries lag the source considerably; that the nightly builds are for active playtesting only and are explicitly not considered stable for release; and that you need to own the original game, because the repository ships the engine and no assets, texts or artwork from it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. opennox/opennox on GitHub
3. Project website
4. README
5. Releases