First, I wanted to give a big shout out to my first two subscribers: empirefrizz and ishaanksheth. Appreciate your support!

In the early 20th Century, Piet Mondrian, a Dutch artist, was quietly revolutionizing the theory and practice of abstract visual art. While he created art in different styles, he is perhaps best known for his grid-based paintings (see above). These paintings comprise disjoint variegated squares and rectangles filling the entire canvas.

So, how does that relate to dungeon maps? A dungeon layout is a 2D map on a discrete grid indicating which tiles are to be placed in each cell making up the dungeon. In constructing the layout, we need to divide the space into non-overlapping portions, for example, to place rooms and corridors. If we were to divide our space using axis-aligned cuts we would produce a figure (see above) very much like a Mondrian painting.

Binary space partitions

In this article, we’ll look at a simple algorithm to create Mondrian-like “paintings”. Another name for this technique is binary space partitioning. You may have heard of this method in the context of creating an efficient search structure for points in space - an important problem in computer graphics - it’s the same idea.

The algorithm works like so:

1. Begin with a single cell of the desired final layout size.

2. Divide the cell along its longest axis, uniformly between [min_width, width - min_midth] or [min_height, height - min_height], whichever the case may be.

3. Pick a cell at random, and divide it as in Step 2 if its area is greater than min_area.

4. Repeat Step 3 until there are no dividable cells left.

Here’s an illustration of binary space partitioning in action:

We have design freedom to choose which cell and axis to split at each step, as well as the terminating condition. The parameters are the initial width, height, minimum cell area, minimum cell width and height, and, as always, the random seed.

Implementation

Let’s begin our implementation by defining the data structures for our binary space partition. We represent the partition with a binary tree. The leaves of the tree represent the final partitions of the space, and their ancestor nodes represent intermediate splitting steps:

@dataclass
class Rect:
    x: int = 0
    y: int = 0
    width: int = 0
    height: int = 0

@dataclass
class Node:
    index: int = 0
    rect: Rect = field(default_factory=Rect)
    axis: Optional[int] = None
    split: Optional[int] = None
    left: Optional[”Node”] = None
    right: Optional[”Node”]= None

Each node contains a rectangle describing its area within the layout, references to its left and right child, and we assign it an index for visualization purposes later on. The axis and split fields are optional, but make some parts of the implementation easier.

A binary space partition, then, is represented by a single root node, and, for convenience, we maintain a set of leaf nodes:

class BinarySpacePartition:
    root: Node
    leaves: Set[Node]

The classes initializer sets up the root node and begins splitting:

def __init__(self,
             width: int = 100,
             height: int = 100, 
             min_width: int = 10,
             min_height: int = 10, 
             min_area: int = 250,
             seed: Optional[int]=None):

    if seed is not None:
        random.seed(seed)
    
    self.root = Node(index=0)
    self.root.rect = Rect(0, 0, width, height)
    self.axis = 0
    self.count_nodes = 1
    self.leaves = [self.root]

    self._split(min_width, min_height, min_area)

Here is the meat of the code, the splitting algorithm:

def _split(self, min_width: int, min_height: int, min_area: int):
    leaves_todo = list(self.leaves)
    
    while len(leaves_todo):
        candidate = random.choice(leaves_todo)
        leaves_todo.remove(candidate)

        # Work out whether we need to split this node
        r = candidate.rect
        if (min_area < r.width * r.height):
            # Split maximum dimension
            if r.width > r.height:
                candidate.axis = 0
            else:
                candidate.axis = 1

        if candidate.axis == 0:
            candidate.split = random.randrange( \
                min(min_width, r.width - min_width), \
                max(r.width - min_width, min_width) + 1)
            
            candidate.left = Node( \
                index=candidate.index, \
                rect=Rect(r.x, r.y, candidate.split, r.height))
            
            candidate.right = Node( \
                index=len(self.leaves), \
                rect=Rect(r.x + candidate.split, r.y, \
                          r.width - candidate.split, r.height))

        else:
            candidate.split = random.randrange( \
                min(min_height, r.height - min_height), \
                max(r.height - min_height, min_height) + 1)
            
            candidate.left = Node(index=candidate.index, \
                rect=Rect(r.x, r.y, r.width, candidate.split))
            
            candidate.right = Node( \
                index=len(self.leaves), \
                rect=Rect(r.x, r.y + candidate.split, 
                          r.width, r.height - candidate.split))

        # Update leaves
        self.leaves.remove(candidate)
        self.leaves.extend([candidate.left, candidate.right])
        leaves_todo.extend([candidate.left, candidate.right])

