Bound the world requirement

814. Lesson identity

Module

2.10 — Living world

Lesson

Bound the world requirement

Academic type

Systems

Schema type

text

Order

2 in the module

Estimated time

35–45 minutes, including practice

815. Learning objective

After this lesson, you can specify one living-world behavior as a bounded state contract with a clear owner, permitted transitions, and deterministic consequences.

816. Why this matters

“Make the world feel alive” is a direction, not an implementable requirement. If the requirement has no boundary, every system can become responsible for it and every consequence can spread through the game. A bounded contract gives you a behavior that can be designed, tested, explained to an AI coding partner, and changed without accidentally expanding the entire world simulation. The goal is not to make the world less interesting; it is to make one meaningful behavior reliable.

817. Prior knowledge

You should already be able to distinguish authored world state, schedules, bounded simulation, and unbounded simulation from Scripted world versus simulated world. You should also be comfortable describing a game behavior in terms of state, a triggering event, and an observable result.

818. Core concept

A world requirement is bounded when it answers four questions:

1. What behavior is being specified?
2. Which system owns its state and transitions?
3. What is the smallest state contract that is sufficient?
4. What deterministic consequence follows from each permitted transition?

A requirement is not bounded merely because it has a short description. It is bounded when its responsibilities, states, inputs, outputs, and limits are explicit. Its evidence must also record the selected behavior model—authored state, schedule, or bounded simulation—and explain why that model is the smallest sufficient choice for the intended player-facing result.

For example, “the market should react to player activity” is not yet a bounded requirement. It does not identify the activity, the market state, the owner, the timing, or the consequence. A bounded version might be:

The district market tracks a three-state supply condition—stable, strained, or restocked—and begins in stable. The market system owns the condition. Consuming available stock while the condition is stable changes it to strained; completing a delivery while it is strained changes it to restocked; consuming stock while it is restocked changes it back to strained. For any event and current-state combination not listed here, the condition does not change. Each transition changes only the displayed stock message and the price of one defined item category.

This is still a design decision, not a complete implementation. It is specific enough to evaluate without promising a simulation of every economic factor.

819. Mental model

Use the BOUND contract:

Then add four supporting decisions:

• Initial state: the state in which the contract begins.
• Behavior model: authored state, schedule, or bounded simulation.
• Out of scope: behaviors this requirement does not control.
• Evidence: what you will observe to confirm that the contract works.

A compact contract can be written as:

Behavior: [one world behavior]
Owner: [one system]
State: [small finite set or bounded value]
Initial state: [one valid state or bounded starting value]
Allowed transitions: [event + current state -> next state]
Consequences: [specific observable results]
Behavior model: [authored state | schedule | bounded simulation]
Why this is the smallest sufficient model: [brief justification tied to the required result]
Out of scope: [nearby behaviors excluded]
Evidence: [testable observations]

The owner is not the same as the event source. A player action may trigger a transition, while the market system still owns the market state. Keeping those roles separate prevents unrelated systems from modifying the same fact.

820. Concrete example

Suppose the ambition is: “The settlement should remember whether the player has helped it.”

This statement is too broad. “Helped” could mean delivering supplies, protecting residents, completing dialogue, spending currency, or finishing a major objective. It also implies an unclear number of downstream reactions.

A bounded alternative is:

Behavior: The settlement gate displays one of two access conditions after a supply delivery.
Owner: Settlement access system.
State: access_locked | access_open.
Initial state: access_locked.
Allowed transitions:
  supply_delivery_completed while access_locked -> access_open
  for any other event, or while access_open, the state remains unchanged.
Consequences:
  access_open changes the gate prompt and permits entry through the gate.
Behavior model: Authored state.
Why this is the smallest sufficient model:
  The requirement needs one persistent fact and one defined transition; it does not need timed activity or continuously interacting agents.
Out of scope:
  resident schedules, prices, reputation, enemy behavior, and dialogue memory.
Evidence:
  after the delivery event, the prompt changes and the gate can be entered;
  unrelated actions do not change the access state.

