# OpenHV: an open content RTS built as a mod on the OpenRA engine > OpenHV is a GPL-3.0 pixelart science-fiction RTS that runs as a mod for OpenRA, following the design of Daniel Cook's Hard Vacuum, with MiniYAML rules, Lua mission scripts, LAN and internet multiplayer, bots and a map editor. The judgement is that the mod architecture gives it an unusually small codebase and an unusually open content pipeline, and that it inherits the engine's pace and its constraints. **OpenHV/OpenHV** — An Open Source Pixelart Science-Fiction Real-Time-Strategy game - Repository: https://github.com/OpenHV/OpenHV - Website: https://www.openhv.net - Stars: 1,087 · Forks: 67 - Language: C# - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/openhv-openhv ## A mod, not an engine, and why that matters OpenHV is a mod for OpenRA, and that single word determines most of the project's characteristics. The description is precise: it is a mod for OpenRA based on the Hard Vacuum design by Daniel Cook, and it aims to be an open content real-time strategy game with no exceptions. Set in the distant future where a mega corporation battles itself, it comes with multiplayer support for LAN and internet, competent skirmish bots, and an integrated map editor. Spectators can join and replays can be shared. Running on an existing engine rather than shipping one is what keeps the codebase small and the content pipeline open. The repository layout shows it. There is `OpenHV.slnx`, the solution file, and the source is in `sources/`. There is `OpenRA.Mods.HV/`, which is the managed part of the mod, and `mods/`, which holds the content. The `mod.config` file at the root carries the mod's identity, and the Makefile reads `MOD_ID` and `ENGINE_DIRECTORY` out of `user.config` or `mod.config`. There is a `fetch-engine.sh` script, which is how the engine dependency is obtained, and `packaging/` for the distribution packages, whose status is tracked on Repology through the tiny-repos badge. The primary language is C#, and the licence for the source code is GPLv3, matching the OpenRA engine and the SDK scripts. The consequence of the mod architecture is that the game inherits the engine's characteristics, both the good ones and the rest. An OpenRA game is built on a fixed-timestep simulation with the engine mediating every interaction, which produces a distinctive, deliberate feel that many players love and others find slow. It also means an engine update can change how the game plays. The design lineage is worth naming because it explains the shape of the game. Hard Vacuum was a post-mortem by Daniel Cook of a game he made, and OpenHV follows that design rather than inventing a new one, which is why it reads as a reimplementation with an open licence rather than a new commercial strategy title. ## Game rules live in MiniYAML, missions live in Lua The content side of the project is the part that makes it genuinely open rather than merely free. Game rules are defined in text files using a dialect called MiniYAML, and there is IDE support in Visual Studio Code through the OpenRA extension published on the marketplace. The point of a text format for rules is that a rule change is a diff in a text file, reviewable in a pull request and editable without a special tool. Script missions or mini-games are written in Lua, with an API documented in the project's Read the Docs documentation, and a separate Visual Studio Code extension for code completion. So the two layers of customisation are distinct: MiniYAML for the rules that govern the game, Lua for the logic that scripts a mission or a mini-game inside it. The Makefile shows how both are checked in continuous integration. There is a `check-scripts` target that checks lua scripts for syntax errors, a `test` target that checks the mod yaml for errors, and a `check` target that checks the engine and the mod dlls for StyleCop violations. The `check-scripts` target is conditional on `luac` being available, which the Makefile detects with `command -v luac`, and the Lua file set is discovered by searching `mods/hv/maps/*` for `.lua` files. The build targets are correspondingly granular. `make` compiles, `make clean` removes the files created by compiling, `make version` sets the mods version, and `make TARGETPLATFORM=unix-generic` compiles using system libraries for native dependencies rather than the bundled ones. The version handling is itself worth a note. The `VERSION` variable is derived from `git name-rev --name-only --tags --no-undefined HEAD`, falling back to a `git-` prefixed short hash when there is no tag, so a build from a working tree still identifies itself. ## Building and launching differ per platform, and the docs are thin The getting started section is short, and the build is a two-step affair. To launch the project from the development environment you must first compile the project by running `make.cmd` on Windows, or opening a terminal in the SDK directory and running `make` on Linux or macOS. You can then run `launch-game.cmd` on Windows or `launch-game.sh` on Linux or macOS to run the game. So the workflow is: compile once, then launch. The `make` invocation is not a development server with hot reload in the usual sense, and the launch scripts are what actually start the game against the engine. The repository also has dedicated server launchers, `launch-dedicated.cmd` and `launch-dedicated.sh`, which is what you would use for a headless multiplayer server rather than playing locally. There are `utility.cmd` and `utility.sh` scripts as well. The build itself is a .NET build, and the Makefile reaches into the toolchain for the runtime identifier. `DOTNET = dotnet`, `RUNTIME ?= net6`, and `DOTNET_RID` is derived by parsing `dotnet --info` for the `RID:` field. The default target platform is otherwise derived from `uname`. The documentation is on Read the Docs, and the build instructions live in the project wiki rather than in the README. The README links to the wiki page on building the game for more details, which is where the parts the README skips are meant to be found. One practical note about the engine dependency. The `fetch-engine.sh` script exists to obtain the engine, and `ENGINE_DIRECTORY` in the configuration file tells the build where it is. That is a two-way relationship between the mod and the engine, and it is the thing most likely to cause friction for a new contributor, because a mismatched engine version produces failures that look like bugs in the mod. ## Content is licensed separately from the code, on purpose The licensing section is the most carefully worded part of the README, and it is split in two because the project covers two different kinds of work. The source code, the OpenRA engine and the SDK scripts, are all under GPLv3, with the `COPYING` file at the repository root. That is the copyleft part, and it is the same licence the engine ships under. The content is a separate matter. The mod data files, which are the artwork, the sound files and the game rules, are not part of the source code and are distributed under different terms. Five Creative Commons badges are shown, covering CC BY US 3.0, CC BY 3.0, CC BY 4.0, CC BY-SA 4.0 and CC0. The instruction is to check the ReadMe files in the sub folders for details. The reason for the split is the same reason the game is described as open content with no exceptions. A game whose rules are data files can have those files licensed permissively, and the choice of Creative Commons licences rather than GPL for art and audio is what lets a modder reuse a sprite or a sound in their own work without inheriting a copyleft obligation on the whole project. For a contributor, the practical rule is that the licence of the file you are editing is the one that applies to it. The `COPYING` file covers the code; the subfolder ReadMe files cover the content, and they differ from folder to folder. There is one more piece of infrastructure in the licensing section that is easy to miss. Free code signing on Windows is provided by SignPath.io, with the certificate from the SignPath Foundation. That matters operationally rather than legally: it is how the Windows builds are signed so that a user installing the game does not get an unsigned executable warning from the operating system. ## A small project with a broad release cadence and a dated tag The release history is where the project's current state is most visible, and it needs reading carefully. The listed releases are 20250628 from 2025-06-28, 20250715 from 2025-07-15 and 20250725 from 2025-07-25. So the tagged releases stop in July 2025, while the last push to the repository was on 2026-10-19. The repository is not archived, so the code is being worked on, but there has been no tagged release in more than a year. The tags are dated rather than versioned, which is a deliberate convention for a mod where the content and the build are coupled and a date is a more honest identifier than a semantic version. The `make version` target exists to set a custom version when that is needed, and the `VERSION` variable falls back to a git hash when no tag exists. Packaging is tracked through Repology, with a tiny-repos badge pointing at the OpenRA project entry, which is how a Linux user would find the package for their distribution rather than building from source. The project infrastructure shows a serious commitment to community participation. The README carries badges for continuous integration through a GitHub Actions workflow, a Read the Docs documentation status badge, and three separate chat platforms: a Discord server, a Matrix room, and IRC or Jabber on the FreeGameDev network with three channels, openhv, openhv-lobby and openhv-dev. A project with a development channel on a general games IRC network is one that expects people to show up and talk. The Makefile also has a `install` target, listed in its `.PHONY` line alongside the others. ## Where the OpenRA route costs you Two limitations follow from the mod architecture and are worth naming before anyone commits. The first is the engine coupling. A mod runs against a specific engine version, and the two move at different speeds. The `fetch-engine.sh` script and the `ENGINE_DIRECTORY` setting exist to manage that relationship, and the risk is that an engine update changes behaviour in a way that only shows up in play. For a player, that means the build you have is the build that works, and for a contributor it means testing against more than one engine version is not free. The second is the engine's own feature set. Anything the engine does not support cannot be added by the mod without forking the engine, which the project does not want to do. The listing of features in the README, multiplayer with LAN and internet, skirmish bots, an integrated map editor, spectators and shared replays, is the complete list of what the engine provides, and it is a good list, but it is a closed one. A third thing is worth noting about the licensing arrangement, though it is not a limitation. The engine is GPLv3, and the content is under a mixture of Creative Commons licences, one of which is CC BY-SA 4.0. For a modder who takes both the code and the content into a derivative work, the copyleft obligation of the code travels with the code and the share-alike obligation of that content travels with that content. The separation is clean, and it is the reason the project can call itself open content with no exceptions, but it does mean that a derived project has to track two licence regimes rather than one. For a comparison, a commercial RTS with an open engine would give you the same engine features and a much larger content pipeline with a single commercial licence, and the difference in what you can do with the assets would be the thing you would be giving up. ## Conclusion OpenHV fits a player who wants a complete sci-fi RTS with no paid content, no closed engine and no data-driven storefront, and who is comfortable with a retro aesthetic and the slower pace of an OpenRA-era game. It does not fit a team that needs a modern engine with modern netcode, and it does not fit a modder who expects the content pipeline to be a conventional asset pipeline. Verify first that the OpenRA engine version you have matches what the mod expects, since the mod ships a `fetch-engine.sh` script and the Makefile reads an `ENGINE_DIRECTORY` value from `user.config` or `mod.config`, that the platform packages for your operating system are current, and that the content licence terms in the subfolder ReadMe files are what you need, since the artwork, sound and rules are under a mix of Creative Commons licences rather than the GPL that covers the source code. ## FAQ ### How do I build and run OpenHV? Compile first with `make.cmd` on Windows or `make` in the SDK directory on Linux and macOS, then run `launch-game.cmd` on Windows or `launch-game.sh` on Linux and macOS. More details are on the project wiki's build page. ### What engine does OpenHV need and where does it come from? OpenHV is a mod for OpenRA, and the engine is obtained with the `fetch-engine.sh` script at the repository root. The build reads an `ENGINE_DIRECTORY` value from `user.config` or `mod.config` to know where the engine lives, and the `fetch-engine.sh` script has to be run first. ### How are OpenHV game rules and mission scripts written? Game rules are defined in text files using a dialect called MiniYAML, with IDE support available as a Visual Studio Code extension. Script missions and mini-games are written in Lua, with a documented API and a separate extension for code completion. ### What licences apply to OpenHV code and content? The source code, the OpenRA engine and the SDK scripts are under GPLv3, with the `COPYING` file at the repository root. The mod data files, meaning artwork, sound and game rules, are not part of the source code and are distributed under various Creative Commons licences, and the subfolder ReadMe files give the details. ### Does OpenHV have multiplayer and a map editor? Yes. The game comes with multiplayer support over LAN and internet, competent skirmish bots and an integrated map editor, and it allows spectators to join and replays to be shared. Dedicated server launchers are provided as `launch-dedicated.cmd` and `launch-dedicated.sh`. ## Sources - [License: GPL-3.0](https://github.com/OpenHV/OpenHV/blob/main/LICENSE) - [OpenHV/OpenHV on GitHub](https://github.com/OpenHV/OpenHV) - [Project website](https://www.openhv.net) - [README](https://github.com/OpenHV/OpenHV/blob/main/README.md) - [Releases](https://github.com/OpenHV/OpenHV/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openhv-openhv