An animation of this algorithm was given in the previous section. The end result is a layout like this:

Discussion

In implementing the algorithm in Python from scratch, I discovered some gotchas that seem obvious after the fact.

In my first implementation attempt, I performed the splits in a depth-first manner. This produces similar output to the final method I decided upon but doesn’t nearly look as good for visualization. Also, choosing which cell to split at random allows additional termination conditions, such as: “conclude when there are x cells” (and the layout will be balanced).

For the termination condition, I began with a rule that terminated when neither axis of a cell could be split so that the width or height would be greater than some minimum threshold. However, this resulted in too many square-like cells rather than a diversity of aspect ratios.

Some alternatives I tried for choosing which axis to split were:

• choose the axis at random; and.

• alternate the axis to split from parent to child.

These produced reasonable results, although contained many cells that were too long in one axis. Better results, in my (subjective) opinion, achieve a sweet spot for the distribution of cell aspect ratios. We don’t want them all to be square-like, but neither do we want them to be long and skinny.

These observations drove home the message that procedural generation is part science, part art. We have to implement the methods with an understanding of the constraints that make the output believable, interesting, and fun.

What’s next?

One method to use a binary space partition to construct a dungeon layout, is to place a room in each cell. The room can be smaller than the cell and offset randomly from the cell boundary. Then we can simply join adjacent cells in some way:

Being able to construct a binary space partition, however, is a very general purpose tool for dividing the layout space and can be combined effectively with other methods.

In my next post, we’ll continue our discussion of traditional PCG methods for dungeon building with another method that achieves a disjoint partition but without aligning the splits to the axes.

Resources

• Full Python implementation (to be posted shortly): https://github.com/stefanwebb/generative-gamedev

Something very weird happened today with which I am only just starting to come to terms. A coding challenge question from LeetCode (which I have received in real interviews) turned out to be useful and in fact was just what I needed for the next step in my procedural content generation system. Who knew that all that time spent practicing dynamic programming and graph traversal would come in handy at some point?

If you recall, in the previous article we coded up a simple system, called the cellular automaton, for generating “organic-looking” maps, such as for a rocky cavern or an archipelago. We left off the discussion having produced output like this,

where the white space represents an open cave floor or, alternatively, the land mass of an island, and the black space represents solid rock or ocean.

To go from this to something useful in an actual rogue-like dungeon crawler, however, we need to apply additional constraints. In this article and the subsequent ones, we’ll look at algorithms for:

• removing smaller rooms;

• combining larger rooms; and,

• tracing an outline of the resulting single connected space.

The dungeon map will “make sense” in that the player will be able to get from anywhere to anywhere else and we’ll know where to place the walls. Optionally, we’ll also implement the functionality to remove small enclosed areas of rock. I think they add interest to the map, but it’s nice to have the option.

⛵️ Navigating the islands

The challenging initial step to applying our constraints is to determine the connected components, or “islands”, in our map. But wait, I’ve seen this before as a LeetCode problem! One solution to calculate the connected components is as follow:

1. Initialize an array to store whether each cell has been visited by the algorithm.

2. Loop over map cells.

3. When we encounter a cell we haven’t visited, we start a breadth- (or depth-) first search for connected cells, that is, neighboring cells that have the same value.

After the algorithm has terminated, we have an array of “islands,” their cell locations and values.

Here is the gist of the algorithm in Python, using the same CellularAutomaton class as the previous article:

This code could use some tidying up and making object-oriented, but I’ll leave that for another day.

You can see a visualization in the video at the begining of the article.

→ What’s Next?

In the next article, we’ll use this information on the connected components to remove smaller components and join larger ones. Also, we’ll determine the boundary of the single large room so we know where to place wall (or coast) tiles in Unity.

Resources

• Number of Islands - LeetCode

• Number of Connected Components in an Undirected Graph - LeetCode

• Johnson et al., 2010. Cellular automata for real-time generation of infinite cave levels. PCGames, 2010.

