Design phases without a second combat system

656. Lesson identity

Module

2.4 — Boss design

Lesson

Design phases without a second combat system

Academic type

Systems

Schema type

text

Order

2 of the module

Estimated time

35–45 minutes, including practice

657. Learning objective

After this lesson, you can produce a phase table that specifies each phase's trigger, preserved combat invariants, player-facing feedback, recovery path, and ownership across combat, encounter, boss, and presentation systems.

658. Why this matters

A phase change should make the existing boss contract more demanding, clearer, or differently timed—not replace it with an unrelated game. Reusing established combat rules reduces cognitive load for the player and implementation risk for the team. Clear ownership prevents phase logic from duplicating combat resolution or presentation logic from becoming the source of truth for gameplay. It also gives an AI coding partner a bounded specification instead of an invitation to add arbitrary attacks, states, or resources.

659. Prior knowledge

You should already be able to identify a boss promise, player decision, readable threat, and punishable mistake from 2.4 L1 — A boss is a readable contract. You should also be familiar with the combat rules and feedback conventions established earlier in Stage 2.

660. Core concept

A boss phase is a controlled variation of an existing contract. The phase may change timing, positioning, sequencing, or pressure, but it must preserve the encounter's core decision unless the design explicitly declares a new contract. Every phase needs four parts:

1. Trigger: the condition that starts the phase.
2. Invariants: the rules that remain true across the transition.
3. Feedback: what tells the player that the phase has changed and what decision is now expected.
4. Recovery: how the player and boss return to a stable, legible combat state.

It also needs explicit ownership:

• Combat owns resolution: hit detection, damage application, invulnerability, interruption, and death remain governed by the combat system.
• Encounter owns orchestration: phase triggers, sequencing, arena conditions, and the timing of boss behavior belong to the encounter layer.
• Boss owns intent: the boss selects or exposes an attack pattern, movement choice, or recovery behavior within the existing combat contracts.
• Presentation owns communication: animation, sound, effects, UI, and arena cues communicate state changes but do not decide whether damage or a hit occurred.

A phase table exposes both the design change and the boundary between systems before implementation begins.

661. Mental model

Use the Phase Delta and Ownership Test:

A phase is successful when its delta is meaningful, its invariants keep the fight recognizable, and each system has one clear responsibility. Presentation may reveal a phase; it must not silently create one. Boss logic may request an attack; it must not apply damage by bypassing combat resolution.

662. Concrete example

Assume the boss contract is: the player must read a telegraphed charge, move out of its path, and punish the recovery window.

This design creates escalation through timing and sequencing. It does not add a new stamina meter, a new weapon interaction, or a separate movement system. The player continues solving the original problem—read, evade, punish—with a more demanding version of the same contract. The ownership column also prevents a common implementation error: the boss controller can request or describe an attack, but the combat system remains the authority for whether that attack hits and what damage it causes.

663. Common mistake

The common mistake is treating a phase as permission to add content rather than as a controlled design change with explicit system boundaries. A designer may add projectiles, a summon, a new resource, and a new arena rule because the boss needs to feel different. An implementer may then let the boss controller apply damage directly or let a visual effect determine a hit. The result is a second combat system that competes with the original promise and makes failure difficult to diagnose.

Test each proposed phase feature with two questions: Does it deepen the existing player decision, or does it ask the player to learn a different game? and Which system owns the decision, resolution, and communication? If it creates a different game, remove it, defer it, or explicitly redesign the boss contract before implementation. If it duplicates combat resolution, route it through the established combat authority instead.

664. Guided practice

Create a phase table for a hypothetical boss using this contract:

The player waits for a readable opening, avoids a committed attack, and uses the attack's recovery window to deal damage.

Design three phases. For each phase, write:

• the trigger;
• one variable that changes;
• at least two invariants that remain true;
• the feedback the player receives before or during the change;
• the recovery condition that restores a stable combat state;
• the owner of the trigger, boss intent, combat resolution, and presentation cue.

Then perform the Phase Delta and Ownership Test. Mark each proposed change as one of the following:

• Deepens: increases timing, positioning, or sequencing pressure while preserving the contract;
• Neutral: changes presentation without changing the decision;
• Competes: introduces a new decision system that may obscure the contract;
• Misowned: asks the wrong system to resolve or communicate the behavior, such as boss logic applying damage directly.

Revise or remove every item marked Competes or Misowned. Your meaningful design decision is choosing which escalation to keep when a more elaborate feature would be easier to describe but less consistent with the boss promise, then assigning each remaining responsibility to the correct system.

665. Validation / evidence

Your evidence is a completed three-row phase table with an ownership column. It passes when:

• every phase has an explicit trigger;
• the core player decision remains recognizable in all phases;
• at least two invariants are named rather than implied;
• feedback tells the player what changed before the new demand must be solved;
• every phase has a recovery path;
• combat resolution remains the authority for hit detection, damage, interruption, invulnerability, and death;
• boss logic describes or requests behavior without directly bypassing combat resolution;
• encounter logic controls phase sequencing without becoming a duplicate combat resolver;
• presentation communicates state changes without silently changing gameplay rules;
• no phase requires an unannounced combat resource, control scheme, or unrelated objective;
• the table can be handed to an implementer without relying on phrases such as “make it more intense.”

A useful final test is to hide the phase names and read only the trigger, feedback, recovery, and ownership columns. You should still be able to explain what the player is expected to notice and do, which system initiates the change, and which system resolves its consequences.

666. Key takeaways

• A boss phase is a controlled variation of an existing contract, not automatically a new combat system.
• Triggers define when a phase begins; invariants define what remains reliable.
• Combat owns combat resolution; boss and encounter logic express intent and orchestration; presentation communicates the result.
• Feedback must communicate both that the phase changed and what decision now matters.
• Recovery prevents escalation from becoming permanent confusion or an unbounded attack chain.
• A phase table turns boss escalation and system ownership into a reviewable design before code is written.

667. Next lesson

Continue to 2.5 — Inventory, equipment, and crafting.

668. Knowledge check