Combat is a contract, not a weapon list

554. Lesson identity

Module

2.1 Combat

Lesson order

1

Academic type

Systems

Estimated time

25–35 minutes, including practice

Entry capability

Distinguish a game rule from content and describe a bounded interaction through its actors, input, response, state change, and repeatable consequence. No completed combat implementation is required.

This lesson defines combat as a bounded exchange between actors. The goal is not to enumerate weapons. The goal is to specify what can happen, which system may make each decision, which state may change, and which neighboring systems must remain untouched.

555. Learning objective

After this lesson, you can specify a combat exchange by naming its actors, input, rules, attack-commitment boundary, combat resolver, authoritative health state, outcomes, and protected neighboring systems.

556. Why this matters

A weapon list describes content, but it does not define a playable combat system. A combat contract provides a stable boundary that can be implemented, tested, tuned, and extended. It also gives generated code an explicit specification against which it can be reviewed.

A precise contract prevents several systems from making the same decision. Combat validation may authorize an attack. A combat resolver may propose a damage amount. The target's health state authorizes and applies the health mutation. Presentation reports the outcome. Ammunition state records the cost of a committed shot. These responsibilities cooperate, but they are not interchangeable.

557. Prior knowledge

Before beginning, you should be able to:

• distinguish a game rule from a piece of content;
• identify the actor, input, response, and state change in a bounded interaction;
• describe a repeatable interaction using ACT → RESPOND → CHANGE → AGAIN; and
• separate an intended interaction from neighboring systems outside its rule boundary.

For example, “a pistol has a particular model” is content. “An authorized shot consumes one ammunition unit when the shot is committed” is a rule.

558. Core concept

A combat contract is a precise statement of one meaningful exchange between actors. It defines:

1. Actors: who initiates and who may receive the exchange.
2. Input: the command that requests the exchange.
3. Readiness and authorization rules: conditions that determine whether the command may become an attack.
4. Attack commitment: the point at which an authorized attack is actually fired or performed.
5. Hit validation: the determination that the committed attack reached an eligible target. A miss is still a committed attack.
6. Combat resolver: the system that calculates a proposed damage amount after the relevant rules and modifiers are known.
7. Target Health State: the exclusive authority that accepts or rejects the proposed health transition according to its invariants, applies any authorized mutation, and records the resulting health and applied damage.
8. Feedback: information that communicates the recorded result without changing health.
9. Protected neighbors: related systems that may observe the exchange but must not be directly mutated by it without a separate contract.

559. Three distinct responsibilities

Use these terms consistently:

• Proposed damage: a calculated value produced by the combat resolver. It is a proposal, not yet a health mutation.
• Authorized health mutation: the transition accepted and applied by the Target Health State after enforcing its own rules and invariants.
• Applied outcome: the resulting health and any applied-damage record owned by the Target Health State.

The resolver may calculate or propose damage, but it must not subtract target health or maintain a competing health value. The Target Health State does not need to own every calculation that produced the proposal; it owns the decision to mutate its health and the recorded outcome of that mutation.

A weapon remains content. Different weapons may provide different range, timing, cost, or damage inputs while using the same contract.

560. Mental model

Use the Authorized Exchange with One Health Authority model:

A compact contract can read:

When [attacker] issues [input] and readiness rules authorize it, the attack becomes committed at [commitment point]. Ammunition is consumed according to that commitment rule. If hit validation identifies an eligible target, [combat resolver] calculates a proposed damage amount and submits it to the Target Health State. That state alone authorizes and applies the health mutation and records the outcome. Presentation reports the recorded result, while protected neighbors remain unchanged.

561. Concrete example

Consider one ranged attack against one target:

1. The player issues a fire command.
2. Readiness validation checks that the weapon is ready and that ammunition is available.
3. If readiness fails, no shot is committed and no ammunition is consumed.
4. If readiness passes, the shot is committed and one ammunition unit is consumed.
5. Hit validation determines whether the shot reached an eligible target. A miss consumes ammunition because the shot was already committed.
6. If there is a valid hit, the combat resolver calculates a proposed damage amount. It does not change health.
7. The Target Health State checks its mutation rules, applies any authorized health change, and records the resulting health and applied damage.
8. Presentation reports a miss, blocked result, or applied hit from the recorded outcome. It does not subtract health.
9. Mission completion, rewards, inventory ownership, and enemy spawning remain unchanged unless another contract explicitly handles them.

