Random versus generated

These are not the same thing and confusing them is the root of most bad procedural content. Randomness is a source of variation. Generation is the use of that variation within constraints that guarantee the result is playable.

A random level is a level that might be impossible. A generated level is one that cannot be, because the generator was written to make impossibility unreachable. The difference is entirely in the constraints, and the constraints are where all the actual design work lives.

This matters more than it sounds because an impossible generated level is indistinguishable from difficulty from the player's side. They do not know the layout was unwinnable. They assume they failed, and they keep failing, and eventually they conclude the game is unfair - which it is.

Seeded randomness, and why it is worth the effort

Using the built-in random number generator gives you variation and nothing else. A seeded generator gives you variation you can reproduce, which changes what you can do with it.

We use Mulberry32, a small fast algorithm producing a repeatable sequence from a 32-bit seed. Same seed, same sequence, same level, every time, on every device.

  • Bugs become reproducible. 'Seed 4,281 produces an unclearable hill' is a bug report you can act on.
  • Verification becomes meaningful. You can generate ten thousand levels from sequential seeds and check them all.
  • Layouts can be shared. Any generated level can be reproduced from its seed alone.
  • Testing becomes deterministic, so a passing test today means something tomorrow.

The cost is about thirty lines of code. There is no reason to use unseeded randomness in a generator, and we would treat doing so as a defect rather than a shortcut.

Advertising keeps Candy Arcade free. Ads never cover gameplay or controls.

Verify, do not hope

Every generator on this site checks its output before the player ever sees it. These are the actual checks, because a list of principles is less useful than a list of what we do.

GeneratorConstraintVerification
MazeEvery cell must be reachableFlood fill and compare the reached count to the cell count
Corridor gapsThe next gap must be reachable from this oneLimit each centre to a vertical distance the player can travel in the time available
Rolling terrainEvery hill must be clearableCap each rise by the momentum the preceding descent can supply
Lane chunksAt least one lane must be clearChoose blocked lanes from a shuffled list, never all of them
Tunnel formationsThe passage must stay wide enoughClamp each centre so the full corridor width fits inside the bounds
Collectible placementCandy must sit on a survivable pathPlace only after the layout is generated and verified; trails go on the lane the chunk reports as clear

The last row is the one with the largest effect on play. Because collectibles are placed only on verified routes, the game communicates its own safe path continuously. A player who follows the candy is being guided by verification results without knowing it, which is why we can state on every game page that following the candy is survivable.

Template assembly

Full generation from first principles is not always the right tool. For content where you want the handmade quality of designed sections with the variety of generation, assembling verified templates works better.

Candy Tunnel does this: its formations come from a set of shapes each verified passable, assembled in a random order with random parameters within safe ranges. The result is recognisably designed - the formations look intentional because they were - while the sequence is always new.

The trade-off is repetition. With eight templates, a long run will show each one several times, and players will notice. Mitigations that work: parameterise each template so instances differ, vary the spacing between them, and avoid placing the same template twice in succession. Mitigations that do not work: adding more templates, which delays recognition without preventing it.

Generating a difficulty curve

A generator producing uniformly difficult content produces a flat game. The parameters must change with progress, and the interesting question is which parameters and how.

How a corridor tightens

Our corridor generator takes a minimum gap, a maximum gap and a count. Each successive gap interpolates from maximum toward minimum across roughly the first eighty percent of the sequence, then holds.

The hold is the important part. A corridor that narrows without limit eventually becomes impassable, so the curve has a floor - it approaches a minimum width and stays there. Difficulty rises and then plateaus, which keeps very long runs demanding but possible.

Every generated curve on this site has a bound of this kind: speed has a ceiling, corridors have a minimum width, obstacle density has a maximum, and the glow radius in Candy Tunnel has a floor. An unbounded parameter always eventually produces an impossible game, and the only question is how long the player plays before reaching it.

Making generated content feel designed

The common complaint about procedural content is that it feels arbitrary. That is usually not a problem with generation but with a generator that only considers individual elements rather than their relationships.

  • Enforce spacing rules. A slick patch immediately before a hazard is unfair, so ours never places one within an obstacle-length of the next hazard.
  • Vary rhythm deliberately. Long stretches of uniform density feel machine-made even when the placement differs.
  • Follow difficulty with reward. Gummies cluster immediately after the tightest gaps in Rocket Candy Run, which reads as the game acknowledging what you just did.
  • Mirror where appropriate. Our stage generator mirrors interior blocks left to right, which makes rooms feel composed rather than scattered.
  • Place collectibles with intent, not uniformly. A trail says something; a sprinkle does not.

