#57 - Mobile (iPhone): on-screen controls take half the screen — heavy layout - frankenbit/cellblock

bosun commented

2026-06-21 15:46:10 +02:00

Owner

Symptom (operator playtest, 2026-06-21, iPhone)

Operator: "the controls look heavy - they take half the screen" on iPhone.

The game's on-screen controls (whether touch buttons, the title-screen UI, or other UI elements) consume disproportionate screen real estate on mobile viewport, leaving inadequate space for the actual play field.

Likely root causes (need investigation)

Needs Shipwright/Pilot diagnostic to identify WHICH elements are heavy:

Touch-control overlay: if the game has virtual buttons for mobile play (left/right/down/rotate/drop), they may be sized for desktop dimensions and not scaled to viewport
Title screen UX: SOLO/VERSUS buttons + HIGH SCORES attract-view may be desktop-sized
HUD elements: NEXT preview / score / streak / leaderboard at game-over may overflow on narrow viewport
Viewport meta tag: if <meta name="viewport"> isn't set or has wrong scale, browser zooms inappropriately
CSS pixel-vs-rem sizing: hardcoded px values that don't scale to device pixel ratio

Acceptance criteria

Play field takes ~70%+ of vertical screen real estate on iPhone (or proportional to display aspect)
On-screen controls (if any) sized to thumb-reachable but not visually-dominant
Title screen + game-over screens scale properly on mobile viewport
Touch interactions don't conflict with keyboard handlers (mobile users tap, desktop users key)
Tested on at least one iOS device (operator's iPhone) + verified visually

Lane

Shipwright (render/layout) + Pilot (state-machine/input if touch handlers needed). Probably bundled if responsive-layout changes affect multiple screens.

Effort

Size/M-L — depends on whether mobile was scoped or scaffolded at all originally. If the game was desktop-only, mobile work is essentially new substrate (viewport meta + responsive scaling + touch input). If touch was scaffolded but un-tuned, it's a tuning pass.

Honest scope note

Cellblock was built primarily for desktop play during the jam + post-jam polish. Mobile support hasn't been a target in any of the work today. The operator's mobile playtest is the first real signal about mobile UX gaps, so this tracker should be read as "surfacing the gap" rather than "fixing a regression" — there's no mobile baseline to regress from.

## Symptom (operator playtest, 2026-06-21, iPhone) Operator: *"the controls look heavy - they take half the screen"* on iPhone. The game's on-screen controls (whether touch buttons, the title-screen UI, or other UI elements) consume disproportionate screen real estate on mobile viewport, leaving inadequate space for the actual play field. ## Likely root causes (need investigation) Needs Shipwright/Pilot diagnostic to identify WHICH elements are heavy: 1. **Touch-control overlay**: if the game has virtual buttons for mobile play (left/right/down/rotate/drop), they may be sized for desktop dimensions and not scaled to viewport 2. **Title screen UX**: SOLO/VERSUS buttons + HIGH SCORES attract-view may be desktop-sized 3. **HUD elements**: NEXT preview / score / streak / leaderboard at game-over may overflow on narrow viewport 4. **Viewport meta tag**: if `<meta name="viewport">` isn't set or has wrong scale, browser zooms inappropriately 5. **CSS pixel-vs-rem sizing**: hardcoded px values that don't scale to device pixel ratio ## Acceptance criteria 1. Play field takes ~70%+ of vertical screen real estate on iPhone (or proportional to display aspect) 2. On-screen controls (if any) sized to thumb-reachable but not visually-dominant 3. Title screen + game-over screens scale properly on mobile viewport 4. Touch interactions don't conflict with keyboard handlers (mobile users tap, desktop users key) 5. Tested on at least one iOS device (operator's iPhone) + verified visually ## Lane Shipwright (render/layout) + Pilot (state-machine/input if touch handlers needed). Probably bundled if responsive-layout changes affect multiple screens. ## Effort Size/M-L — depends on whether mobile was scoped or scaffolded at all originally. If the game was desktop-only, mobile work is essentially new substrate (viewport meta + responsive scaling + touch input). If touch was scaffolded but un-tuned, it's a tuning pass. ## Honest scope note Cellblock was built primarily for desktop play during the jam + post-jam polish. Mobile support hasn't been a target in any of the work today. The operator's mobile playtest is the first real signal about mobile UX gaps, so this tracker should be read as "surfacing the gap" rather than "fixing a regression" — there's no mobile baseline to regress from.