Freedoom is not a game program, it is three IWADs and a rule that every asset must be original

It is data, not a program, and that shapes everything

Freedoom is a complete, free content first person shooter game based on the Doom engine. The README makes the first thing clear: Freedoom is not a program, it consists of the levels, artwork, sound effects and music that make up the game, and to play it must be paired with an engine that can play it.

That distinction is the whole architecture. A source port, as the community calls the engines, is downloaded separately, and the README points to the Doom Wiki for the lengthy list of options, with GZDoom singled out as particularly recommended for its support of single player, multiplayer and the majority of mods made for both Doom and Freedoom.

The installation story follows from the split. On Windows you place the Freedoom data files, the ones ending in `.wad`, alongside the engine executable. On Unix-like systems they go in `/usr/share/games/doom` or in your home directory, and if your operating system distribution packages Freedoom it should already be in the right place. Distributions also install programs named `freedoom1`, `freedoom2` and `freedm` that automatically run an engine, along with desktop files so the game can be started from a graphical interface instead of the command line.

Those three wrapper names are worth noticing. They are not three engines, they are three entry points into whatever engine the distribution has chosen, one per campaign, and a distribution that ships them has already solved the engine selection problem for its users.

Three games in one, with deliberate compatibility targets

Freedoom is actually three games in one: two single-player oriented campaigns and one set of levels designed exclusively for multiplayer deathmatch.

Phase 1 is four episodes of nine levels each, 36 levels in total, and it aims for compatibility with The Ultimate Doom mods, also known as plain Doom or Doom 1. Phase 2 is 32 levels in one long episode, featuring extra monsters and a double-barrelled shotgun, and it aims for compatibility with Doom II mods. FreeDM is a 32-level game designed for competitive deathmatch play.

The compatibility targets are a design constraint rather than a marketing line, and they are enforced in the contribution guidelines. Every level must be vanilla-compatible, requiring an expanded-limits or limit-removing engine is not permissible, you may not exceed the limits of the original Doom engine, and you may not depend on additional mapping features. Levels should be in Doom's original format, not in Hexen format.

The reason to impose that is the same reason the project is not a Doom clone. If the data stays inside the vanilla limits, then any engine can run it, including the strict ones, and the game survives the death of any particular port. The contribution guide says to test levels in Chocolate Doom, described as an engine with strict adherence to vanilla Doom limits and bugs, because working in it assures that levels can be played with any Doom engine. It also recommends using a Doom editor to check for errors, with Eureka's Check All menu or the F9 key, and running `make test` if possible.

The guideline against renderer tricks is the subtlest of them. Software-renderer tricks, such as simulating 3D bridges or deep water effects, may render incorrectly on engines with hardware acceleration, so the guide asks contributors not to use them.

The originality rule is the real contribution policy

The intellectual property section of the contribution guide is where Freedoom differs from most open projects, and it is worth reading closely.

The rule is that you must have permission for everything you submit. If you make your own resources, do not base them on resources from Doom or any other restricted work. If you take work from other places, make sure it is freely licensed or that you obtain permission to include it, and contributors may not place additional restrictions compared to the normal Freedoom licence.

The guide also corrects a misreading of the project. Freedoom's name leads some people to think the goal is to make a free clone of Doom, and the guide says plainly that this is not the case. Compatibility with Doom is a goal, but the project is building its own game, and contributors are asked to make an effort to ensure their work is original and distinct rather than a copy of anything from Doom.

The warning about free resource sites is the practical trap. Although they look usable at first glance, many are free for non-commercial use only, and one of the things the project wants to be able to do is put its content in GNU/Linux distributions, which can be sold or developed commercially. A non-commercial asset in the tree would make the whole distribution unusable, so the rule is about protecting the content's reusability rather than about purity.

The contrast with the wider Doom modding scene is explicit. Most Doom projects are lax about reusing intellectual property, and there are many mods that contain modified Doom sprites. Freedoom does not have that liberty, and the guide says so without hedging.

