An encounter has a boundary

616. Lesson identity

Module

2.3 — Spawning and encounters

Lesson

1 of the module

Academic type

Concept

Schema type

text

Estimated time

25–35 minutes

Capability target

Define one encounter lifecycle.

617. Learning objective

After this lesson, you can define an encounter by naming its activation condition, active state, completion condition, and terminal outcome.

618. Why this matters

A group of enemies is not automatically an encounter. Without a boundary, the game cannot reliably decide when to activate the group, when to stop spawning or directing it, or when the player has completed the challenge. This distinction also gives AI a precise design target: it can help implement a lifecycle only after you have specified the lifecycle. The encounter boundary is therefore a design contract, not merely a code organization choice.

619. Prior knowledge

You should be able to distinguish a system that decides from a system that performs, as introduced in 2.2 L2 — Separate deciding from doing. This lesson explicitly hands off from that boundary: the encounter decides whether activation and completion transitions are valid, while other systems perform the resulting actions. In particular, you should be comfortable describing a request or intention without treating it as proof that an action succeeded.

620. Core concept

An encounter is a bounded gameplay process with explicit phases and transitions.

A useful encounter definition answers four questions:

1. What activates it? A player action, a location condition, a story condition, or another declared trigger.
2. What makes it active? The state in which the encounter may request participant spawning, register participants, direct coordination, and evaluate progress.
3. What completes it? A rule such as defeating all required participants, surviving a duration, or reaching a declared objective.
4. What happens after completion? The encounter becomes terminal: it does not silently reactivate or continue producing work unless a separate rule says so.

The enemies are participants inside this process. They are not the process itself. An encounter may contain zero currently active enemies during a transition and may still be active if its rules allow more participants to appear.

621. Mental model

Use the encounter boundary model:

INACTIVE
   │ activation condition is true
   ▼
ACTIVE
   │ completion condition is true
   ▼
COMPLETED

The key boundary is between participant state and encounter state. An enemy can be defeated while the encounter remains active if another required participant is pending. Conversely, an encounter can complete only when its own completion rule is satisfied, not merely because one enemy disappeared.

When describing transitions, keep the previous lesson's separation in place: the encounter controller decides whether a transition is valid; other systems perform the resulting spawn, movement, combat, or reward actions. The completion rule supplies the criterion that the controller evaluates; the rule itself is not a deciding system.

622. Concrete example

Consider a small courtyard challenge:

• Activation: the player enters the courtyard.
• Active: the encounter registers two required guards. It tracks whether each required guard has been defeated.
• Completion: both required guards are defeated.
• Terminal outcome: the encounter records completion and no longer accepts the same activation as a new run.

The two guards are not the boundary. They are the encounter's current participants. If one guard is defeated and the other is still present, the encounter is active, not complete. If a guard is removed because of a temporary gameplay event, that removal also does not automatically prove completion. The encounter lifecycle evaluates the declared completion rule to determine what counts as complete.

623. Common mistake

A common mistake is to define an encounter as “the enemies placed in this area.” That definition breaks when an enemy leaves the area, is replaced, spawns later, or is defeated before another required participant appears. It also makes completion ambiguous. Define the encounter's lifecycle first, then define how enemies participate in it.

624. Guided practice

Create one fictional encounter specification; no code is required. The primary evidence artifact is an encounter lifecycle table. Complete every field in the table before writing explanations.

Choose one completion rule: all required participants, a survival duration, or an objective event. The chosen rule must appear consistently in the table and in the three test cases.

Use this table:

The table must define the activation condition, active responsibility, completion condition, and terminal outcome. For authority, identify the encounter lifecycle or another specifically named deciding system; do not assign transition authority to a completion rule, a participant's state, or visual presentation alone. A rule supplies a criterion for the named authority to evaluate. Keep the previous lesson's boundary: the authority decides whether a transition is valid, while other systems may perform resulting actions.

Then test the same table with these three cases:

1. The player reaches the activation area but no enemy has spawned yet.
2. One participant is defeated while another required participant is pending.
3. The completion condition becomes true, but a late event tries to activate the encounter again.

For each case, write the current phase, the proposed transition if any, and the authority that accepts or rejects it. If the table cannot answer one of the cases, revise the lifecycle boundary instead of adding an informal exception.

625. Validation / evidence

Submit one completed encounter lifecycle table and three written test-case decisions. The lifecycle table is the primary evidence artifact. It is sufficient when:

• every row names a phase;
• every applicable transition into and out of a phase is explicit;
• every transition names its deciding authority;
• activation, active responsibility, completion, and terminal outcome are defined;
• case 1 identifies whether the encounter is inactive or active without treating the absence of a spawned enemy as proof of completion;
• case 2 distinguishes participant state from encounter state while a required participant remains pending; and
• case 3 applies the completed boundary to the late activation event without silently reactivating the encounter.

The evidence should let another person determine the encounter's phase and valid transition from the table alone.

626. Key takeaways

• An encounter is a bounded lifecycle, not merely a group of enemies.
• Activation, active behavior, and completion must be explicit.
• Participant changes do not automatically determine encounter completion.
• A deciding system evaluates a completion rule; the rule is a criterion, not an authority.
• A completed encounter needs a terminal outcome and a clear reactivation rule.
• A precise boundary gives implementation systems and AI a reliable design contract.

627. Next lesson

Continue to 2.3 L2 — Orchestrate actors without duplicating authority, where you will turn the lifecycle specification into an encounter board with triggers, phases, participant coordination, and named owners.

628. Knowledge check