feat(shell): mobile keypad rearrangement + font touch-ups

[mparrett]

Polish for the existing Touch-UI web shell's on-screen keypad, sliced out of the shader demo spike (#168), since it's independent. The changes are sensible, unambiguous / pre-existing usability gaps, noticed during general play testing against the mobile shell. No renderer or shader code here, just tools/xsofy-shell.html.

Changes

• PLAY pane — WAIT/ENTER swap. Wait is the high-frequency key, so it moves up to the top row where enter was; enter takes wait's old corner. y/n also swap to n/y to match the landscape variant.
• PLAY pane — ` (DEV) tile. Fills the empty col-1/row-3 cell so the dev console is reachable on touch devices with no physical keyboard. The console is dev-gated game-side (?mode=dev), so the key is a no-op for regular players.
• a–z pane — ( and ) keys. Added left of z. Portrait: they replace the stagger spacer and backspace slims 3→2. Landscape: thin span-1 keys, esc/backspace slim to fit. Makes the dev console's command syntax typeable on touch.
• Font default 14 → 18 (landscape/desktop). 14 reads small on laptop screens too; portrait keeps its phone-tuned 22. A stored user choice (the font chip's localStorage value) still wins over both defaults, so nobody's existing setting changes.

Notes

Every keypad row still tiles cleanly: PLAY stays 6×6→5 rows (30 cells), and the a–z rows sum to 20 units in both orientations. These exact hunks were exercised under Playwright as part of #168; the PR-preview smoke gate covers boot here.

🤖 Generated with Claude Code

Made with Cursor

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-08-07 13:30 UTC

[mparrett]

Review context for this and the other five ready PRs, with suggested order and merge-order notes: #182

[nnunley]

I'd would be nice to have more on screen real-estate for display.

We should do a design spike for constrained screens . Maybe something that opens radial, context-sensitive menus on long press, move to position/attack on tap, etc. Alternative, an on screen controller overlay with directions, menu context menus, etc.

[mparrett]

I'd would be nice to have more on screen real-estate for display.

We should do a design spike for constrained screens . Maybe something that opens radial, context-sensitive menus on long press, move to position/attack on tap, etc. Alternative, an on screen controller overlay with directions, menu context menus, etc.

@nnunley Valid point and agree we should spike on it. Taking this as non-blocking given the approval. Thanks for taking a look and endorsing. For initial gameplay, the small changes here remove substantial awkwardness.

Some disclosure/context for the current design that this PR makes adjustments to: The existing TUI works well enough in a square terminal area. Taller aspect ratios also work, but needed a closer look for some cases. I ran with a square-ish constraint for the terminal area + remainder as input as the straightforward first cut. The current UI mainly grew around these practical constraints, rather than being defined by a proper spike on design options. That said, I did play test this quite a bit and it's surprisingly workable for what it is.

[mparrett]

@nooga I'm going to run with this PR given that it is approved and unblocks the current mobile gameplay, but please know know I'd still value your input. I understand you have a ton on your plate right now.