Combat

Model

Combat is script-driven. The seven programs COMBAT1 through COMBAT7 compose ordinary VM variables, flags, animations, actions, random branches, sound effects, and faith changes. A compatible engine MUST execute those programs rather than inventing a separate health/damage simulation.

The encounters correspond to:

The action selectors are .11 Attack, .12 Defend, .13 Retreat, and .14 Combat. They are ordinary scene action targets and their program targets define the outcome. An action is available only while its target record is active. Manual mode normally activates Attack, Defend, and Retreat. Automatic mode normally activates Combat and Retreat. Combat 6 has no Defend target. The numeric selector syntax draws the corresponding one-based frame from loaded ART slot 1. Because every encounter loads COMBTAGS.ART first, the hover labels are the four authored frames rather than host-rendered text. Keyboard A (or S), D, and R choose Attack, Defend, and Retreat. C chooses an active ordinary .c target if one exists, otherwise it chooses Combat.

Player understanding

Captain Bible does not have hit points. His 0–100% Faith meter is the loss condition. Cyber attacks and incorrect choices reduce faith. At negative faith, the engine clamps it to zero and enters the OVER scene.

The player answers a Cyber’s lie through study before the physical encounter. Within combat, Attack and Defend manipulate timing and animations. The Combat action enters a script-defined randomized exchange. Sword flag 30 and Shield flag 31 affect those branches and the duration of useful windows. Retreat exits without defeating the Cyber. The scripts, not the engine, decide which animation phase makes each action effective.

Automatic Combat is persistent flag 37. Ordinary combat sets flag 38 while active; the options menu MUST prevent changes to Automatic Combat during that interval. Combat 6 intentionally does not use the lock.

Faith loss

Opcode 81 supplies a base loss in internal faith units. The engine applies:

No-combat installation mode suppresses the subtraction. The shipped static loss sites are:

These are possible branch sites, not values that all occur in one fight.

Outcome contract

Victory in combat 1–5 and 7 changes the current connected map-cell kind to B. Combat 6 changes it to A, copies parameter B to parameter A, and clears B, revealing the covered Scripture station. Retreat skips these mutations, so returning to the location preserves the encounter.

The Zapper victory alternates faith between 1 and 10000 five times as a visual meter flash and ends at full faith. This reward occurs before the cell is marked cleared.

Every encounter eventually selects the appropriate level hall scene and starts a palette blackout. Two special hall variants may be selected by scene state. Program self-patching constructs the hall name from the current level letter. Scene logic also clears parameter A at the common exit where directed by the resource.

Animation and synchronization

Combat animation records use the format in Scene runtime. Actions commonly disable choices, start one or more linked animations, play a sound, and suspend until completion. Muted audio MUST use an equivalent logical completion timer. Random modulo results select branches; deterministic test runs MAY inject a known initial state. Ordinary play MUST use the shared generator and consumption order defined in Lifecycle and scheduling without reseeding it. An interactive host SHOULD choose a varying initial state unless the player explicitly requests deterministic play.

Dispatching an action target starts scheduler slot zero as a fresh invocation: the target replaces its cursor, the slot becomes active and unsuspended, its stale delay and call stack are cleared, and it is eligible during the same controller update. Opcode 3E applies the same fresh-start state to its named slot and runs that slot immediately before its caller continues. Combat idle loops deliberately accumulate negative delays, so retaining the old delay would make a selected action appear unresponsive.

POWER is the in-combat study/power scene. It can patch a numbered combat1 name and return to the corresponding encounter. It is not the game-over scene. Implementations MUST support this entry even though the exact set of all scene paths that invoke it is not a separate engine invariant.