Jara Gonzalez & Guzdial: Generating Enemy Shapes as Gates You Need a Mechanic to Beat — Fukai Reads

TL;DR

Procedural Content Generation (PCG, the practice of building game content algorithmically rather than by hand) has long focused on terrain, items, and on enemy behaviour or numeric stats. Yet almost no work has tried to generate an enemy's shape — the body plan, i.e. the collision information that determines how the player physically interacts with it. This paper represents enemies as a 4x4 grid of collision cells in a simple 2D platformer, and compares three ways to generate enemies that can be defeated only when the player has a specific movement mechanic.

The central finding: making an enemy defeatable is easy, but making one defeatable only with a given mechanic and not without it (a gate) is hard. A genetic algorithm that naively optimizes only for the augmented player being able to win ended up producing enemies anyone could beat. By contrast, the simplest method — run A* search to test which cells are reachable, then apply a small deterministic rewrite rule — produced the best gating and the most diverse shapes in about 3 seconds. This article explains the paper so you can grasp it without opening it.

Introduction

The authors are Johor Jara Gonzalez and Matthew Guzdial, of the Department of Computing Science at the University of Alberta and the Alberta Machine Intelligence Institute (Amii) in Canada. Guzdial is a well-known researcher in PCGML, the use of machine learning to generate game content. This is a preprint posted to arXiv on 1 June 2026 (arXiv:2606.02832); it has not yet been confirmed to have passed peer review, and has almost no citations — a brand-new piece of work.

My reason for picking it today is simple. When people hear "generate an enemy," they imagine stats, attack patterns, or visuals. But this paper tackles something earlier: the shape — the very arrangement of collision cells that decides where you must strike to win and what kills you on contact. For a game maker this is a humble but essential design variable, and as a target for automatic generation it was strikingly untouched. It is close to implementation and easy to translate into design vocabulary. That is why I chose it. The authors also released their code.

Background

PCG textbooks and surveys have centered on levels, rules, items, stories, and quests. Enemies appear only peripherally, as part of NPC difficulty balancing or encounter design. In fact, prior enemy-generation research splits into three separate strands: behaviour (how an enemy acts and adapts, controlled by reinforcement learning or, recently, large language models), numeric features (health, damage, speed, tuned and balanced by evolutionary search), and mechanics (new rules or abilities the enemy can use, built by program synthesis).

But, the authors note, all of these assume the enemy's collision-bearing shape is fixed by a human designer. Even work that swaps sprites (A Rogue Dream) changes only appearance, not collision. So generation of the shape itself was a gap — the starting point of this paper.

