Design a generator around invariants

2314. Lesson identity

Module

5.12 — Procedural content

Lesson

Design a generator around invariants

Academic type

Systems

Schema type

text

Order

Lesson 1 of the module

Estimated time

35–45 minutes, including practice

This lesson defines the contract for a procedural system before implementation begins.

2315. Learning objective

After this lesson, you can specify a procedural generator with explicit invariants, bounded inputs, deterministic seed behavior, and testable failure cases.

2316. Why this matters

Procedural generation produces variation, but variation is not the same as quality. A generator is useful only when its outputs remain playable, valid, and inspectable across many runs. Clear invariants give an AI coding partner or another developer a precise target instead of a vague request for “more variety.” They also make failures diagnosable: you can identify which guarantee was broken and under which conditions.

2317. Prior knowledge

You should be able to describe a game system in terms of rules, state, feedback, and acceptance evidence. The review process from 5.11 — Audio and feedback is relevant because generated content also needs contextual validation rather than approval based on an isolated result. No implementation of a procedural generator is required for this lesson.

2318. Core concept

An invariant is a property that must remain true for every accepted generated result. It is different from a preference. “Rooms should feel varied” is a design goal; “every room has at least one valid entrance and exit” is an invariant that can be tested.

A useful generator specification separates five elements:

A complete specification also distinguishes hard constraints from soft goals. Hard constraints determine whether a result is accepted. Soft goals influence selection among accepted results, such as preferring a wider variety of room sizes.

2319. Mental model

Use the Generate → Check → Accept or reject model:

1. Generate: Produce a candidate from bounded inputs and a recorded seed.
2. Check: Evaluate every hard invariant and record the result.
3. Accept or reject: Keep the candidate only if all required checks pass; otherwise reject it, retry within a stated budget, or return a controlled failure.

The model has three important consequences:

• A random-looking result is not automatically a valid result.
• Reproducibility is part of the system contract, not merely a debugging convenience.
• Failure behavior must be designed. An unbounded retry loop hides an impossible or contradictory specification.

2320. Concrete example

Consider a generator for a small encounter layout. The generator receives a seed and a requested room count.

In this contract, the requested count is not merely a preference: the accepted output must contain exactly the requested number of rooms. The request itself must be an integer from 8 through 12. Therefore, a request for 10 rooms must produce an accepted layout with exactly 10 rooms; it is not acceptable to return any count in the 8–12 range. A request below 8, above 12, or otherwise non-integer is rejected before generation begins.

Hard invariants:

• The accepted output contains exactly the requested number of rooms, where the request is an integer from 8 through 12.
• Every room has a valid position inside the play area.
• The entrance and objective are distinct rooms.
• At least one traversable path connects the entrance to the objective.
• No two rooms overlap beyond the permitted margin.

Bounds and seed behavior:

• Requested room count: integer from 8 through 12; output room count must equal this request exactly.
• Play area: 40 by 40 cells.
• Retry budget: at most 20 candidates for one base seed and valid room-count request.
• Attempt policy: initialize one pseudorandom stream once for the request, then consume that stream continuously across attempts rather than reinitializing it with the same seed for each candidate.
• Record the base seed, requested room count, generator version, configuration, and attempt policy. Reusing that complete contract reproduces the accepted output or the same controlled failure.

Failure behavior:

If the requested room count is outside the 8–12 bound or is not an integer, the system rejects the request before attempting generation and reports the invalid value and the permitted bound. If a valid request cannot produce a candidate satisfying all invariants within 20 attempts, the system returns a controlled generation failure containing the seed, requested room count, generator version, failed invariant names, and retry count. It does not silently substitute another room count, return an invalid layout, or retry forever.

A soft goal may then choose among valid layouts: for example, prefer layouts whose room sizes are not all identical. That goal can improve variety without weakening the exact room-count contract or any other hard invariant.

2321. Common mistake

The common mistake is treating a successful function call as proof that generation succeeded. A generator can return an object, draw a map, or produce plausible data while violating connectivity, bounds, uniqueness, or reproducibility requirements. “It generated something” is an execution result, not an acceptance decision.

Another mistake is adding randomization before defining the seed contract. If the source of randomness is not controlled and recorded, a failure may disappear before it can be investigated.

2322. Guided practice

Write a one-page specification for a procedural system of your choice: an encounter layout, item set, quest variation, visual arrangement, or another bounded content system. Do not implement it yet.

Complete these steps:

1. State the system's purpose in one sentence.
2. List at least four hard invariants. Each must be testable as true or false.
3. Define the relevant input and output bounds for your chosen system.
4. Specify what the seed controls, how retries advance deterministically, and what seed, request, version, configuration, and attempt-policy information must be recorded for reproduction.
5. Define one soft goal that can improve variation without becoming a hard requirement.
6. Define a finite retry budget and the information returned when generation fails.
7. For each invariant, name the evidence that would prove it passed.

Make one explicit decision about an impossible or invalid request: reject it before generation, handle it through bounded retries, or use a controlled fallback. Explain why that choice preserves the contract of your chosen system.

2323. Validation / evidence

Your specification is ready for review when another developer can answer all of these questions without guessing:

• What must be true of every accepted result?
• Which values are bounded, and what happens outside those bounds?
• If an output count is requested, must the result equal that count or merely fall within a range?
• Can the same base seed, request, generator version, configuration, and attempt policy reproduce the accepted result or controlled failure?
• How is each invariant tested?
• What happens after the retry budget is exhausted?
• Which goals are preferences rather than acceptance conditions?

The evidence for this lesson is the completed specification, including an invariant table and a documented failure path. The evidence must state the system's acceptance contract, its input and output bounds, how invalid requests are handled, and what happens when the retry budget is exhausted. A reviewer should be able to identify at least four invariants, their checks, and the exact condition under which the result is rejected or a specified fallback is used.

Practical submission and rubric

Submit the one-page specification as the practical assessment artifact. Score each criterion as 0 = absent or not testable, 1 = present but incomplete, or 2 = complete and testable, for a total of 10 points:

• Invariants: At least four hard invariants are stated as testable conditions.
• Bounds: Relevant input and output limits, including invalid-request behavior, are explicit.
• Deterministic reproduction: The recorded seed, request, generator version, configuration, and attempt policy can reproduce the accepted output or controlled failure.
• Finite failure handling: The retry budget and the rejection, controlled-failure, or predeclared fallback behavior are specified.
• Acceptance evidence: Every invariant names the check or artifact that demonstrates whether it passed.

2324. Key takeaways

• An invariant is a property every accepted generated result must preserve.
• Bounds prevent uncontrolled inputs and make the generator's behavior predictable.
• Seeds and generator versions make procedural results reproducible.
• A valid system defines rejection, retry limits, and controlled failure behavior.
• Soft goals may improve variety, but they must not silently replace hard constraints.

2325. Next lesson

Next, continue with 5.12 L2 — Evaluate variation without worshiping quantity, focusing on sampling, rejection, and quality gates.

2326. Knowledge check