A DeuTex tree is the source, and the Makefile is the build system

Freedoom ships its complete source code, and the README says so as one of the freedoms it wants you to have: you may study it, for example to see how an IWAD is built. The form of that source is a DeuTex tree.

The Makefile shows how that becomes a playable file. DeuTex is the tool that assembles the WAD, and the build defines the basic arguments including a rate of accept, with a variant that adds the Doom 2 flag against the bootstrap directory. The three outputs are `wads/freedoom1.wad`, `wads/freedoom2.wad` and `wads/freedm.wad`, and the default target builds the check plus all three.

The subdirectory structure mirrors the content pipeline. There are separate targets for `lumps/dehacked` because the graphics and text depend on generated dehacked files, then for `graphics/text`, `lumps/playpal`, `lumps/colormap`, `lumps/genmidi`, `lumps/dmxgus`, `lumps/textures`, `lumps/wadinfo` and `bootstrap`. The `lumps/` directory is the raw lump content, `graphics/` and `sprites/` are the visual assets, `sounds/` and `musics/` are audio, `levels/` holds the maps, `flats/` holds the floor textures, `manual/` holds the manual sources, and `dist/` and `scripts/` handle packaging and helper tooling.

A few details in the Makefile are practical rather than historical. The version string comes from `git describe`, falling back to `v0.14.0-alpha-unknown`, so the build records the exact source revision. There is a `deutex-check` target that verifies the installed DeuTex supports PNG, because the game assets are PNG files, and a `pngs-modified-check` target. The legacy transparency index is handled explicitly, with 255 replaced by 133, which is the kind of detail that only matters because a specific old engine needs it.

Node building is delegated to a separate tool, ZenNode, with its own level patterns, and the `bootstrap` directory holds the entry points for the Doom 2 style build.

The manual, the documentation and the release state

Freedoom ships a PDF manual that describes how to play, including an introductory tutorial and tactical tips, along with information on the monsters and power-ups encountered during play. It is available in multiple languages from the project website, and printed physical manuals are also sold.

That detail is a good sign about the project's seriousness. A free content project that writes a proper manual, translates it and produces a printed edition is treating itself as a released product rather than a hobby archive, and the manual source is in the repository as AsciiDoc files, one per language, which the Makefile picks up with a wildcard and builds into PDFs through the asciidoc and a2x toolchain.

The documentation in the repository is structured. There is `README.adoc` as the main readme, `COPYING.adoc` for the licence terms, `COMPILING.adoc` and `BUILD-SYSTEM.adoc` for the build, `NEWS.adoc` for the release notes, and `CREDITS`, `CREDITS-LEVELS` and `CREDITS-MUSIC` files that credit contributors separately for the project, the levels and the music. Separating the credits by category tells you that level design and music are recognised as distinct contributions, which is true of this scene.

The release history is sparse in a way that is worth understanding. v0.13.0 was published on 2024-01-29, before that v0.12.1 on 2019-10-22 and v0.12.0 on 2019-10-10, a gap of more than four years between the 0.12 and 0.13 series. The last push to the repository was on 2026-10-02 and the repository is not archived, and the Makefile fallback version of `v0.14.0-alpha-unknown` tells you there is work in progress on the next series. The work is continuous, the tagged releases are occasional, and a user picking a version should read NEWS.adoc rather than assume the latest tag is recent.

Editorial conclusion

Adopt Freedoom if you want a complete, freely distributable single player shooter that runs on any Doom engine, and you are willing to pair it with an engine you obtain yourself. Do not adopt it if you need a game that ships as one executable, because the project explicitly is not a program and requires an engine alongside the data files. Verify first that the engine you plan to use supports the IWAD format and the monster set you need, that your platform has a package that installs the data in the right location, and that the licence file matches what you intend to do with the assets, since the project treats redistribution and modification as freedoms rather than permissions.

Frequently asked questions

Official sources

1. freedoom/freedoom on GitHub
2. Issues
3. Project website
4. README
5. Releases