The reward-after-difficulty rule is the cheapest one to implement and has the largest effect on perceived authorship. A generator that gives you something immediately after a hard section feels like it noticed. It did not, of course - it is a conditional - but the effect on the player is real.

When not to generate

Generation is wrong for a substantial share of content, and recognising that is as useful as implementing it well.

  • Precision platforming. Candy Jump Challenge's fifteen levels are hand-built because every gap is at the limit of a jump, and a generator cannot reliably produce that without producing impossible gaps too.
  • Puzzle levels. Candy Cannon Challenge's twenty levels are hand-built so each has a clean intended solution and a meaningful par score.
  • Deterministic pattern games. Candy Factory's whole premise is exact repeatability, which generation would undermine.
  • Tutorial content. The first thing a player sees should teach reliably, and a generated first level teaches something different every time.

The test: if the content's value depends on a specific relationship between its parts, build it. If its value is variety within understood rules, generate it. Roughly half our library is generated and half is hand-built, and the split follows that line.

A generator checklist

  • Is the randomness seeded?
  • Is the output verified, or only hoped to be valid?
  • Does every parameter that escalates have a bound?
  • Are collectibles placed after verification, on verified routes?
  • Are spacing rules enforced between elements, not just within them?
  • Can you generate ten thousand instances and check them all automatically?
  • Is there a rhythm to the output, or is it uniform?
  • Would this content be better hand-built?

Common mistakes

  • Using unseeded randomnessBugs become irreproducible and verification becomes impossible. Seeding costs about thirty lines.
  • Trusting a generatorAn impossible generated level is indistinguishable from difficulty from the player's side, so they blame themselves.
  • Leaving an escalating parameter unboundedA corridor that narrows forever ends in a wall. Every curve needs a floor or a ceiling.
  • Placing collectibles before verifying the layoutProduces trails leading into hazards, which teaches the wrong movement with the game's authority behind it.
  • Generating content whose value is in its specific relationshipsPrecision platforming and puzzle levels should be hand-built. A generator cannot reliably produce 'only just possible'.
  • Adding more templates to fix repetitionIt delays recognition rather than preventing it. Parameterise and vary spacing instead.

Practical tips

  • In generated games, trust the collectibles - they are placed on verified routes by construction.
  • Expect difficulty to plateau rather than rise forever; every curve here has a bound.
  • Template-based games reward pattern learning, because you will see each formation again.
  • Hand-built levels reward memorisation; generated ones reward understanding the rules.
  • If a generated game feels unfair, check whether it is actually unbounded difficulty rather than your play.

Key takeaways

  • Random means variation; generated means variation within constraints that guarantee playability.
  • Seeded randomness makes bugs reproducible and verification possible.
  • Every generator should verify its output - flood fills, reachability limits, momentum caps.
  • Collectibles must be placed after verification, on verified routes.
  • Every escalating parameter needs a bound, or the game eventually becomes impossible.
  • Generation is wrong for precision platforming, puzzles, deterministic patterns and tutorials.

Frequently Asked Questions

What is the difference between random and procedurally generated?

Randomness is a source of variation. Generation uses that variation within constraints that guarantee the result is playable. A random level might be impossible; a properly generated one cannot be.

Why use a seeded random number generator?

Because it makes output reproducible. Bugs become 'seed 4,281 fails' rather than 'sometimes it breaks', and you can verify thousands of generated levels automatically.

How do you know a generated level is possible?

By checking. Mazes are flood-filled, corridor gaps are limited to distances the player can travel, hills are capped by available momentum, and obstacle rows always leave a clear lane.

Are all Candy Arcade levels generated?

About half. Candy Jump Challenge, Candy Cannon Challenge, Candy Factory and Candy Castle Hunt are hand-built, because their value depends on specific relationships between parts.

Why does generated content sometimes feel arbitrary?

Usually because the generator considers elements individually rather than their relationships. Spacing rules, rhythm variation and reward-after-difficulty all make generated content feel authored.