Here is the core of the idea: imagine you have a square petri dish divided into tiny squares or cells. Each cell contains a bacterium and can be in either a “dead” or “alive” state. Initially, the cells are in either state at random, independently of each other.

We divide time into discrete steps and a simple rule determines the state of a cell at the next step:

• If a cell is alive but it has has 5 or less neighbors who are alive, it dies.

• If a cell is dead and it has 3 or more living neighbors, it becomes alive.

• Otherwise, the cell remains in its current state.

What we mean by “neighbors” is at our discretion. We’ll define it as the eight immediately surrounding cells. Also, I’ve chosen 4 for the “survival threshold” and 5 for the “birth threshold”, but again this is a parameter we can set.

🤓 Let’s code it up!

We’ll encapsulate our cellular automaton in a Python class. It needs to store the construction parameters, the grid of cell states, as well as an additional buffer for calculating the next time step:

When an object of this class is instantiated, we need to allocate the cell arrays and initialize them. The initial state has independent random values with the flip of a coin:

To count the number of neighboring cells that are alive, we take a slice of the array, and use a simple trick to treat out-of-bounds neighbors as alive:

The following method simulates a single time step of the automaton using the rule we previously described. Notice how the values of the next time step only depend on the previous time step, or rather, we update all of the cell values asynchronously:

Finally, we just need some methods to visualize our “dungeon”:

🧐 Results

Here is some output over 12 time steps:

and the final frame:

The black regions represent rock walls and the white, open space. You should try playing around with the parameters to understand their effect on the cavern geometry.

By changing the random seed you can generate a practically infinite number of dungeons. And by fixing the seed, you can, in effect, store a dungeon in 64-bits!

→ What’s next?

Our cavernous dungeon could use some heuristic improvements over the plain automaton output. There are several disconnected “rooms”, including some that are too small to be practical. A simple post-processing step numbers the “islands,” removing those smaller than a given threshold and joining the larger ones to form a single large cavern.

But, we’ll have to leave that for another day! Hope to see you in the next article 🤠

Resources

• My Python implementation (to follow shortly…)

• Johnson et al., 2010. Cellular automata for real-time generation of infinite cave levels. PCGames, 2010.

A dungeon for role-playing games can be conjured out of the æther with just a source of randomness and a few clever algorithms. But how? And why would we want a computer to design our dungeons - doesn’t that take out the fun?

First, let’s address the why. As a game designer, it is immensely advantageous to have game experiences that vary each time you play. It becomes difficult, after all, to empathize with your imagined player if you’ve experienced each level ad infinitum. But replayability is not just a boon for the designer, it’s also one for the player. A game stays fresh much longer when the content varies each time - think of the dungeons of Diablo, or the world maps of Civilization.

So, what are our options for procedurally building a dungeon? Here are three families of methods commonly used: “digging” agents, cellular automata, and binary space partitioning:

• “Digging” agents construct a dungeon one room at a time, connecting each nearby to one of the previously constructed rooms. I like to think of this method as being like a digger that successively carves out open space underground.

• Cellular automata are systems that can “evolve” a dungeon’s geometry where an element’s value at the next time is a simple function of the value of its neighbors. Cellular automata can produce interesting and varied organic-looking geometry.

• Binary space partitioning is an algorithm that recursively splits the map area along an axis just like a Mondrian painting. We can then place rooms in each partition of the space.

As with other types of procedurally generated content, our output has constraints. A dungeon must presumably be fully connected, have a diversity of rooms and environments, and direct the player towards a goal. Some of these constraints relate to the geometry of the dungeon, and others relate more to the items and creatures we place in them and how the user can interact with the environment.

What’s next?

We’ve touched upon a handful of “traditional” algorithms for constructing dungeons, yet we’ve barely scratched the surface. In future articles, I intend to implement these dungeon construction methods and more in Python and C# and integrate them into a dungeon system I’ve been building in an online course: “Unity Procedural Generation: Build Infinite Game Levels”.

We discussed how to generate a dungeon, but not what makes a dungeon fun or challenging. And is this even something we can quantify? I think this topic will intersect with interesting graph theory and graph algorithms. If we can quantify a dungeon “goodness”, then we can apply a wealth of search methods to find a good one.

