Scripted world versus simulated world

801. Lesson identity

Module

2.10 — Living world

Lesson

Scripted world versus simulated world

Academic type

Concept

Schema type

text

Order

1 in the module

Estimated time

30–40 minutes, including practice

This lesson replaces the vague requirement that a world should feel “alive” with a decision framework for choosing authored state, schedules, or bounded simulation.

802. Learning objective

After this lesson, you can classify a world behavior as authored state, scheduled behavior, or bounded simulation and justify the choice using player impact, required variability, and implementation scope.

803. Why this matters

A world does not become better merely because more of it is simulated. Simulation adds rules, state, debugging surfaces, and opportunities for surprising results. Authored state can produce a stronger dramatic beat; a schedule can make time feel meaningful; a bounded simulation can create repeatable variation inside a defined area. Your job is to select the smallest behavior model that produces the intended player experience.

This distinction also improves AI direction. If you ask an AI tool to “make the world feel alive,” it may generate an oversized system with unclear ownership. If you specify the behavior category and its boundaries, you can evaluate the proposal as a game developer rather than accepting complexity as progress.

804. Prior knowledge

You should be able to describe a system in terms of state, rules, player-facing consequences, and explicit boundaries. This lesson builds on the previous module work on thin, explicit faction consequences, including approved inputs, thresholds, and response ownership.

805. Core concept

“Living world” is not an implementation category. It is a player-facing goal that must be translated into a behavior choice:

1. Authored state: A deliberate state or transition selected by the design, such as a location becoming closed after a mission event.
2. Schedule: A planned change based on time, phase, or sequence, such as a shop opening during the day and closing at night.
3. Bounded simulation: A rule-driven process that generates outcomes within an explicit scope, such as a small group of agents choosing destinations from a limited set.

These choices are not ranked from simple to advanced. The correct choice depends on the experience, not on how much computation the system can perform.

A useful distinction is:

• Authored state answers, “What state should this moment produce?”
• A schedule answers, “When should this known behavior occur?”
• A bounded simulation answers, “What outcome should rules produce within this defined scope?”

806. Mental model

Use the Intent → Variability → Scope test:

Choose the narrowest column that satisfies the player-facing requirement. A behavior can also combine categories, but each part should still be named. For example, a schedule may activate a bounded simulation during a night phase; the schedule controls when, while the simulation controls how outcomes vary.

807. Concrete example

Suppose a settlement has a repair shop:

• Authored state: After the player delivers a required part, the shop changes from unavailable to available. The design needs this exact progression beat.
• Schedule: The shop is available from morning through evening and unavailable overnight. The timing is the experience; no agent simulation is required.
• Bounded simulation: During open hours, three customers select from two repair queues. Their choices change which service is available first, but only inside this shop and only while the shop is active.

If the design requirement is “the player must find the shop closed until the delivery is complete,” simulation is the wrong tool. If the requirement is “the shop should have different customer activity each visit,” a bounded simulation may be justified. If the requirement is only “the shop should not operate at night,” use a schedule.

808. Common mistake

The common mistake is treating simulation as a synonym for quality. A simulated version of a behavior can undermine a required story beat, create results the player cannot read, or consume time without changing decisions. Another mistake is calling a long list of scripted exceptions a simulation. If every outcome is manually authored, label it as authored state and manage it as such.

809. Guided practice

Classify each behavior and write one sentence explaining the decision:

1. A gate must remain locked until the player completes a named objective.
2. A guard changes patrol route at the start of each watch period.
3. Wildlife chooses one of four resting areas within a valley, but only while the player is nearby.
4. A notice board displays a specific message after a faction consequence is triggered.

For each item, use the Intent → Variability → Scope test. Then revise one item so that it uses a different category without violating the player-facing requirement. If you cannot revise it without changing the experience, state why.

Your decision must identify:

• the selected category;
• the state or inputs that activate it;
• the boundary that prevents unnecessary system growth;
• the player-facing reason for the choice.

810. Validation / evidence

Your evidence is a four-row classification table or equivalent design note. Each row must contain a behavior, category, activation condition, scope boundary, and justification. A strong result distinguishes a required authored beat from time-based behavior and from genuine rule-driven variation. It does not justify simulation solely by saying that it is more realistic or more advanced.

811. Key takeaways

• “Living world” describes an outcome, not a system design.
• Authored state is appropriate when the player needs a specific result.
• Schedules make known behavior change at defined times or phases.
• Bounded simulation is appropriate only when rule-driven variation improves the experience within a clear scope.
• Name the behavior category before asking an AI tool to propose implementation details.

812. Next lesson

Next: 2.10 L2 — Bound the world requirement.

813. Knowledge check