A blocked hit may produce proposed damage but no applied health change if the Target Health State rejects or reduces the mutation according to its rules. That distinction is why proposed damage and applied damage must not be treated as the same record.

562. Common mistakes

563. Duplicate authority

The combat resolver calculates 20 and directly subtracts it from health. An animation callback then subtracts 20 again. Both systems have become health authorities. The correction is to let the resolver submit one proposal and let only the Target Health State authorize and apply the transition.

564. Ambiguous ammunition timing

“Consume ammunition after a valid attack” is incomplete. It could mean after readiness authorization, after the shot is fired, after a hit, or after damage is applied. State the commitment boundary instead.

A clear rule is:

Consume ammunition when an authorized shot is committed. Consume none for an invalid fire command. A committed miss or blocked hit still consumes ammunition.

Other designs are possible, but the contract must explicitly state what happens for an invalid command, a miss, and a blocked hit.

565. Unprotected neighboring mutation

A target reaching zero health may eventually contribute to mission or reward logic, but the bounded attack contract should not directly rewrite mission completion or grant rewards. It may emit or expose an outcome for another contract to observe.

566. Guided practice

Write a contract for one ranged attack against one target.

Answer all of these questions:

1. Who are the attacker and target?
2. What input requests the attack?
3. Which readiness conditions authorize or reject the command?
4. At what exact point is the attack committed?
5. When is ammunition consumed, and what happens on an invalid command, a miss, and a blocked hit?
6. Which system performs hit validation, and what may it decide?
7. What is the combat resolver called, and what is it permitted to calculate or propose?
8. What request does the resolver submit to the Target Health State?
9. Why must the resolver not mutate health?
10. How does the Target Health State authorize, apply, and record the health outcome?
11. What feedback is produced for a miss, blocked result, or applied hit?
12. Which two or more neighboring systems are protected from direct mutation?

Use this template:

Actors:
Input:
Readiness authorization rules:
Invalid-command result:
Attack commitment point:
Ammunition rule:
Result on a miss:
Result on a blocked hit:
Hit validator and permitted responsibility:
Combat resolver and permitted responsibility:
Proposed-damage request:
Target Health State and exclusive responsibility:
Recorded health outcome:
Feedback:
Protected neighbors:
Why resolver and health authority remain separate:

567. Validation and evidence

Submit the completed contract as the lesson's practical evidence. Check it against these criteria:

• The exchange has one clear initiating input and identifiable actors.
• Readiness authorization is separated from hit validation and damage resolution.
• The attack commitment point is explicit.
• Ammunition behavior is stated for an invalid command, a committed miss, and a blocked hit.
• The combat resolver is named and may only calculate or propose damage; it does not mutate health.
• The Target Health State is the exclusive authority that authorizes and applies the health mutation and records the applied outcome.
• Proposed damage is distinguishable from applied damage or resulting health.
• Presentation communicates outcomes without changing health.
• At least two neighboring systems are protected from direct mutation.
• The contract is precise enough that two implementers would not choose materially different authority or ammunition boundaries.

If two systems can subtract health, if ammunition depends implicitly on hitting the target, or if the contract does not distinguish proposed from applied damage, revise it before continuing.

568. Key takeaways

• Combat is a bounded contract, not a catalog of weapons.
• Readiness authorization, attack commitment, hit validation, damage resolution, and health mutation are distinct boundaries.
• The combat resolver calculates a proposed damage amount without mutating health.
• The Target Health State exclusively authorizes and applies the health mutation and records the applied outcome.
• Ammunition rules must state what happens on invalid commands, misses, and blocked hits.
• Presentation and neighboring systems may observe outcomes without becoming health authorities.

569. Next lesson

Continue to 2.1 L2 — Trace damage from intent to outcome, where you will map the exchange and diagnose duplicate-authority paths.

570. Knowledge check