Separate deciding from doing

601. Lesson identity

Module

2.2 — Enemy AI

Lesson

Separate deciding from doing

Academic type

Systems

Order

2 in the module

Estimated time

35–45 minutes, including practice

602. Learning objective

After this lesson, you can draw an AI boundary diagram, write acceptance criteria for patrol, alert, pursuit, and disengage contracts, and trace the effect of a changed detection rule across those boundaries.

603. Prior knowledge

This lesson builds on 2.2 L1 — Enemy behavior is a state contract. You should be able to identify a state's entry condition, observable behavior, exit condition, owner, and fallback.

604. Why boundaries matter

An enemy decision controller should choose what the enemy intends to do. It should not secretly move the enemy, mutate health, confirm death, control presentation, or grant rewards.

When one controller performs all those operations, behavior changes create hidden coupling. Clear contracts make each request reviewable: the decision controller proposes an intention, the appropriate domain system applies its own rules, and an observable result returns to the state contract.

605. The controller contract

Use the model observe → decide → request → validate → enact → report:

Perception facts
      |
      v
Decision/state controller -- request --> Domain system
                                      validates its own rules
                                      enacts or rejects
                                             |
                                             v
                                  Observable result
                                             |
                                             v
                              State contract and presentation

The responsibilities in this lesson use the following consistent allocation:

• Perception: reports raw or normalized facts, such as visibilityConfidence, distance, or whether line of sight is currently blocked.
• Decision/state controller: owns behavior policy. It compares perception facts with the state contract's thresholds, chooses states and intentions, and determines whether pursuit remains behaviorally permitted.
• Movement controller: owns locomotion feasibility and execution, including navigation, blocked paths, speed limits, and stopping constraints.
• Combat system: validates attack requests, including range, cooldown, target validity, and attack rules.
• Health system: applies accepted damage and owns health mutation.
• Outcome system: confirms terminal results such as Defeated or Escaped according to game rules.
• Animation or presentation system: represents confirmed states and results without creating authority.
• Reward or progression system: reacts to confirmed outcomes rather than to AI intentions.

An implementation may combine combat, health, and outcome components. Even when combined, every rule must still have one explicit authoritative owner. In the examples here, combat validates the attack, health applies accepted damage, and outcome confirms a terminal result.

606. Detection contract

This lesson uses one explicit detection contract:

1. Perception reports a normalized fact such as visibilityConfidence = 0.72.
2. The Patrol → Alert decision/state contract owns the alert threshold, such as alertThreshold = 0.65.
3. The decision controller compares the reported fact with that threshold.
4. If the contract permits the transition, the controller enters Alert or emits the corresponding intention.

Perception does not decide that the enemy must enter Alert. Changing the alert threshold therefore changes the decision/state contract, not the perception contract. Perception changes only if the meaning, range, or production of visibilityConfidence changes.

607. Policy is not feasibility

Pursuit involves two different questions:

• Policy: Should this enemy continue pursuing? The decision/state controller answers this using the pursuit contract, target validity, pursuit limits, and relevant reported facts.
• Feasibility: Can the requested movement be enacted now? The movement controller answers this using navigation, blocked-route, locomotion, and stopping rules.

For example, pursuit can remain permitted even when a route is temporarily blocked. The movement controller may reject the current movement request, after which the state contract chooses a fallback such as waiting, requesting a different route, repositioning, or disengaging. A movement rejection does not silently rewrite behavior policy.

608. Attack and outcome boundaries

When the enemy wants to attack, the decision controller emits an attack request or intention for the combat system to validate. It does not emit an already validated attack.

Decision: RequestAttack(targetId)
Combat: validate range, cooldown, target validity, and attack rules
Combat: accept or reject the request
Health: apply accepted damage and mutate health
Outcome: confirm Defeated if the terminal rule is satisfied
Presentation: represent the confirmed attack and outcome
Rewards: react once to the confirmed outcome

An attack animation does not prove that an attack was accepted. A low health value or completed death animation does not by itself confirm Defeated. The authoritative result must come from the system that owns that rule.

609. Transition example

Consider Patrol, Alert, Pursue, and Disengage:

610. Common mistakes

A descriptive method with hidden authority

A method named enemyAttack() is not a meaningful boundary if it directly mutates health, starts authoritative death logic, and grants rewards. A boundary requires a request, an authoritative validator, and an observable result.

Letting movement decide behavior policy

The movement controller may report RouteBlocked, but it should not decide that pursuit is no longer allowed. The decision/state contract interprets that result and chooses whether to retry, reposition, wait, or disengage.

Letting presentation confirm rules

Animation represents accepted actions and confirmed outcomes. It does not determine whether damage applied, whether an enemy was defeated, or whether a reward is due.

611. Guided practice

Complete the practical assessment attached to this lesson. It provides a partially completed contract table so you do not need to duplicate every diagram label in prose.

Your work has four parts:

1. Complete one boundary diagram for perception, decision/state, movement, combat, health, outcome, presentation, and rewards.
2. Complete the missing cells in the provided transition table and write five concise acceptance criteria: one each for patrol, alert, pursuit, disengage, and a confirmed terminal outcome.
3. Choose whether the state controller receives distinct results such as TargetLost, Escaped, and Defeated, or a smaller result set. Explain the trade-off without transferring outcome authority to the AI.
4. Raise the alert threshold and trace the affected contract, downstream behavior, owners, and one contract or test that must be reviewed.

Do not write implementation code. The evidence is the boundary model and its contract reasoning.

612. Validation checklist

Your submission should make the following visible:

• Perception reports visibilityConfidence; the Patrol → Alert decision/state contract owns the alert threshold.
• The decision/state controller determines whether pursuit is permitted.
• The movement controller validates locomotion feasibility, navigation, and stopping constraints.
• An attack crosses the boundary as an unvalidated request for combat to validate.
• Combat validates attacks, health mutates health, and outcome confirms terminal results.
• Presentation and rewards react only to authoritative results.
• At least one rejected request has an observable fallback.
• The changed-threshold analysis names the contracts and owners that require review.

613. Key takeaways

• Decision controllers choose states and intentions; domain systems enforce their own rules.
• Perception reports facts, while the decision/state contract owns the alert threshold used here.
• Pursuit permission is behavior policy; movement feasibility is a locomotion concern.
• Attack intentions must be validated by combat before health changes.
• Combined components are acceptable only when each rule still has one explicit authoritative owner.
• Rejections and confirmed outcomes must return observable results to the state contract.

614. Next lesson

Next: 2.3 L1 — An encounter has a boundary. Confirmed spawn, active, defeated, escaped, and cleanup results will become inputs to the encounter lifecycle you define there.

615. Knowledge check