Procedural Dungeon: handcrafted rooms, procedural layout, Unreal plugin

Rooms are levels you made, not meshes the tool makes

The plugin's central idea is that rooms are handmade Unreal levels instanced in the world. You define their size and their doors, along with several other parameters, and then you write the rules that decide which room goes where. The stated aim is to combine the creativity and precision of handmade room designs with the unpredictability of procedural generation, and the division of labour is strict. The plugin does not build walls or place assets. It takes a set of room levels you authored, knows their bounds and door positions, and stitches them into a layout according to rules that live in your project. That split is the entire difference from the approach where a generator emits geometry, and it has an obvious consequence. The art direction of every room is entirely under your control, and the plugin never fights you about surface finishes, lighting or modular kit pieces, but you also have to author the room content yourself, which is the bulk of the work in a dungeon game.

The generation rules are yours, in Blueprint or C++

The example in the documentation makes the model concrete, and the rules are described as extremely simple. A special room, shown in red, spawns the player. Then 10 rooms are chosen randomly from a list of rooms in blue, green, yellow and cyan. Then a special purple room is used as an end goal. Finally 10 more rooms are chosen randomly. The plugin is the mechanism that instantiates those rooms and connects their doors; the logic that picks them is written in blueprints or C++, and the documentation stresses that you code your own rules with flexibility and customisation. This is the design decision that makes the plugin worth learning rather than a black box. The interface and component layer, with RoomVisitor, RoomObserver and DeterministicRandom among the named examples, exists to let your rules observe and drive the generation. DeterministicRandom in particular is the piece that lets a layout be reproducible from a seed, which matters if you want the same dungeon for a player on replay or in a multiplayer session.

Door types and culling are what make a layout playable

Two features carry most of the practical weight beyond the rules themselves. Different door types allow more complex dungeons, which is what turns a corridor of interchangeable rooms into a space with structure, since a locked door, a one-way door and a normal door impose different constraints on your generation rules. The optional room culling system allows only the relevant rooms to be rendered to the player, and in the documentation's own framing it is a simple occlusion culling system, described as one rudimentary way to optimise the GPU side by reducing drawing, and explicitly stated to be far from perfect but a good start. The word optional matters, because you can also turn it off. A dungeon generator that instantiates every room of a large map at once will hit the machine's limits, and culling is the mechanism that keeps a big layout affordable, but the documentation is clear that the other optimisations are your job.

Multiplayer support and an experimental save system

The plugin is described as ready for multiplayer games, with the push model and subobject lists implemented. In Unreal terms that means the dungeon state can be replicated rather than being local to one machine, which is the difference between a generator that works in a single player prototype and one that can be used in a networked game. The save and load side is more cautious. Since version 3.5 of the plugin there are some nodes to help you set up a save and load of the dungeon, and the documentation links them to a dedicated guide on saving a dungeon, but the feature is marked experimental and the answer says it will need some work on you. So the honest reading is that the save nodes are a starting point rather than a finished system. The distinction matters, because in a multiplayer game the dungeon layout has to be both reproducible and persistent, and the plugin gives you the mechanism to record it without taking on the design of your own save format.

Installation is the normal Unreal plugin path, with a wiki to fall back on

There is no install command, and the documentation says as much: install it like any other Unreal Engine plugin, and if you have trouble with installation, read the Installation page of the wiki. The engine support is what you should check first, since the release badge lists Unreal Engine 4.27, 5.4, 5.5, 5.6, 5.7 and 5.8 as the supported versions, and the project is described as an Unreal Engine 4 and 5 plugin. A plugin built for a specific engine version is the most common reason an Unreal install goes wrong, so the wiki's Getting Started guide is where the version-specific steps live, along with a guide on how the plugin works internally and a full list of the exposed classes and nodes in Blueprint. The repository itself is a C++ Unreal Engine code plugin, with a ProceduralDungeon.uplugin descriptor, a Source directory, a Config directory, a Resources directory and a .clang-format file, which tells you the code is formatted with clang-format and is laid out in the standard plugin structure.

The licence is a choice between CeCILL-C and a Fab EULA

The licensing here needs a decision rather than a reading. The repository carries two licence files, LICENSE-CeCILL-C and LICENSE.md, and the licence badge reads CeCILL-C or Fab EULA, which corresponds to the two ways you can get the plugin. The open source path in the repository is CeCILL-C, a French open source licence derived from the GPL family and approved by the French Free Software Foundation, which carries reciprocal obligations on redistribution. The alternative is the plugin's listing on Fab, the Epic marketplace, where the terms are the Fab EULA. The README also marks a set of premium features as exclusive to the Fab version, and the one named is a Dungeon Map UMG widget that is ready to use out of the box and fully customisable. That is a meaningful split for evaluation. The repository version is the plugin without the map widget, under a reciprocal open source licence, and the marketplace version adds the widget under commercial marketplace terms. Which of those fits your project depends on your distribution model, and it is worth reading both texts before you build on either.

Actively maintained, versioned through 3.9.x

The project is not archived and the last push was on 2026-10-21, with the repository carrying a maintenance badge reading Actively Maintained. The release history is regular: v3.9.0 on 2026-07-29, v3.9.2 on 2026-08-18 and v3.9.3 on 2026-09-24. There is a CHANGELOG.md and a CONTRIBUTING.md in the repository, and the project accepts pull requests, with contributions to the wiki also welcomed. There is a Discord server dedicated to the plugin for questions and help, an issue template for bug reports at the bug report URL, and a separate example project repository, BenPyton/DungeonExample, plus a video demonstrating the room spawning. The presence of a separate example project rather than a demo level inside the plugin repository is a deliberate choice, and it is the fastest way to see what a working setup looks like before you write your own generation rules.

Editorial conclusion

Adopt Procedural Dungeon if your Unreal project has rooms you want to design by hand and a layout you want to generate at runtime, and you can accept authoring the generation rules yourself in Blueprint or C++. Do not adopt it if you want the plugin to produce geometry, because it does not, and do not adopt it expecting the dungeon map UMG widget, which the project lists as a Fab-exclusive premium feature. Before you commit, decide between the CeCILL-C licence in the repository and the Fab EULA for the marketplace version, read the wiki's Getting Started and Installation pages for the actual engine version support, and check the supported engine versions listed in the release badge against your project.

Frequently asked questions

Official sources

1. BenPyton/ProceduralDungeon on GitHub
2. Issues
3. README
4. Releases