← All decisions

#0025 · 2026-08-08 · accepted · gameplay

Phase 8 (playtesting/tuning): empirical verification confirms the constants are sane; subjective feel-tuning deferred to the user's own hands-on play

merge-gameplaytestingtuning

Context

Phase 8, the final phase of the approved merge-puzzler plan, calls for tuning constants (drop_cooldown, danger_timer_threshold, tier radii/colors/scores, spawn height, gravity) 'manually via the dev server' -- an inherently hands-on, subjective activity ('does this feel right') that an agent without eyes on a real rendered screen or hands on a mouse cannot perform the way a human playtester would.

Options considered

Guess at improved constant values and change them speculatively, based on reading the numbers alone — rejected
Would risk introducing untested regressions to values that already have no evidence of being wrong, purely to appear to have 'done' this phase. This project's standing practice is to verify empirically before acting, not guess -- and 'feels fun' has no empirical proxy an agent can measure.
Run a real, longer, real-browser playtest via Playwright automation -- multiple drops over ~10+ seconds at varied positions -- to empirically confirm the constants are at least internally consistent and produce correct, working gameplay (not broken, not degenerate), then explicitly hand subjective feel-tuning to the user — chosen
This is the one part of 'does it work' an agent genuinely can verify without eyes: real physics settling, real merges happening, real score changing, no premature or missing game-over. Anything beyond that (does the cooldown feel too slow, is the danger threshold too forgiving) is a taste judgment outside what automation can answer, and pretending otherwise would be dishonest.

Decision

Ran a one-off Playwright probe (not committed -- ad-hoc, scratchpad-only, distinct from the repo's permanent tools/browser_check.ts) against the real dev server: dropped one piece and empirically tracked its world-y over 3 seconds via the same GPUBuffer-capture technique introduced for decision 0021, confirming it actually falls and settles near the floor (min y observed ~1.4, spawn ~85, bounds 0-100) rather than getting stuck or glitching; then held-and-released the drop button 10 times over ~10 seconds at varied canvas positions and read the real #glemy-score/#glemy-game-over DOM elements afterward, confirming real merges occurred (score: 40, not stuck at 0) and the game correctly had not ended prematurely (game-over still hidden) under normal, moderate play. Cross-checked the current constants analytically too: gravity -98 world-units/s² over a spawn height of 85 (bounds.max.y - 15) predicts roughly a 1.3s fall to the floor, comfortably longer than the 0.5s drop cooldown (so a player always has a settling piece to react to, never spamming faster than physics can show them) and comfortably shorter than the 3.0s danger-timer threshold (so reaching the danger line isn't instant, but also isn't so slow the threshold feels irrelevant). No constant was changed as a result -- everything checked out internally consistent and functioning correctly.

Verification

Real headless-Chromium session: 225 real y-position samples captured for a single dropped entity over 3s confirming it falls to and settles near the floor; a real ~10-drop, ~10-second session afterward showing a nonzero, correctly-accumulating score (40) via the real DOM element Phase 7 wired up, and no premature game-over. All 135 Erlang / 169 JavaScript gleam test cases still passing (unchanged by this phase, since no source was modified) and tools/browser_check.ts still passing.

Consequences

docs/development-plan.md's closing summary and physics roadmap (§8/§11) were updated to point at this decision and the full merge-puzzler decision range (0017-0024) instead of the stale 'no game design yet' framing that predated this whole plan. Actual feel-tuning of drop_cooldown, danger_timer_threshold, tier radii/colors/scores, spawn height, and gravity remains open, explicitly left for the user (or a future session with the user's real hands-on feedback) rather than guessed at here -- this is the one legitimately open item left from the original approved plan.

References