# OpenEnroth: a modern reimplementation of the Might and Magic VI to VIII engine

> OpenEnroth is an open source C++ reimplementation of the Might and Magic VI to VIII engine that reads the original game data, ships Windows, Linux, macOS and experimental Android builds, and today can play MM7 only while MM6 and MM8 remain on the milestones list.

**OpenEnroth/OpenEnroth** — Open reimplementation of Might and Magic 6 7 8 game engine

- Repository: https://github.com/OpenEnroth/OpenEnroth
- Stars: 875 · Forks: 114
- Language: C++
- License: LGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/openenroth-openenroth

## The engine is open, the game data is not

The single most important fact about OpenEnroth is what it is not. It is not a game. It is an open source reimplementation of the Might and Magic VI to VIII game engine, written in C++, and it deliberately contains no game assets of its own. The README states that it uses the original game data, so you will need a copy of the game to play. What you get from the project is the engine, and what you have to supply is the content.

That boundary is why the project sits where it does legally and practically. It ships binaries, not content. The data comes from a legitimate purchase, and the README points at the GOG.com listing for Might and Magic VII, noting that copies from other sources such as an original retail disc should also work.

The minimum requirement is narrower than a full install. At the very least, OpenEnroth requires the ANIMS, DATA, MUSIC and SOUNDS directories from the game data. That set is what every platform section repeats, which makes it easy to check whether an extraction worked before blaming the engine.

The project is not archived, the last push was on 2026-10-20, and the release feed shows a nightly build from 2026-09-28. Supported platforms are Windows, Linux, macOS, and Android, with the Android build labelled experimental.

## Extracting a GOG installer on Linux and macOS needs innoextract

On Windows you run the GOG installer and the data lands on your disk. On Linux and macOS the installer cannot be run directly, and the README's answer is a third party extraction tool called innoextract, which handles the Inno Setup format the GOG installer uses.

The install step differs by distribution. On macOS the instruction is to install Homebrew if you do not have it and run:

```bash
brew install innoextract
```

On Debian based systems, which the README lists as Ubuntu or Debian including Linux Mint and Pop!OS, the command is:

```bash
sudo apt install -y innoextract
```

On Fedora or other RedHat based systems, with immutable distributions such as Bazzite called out as exceptions, it is:

```bash
sudo dnf install -y innoextract
```

For anything else, the README points at Repology, which lists package names for most distributions. Once the tool is present, the extraction itself is one command, and the README gives it in inline form with the destination and the installer path as placeholders:

```bash
innoextract -e -d <new game data directory> <path to GOG installer .exe>
```

The -e flag extracts, -d sets the destination directory. This is the step where a wrong path costs you the most time, because the game data has to end up where the engine can find it afterwards.

## OPENENROTH_MM7_PATH overrides where the engine looks for data

Each platform has its own expected location for the game data, and there is a single escape hatch that works everywhere. You can set an environment variable called OPENENROTH_MM7_PATH to point at the location of the game data. If it is set, OpenEnroth will look for game assets only in that location, which is a useful property when your layout differs from the expected one.

The variable is worth adding to your shell profile, and the README suggests ~/.profile on Linux or ~/.zshrc on Mac:

```bash
export OPENENROTH_MM7_PATH="<path-to-mm7-game-assets>"
```

The word only matters. When the variable is set, the engine does not fall back to scanning its usual directories, so a stale or wrong path produces an engine that cannot find its data rather than one that quietly tries somewhere else.

For Flatpak on Linux, the expected location is inside the sandbox instead, at ~/.var/app/io.github.openenroth.openenroth/data/mm7/data/, where you create the directory and move at least the ANIMS, DATA, MUSIC and SOUNDS folders in. The Flatpak case is worth planning for, because a path override inside the sandbox and a path override on the host are not automatically the same thing, and the README does not spell out how the two interact.

## Four platform layouts, one set of game folders

The Windows install is the simplest. You download the zip, unzip OpenEnroth.exe and OpenEnroth.pdb into the directory that contains the game data, and run the executable. The debug symbols are shipped alongside the binary, which tells you these are RelWithDebInfo builds, the kind you want when a crash needs to be readable.

On macOS the steps are longer because of how the platform treats downloaded applications. You move the game data to ~/Library/Application Support/OpenEnroth, creating the directory if needed, then download the arm64 disk image, with an x86_64 variant for Intel Macs, open it and drag OpenEnroth.app into Applications. Then there is the quarantine step, which the README explains as clearing the quarantine flag because macOS will refuse to launch unsigned binaries without it:

```bash
xattr -rc /Applications/OpenEnroth.app
```

Linux uses Flatpak. You check for support by running flatpak --version, install the flatpak package from the releases page with flatpak install --user, create the data directory described above, and then launch from the application menu or with flatpak run io.github.openenroth.openenroth.