Finally, I think it’s interesting to revisit these older methods in the age of Generative AI. Can we teach our utility-function-for-dungeon-funness to a foundation model? And can we use foundation models to control dungeon generation via natural language descriptions and images?

Stay tuned, and hope to see you in the next article!

Take Rogue from 1980, one of the first dungeon crawlers. Instead of hand-built maps, every dungeon you play through is created by an algorithm that mixes in randomness. Room sizes, layouts, hallways, monster placements, and treasure drops all get shuffled each run. That’s what kept the game fresh.

Procedural generation originally solved two problems:

1. Replayability – Every run felt new, so players didn’t get bored as quickly.

2. Memory limits – Hardware in the ’80s and ’90s couldn’t store massive worlds. Generating them on the fly let games feel huge without needing gigabytes of space. For example, The Elder Scrolls II: Daggerfall (1996) gave players an open world about the size of Great Britain, all packed into just a few hundred megabytes.

And it goes back even further. Tabletop RPGs like Dungeons & Dragons relied on procedural generation too. Rolling dice determined stats, monster encounters, and treasure locations. D&D actually inspired early PC games like Rogue.

So what’s different about today’s AI-generated content? Traditional procedural methods follow hard-coded rules and algorithms. Modern AI, on the other hand, uses machine learning—foundation models like LLMs or vision-language models that were trained on massive datasets. Instead of just “rolling the dice,” we’re prompting systems that have learned patterns from the real world.

That doesn’t mean AI generation is a brand-new invention—it’s more of an evolution. We’ve had procedural generation in games for nearly 50 years. The new twist is that machine learning replaces rigid algorithms with models that can generalize and adapt. To me, prompting an LLM is just another tool in the game dev toolbox—albeit a super powerful one. And the most exciting part is seeing how developers combine traditional procedural tricks with AI to create something altogether new!

Picture a Tomb Raider where Lara Croft just floats stiffly through the ruins instead of vaulting, rolling, and leaping across them. Or a Quake where enemies drift aimlessly, instead of prowling and lunging at you. Animation transforms these static worlds into living ones. After music, I’d argue it’s the most emotionally charged element in games. So the question is—how do we create animation that truly brings characters to life?

In this series, I’ll walk through the fundamentals of character animation using Unity, Blender, and a sprinkle of Python. A bit of background: I come from an AI research background and now work as a Developer Advocate in the Generative AI space, creating content to inspire others to build with AI. Recently (well, actually, four months ago!), I decided to merge that professional expertise with a personal passion—using Generative AI for game development. My starting point? Human motion synthesis—using AI to generate animations for human characters.

While my foundation in Generative AI was strong, I quickly realized I needed to deepen my understanding of digital animation to make sense of the research papers and code I was exploring. That led me down a rabbit hole of textbooks, Unity forum threads, and scattered documentation. I found YouTube tutorials helpful for quick tips, but they rarely dove into the core concepts behind animation. That gap inspired me to create this short series of blog posts and videos, A Short Primer on Character Animation, to cover not just the “how” but also the “why” of bringing characters to life.”

Articulation: Pinnochio in Digital Form

Look again at the puppet in the thumbnail image. Its rigid segments are linked at joints, each one responding to the pull or release of strings from the puppeteer’s control bar. With deft movements, the puppeteer can make it walk, bow, or wave—every motion of one joint subtly influencing the next through their connections.

This familiar approach to bringing figures to life is called articulation. It works for humans, animals, or even a tree swaying in the wind. In this model, rigid bodies—known as bones—are joined together to form a skeleton, or, armature. The word “articulation” comes from the Latin for “joint,” reflecting the way we rotate and position these bones at their joints to create a pose. When we adjust these orientations, we say the character is articulated.

For example, a common model for human characters contains around 21 bones connected at 20 joints (see the skeletal animation above). I say this is a model since the real human body contains more than 200 bones and 600 muscles, so what we have here is a useful simplification of reality, i.e., a model. A real human would have over 200 degrees of freedom whereas our model has . Still, it is a totally adequate representation for human animation excepting hands, feet, and faces.

What's next?

So, that's the basics of articulated animation: bones, joints, skeletons, and poses. In the next article, we’ll dive deeper into the technical aspects of articulated motion and animate a character with Unity.