How Procedural Dungeons Work in Roguelikes

Every time you start a new run of Slay the Spire, Hades, Dead Cells, or any classical roguelike, the dungeon you’re about to navigate didn’t exist a second ago. It was generated on demand by an algorithm. The same is true for Minecraft caves, No Man’s Sky planets, and the procedural worlds in dozens of browser games. The algorithms are older than the modern indie boom — they trace back to Rogue itself in 1980 — and they’re more elegant than most players realize. Here’s how procedural dungeons actually work, the main techniques, and where each one fits.

Why generate dungeons procedurally

The pitch is replay value. A hand-designed dungeon plays the same every time; a procedurally generated one is different on every run. Roguelikes (the genre’s defining mechanic) build their entire identity around this — each playthrough should feel fresh because the layout, the loot, and the enemy placements are all new.

The trade-off is intentionality. Hand-designed levels can have set-piece moments, deliberate pacing, and architectural surprise that algorithms struggle to match. The art of procedural generation is finding the algorithms that produce coherent, interesting spaces consistently — not just random noise.

Algorithm 1: BSP partitioning

Binary Space Partitioning (BSP) is the canonical algorithm for room-based dungeons. The idea: start with a rectangular space (the dungeon’s outline), then recursively split it into smaller rectangles. Each split is either horizontal or vertical, chosen randomly, and the split position is chosen to avoid producing oversized or undersized rooms.

After enough splits, the dungeon is a tree of rectangles. Each leaf rectangle becomes a room — possibly with its actual room shape randomized within the leaf, so rooms don’t fill their containers exactly. Then corridors are drawn between rooms, usually connecting siblings in the tree first and then connecting larger subtrees.

BSP produces dungeons with the classic Rogue / Nethack feel — rectangular rooms connected by orthogonal corridors. It’s predictable, easy to tune, and produces clearly navigable maps. The 1980 game Rogue used a variant of BSP, and so do most of its direct descendants. Modern games like Brogue still rely on BSP-style algorithms for their core room layout.

Algorithm 2: Cellular automata

Cellular automata produce dungeons with organic, cave-like shapes. The algorithm: start with a grid of random “alive” and “dead” cells. Then iterate — for each cell, look at its neighbors, and decide whether to flip its state based on a rule (typically, alive cells stay alive if they have enough alive neighbors; dead cells become alive if they have enough alive neighbors).

After a few iterations, the random noise smooths into recognizable cave structures — open areas, narrow passages, isolated chambers. The rule parameters control the cave’s openness (more “smoothing” iterations produce wider, more open caves; fewer produce noisier, tighter ones).

Cellular automata are the standard algorithm for cave generation in roguelikes, and you’ll see them in any game with caves rather than dungeons. The original implementation in browser games traces back to mid-1980s academic papers on game-generation algorithms.

One issue with cellular automata: the output can have disconnected regions. The “cave” might consist of three separate chambers with no passages between them. Post-processing steps — flood-fill to identify components, then carve tunnels to connect them — fix this. Without that step, the algorithm produces unplayable maps.

Algorithm 3: Drunkard’s walk

The drunkard’s walk algorithm is the simplest dungeon generator that produces usable results. Start at a point on the grid. Pick a random direction (north, south, east, west). Take a step. Repeat until you’ve carved enough open space.

The walker can be configured to bias toward certain directions, to occasionally “teleport” to a new position, or to spawn additional walkers that explore from different starting points. The output is a network of meandering corridors and pockets that feels organic — less like a designed dungeon and more like a system of caves carved by water.

Drunkard’s walk is used heavily in caves, mines, and “lost” dungeon settings. It’s also extremely fast to implement, which makes it popular for game jams and browser-deployed roguelikes where the dungeon needs to generate quickly. Some games combine drunkard’s walk with cellular-automata smoothing to clean up the output.

Algorithm 4: Prefab connection

The prefab approach steps away from pure procedural generation. Instead of inventing room shapes algorithmically, the designer hand-crafts a library of “prefab” rooms — small designed sections with predefined enemy placements, loot, and architecture. The algorithm then places these prefabs in a layout, connecting them with procedurally generated corridors.

The benefit is intentionality. Each prefab can have a deliberate purpose — a puzzle room, a boss arena, a treasure vault — and the algorithm assembles them into a new sequence each run. The drawback is that the dungeon’s variety is bounded by the size of the prefab library; a game with twenty rooms in its library will eventually feel repetitive.

Many modern roguelikes use a hybrid approach: BSP or some other algorithm decides the global layout, prefabs fill specific significant rooms (boss rooms, shop rooms, vault rooms), and the rest of the dungeon is fully procedural. The Binding of Isaac is a famous example — its room layouts are prefab, but the floor’s room-graph is procedurally generated.

Algorithm 5: Maze generation

Pure maze algorithms — depth-first search with backtracking, Prim’s algorithm, Kruskal’s algorithm — produce dungeons that are entirely corridors with no rooms. Each cell of the grid is either a wall or a passage, and the algorithm carves passages until the entire space is connected.