Android is the experimental branch. The README is candid: Android is not actively tested by the dev team, so expect issues and be prepared to troubleshoot. You install the universal APK, allow installation from unknown sources, and copy the game data to /sdcard/Android/data/io.github.openenroth.openenroth/files/. The same four directories are needed on every platform.

## Nightly only, MM7 only, and a v0.1 milestone for stability

The distribution channel tells you what maturity to expect. The README says that currently only nightly builds are available, which may have bugs, and that a stable release is in progress, tracked against the v0.1 milestone. The releases page carries the nightly artifacts, one per platform, named with a consistent pattern including the RelWithDebInfo suffix.

Game coverage is narrower still. Currently only MM7 is playable. MM6 and MM8 support is planned, and the README points at the project milestones for the current state of that work. That is a commitment expressed through a tracker rather than a date, so treat it as a plan rather than a schedule.

For a project with this scope, the engineering signal is in the repository layout and the tooling rather than in the README. The top level carries CMakeLists.txt, CMakeModules/, CMakeSettings.json, a CPPLINT.cfg, a .clang-tidy configuration, a .editorconfig and a Doxyfile, plus src/, test/, thirdparty/, android/, distribution/, scripts/ and a HACKING.md with build instructions, code style guidelines and contribution guidelines. Separate build and lint GitHub workflow badges indicate both are enforced on every push.

The licence is LGPL-3.0, which matters more here than in most projects. An LGPL library used as a dynamically linked dependency carries obligations that a permissive licence does not, and the licence text governs how you distribute a build that includes it. This is a licensing fact to check against your own use, not a legal opinion.

## Where OpenEnroth is the wrong tool

The wrong-tool cases are structural and worth stating plainly. If you want Might and Magic VI or VIII, this is not the project yet. If you do not own the original game data, the project cannot help, because there is no bundled content and no trial path described anywhere in the setup instructions.

The second wrong case is a stable, supported build for a production or shared environment. Nightly builds that may have bugs are acceptable for a personal install and awkward for a lab machine with twenty copies of the game, or for a distribution you ship to other people. The v0.1 milestone is the concrete thing to wait for if that matters to you.

The third is Android. The README itself flags that platform as not actively tested by the dev team and expects you to troubleshoot. Treating an experimental build as a daily driver means accepting that the path to the data directory on a modern Android phone, where scoped storage restricts writes to app specific folders, is exactly the kind of thing the maintainers cannot keep ahead of.

What OpenEnroth offers where nothing else does is straightforward: an engine that keeps older titles running on current hardware and current operating systems, with the game data the player already owns.

## Conclusion

OpenEnroth is a good fit for a player who owns Might and Magic VII and wants it running on a current platform, and a poor fit for anyone hoping to play MM6 or MM8 today, since only MM7 is playable and the other two are still tracked on the project milestones. Before you start, confirm you have the original game data, since OpenEnroth ships no assets of its own and requires at least the ANIMS, DATA, MUSIC and SOUNDS directories, and download a nightly build rather than expecting a stable release, because the project states that a stable release is in progress against the v0.1 milestone.

## FAQ

### Do I need to own Might and Magic VII to use OpenEnroth?

Yes. OpenEnroth is an engine reimplementation with no assets of its own, so you need the original game data. The README points to the GOG.com listing for Might and Magic VII and notes that other copies, such as an original retail disc, should also work.

### How do I extract the GOG game data on Linux or macOS?

The GOG installer cannot be run directly on Linux or macOS, so the README recommends innoextract. Install it with brew install innoextract on macOS, sudo apt install -y innoextract on Debian based systems or sudo dnf install -y innoextract on RedHat based ones, then run innoextract -e -d <new game data directory> <path to GOG installer .exe>.

### Which game folders does OpenEnroth actually need?

At the very least the ANIMS, DATA, MUSIC and SOUNDS directories from the game data. On Flatpak on Linux they go into ~/.var/app/io.github.openenroth.openenroth/data/mm7/data/, and on macOS into ~/Library/Application Support/OpenEnroth.

### Can I point OpenEnroth at game data in a custom location?

Yes. Set the OPENENROTH_MM7_PATH environment variable to the game data location. When it is set, OpenEnroth looks for game assets only in that location, so the value has to be correct.

## Sources

- [Issues](https://github.com/OpenEnroth/OpenEnroth/issues)
- [License: LGPL-3.0](https://github.com/OpenEnroth/OpenEnroth/blob/master/LICENSE)
- [OpenEnroth/OpenEnroth on GitHub](https://github.com/OpenEnroth/OpenEnroth)
- [README](https://github.com/OpenEnroth/OpenEnroth/blob/master/README.md)
- [Releases](https://github.com/OpenEnroth/OpenEnroth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openenroth-openenroth