AI level generators versus classic procedural generation

These get lumped together constantly and they are not the same category of tool. One is a program you write. The other is a draft somebody hands you.

Classic procedural generation means a rule system. You define the pieces, the constraints, and the process, and the process produces levels. Spelunky assembles rooms from a template grid under rules that guarantee a path from entrance to exit. Binding of Isaac stitches together hand-authored rooms. Minecraft's terrain comes out of layered noise functions with biome rules on top. No Man's Sky builds planets from a seeded pipeline of rules.

A model producing a level means asking for one and receiving one. It arrives as a description, a layout, a tilemap, or a scene, produced in a single pass, based on what you asked for and on everything the model has read about levels.

The difference that matters is not quality. It is that one is a repeatable process with knobs and the other is an artefact. Almost every practical consequence follows from that.

A rule system is consistent by construction. If you write a rule that says every room has at least two exits, every room in every level for the rest of the project has at least two exits. That guarantee costs you nothing to maintain and applies to levels you have never seen.

It is tunable in a way that compounds. Change one parameter and the entire output space shifts. Spelunky's designer has described spending far more time on the rules than on any individual level, and that is the correct ratio, because the rules are the product.

It runs at play time. This is the big one and it is easy to miss. A rule system can generate a new level while the player is playing, on their machine, instantly, forever. That is what makes roguelikes and survival sandboxes work at all. An enormous amount of what people love about Slay the Spire, Hades, Dead Cells and Caves of Qud depends on the run being made fresh.

And it is debuggable. When a rule system produces a bad level, you can find out why, because the cause is a rule and rules can be read. This sounds dry and it is worth a great deal over the life of a project.

The cost is honest too. Rule systems are hard to write, hard to make produce anything with intent, and prone to a particular blandness. Every room is valid and nothing is surprising. This is the classic complaint about large generated worlds: technically endless and emotionally flat.

A model producing a level does something a rule system struggles with: it brings intent. Ask for a level that opens with a long approach so the player sees the destination first, and you get something shaped like that, because the model has read a great deal about how levels are shaped.

It handles fuzzy briefs. Describing what you want in prose is enormously easier than encoding it in constraints. Anyone who has tried to express a feeling in a generation algorithm knows how much of the effort goes into translating taste into rules.

It is very fast for a first draft. Getting a blocked-out layout you can walk around in, twenty minutes after the idea, is a real change in how the early part of a project feels. You get to the question of whether the space works far sooner, and that question is the one that decides most of the rest.

And it is a good idea source. Ask for six layouts for the same brief and you will see approaches you would not have tried, which is useful even if you build none of them. Seeing your idea interpreted badly is often the fastest way to work out what you actually meant.

The cost: it is one artefact, produced once, with no guarantee of anything. Ask twice and you get two different things. There is no parameter to nudge. There is no rule you can inspect to explain why it did that. And nothing in it is verified, which brings us to the most important practical difference.

A well-written rule system can guarantee properties. The exit is reachable. Every key spawns before its door. There is no room with a single one-way entrance. These guarantees hold for every level it will ever produce, including the ones generated on a stranger's machine in two years.

A generated level guarantees nothing. It may have an unreachable objective, a locked door with the key behind it, a gap slightly wider than the jump distance, or geometry the player can fall through. All of these are common, and none of them are visible from reading the layout.

That means every generated level has to be inspected. Walked. Played. Checked against your actual movement rules, which the model does not know, because your jump height and dash distance are numbers in your project, not facts about levels in general.

Inspection is not a small tax. It is often the dominant cost. Ten generated levels sound like ten levels of work saved, until you count the hours of walking them, finding the four that are broken, and fixing the three that are subtly boring.

This is the crisp statement of the whole comparison. A rule system moves the cost up front into writing rules and then approaches zero per level. A model moves the cost to the back into inspecting output, and it stays constant per level forever. Neither is cheaper in the abstract. Which one is cheaper depends entirely on how many levels you need.

If levels need to be generated while the player is playing, you need a rule system. There is no alternative. A game whose identity is the fresh run needs generation on the player's machine, in milliseconds, with guarantees.

If you need many levels that are all correct and all similar in kind, you need a rule system. The break-even point comes fast. Somewhere around the twentieth level, writing the rules would have been cheaper than inspecting the outputs, and every level after that is free.

If you need a handful of specific, distinctive spaces, generated drafts are a fine starting point and rules are overkill. Writing a constraint solver to produce four hand-crafted-feeling levels is a poor use of a month, and the result will feel less deliberate than four spaces you arranged yourself.

If you are exploring, before you know what your levels even are, generated drafts win easily. This is the phase where you do not yet know the rules, which makes writing a rule system premature. You cannot encode a preference you have not formed.

And if you are looking at a blank project with no levels at all, generated drafts get you to a walkable space today. That matters more than it sounds. A space you can walk around answers questions that no document will.

The combination that actually earns its keep is neither of the above on its own. Have a model write and tune the ruleset, and let the ruleset make the levels.

This puts each tool where it is strong. Writing generation code is fiddly, mathematical, and full of exactly the plumbing that a model handles well: grid logic, constraint checks, seeded randomness, connectivity tests, spawn placement. Meanwhile the rule system retains every property that made it valuable, because it is still a rule system.

The workflow is a loop. Describe the levels you want in prose. Get a generator that attempts it. Run it and look at fifty outputs. Describe what is wrong in plain terms, because you can see it plainly. Get the rules adjusted. Run it again.

That loop is much more comfortable than either extreme. You are not hand-writing constraint code, and you are not inspecting every level forever. You are inspecting output in batches and steering the process that made it, which is the right altitude for a designer to be working at.

It also fixes the blandness complaint from a useful direction. Most flat generated worlds are flat because their rules encode connectivity and nothing else. Adding rules about pacing, sightlines, landmark placement or moments of relief is not hard to describe and is fiddly to code, which is precisely the split this workflow is built for.

Whichever route you take, the same measurement applies at the end: somebody has to play it and say whether it is any good. That is not a technical task and it does not require having written the code.

Look at fifty outputs, not one. One good level from a generator tells you almost nothing, because you may have got lucky. The distribution is the thing you are evaluating, and the distribution only shows up in volume.

Look at the worst outputs specifically. Anyone can be impressed by the best roll. Your players will hit the median and occasionally the bottom, and the bottom is what they will remember and describe to other people.

Walk the level at player speed, with your real movement, and notice where you got bored. Boredom in a generated space is usually a missing rule about variation or rhythm, and it is completely invisible from a top-down view.

A generated level is a strong placeholder and a weak final space, in exactly the way a generated model or a generated line of dialogue is. It holds the shape while you find out what the shape should be. Whether it survives to ship is a judgement made by playing it, which is the one part of this that has not changed at all.

It is easy to write off rule systems as dated and easy to write off generated levels as unreliable. Neither dismissal survives contact with real projects.

Rule systems built the most replayable games of the last fifteen years and continue to be the only way to make a level at play time. They are not going anywhere, and the craft of writing them is one of the more valuable things a designer can learn, because it forces you to say precisely what you want.

Generated drafts collapse the distance between an idea and a walkable space, and that changes how quickly you can find out whether an idea is wrong. That is worth a lot, and it is worth more the earlier you are in a project.

The mistake is treating them as competitors for the same slot. They occupy different points in a project. Drafts early, when you are still finding out what your levels are. Rules later, when you know, and you need a hundred more of them to be correct without you looking.