Depth-first search with backtracking is the most common implementation. The algorithm starts at a cell, picks a random unvisited neighbor, carves a passage to it, and recurses. When it reaches a dead end, it backtracks to the most recent cell with unvisited neighbors and continues.

Pure maze algorithms produce dungeons that feel like puzzles — winding corridors, dead ends, the player navigating by spatial memory. Few modern roguelikes use pure mazes for their main layout (they’re hard to fight in), but maze segments embedded in larger dungeons are common.

Combining algorithms

Real games rarely use a single algorithm in isolation. The most common patterns combine multiple techniques:

• BSP for rooms + drunkard’s walk for corridors. Classic Rogue-style layout with organic connections.
• Cellular automata for caves + prefab for boss rooms. Organic exploration with designed set-pieces.
• BSP for floor structure + cellular automata for natural variation within rooms. Rectangular rooms with rough edges.
• Prefab for everything + procedural for the room order. Highly designed individual rooms in a fresh sequence per run.

Each combination produces a distinct feel. Players can usually identify which technique a game is using after a few runs — Brogue feels different from Caves of Qud, which feels different from The Binding of Isaac, and the underlying algorithms are part of why.

The history

The original 1980 Rogue, by Michael Toy and Glenn Wichman, used a partitioning algorithm and orthogonal corridors. Its successors — Hack, Nethack, Moria, Angband — refined the same approach over the next two decades. The cellular-automata cave algorithm was popularized in roguelikes by Brian Walker’s Brogue (2009), which made organic caves a standard part of the genre’s vocabulary.

The 2010s indie roguelike boom — Spelunky, The Binding of Isaac, Dead Cells, Hades, Slay the Spire — pushed the algorithms in new directions, combining prefabs with procedural connection for more designed-feeling layouts. Browser-deployed roguelikes (Cogmind’s web version, several Itch.io entries) carry the same algorithmic lineage with the constraint of running in a tab. For more on the genre at large, see our primer on roguelikes.

How browser-deployed roguelikes handle generation

Browser roguelikes face additional constraints: the algorithm needs to be fast (the player is waiting), memory-efficient (JavaScript heap is tighter than native), and deterministic enough to reproduce the same dungeon from a seed (so players can share interesting runs). Most browser roguelikes use simplified versions of the canonical algorithms tuned for these constraints.

Procedural generation in browser games extends well beyond roguelikes — see our procedural generation in browser games piece for the wider survey.

Why this matters for game design

The choice of algorithm shapes everything about how a roguelike feels. BSP-heavy games feel architectural; cellular-automata games feel exploratory; prefab-heavy games feel designed; maze-heavy games feel puzzle-like. Designers pick based on the experience they want players to have, then tune the parameters until the output consistently matches the design intent.

This is the unsexy reality of procedural generation: the algorithms are well-known, the implementation is straightforward, and the craft is in the parameter tuning. A game with bad procedural generation isn’t using a bad algorithm — it’s using the right algorithm with wrong parameters or insufficient post-processing.

Frequently asked questions

What algorithm does Rogue use?

Rogue (1980) used a BSP-style partitioning algorithm — the dungeon was divided into a 3×3 grid of cells, each cell could contain a room, and rooms were connected by orthogonal corridors. Most BSP-based roguelikes use a variant of this approach.

What’s the difference between BSP and cellular automata?

BSP produces rectangular rooms connected by corridors — the “designed dungeon” look. Cellular automata produce organic, cave-like shapes — the “natural cavern” look. Most modern roguelikes use BSP for dungeons and cellular automata for caves, sometimes within the same game.

How do prefab rooms work in procedural games?

Prefab rooms are hand-designed sections that the procedural algorithm places into the dungeon. The algorithm decides where to place them and how to connect them with corridors. The Binding of Isaac is a well-known example — each room is a designed prefab, and the floor layout is procedurally generated.

Why don’t most roguelikes use pure maze algorithms?

Pure mazes are unpleasant to fight in — winding corridors don’t give enemies room to maneuver, and combat in narrow passages devolves into corridor-shooting. Most roguelikes use room-based layouts with maze segments mixed in rather than full mazes.

Are procedural dungeons random?

They’re algorithmic rather than random — the same seed produces the same dungeon every time. The randomness is in the seed, not in the algorithm. Players can share interesting dungeons by sharing the seed, which is how some roguelike communities organize challenge runs.

The takeaway

Procedural dungeons are built on a small handful of well-understood algorithms — BSP, cellular automata, drunkard’s walk, prefab connection, and maze generation. The art is in combining them and tuning the parameters until the output feels coherent. Every roguelike you’ve played uses some combination of these techniques. For a procedural-generation cousin in a totally different genre, the Chrome Dino game‘s obstacle sequence is algorithmically generated too — simpler than dungeon generation, but built on the same family of ideas: randomness within designed constraints.

Related: Browser Game Scheduling Habits That Work · Why Bad Graphics Work in Some Games · The Psychology of Idle Games: Why They Work