DevilutionX: a maintained open source engine for Diablo and Hellfire

Why a port exists at all when the original still runs

The README states the purpose without inflation: DevilutionX is a port of Diablo and Hellfire that tries to make the game simple to run while providing engine improvements, bug fixes and some optional quality of life features. That is a reimplementation of the engine, not a copy of the game. The data files stay exactly where Blizzard put them, and the port reads them.

The practical reason to care is the platform list. The repository carries continuous integration workflows for Linux on x86_64, AArch64 and x86, macOS on x86_64, Windows under both MinGW and MSVC, Android, iOS, PS4, the original Xbox through the nxdk toolchain, Xbox One and Series, Nintendo Switch, PlayStation Vita, Nintendo 3DS and Amiga M68K. Very few engines from 1996 have that reach. A build badge per platform in the README is not proof of quality, but it does mean the project still bothers to compile on a PlayStation Vita.

The interface side is deliberately conservative. The screenshot caption notes that the health bar and experience bar are off by default and can be switched on in the game settings, and that widescreen can be disabled if you prefer the original framing. Those two lines say something about the design rule: the default is the original look, and anything new is opt-in through a config file documented on the project wiki.

Installing means supplying your own game data

There is no installer and nothing to buy here. The README's instruction is to download the latest DevilutionX release, extract it wherever you want, and copy your own `DIABDAT.MPQ` into that folder. If you do not have an original CD, it points at two places to buy Diablo, GOG.com and Battle.net, and it documents how to pull the archive out of the GOG installer.

For Hellfire there are four more archives to copy in: `hellfire.mpq`, `hfmonk.mpq`, `hfmusic.mpq` and `hfvoice.mpq`. More detail lives in `docs/installing.md` in the repository.

There is a path for people who have no copy at all, and it comes with a stated limit. The `spawn.mpq` file from the shareware release can stand in for `DIABDAT.MPQ`, which the README says lets you play the shareware portion of the game. Shareware Diablo is a truncated game, so treat this as a way to evaluate the port rather than a way to play.

Two consequences follow from the data-file approach. Saving, modding and configuration all live alongside your game data rather than inside it, so a clean reinstall of the executable does not touch your progress. And the executable on its own does nothing, which is the single most common misunderstanding people arrive with.

Stable releases and the faster moving master branch

The tagged releases tell you what has actually shipped. Version 1.5.5 came out on 2025-10-30 and its notes are a mixture of features and fixes: adjustable multiplayer game speeds, character name validation, CTRL plus mouse wheel for map zoom, ZeroTier multiplayer on iOS, a fix for crashes when a TCP connection times out, and a guard against stash corruption. Version 1.5.4 from 2025-02-08 added gamepad improvements, Windows XP and macOS PowerPC support, big-endian networking fixes and a set of save corruption guards. Version 1.5.3 from 2024-08-31 was mostly fixes, including errors converting Hellfire saved games.

Those notes are more useful than they look. Save corruption gets called out repeatedly across versions, and each release narrows it: 1.5.4 makes file sync services less likely to corrupt saves and loosens validation in single player games, while 1.5.5 guards the stash. If you are reading an old thread about corrupted saves, the version matters.

The gap between releases and commits is the other thing to understand. The default branch `master` was last pushed on 2026-09-28, months after 1.5.5, and the repository is not archived. The README's Test Builds section is the answer to that: nightly artifacts are published from CI for each platform, with an explicit warning to back up files because they may contain bugs and a note that you must be logged into GitHub to download the attachments. The full list of changes lives in `docs/CHANGELOG.md`.

What lives in the source tree and how it builds

The repository is a C++ project with a conventional layout. `Source/` is the engine itself, `3rdParty/` holds vendored dependencies, `CMakeLists.txt` and the `CMake/` directory are the build system, and `CMakeSettings.json` targets IDEs that read CMake presets. `Packaging/` holds the per-platform packaging, `Translations/` the localisation files, `assets/` the game art, and `docs/` the installing, building, contributing and changelog documents.

There are dedicated directories for the platforms that need them: `android-project/` and `uwp-project/` for the two mobile and Windows app forms. `test/` holds the test suite, which the repository tracks through `codecov.yml`, and `tools/` holds the modding tools the README mentions. `vcpkg.json` is the C++ dependency manifest, `Brewfile` exists for Homebrew, and `.devcontainer/` gives you a containerised environment if you would rather not set up toolchains by hand.

Modding gets more than a compiled binary. The README says the project provides the full source plus modding tools as a starting point, and points at a wiki page listing community mods built on DevilutionX. For a 1996 game engine, having the whole source public and documented is the more useful contribution, and it is what makes those mods possible at all.

How this compares to the original, the shareware demo and other mods

Against the original Blizzard release, DevilutionX is the same game with a maintained engine and a few optional conveniences. You keep the original data files, so nothing about your install is proprietary to the port. The trade is that you give up whatever the original does that the port has not reimplemented, and the wiki is where you find out what that is, since the README deliberately points there rather than listing features.

Against the shareware demo, the comparison is about how much game you get. The demo runs on the port through `spawn.mpq`, but it is the truncated release. Buying Diablo from GOG or Battle.net is the step that turns the port into the full game.

Against other community projects such as Belzebub, the difference in approach is that DevilutionX is a broad platform port with a published engine improvement and bug fix track, while the README makes no claim about other projects' scope. The useful signal for Belzebub is that the DevilutionX wiki maintains a community mods list, which is where a comparison would start rather than a feature chart.

There is also a limit worth stating plainly. This is Diablo and Hellfire. It is not Diablo II, and the related searches for this project keep returning Diablo II, which is a different engine with a different mod scene.

Contributing, testing and where the documentation stops

The README asks for help in five ways: coding, documentation, testing the latest builds, spreading the word, or hanging out on the Discord server. That middle item is unusual and practical. Test builds are how a project with seventeen platform targets catches regressions before a tagged release, and the README is honest that a test build needs a file backup.

The documentation is split across the wiki and the repository. The wiki holds the manual for available features, the config file reference that the health bar and widescreen options point at, and the community mods list. The repository holds `docs/CHANGELOG.md`, `docs/installing.md`, `docs/building.md` and `docs/CONTRIBUTING.md`. The README itself is short on purpose: it identifies the project, explains the data requirement, links the build instructions and shows the platform badges.

One licensing point deserves care rather than a summary. The repository is presented as free and open source work, but the thing it renders is Blizzard's data, which you must own. The README never asks you to patch or redistribute the MPQ archives, and that boundary is the one you have to respect when you use it.

Editorial conclusion

DevilutionX earns its place if you own a copy of Diablo or Hellfire and want it to run on hardware Blizzard never shipped it for, or if you want an engine you can read, patch and mod. It is the wrong tool for someone without the original data, because the executable alone is unplayable and the shareware route covers only a portion of the game, and it is the wrong tool for Diablo II, which is a different engine. Two practical notes before you start. The latest tagged release is 1.5.5 from 2025-10-30 while `master` was pushed on 2026-09-28, so the stable build and the current source are meaningfully apart, and the test build artifacts are explicitly labelled as possibly buggy. Start by dropping `DIABDAT.MPQ` into the release folder, read the config file page for the interface toggles, and browse the community mods list before deciding whether to compile anything.

Frequently asked questions

Official sources

1. diasurgical/DevilutionX on GitHub
2. Issues
3. README
4. Releases