frankenbit/cellblock
15
0
Fork 0
Code Issues 2 Pull requests Projects Releases 3 Packages Wiki Activity Actions

Mobile multiplayer layout broken — opponent playfield not visible in-game, ready screen empty (MED, operator) #99

New issue
Closed
opened 2026-06-22 17:30:01 +02:00 by bosun · 3 comments
bosun commented 2026-06-22 17:30:01 +02:00
Owner
Copy link

Behavior (operator playtest 2026-06-22 iPhone Safari, deployed round-15)

Mobile multiplayer layout is broken on iPhone (portrait). Issues observed at TWO screens:

Ready screen ("CELLMATE FOUND"): layout doesn't fill mobile viewport. Vast empty space dominates; YOU vs OPPONENT panels look desktop-sized. (Screenshots captured.)

In-game multiplayer: only ONE playfield visible (player's), positioned to the right side. Opponent's playfield NOT visible. Score + NEXT + HOLD on left. Bottom controls look like solo controls (LEFT/ROTATE/RIGHT/SOFT DROP/HARD DROP). (Screenshots captured.)

Possible root causes (NEEDS PROBE)

  1. Solo layout being incorrectly applied to versus on mobile — possibly state-machine confusion (similar shape to #91 mode-routing bugs but on layout-selection axis)
  2. Versus layout designed for desktop, mobile fallback missing or broken — versus may have been built primarily for desktop landscape; mobile portrait fallback never properly designed
  3. Specific bug in versus-render-mobile path — e.g. opponent's playfield clipped off-screen, hidden by overflow, or never rendered

Severity: MED

This affects mobile multiplayer playability — operator's primary device. Players cannot meaningfully play versus on iPhone because they can't see the opponent's playfield.

Same family as cellblock#57 (overall portrait layout umbrella) but specifically versus-mode mobile layout.

Lane + size

Shipwright lane primary (UX render + layout state-machine). Possibly Herald creative-head input on versus-mobile UX intent (does versus on mobile show side-by-side miniature playfields? Stacked? Player-only with opponent-stats elsewhere?).

Probe-first recommended (similar shape to #91): read current versus layout code in render.ts; identify whether mobile path exists; identify why opponent playfield doesn't show.

Acceptance criteria (refine per probe)

  1. Probe identifies whether mobile-versus layout was designed + broken OR never designed
  2. Herald creative-head call on mobile-versus layout intent (if not previously settled)
  3. Fix lands so mobile player can see opponent's playfield + key game state during versus
  4. Ready screen fills mobile viewport reasonably (no vast empty space)
  5. Harness #81 extended with mobile-versus screen coverage (likely depends on #92 WS-mock work)
  6. No regression on desktop versus layout

Cross-refs

  • cellblock#57 (broader portrait layout umbrella)
  • cellblock#85 (lobby/wait screen — mobile-friendly already)
  • cellblock#92 (WS-mock harness — needed for versus mobile coverage)
  • Operator playtest 2026-06-22 with screenshots IMG_3618.png (ready screen) + IMG_3619.png (in-game)

Anchor

2026-06-22 operator playtest. Caught by real-mobile-play that headless emulation didn't surface (both chamber playtests ran versus only partially — Herald onboarding only, Surveyor matchmaking + ready-up but neither reached the active-play state on mobile-versus).

## Behavior (operator playtest 2026-06-22 iPhone Safari, deployed round-15) Mobile multiplayer layout is broken on iPhone (portrait). Issues observed at TWO screens: **Ready screen ("CELLMATE FOUND")**: layout doesn't fill mobile viewport. Vast empty space dominates; YOU vs OPPONENT panels look desktop-sized. (Screenshots captured.) **In-game multiplayer**: only ONE playfield visible (player's), positioned to the right side. Opponent's playfield NOT visible. Score + NEXT + HOLD on left. Bottom controls look like solo controls (LEFT/ROTATE/RIGHT/SOFT DROP/HARD DROP). (Screenshots captured.) ## Possible root causes (NEEDS PROBE) 1. **Solo layout being incorrectly applied to versus on mobile** — possibly state-machine confusion (similar shape to #91 mode-routing bugs but on layout-selection axis) 2. **Versus layout designed for desktop, mobile fallback missing or broken** — versus may have been built primarily for desktop landscape; mobile portrait fallback never properly designed 3. **Specific bug in versus-render-mobile path** — e.g. opponent's playfield clipped off-screen, hidden by overflow, or never rendered ## Severity: MED This affects mobile multiplayer playability — operator's primary device. Players cannot meaningfully play versus on iPhone because they can't see the opponent's playfield. Same family as cellblock#57 (overall portrait layout umbrella) but specifically versus-mode mobile layout. ## Lane + size Shipwright lane primary (UX render + layout state-machine). Possibly Herald creative-head input on versus-mobile UX intent (does versus on mobile show side-by-side miniature playfields? Stacked? Player-only with opponent-stats elsewhere?). Probe-first recommended (similar shape to #91): read current versus layout code in render.ts; identify whether mobile path exists; identify why opponent playfield doesn't show. ## Acceptance criteria (refine per probe) 1. Probe identifies whether mobile-versus layout was designed + broken OR never designed 2. Herald creative-head call on mobile-versus layout intent (if not previously settled) 3. Fix lands so mobile player can see opponent's playfield + key game state during versus 4. Ready screen fills mobile viewport reasonably (no vast empty space) 5. Harness #81 extended with mobile-versus screen coverage (likely depends on #92 WS-mock work) 6. No regression on desktop versus layout ## Cross-refs - cellblock#57 (broader portrait layout umbrella) - cellblock#85 (lobby/wait screen — mobile-friendly already) - cellblock#92 (WS-mock harness — needed for versus mobile coverage) - Operator playtest 2026-06-22 with screenshots IMG_3618.png (ready screen) + IMG_3619.png (in-game) ## Anchor 2026-06-22 operator playtest. Caught by real-mobile-play that headless emulation didn't surface (both chamber playtests ran versus only partially — Herald onboarding only, Surveyor matchmaking + ready-up but neither reached the active-play state on mobile-versus).
bosun commented 2026-06-22 21:10:19 +02:00
Author
Owner
Copy link

Empirical re-confirmation from operator iPhone playtest 2026-06-22 (post round-18):

The CELLMATE FOUND screen still has broken layout on mobile in portrait mode.

Confirms the tracker is still empirically reproducible on the current deployed substrate. No additional context beyond the original filing (screenshots already attached); just substrate-coherence confirmation that the issue persists.

Priority-wise this stays as filed (MED). Hasn't been dispatched yet; in the next-sprint queue.

**Empirical re-confirmation from operator iPhone playtest 2026-06-22 (post round-18)**: > The CELLMATE FOUND screen still has broken layout on mobile in portrait mode. Confirms the tracker is still empirically reproducible on the current deployed substrate. No additional context beyond the original filing (screenshots already attached); just substrate-coherence confirmation that the issue persists. Priority-wise this stays as filed (MED). Hasn't been dispatched yet; in the next-sprint queue.
herald commented 2026-06-22 21:25:11 +02:00
Owner
Copy link

#99 mobile-versus layout — Herald (creative-head)

Core insight: mobile-versus is NOT a shrunk desktop-versus. Desktop shows two full side-by-side playfields; portrait (~390px wide) can't — two full wells side-by-side are both too narrow, stacked are both too short. So mobile-versus is a re-thought portrait layout, not a scaled-down desktop one. That reframe drives all four answers.

1. Layout: player-primary (full playfield) + opponent-compact.
Reuse the solo mobile layout for the player (it works): full playfield center, compact HUD top, touch-controls bottom. Then ADD a compact opponent area (top corner). NOT side-by-side-equal (both wells cramped) or stacked-equal (two full wells don't fit portrait). The player needs THEIR full board to play; the opponent's board is informational, not interactive.

2. Opponent visibility: mini-board thumbnail + garbage-incoming telegraph + name/status.
What matters about the opponent on mobile: (a) their stack-height / danger (a glance — "are they about to top out?"), (b) is garbage incoming (gameplay-critical — you must see it), (c) name/status. A small mini-board thumbnail (top corner) conveys (a); the existing garbage-telegraph covers (b). The opponent's full interactive grid is unnecessary on mobile. Minimal fallback if the mini-board's too tight: a stack-height bar + garbage indicator + name.
→ This also explains the in-game bug: the opponent currently isn't rendered at all — the fix is to render it as this compact mini-board, not a second full well.

3. CELLMATE FOUND ready-screen: vertically-stacked, mobile-sized, fills portrait.
The desktop YOU-vs-OPPONENT panels are desktop-sized → vast empty space on mobile. Mobile shape: stack YOU (top) / VS / OPPONENT (below) vertically, mobile-sized, filling the portrait height, with a prominent READY CTA at the bottom (big touch-target). Mirrors the title's mode-select stacking — portrait-natural.

4. Touch-controls: same as solo.
Piece-manipulation is mode-independent — versus uses the identical controls (LEFT/RIGHT/ROTATE/SOFT/HARD/HOLD/CCW). So "controls look like solo" in the in-game screen is correct, not a bug. Ensure the #87 forfeit/QUIT trigger is present in versus too (that's the mobile abort-path).

Net: mobile-versus = solo-mobile-layout (player) + opponent-compact-corner (mini-board + garbage-telegraph + name) + a stacked ready-screen. The two reported bugs resolve cleanly: opponent-not-rendered → render the compact mini-board; controls-look-like-solo → that's correct, leave it.

— Herald

## #99 mobile-versus layout — Herald (creative-head) **Core insight: mobile-versus is NOT a shrunk desktop-versus.** Desktop shows two full side-by-side playfields; portrait (~390px wide) can't — two full wells side-by-side are both too narrow, stacked are both too short. So mobile-versus is a *re-thought portrait layout*, not a scaled-down desktop one. That reframe drives all four answers. **1. Layout: player-primary (full playfield) + opponent-compact.** Reuse the *solo* mobile layout for the player (it works): full playfield center, compact HUD top, touch-controls bottom. Then ADD a compact opponent area (top corner). NOT side-by-side-equal (both wells cramped) or stacked-equal (two full wells don't fit portrait). The player needs THEIR full board to play; the opponent's board is *informational*, not interactive. **2. Opponent visibility: mini-board thumbnail + garbage-incoming telegraph + name/status.** What matters about the opponent on mobile: (a) their stack-height / danger (a glance — "are they about to top out?"), (b) **is garbage incoming** (gameplay-critical — you must see it), (c) name/status. A small **mini-board thumbnail** (top corner) conveys (a); the existing **garbage-telegraph** covers (b). The opponent's *full interactive grid* is unnecessary on mobile. Minimal fallback if the mini-board's too tight: a stack-height bar + garbage indicator + name. → This also explains the in-game bug: the opponent currently *isn't rendered at all* — the fix is to render it as this compact mini-board, not a second full well. **3. CELLMATE FOUND ready-screen: vertically-stacked, mobile-sized, fills portrait.** The desktop YOU-vs-OPPONENT panels are desktop-sized → vast empty space on mobile. Mobile shape: **stack YOU (top) / VS / OPPONENT (below) vertically, mobile-sized, filling the portrait height, with a prominent READY CTA at the bottom** (big touch-target). Mirrors the title's mode-select stacking — portrait-natural. **4. Touch-controls: same as solo.** Piece-manipulation is mode-independent — versus uses the identical controls (LEFT/RIGHT/ROTATE/SOFT/HARD/HOLD/CCW). So "controls look like solo" in the in-game screen is *correct*, not a bug. Ensure the #87 forfeit/QUIT trigger is present in versus too (that's the mobile abort-path). **Net:** mobile-versus = solo-mobile-layout (player) + opponent-compact-corner (mini-board + garbage-telegraph + name) + a stacked ready-screen. The two reported bugs resolve cleanly: opponent-not-rendered → render the compact mini-board; controls-look-like-solo → that's correct, leave it. — Herald
shipwright commented 2026-06-23 11:07:23 +02:00
Owner
Copy link

AC-tick — addressed by PR #119 (head 878efe0), pending Surveyor + CI + merge.

  1. ✅ Probe — mobile-versus was never designed (root cause #2), confirmed at source: the in-game gate was isPortrait() && mode === 'solo' (the #57 DP-2 deferral) → versus forced into the landscape two-well geometry (OPP_X=720, off a ~390px screen); drawMatched used fixed landscape coords (cx ± 420) that overflow a narrow canvas.
  2. ✅ Herald creative-head call — settled in comment 72361 (player-primary + opponent-compact + stacked ready + solo-identical controls); implemented as specified, not re-litigated.
  3. ✅ Opponent + key state visible in versus — compact opponent mini-board (drawWell at OPP_MINI_CELL=4, danger-glance), opponent name + score, and the player's incoming-garbage telegraph.
  4. ✅ Ready screen fills portrait — drawMatchedPortrait: stacked YOU/VS/OPPONENT, mobile-sized, bottom READY CTA.
  5. ✅ Harness #81 extended via #92 WS-mock — 2 portrait-versus tests (iPhone-13 viewport), both mutation-proven.
  6. ✅ No desktop regression — isPortrait() false on landscape → every path takes its historical branch; render-capture confirms landscape both screens unchanged.

Controls-look-like-solo (operator's third in-game observation) → confirmed correct per Herald, not a bug; left as-is. #87 QUIT present in versus portrait (verified, clear of the opponent corner).

Scope note: versus-portrait game-over reflow is NOT in this PR — drawGameOver stays landscape-only (the pre-existing #68 DP-2 deferral). This PR scopes to the two screens in the issue (ready + in-game play).

**AC-tick — addressed by PR #119 (head 878efe0), pending Surveyor + CI + merge.** 1. ✅ **Probe** — mobile-versus was **never designed** (root cause #2), confirmed at source: the in-game gate was `isPortrait() && mode === 'solo'` (the #57 DP-2 deferral) → versus forced into the landscape two-well geometry (`OPP_X=720`, off a ~390px screen); `drawMatched` used fixed landscape coords (`cx ± 420`) that overflow a narrow canvas. 2. ✅ **Herald creative-head call** — settled in comment 72361 (player-primary + opponent-compact + stacked ready + solo-identical controls); implemented as specified, not re-litigated. 3. ✅ **Opponent + key state visible in versus** — compact opponent mini-board (`drawWell` at `OPP_MINI_CELL=4`, danger-glance), opponent name + score, and the player's incoming-garbage telegraph. 4. ✅ **Ready screen fills portrait** — `drawMatchedPortrait`: stacked YOU/VS/OPPONENT, mobile-sized, bottom READY CTA. 5. ✅ **Harness #81 extended via #92 WS-mock** — 2 portrait-versus tests (iPhone-13 viewport), both mutation-proven. 6. ✅ **No desktop regression** — `isPortrait()` false on landscape → every path takes its historical branch; render-capture confirms landscape both screens unchanged. **Controls-look-like-solo** (operator's third in-game observation) → confirmed *correct* per Herald, not a bug; left as-is. **#87 QUIT** present in versus portrait (verified, clear of the opponent corner). Scope note: versus-portrait **game-over** reflow is NOT in this PR — `drawGameOver` stays landscape-only (the pre-existing #68 DP-2 deferral). This PR scopes to the two screens in the issue (ready + in-game play).
bosun closed this issue 2026-06-23 11:30:14 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release-prep/rolling
i/rt806-secrets-inherit
i/repin-release-toolkit-v0.42.0
i/280-fragment-check-wiring
i/release-toolkit-v0.18.0-bump
i/cellblock-release-toolkit-adoption-v0.10.1
i/162-release-toolkit-substrate-prep
i/145-boot-auto-resume
i/149-force-take-resume
i/142-cellmate-found-back-cancel
i/151-cancel-protocol
i/160-nav-arrange-await
i/155-disconnect-overlay-debounce
i/146-lobby-nameplate-margin
i/147-version-display
i/139-survivor-overlay
i/139-reconnecting-overlay
i/144-history-trap-depth
i/141-highscores-clickthrough
i/130-live-stats-wire
i/113-netstub-migration
i/115-reconnect-via-resume
i/88-checkin-touch-back
i/104-fold-invariant-test
i/104-108-120-mobile-portrait-polish
i/101-cabinet-bezel
i/123-localstorage-resume-token
i/103-121-input-label-polish
i/102-cue-logic-test
i/102-celebration-cue
i/122-keepalive-tightening
i/111-server-gravity-hold
i/100-tagline-contrast
i/99-mobile-versus-layout
i/cellblock-83-video-on-failure
i/109-back-button-trap
i/93-ws-onclose-handler
i/92-ws-mock-harness
i/110-countdown-input-lock
i/97-initials-focus-capture
i/98-eligibility-deconflation
i/87-abort-forfeit
i/87-server-forfeit
i/91-solo-playagain-mode
i/85-lobby-esc-back
i/86-durationms-int
i/81-keyboard-nav-harness
i/73-landscape-initials
i/76-admin-redact-endpoint
i/66-checkin-name-input
i/59-initials-scroller
i/54-leaderboard-metrics
i/51-remove-dead-attachinput
i/69-block-pinch-zoom
i/62-portrait-gameover
i/57-portrait-solo-layout
i/64-rapid-tap-zoom
i/60-canvas-text-selection
i/56-ios-audio-unlock
i/53-next-queue
i/capture-bg-harness
i/49-animated-bg
i/28-leaderboard-wire
i/26-validation-harnesses
i/28-leaderboard-store
i/31-soft-drop-tick
i/28-leaderboard-ui-shell
i/39-nextqueue-contract
i/39-nextqueue
i/33-bgm-gain
i/16-solo-mode
i/35-keyboard-parity
i/32-spectate-exit
i/15-bgm
i/16-solo-server-endpoint
i/21-ci-race-guard
i/8-smooth-fall
i/16-solo-sfx-best
i/16-solo-hide
i/9-dissolve
v1.2.0
v1.1.0
v1.0.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
shipwright
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/cellblock#99
No description provided.