Return defeated parties to dormant state
This commit is contained in:
@@ -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`.
|
||||
|
||||
Reference in New Issue
Block a user