Procedural Content Generation: Build the Vocabulary Before You Automate the World

Procedural content generation is often approached from the wrong end.

We start with the generator. We write the script. We ask the system to create a road, a building, a park, a level, or an entire world—and then we spend the next several iterations repairing geometry that was never constrained strongly enough in the first place.

While building a low-poly theme-park environment, we ran directly into that failure. A procedural road generator produced something recognizable as a road: asphalt, lane markings, curbs, sidewalks, guardrails and believable scale. But when the road bent aggressively, the geometry warped. The road width pinched. Sidewalk panels fanned. The generator was solving geometry and composition at the same time.

The correction produced a broader architecture:

This turns out to line up with several established ideas in procedural generation, modular level design, shape grammars, grid snapping and constraint-based synthesis.

Procedural content generation needs an alphabet

Before a system can generate a convincing world, it needs a finite set of things it already knows how to place.

In a road system, that vocabulary might contain a straight, gentle curve, tight curve, T-junction, four-way intersection, dead end, roundabout, parking entrance, crosswalk, curb ramp, median and guardrail section. In architecture, the vocabulary might be walls, windows, doors, roof pieces and facade modules. In a theme park, it expands to rides, shops, paths, queue pieces, benches, lights, trees and service infrastructure.

This is not a new idea. Shape-grammar research has long treated procedural modeling as the composition of reusable shapes under explicit production rules. Müller and colleagues' CGA Shape work showed that context-sensitive rules can generate detailed architectural models while preserving relationships between components rather than modeling every building as one unconstrained object.

Stage one: build the vocabulary

The first stage is deliberately unglamorous: author clean modules.

Every module should already look correct before automation touches it. Its scale is known. Its pivot is intentional. Its materials are approved. Its silhouette works from the target camera. Its connection edges are clean. A road curve is a finished road curve, not a straight road that a later script hopes to bend into submission.

Recent procedural-architecture research makes this same move in a modern AI-assisted workflow. Quattrini and colleagues describe translating architectural logic into modular, reproducible data structures, then using Blender's Python API and language models to mediate between description, mathematical rules and generated form.

The practical lesson is straightforward: procedural quality begins upstream in the quality of the primitives.

Stage two: define how the vocabulary connects

A library of beautiful modules is still not a system.

The second stage gives every module a connection contract: sockets, pivots, allowed rotations, compatible neighbors, entry and exit directions, width, elevation, access class, lane count, path class, and any constraints that determine whether two pieces are allowed to touch.

This is where modular level design becomes machine-readable.

Unity's editor exposes grid and increment snapping precisely because repeatable placement is easier when objects share a spatial contract: GameObjects can be aligned to a grid and moved or rotated by fixed increments rather than positioned approximately by eye.

Constraint-based generators take the idea farther. In the simple tiled model of Wave Function Collapse, generation starts with a list of tiles and adjacency data; propagation removes placements that violate the allowed neighborhood relationships. The important ingredient is not randomness. It is the encoded statement of what is allowed to connect to what.

Stage three: automate composition

Only after vocabulary and connection rules are stable does automation become the easy part.

The script no longer has to answer, “What should a road corner look like?” It answers, “Which approved road piece satisfies this connection?”

The difference is enormous.

At that point, procedural generation is closer to constrained assembly than unconstrained creation.

Epic's Procedural Content Generation framework exposes a similar separation. PCG graphs manipulate points carrying transforms, bounds, density and user-defined attributes; those points can then spawn assets. The framework is built around filtering, transforming and composing spatial data rather than requiring the procedural graph to remodel each asset from scratch.

Why this matters for AI-generated 3D worlds

Language models are very good at producing scripts. That can create the illusion that scripting should come first.

But a script is only as useful as the representation it operates on.

If the representation is “make me a road,” the model has to make dozens of coupled design decisions at once. If the representation is “place one approved two-lane gentle-left module, rotation 90 degrees, socket B to socket A,” most of the fragile design work has already been compiled into the asset system.

This suggests a more durable role for AI in procedural world building:

The model can decide what the world needs. The kit defines what things are. The connection grammar defines what is legal. The runtime owns exact placement.

The theme-park road failure was useful

Our first road generator attempted to create the full corridor from sampled centerline geometry. It produced recognizable asphalt, lane markings, curbs, sidewalks and guardrails, and it even held believable human scale. But aggressive bends exposed the weakness: offset normals converged and diverged, causing visible pinching and warped sidewalk panels.

That failure revealed that we had automated one layer too early.

The better approach was visible in a modular road kit: straights, curves, intersections, crossings, islands and roundabouts already solved as authored pieces. Once those pieces exist, the network is mostly a placement problem.

That changed our production order from:

to:

The pattern generalizes beyond roads

The same architecture applies almost everywhere.

A food-stand generator should start from approved stand bodies, counters, roof signs and utility modules. A ride system should start from approved supports, track families, cars, queue modules and themed set pieces. A website generator benefits from approved navigation, hero, card, footer and interaction patterns. An enterprise AI workflow benefits from approved tools, contracts and execution primitives before autonomous orchestration begins.

In each case the system improves when it separates three questions:

A useful mental model: vocabulary, grammar, composer

The architecture can be compressed into three layers.

Vocabulary is the set of approved reusable modules.

Grammar is the set of spatial, semantic and functional relationships that say how modules may connect.

Composer is the algorithm—or AI plus algorithm—that chooses and places valid modules to satisfy a larger objective.

That framing is useful because each layer can improve independently. Artists can improve the modules without rewriting the generator. Engineers can improve placement logic without remodeling assets. AI can make better planning decisions without owning the exact geometry.

The deeper implication

Procedural generation is often marketed as a way to create more content with less manual work.

The more important advantage may be that it forces knowledge to become explicit.

When a road module needs a socket, you have to decide exactly where the connection is. When two tiles need an adjacency rule, you have to state which combinations are valid. When an automatic placer needs a grid, you have to define scale. Ambiguity that a human artist might unconsciously resolve must become data.

That explicit knowledge is reusable by people, scripts, engines and AI systems.

This connects directly to our earlier work on AI agent skills and procedural memory: the valuable artifact is not only the finished output. It is the reusable procedure and structure that make the next output easier.

Build the vocabulary. Define the grammar. Then automate the composition.