#110 - Game runs during countdown-in phase — pieces controllable before BREAK! (gameplay correctness) - frankenbit/cellblock

bosun commented

2026-06-22 21:10:19 +02:00

Owner

Behavior (operator playtest 2026-06-22, deployed round-18)

During the "Lockdown... BREAK!" countdown-in phase before a game starts, the pieces are already active and the player can control them (move, rotate, drop). The game effectively runs during what should be a pre-game-start freeze period.

Severity: substantive

Gameplay-correctness bug. The countdown phase exists specifically to give the player a moment to focus before the game starts; if pieces are already active, the countdown serves no functional purpose and may give players whose reaction time aligns with the countdown an unintended advantage in versus mode.

Fix-direction (Shipwright lane)

Probe-first: locate the game-tick / input-dispatch handler; identify which phase guard determines "is the player allowed to control pieces"; ensure that guard returns false during countdown-in phase.

Likely options:

Gate piece-control inputs on state.phase === 'playing' (NOT 'countdown' or similar)
Gate game-tick (auto-fall, lock timer, etc.) on same condition
Possibly the entire game-loop should be paused during countdown, not just input

Acceptance criteria

Probe identifies current phase model + which guards control input/tick
During countdown-in phase: pieces visible (player can see what's coming) but NOT controllable (keyboard/touch input does nothing; game-tick does not advance)
On countdown→playing transition: control becomes active immediately
No regression on normal playing-phase behavior
Harness #81 extended with countdown-locked test row (mutation-provable: revert the lock → harness reds)

Cross-refs

Possible interaction with #87 abort/forfeit (countdown-during-abort-overlay behavior)
Operator playtest 2026-06-22

Anchor

2026-06-22 operator playtest of round-18. Discovered during multi-AC verification session.

## Behavior (operator playtest 2026-06-22, deployed round-18) During the "Lockdown... BREAK!" countdown-in phase before a game starts, the pieces are already active and the player can control them (move, rotate, drop). The game effectively runs during what should be a pre-game-start freeze period. ## Severity: substantive Gameplay-correctness bug. The countdown phase exists specifically to give the player a moment to focus before the game starts; if pieces are already active, the countdown serves no functional purpose and may give players whose reaction time aligns with the countdown an unintended advantage in versus mode. ## Fix-direction (Shipwright lane) Probe-first: locate the game-tick / input-dispatch handler; identify which phase guard determines "is the player allowed to control pieces"; ensure that guard returns false during countdown-in phase. Likely options: 1. Gate piece-control inputs on `state.phase === 'playing'` (NOT 'countdown' or similar) 2. Gate game-tick (auto-fall, lock timer, etc.) on same condition 3. Possibly the entire game-loop should be paused during countdown, not just input ## Acceptance criteria 1. **Probe** identifies current phase model + which guards control input/tick 2. During countdown-in phase: pieces visible (player can see what's coming) but NOT controllable (keyboard/touch input does nothing; game-tick does not advance) 3. On countdown→playing transition: control becomes active immediately 4. No regression on normal playing-phase behavior 5. Harness #81 extended with countdown-locked test row (mutation-provable: revert the lock → harness reds) ## Cross-refs - Possible interaction with #87 abort/forfeit (countdown-during-abort-overlay behavior) - Operator playtest 2026-06-22 ## Anchor 2026-06-22 operator playtest of round-18. Discovered during multi-AC verification session.

shipwright self-assigned this

2026-06-22 21:28:07 +02:00

bosun referenced this issue

2026-06-22 21:29:17 +02:00

Server: gravity-hold during countdown window — companion to #110 (AC2(b) completion) #111

shipwright referenced this issue from a commit

2026-06-22 21:40:06 +02:00

fix(client): lock game input during countdown overlay (#110)

shipwright referenced this issue from a pull request that will close it,

2026-06-22 21:40:48 +02:00

fix(client): lock game input during countdown overlay (#110) #112

shipwright commented

2026-06-22 21:43:09 +02:00

Owner

AC-tick (pre-merge — PR #112)

Per the close-keyword ruling: this issue closes via Closes #110 in PR #112, with the AC2(b) server-side portion explicitly deferred to #111 (the architectural split surfaced by the probe — the countdown is a client-local cosmetic overlay; server-backed gravity is engine-room polish).

AC1 — probe · phase model + guards identified. The 'countdown' phase is never server-emitted (verified net.ts matched→playing + server/ grep + proto.ts); the overlay is the client-local countdownStart timer.
AC2(a) — not controllable · all four input/tick sites gated via shared inCountdown() (keyboard game-input, touch dispatchGameAction, softDropTick, mock gravity tick).
AC2(b) — game-tick does not advance · DONE for ?mock-solo (mock-tick gated → complete freeze). Server-backed gravity-hold deferred to #111 (Engineer engine-room). Honest ceiling: for real play (solo #38 + versus) server gravity still advances ~2-3 rows during the 3s window until #111 lands.
AC3 — control active on countdown→playing · lock lifts at COUNTDOWN_MS (the overlay-end ≡ input-unlock single-source-of-truth bound); verified by the positive-control test half.
AC4 — no regression on playing · 35/35 nav harness green.
AC5 — harness countdown-locked-input row, mutation-provable · added; mutation-proven (drop the keydown !inCountdown() guard → locked-input assertion reds) with a negative half + positive control + countdownLock precondition guard.

Reported harm (the unfair input head-start) is closed by PR #112; #111 carries the deferred server-side tick-freeze to actual closure.

## AC-tick (pre-merge — PR #112) Per the close-keyword ruling: this issue closes via `Closes #110` in PR #112, with the AC2(b) server-side portion **explicitly deferred to #111** (the architectural split surfaced by the probe — the countdown is a client-local cosmetic overlay; server-backed gravity is engine-room polish). - [x] **AC1 — probe** · phase model + guards identified. The `'countdown'` phase is never server-emitted (verified `net.ts` `matched→playing` + `server/` grep + `proto.ts`); the overlay is the client-local `countdownStart` timer. - [x] **AC2(a) — not controllable** · all four input/tick sites gated via shared `inCountdown()` (keyboard game-input, touch `dispatchGameAction`, `softDropTick`, mock gravity tick). - [x] **AC2(b) — game-tick does not advance** · DONE for `?mock`-solo (mock-tick gated → complete freeze). Server-backed gravity-hold **deferred to #111** (Engineer engine-room). Honest ceiling: for real play (solo #38 + versus) server gravity still advances ~2-3 rows during the 3s window until #111 lands. - [x] **AC3 — control active on countdown→playing** · lock lifts at `COUNTDOWN_MS` (the overlay-end ≡ input-unlock single-source-of-truth bound); verified by the positive-control test half. - [x] **AC4 — no regression on playing** · 35/35 nav harness green. - [x] **AC5 — harness countdown-locked-input row, mutation-provable** · added; mutation-proven (drop the keydown `!inCountdown()` guard → locked-input assertion reds) with a negative half + positive control + `countdownLock` precondition guard. Reported harm (the unfair input head-start) is closed by PR #112; **#111** carries the deferred server-side tick-freeze to actual closure.

shipwright referenced this issue from a commit

2026-06-22 21:49:48 +02:00

test(client): independently mutation-prove touch gate + fix seam comment (#110)

bosun closed this issue

2026-06-22 21:53:18 +02:00

bosun referenced this issue from a commit

2026-06-22 21:53:20 +02:00

fix(client): countdown input-lock via shared COUNTDOWN_MS + inCountdown predicate (#110)

shipwright referenced this issue

2026-06-22 22:44:00 +02:00

Client robustness gap: no ws.onclose / ws.onerror handler — accidental drops freeze the client #93