Return defeated parties to dormant state

This commit is contained in:
2026-08-17 20:49:04 -07:00
parent e24b1b4a3f
commit db19a89957
10 changed files with 67 additions and 66 deletions
+23 -25
View File
@@ -49,7 +49,7 @@ The implementation must optimize for the following goals, in order:
- One character per Twitch user
- Twitch Extension controls
- Shared stream-facing game view and chronological action log
- Dormant, Player Phase, Enemy Phase, floor transition, and run reset states
- Dormant, Player Phase, Enemy Phase, floor transition, and administrative run reset states
- AP, movement, combat, AutoGuard, self-heal, death, and resurrection
- One Goblin Guard with guarding, pursuit, and return behavior
- Varied, navigable two-room floors
@@ -276,7 +276,7 @@ type PhaseState =
initialEligiblePlayerIds: string[]
}
| { kind: 'enemy'; phaseId: string }
| { kind: 'transition'; reason: 'floor-advance' | 'party-wipe' }
| { kind: 'transition'; reason: 'floor-advance' | 'admin-reset' }
```
The backend uses a monotonic clock for elapsed phase timing. Wall-clock values
@@ -438,9 +438,9 @@ While no active character exists:
The first accepted `!spawn` creates a living character, removes the banner, and
starts a fresh Player Phase.
The MVP has no voluntary leave or character-removal command. Temporary
disconnects therefore do not create dormancy. A total-party death triggers a
run reset rather than dormancy.
Temporary disconnects do not create dormancy because disconnected living
characters use AutoGuard. A total-party death does create dormancy while
preserving the run, floor, Goblin, and dead character records.
### 9.2 Starting Player Phase
@@ -485,7 +485,7 @@ The living Goblin receives 2 AP and repeatedly selects one deterministic action
until it has no AP or no valid action.
After the Goblin finishes, Guard is discarded and a new Player Phase begins,
unless the floor advanced or the run reset during the Enemy Phase.
unless the floor advanced or the party became dormant during the Enemy Phase.
### 9.5 AutoGuard
@@ -633,25 +633,21 @@ When a living player enters the exit:
The previous Goblin and map are discarded.
### 12.3 Total-party wipe
### 12.3 Total-party defeat
After any death resolution, if participating characters exist and none is
alive, the backend immediately:
1. enters transition state;
2. creates a new run ID;
3. sets the floor counter to 1;
4. generates a new starting floor and Goblin;
5. restores all participating players alive at 3 HP;
6. clears death markers, AP, and Guard;
7. refreshes all self-heals;
8. places all players at the spawn tile;
9. logs the wipe and reset; and
10. begins a fresh Player Phase.
1. enters Dormant state with no deadline;
2. preserves the current run ID, floor, and Goblin;
3. preserves each dead character and current-floor death marker;
4. stops Enemy Phase processing immediately; and
5. logs the party defeat.
Because the reset is immediate, a Channel Points redemption cannot interrupt a
completed total-party wipe. Zero participating characters is explicitly not a
wipe.
A valid Channel Points resurrection revives its owner and starts a fresh Player
Phase from dormancy. A newly eligible viewer may also spawn into the current
floor and resume play. Initial dormancy has no participants, while defeated-party
dormancy retains dead participant records.
## 13. Randomness
@@ -771,7 +767,9 @@ starting an empty client-only log.
When phase is dormant, both applicable views prominently display exactly:
`Type !spawn to spawn in the Twungeon!`
`Activate the Extension to spawn your character in the Twungeon!`
`Must be a follower to spawn.`
## 16. Failure and Recovery Behavior
@@ -879,10 +877,10 @@ Deterministic tests must cover:
- AutoGuard conversion, hit blocking, misses, and reset;
- player and Goblin hit probabilities through injected rolls;
- heal availability and floor refresh;
- death, spawn lockout, resurrection, advancement, and wipe reset;
- death, spawn lockout, resurrection, advancement, and defeated-party dormancy;
- Goblin guarding, aggro on hit or miss, pursuit, return, and death;
- exit entry with a living Goblin;
- dormant versus total-party-wipe conditions;
- initial versus defeated-party dormant conditions;
- serial ordering and stale/duplicate command handling; and
- deterministic floor generation and connectivity validation.
@@ -913,7 +911,7 @@ At minimum, the live test plan must demonstrate:
7. Goblin aggro, pursuit, attack, target death, and return;
8. Channel Points resurrection of the correct dead viewer;
9. floor escape with the Goblin alive and dead-player revival;
10. total-party wipe and Floor 1 reset;
10. total-party defeat, dormant transition, and resurrection recovery;
11. refresh and temporary disconnect recovery; and
12. repetition across multiple generated floors.
@@ -941,7 +939,7 @@ slices:
2. Implement the deterministic floor generator and static stream rendering.
3. Implement player/Goblin state, commands, turn phases, timer, and action log
using local test drivers.
4. Implement death, resurrection messages, floor advancement, wipe reset,
4. Implement death, resurrection messages, floor advancement, defeat dormancy,
dormancy, reconnect, and idempotency.
5. Add the RPGJS adapter without moving rules out of the domain package.
6. Add Twurple chat and follower verification for `!spawn`.