This design may later be expanded, but its current boundary is deliberate. It gives one system ownership of one fact and defines exactly two consequences. A designer can now decide whether this behavior is worth building before adding more world memory.

821. Common mistake

The common mistake is to treat every interesting consequence as part of the same requirement. A learner may begin with a gate that opens after a delivery, then add resident reactions, price changes, patrol routes, weather, reputation, and persistent dialogue because these would make the settlement feel more alive. The original requirement has become an uncontrolled simulation.

Use a separate requirement for each independently owned behavior. If two behaviors must coordinate, specify the event or contract between them rather than giving both systems permission to edit the same state.

822. Guided practice

Choose one abstract living-world ambition from this list, or write a comparable one:

• “The outpost should react to shortages.”
• “The district should feel safer after the player helps.”
• “The world should remember that the player passed through.”

Now produce a BOUND contract for one behavior. Follow these steps:

1. Narrow the verb. Replace words such as “react,” “feel,” or “remember” with one observable change.
2. Name one owner. Select the system that stores the state and authorizes its transitions.
3. Limit the state. Use a small finite set or a bounded numeric range, and declare its initial state. Do not add state merely because a future feature might need it.
4. Write permitted transitions. For each transition, state the triggering event, the current condition, and the next condition. Also state what happens for event/state combinations that are not listed.
5. Specify consequences. List no more than two immediate consequences for this exercise.
6. Choose and justify the behavior model. Select authored state, a schedule, or bounded simulation. Explain why it is the smallest model that can produce the required observable result.
7. Declare exclusions. Name at least three nearby behaviors that remain outside the requirement.
8. Define evidence. State what a tester or designer can observe to confirm both the intended transition and the absence of an unintended one.
9. Validate the contract. Compare the completed worksheet with every criterion in the validation section before considering it complete.

Use this worksheet:

Behavior:
Owner:
State:
Initial state:
Allowed transitions:
  - [event] + [current state] -> [next state]
Unlisted event/state combinations:
  - [remain unchanged, or specify another bounded result]
Consequences:
  -
  -
Behavior model:
  - [authored state | schedule | bounded simulation]
Why this is the smallest sufficient model:
  -
Out of scope:
  -
  -
  -
Evidence:
  -
  -

Before moving on, challenge your own contract with four questions:

• Can another system change this state without going through the owner?
• Is there a state or transition that the behavior does not actually need?
• Could two developers interpret the consequence differently?
• Have you chosen a more complex behavior model than the required observable result needs?

Revise the contract if the answer to any question is yes.

823. Validation / evidence

Your contract is acceptable when it meets all of these checks:

• It describes one observable world behavior rather than a general atmosphere.
• Exactly one system owns the state and its transitions.
• The state has a finite or otherwise explicit boundary and a valid initial state.
• Every allowed transition identifies a trigger and a resulting state.
• Event/state combinations outside the listed transitions have an explicit result, such as no change.
• Consequences are deterministic and limited to the stated behavior.
• At least three adjacent behaviors are explicitly out of scope.
• Evidence can be observed without inferring hidden simulation activity.
• The contract names whether the requirement uses authored state, a schedule, or bounded simulation.
• The contract explains why the selected behavior model is the smallest sufficient choice for the required result.

A strong submission can be handed to another developer who can answer “what changes, who changes it, which model governs it, and what should the player observe?” without asking for a broader world vision.

824. Key takeaways

• A living-world ambition becomes buildable only after its behavior and boundary are explicit.
• The owner stores the state and controls its transitions; the event source does not automatically own the state.
• Small, finite state contracts are easier to test and safer to extend.
• Deterministic consequences make a world behavior observable rather than merely atmospheric.
• The smallest sufficient behavior model avoids unnecessary schedules or simulation.
• Out-of-scope declarations protect the requirement from uncontrolled system growth.

825. Next lesson

Continue to 2.12 — Navigation, maps, and vehicles. When defining a route contract, its navigation representation should expose only the bounded world state the route requires rather than becoming the authoritative owner of world state.

826. Knowledge check