Robotics and artificial-life research has a rich tradition of morphology generation (automatically building a body's structure). There, however, bodies are evolved to maximize the moving agent's own locomotion speed or stability. Game enemies are the opposite: an enemy exists not to make itself stronger but to shape how a separate player must act. In the authors' words, robotics does not usually optimize a robot's body to make it easier (or harder) for another robot to destroy it. This mismatch of objectives means robotics methods cannot be transferred directly.

Approach

The setting is a deliberately simple 2D Unity platformer built to collect collision data, avoiding confounds like complex geometry or multiple enemies. An enemy is a 4x4 grid of 16 cells, each of one of three types: weak (touching it defeats the enemy), lethal (touching it kills the player), and empty (no collision). The player's basic moves are just left, right, and jump.

On top of this, the authors consider an augmented player with one extra mechanic. The four extra mechanics — borrowed from prior automatic mechanic-generation work — are vertical teleport, horizontal teleport, speed boost (multiplying horizontal speed), and double jump. The design goal is clear: for each mechanic, generate enemies that a basic-only player cannot defeat but an augmented player can. The authors call this gating: a gate you can only pass with a specific ability.

The machinery is an iterative loop. Starting from ten random initial shapes, the basic and augmented players are pitted against an enemy, logging interaction traces — which cell was hit, how, and whether it led to a kill or a death. Those traces drive a single rewrite of the shape, then play resumes, repeated for a fixed number of iterations. The player is controlled in one of two ways: reinforcement learning (learning high-reward behaviour by trial and error; here, Unity ML-Agents with PPO) or A* search (a classic algorithm that reliably finds shortest paths).

There are three generators. The first, NeEF (Neural Enemy Field), is a learned approach: a small neural network takes each cell's features (current type, coordinates, how often it was hit and led to a kill) and predicts what each cell should become. The second, the A*-based production rule, does no learning at all: from A* reachability it applies a deterministic rule — cells the basic player can reach become lethal, cells reachable only when augmented become weak, cells neither can reach become empty. The third applies the same rule but estimates reachability from the trajectories an RL agent actually walked, reflecting a more human-like sense of how hard a cell is to reach. As comparisons, two evolutionary (genetic-algorithm) baselines inspired by robotics were included.

Findings

Evaluation used five metrics: SRAA (how often the augmented player wins; higher is better), SRBA (how often the basic player wins; for a gate, lower is better), SD (diversity of generated shapes; higher is better), DO (how much each shape changed from its initial version), and CT (computation time; lower is better). Values are averaged across the four mechanics (double jump, speed, horizontal and vertical teleport).

The core result is the trap revealed by the GA-A baseline. Scored only on whether the augmented player can win, GA-A reached an SRAA of 1.00 (always defeatable) — but its SRBA also rose to 0.83, meaning the basic player could beat the enemy 83% of the time too. As a gate it fails. Against the authors' design goal, this reads as: making a defeatable enemy is easy; making one defeatable only with a specific mechanic is much harder.

By contrast, the seemingly simplest method — the A*-based production rule — stood out on gating. Its SRBA was 0.00 (the basic player never won: a perfect gate), its augmented SRAA was 0.62, its shape diversity SD was 0.42 (highest of all methods), and it ran in only about 2.38 seconds. The learned NeEF had a higher SRAA of 0.72 but a looser gate (SRBA 0.35) and took about 11 hours (36,062 seconds in the paper). The RL-based production rule showed a strong gate at SRBA 0.10. Overall, the authors report that all three interaction-driven methods matched or beat the evolutionary baselines, and that the GA approaches took the longest even under the same compute budget.

Use cases

For people who make games or puzzles, this work makes concrete the idea of designing an enemy's shape as a gate against player movement. First, metroidvania progression gates — the authors' own motivating example. Right after the player learns double jump or dash, placing a sentinel that can only be beaten using that move lets you design mechanic practice and area unlocking at once. Instead of trying hundreds of layouts by hand, you can have the generator propose candidates that are "defeatable with mechanic A but not B" as starting points.

Second, collision puzzles and boss weak-point layouts. The three-valued grid of weak/lethal/empty maps directly onto a boss's "only-hittable-here" arrangement, or the layout of spikes and footholds. If you are building a 2D action mid-boss, the A* reachability check becomes a tool to automatically verify "is this weak point unreachable without a double jump?" Running in about 3 seconds, it is realistic to embed in a level editor and surface warnings in real time.

Third, soft-lock and exploit detection. A*'s tendency to find paths that are theoretically reachable yet demand inhumanly precise inputs can be flipped into an inspection that surfaces unintended shortcuts. If you are mass-producing hyper-casual or procedurally generated stages, you can run a basic-ability agent and an augmented-ability agent on each stage and automatically filter out levels that are solvable before the intended upgrade — i.e. where the gate is broken. In design terms, this is two roles at once: generating candidates that satisfy a constraint (A but not B) and automatically detecting constraint violations.

Limitations

Start with what the authors themselves acknowledge. A* always finds a shortest path, but the text states plainly that it also counts as "reachable" routes requiring inhumanly precise, lengthy action sequences. The RL-based variant approximates a more human sense of difficulty, but conversely may fail to reach cells that need long, specific sequences. The two answer different questions about the same shape, the authors note, and neither is simply correct. Speed boost, moreover, is treated as an atypical edge case with unusual gating difficulty.

There are many deliberate simplifications. The environment is a stripped-down 2D world avoiding complex geometry and multiple enemies; the enemy is a single 4x4 grid. The mechanic is not given to the generator as an explicit input — a separate generator is trained per environment and per mechanic, so generalizing to new mechanics is outside this experiment. Evaluation is done by re-running agents on the final enemies, not by human playtesting.

From here, what I (Fukai) would point out are things I noticed in reading. A lone 4x4 collision grid is far from a real game enemy's visuals, animation, attack-hitbox timing, or coordination among several foes. "The augmented agent can win" is not the same as "it is fun and learnable for a human," and the paper does not measure the latter. The gap between roughly 11 hours for the learned variants and about 3 seconds for A* is not negligible in practice. Including the fact that this is a preprint with almost no citations, I think it is fair to read the conclusions as: a promising direction shown on a small testbed.

Fukai's Reading

Here I write explicitly as my own interpretation. I would place this work as a step, within PCG's long history of generating what to place (levels, enemies, items), toward generating what to demand of the player. In the vocabulary of design criticism, it is close to automatically designing the lock side of a lock-and-key structure — a lock that opens only with the key of a particular ability — expressed as collision geometry. What strikes me most is that it was not a cutting-edge learner but a naive reachability rule (A*) running in about 3 seconds that produced a perfect gate and the highest diversity. I read this as a reminder of an old PCG lesson: formulate the problem correctly before adding a clever model.

Closing

For those who want to dig deeper: the backbone of this paper is the lineage of automatically generating and evaluating mechanics. Reading it alongside the authors' Mechanic Maker 2.0 (Gonzalez et al., 2023), Zook & Riedl's mechanic generation, and Butler et al.'s program-synthesis approach reveals the map. To trace the roots of morphology generation, Karl Sims' Evolving Virtual Creatures and Lehman & Stanley's novelty search are the origins. For the game-side context of enemies and difficulty, Guzdial et al.'s PCGML overview (2025) gives perspective.

Reframing an enemy not as strength but as shape — and as a gate against player movement — is a small shift of view that adds one new design variable between level design and mechanic design. The testbed is small, but the question is large. I want to follow, hot strong coffee and colored pens in hand, where this direction lands in real games next.

References

Papers and related material referenced in this article:

・An Exploration of Collision-based Enemy Morphology Generation (Johor Jara Gonzalez, Matthew Guzdial, 2026, arXiv preprint arXiv:2606.02832)

・Authors' released implementation (GitHub: Harcurio/Enemy-Morphology-Generation)

・Related: Mechanic Maker 2.0: Reinforcement Learning for Evaluating Generated Rules (Gonzalez et al., 2023)

・Background: Procedural Content Generation via Machine Learning: An Overview (Guzdial et al., 2025)