System Requirements Document for mercy-subway

1. Introduction

mercy-subway is an endless-runner arcade game in the style of Subway Surfers, built to deliver a measurably better user experience than that reference: smoother, clearer, more responsive and less frustrating play. The player controls a forward-running character down a three-lane track, switching lanes, jumping and ducking to avoid obstacles, collecting pickups, and surviving as the run accelerates, accumulating a score that is compared against their own best.

The product intent is a single, cohesive, low-friction run loop: instant entry with no account or setup, split-second legible signals, responsive input, clear feedback on every pickup and collision, and an immediate restart. The audience is a broad casual, mobile-first player who plays in short bursts and needs the game to be readable at a glance mid-run.

The visual and interaction language is a Paula Scher–informed poster system: typography as architecture, flat colliding colour blocks, hard edges, high contrast, and colour-coded lanes — chosen precisely because high-contrast flat colour and oversized type make split-second gameplay readable rather than decorative.

2. System Overview

mercy-subway is delivered as a single first-party, anonymously reachable custom page — Game — that owns the entire accepted lifecycle: entry, run start, in-run control, scoring and pickups, collision and death, immediate restart, and the locally persisted best score. There is no account, no sign-in, no server-side profile, and no second destination.

Actors

• Player (active human persona) — the end user who starts runs, controls the runner, collects pickups, and compares their score against their own best.
• Game runtime (system actor) — the in-page simulation that advances the runner, spawns obstacles and pickups, increases speed, detects collisions, and computes score. It is not a persona and has no separate destination.
• Local browser storage (system actor) — persists the Player's best score on the device. It is not a persona and has no separate destination.

Accepted behavior

• Endless-runner core: forward-running character, lane switching, jumping and ducking, obstacles, collectible pickups, increasing speed, and score.
• A better user experience than the reference game: smoother, clearer, more responsive, less frustrating.

Ownership and exclusions

• All accepted human-facing behavior is owned by the single Game page. No additional pages, dashboards, menus, settings screens, leaderboards, social features, shops, or account surfaces are in scope.
• The reference game Subway Surfers is used only as a genre/feature reference and domain context. No names, copy, characters, art, or assets from it are reproduced.
• No online multiplayer, no cloud sync, no remote leaderboard, and no server-side persistence are accepted.

2a. Product Interpretation and Delivery Boundary

Delivery. mercy-subway is a first-party browser game delivered as one custom page. The Player reaches it anonymously — there is no gate, no sign-in, and no identity establishment of any kind, because no accepted behavior requires privately owned or resumable actor-specific state. The only durable state is the best score, which is device-local and belongs to the device rather than to an authenticated identity.

Access. The Game page is publicly reachable with no access requirement. Nothing in the accepted requirements establishes differentiated permissions, roles, or visibility over shared state, so no role-based access control is described.

Current horizon. Everything in Sections 3, 5, and 2c is current: the run loop, controls, obstacles, pickups, speed ramp, score, collision/death, restart, and best-score persistence.

Future horizon. Nothing beyond the current endless-runner loop has been accepted. Ideas such as additional modes, characters, or online features are not current requirements and appear nowhere in the current pages or acceptance criteria.

2c. Page Content and Component Coverage

Game

The single page of mercy-subway. It is anonymously reachable and owns the complete run lifecycle: poster entry, run start, in-run control and feedback, collision and death, restart, and best-score display.

Information and state

• Entry state — the Scher poster composition: oversized MERCY wordmark over a scarlet SUBWAY block, a RUN call-to-action cut into the scarlet block's corner, a dimmed perspective lane grid receding behind the type, a hazard-stripe band across the lower third, and a small all-caps BEST <n> label top-right.
• Run state — the live track with three colour-coded lane bands, the runner, obstacles, pickups, the live score, the combo multiplier, lane indicators, and the ticker bands.
• Death state — the diagonal scarlet wipe carrying the death message in Anton at full viewport size, then the restart composition with the final score and the best score.
• Persisted state — the best score, read from and written to local browser storage.

Primary actions

• Start a run (the RUN control, or the equivalent start input).
• Switch lanes left and right.
• Jump.
• Duck.
• Restart immediately after death.

Supporting actions

• Read the live score, combo multiplier, and lane position at a glance.
• Read the best score on entry and after death.
• Read the ticker band's score/combo/slogan content.

Domain entities

• Runner — the flat scarlet pictogram the Player controls; occupies exactly one of three lanes and is either grounded, airborne, or ducking.
• Lane — one of three full-height colour-coded bands (teal, ink, teal) with thick cream rules.
• Obstacle — a flat black-and-cream pictogram (barrier, train, tunnel) that ends the run on contact.
• Pickup — a flat yellow coin with a hard ink outline that increases score and drives the combo multiplier.
• Run — one attempt, from start to collision, with a score, a distance/speed progression, and a duration.
• Score — the accumulated value for the current run.
• Combo multiplier — the escalating multiplier driven by consecutive pickups.
• Best score — the highest score achieved on this device, persisted locally.

Component responsibilities

• Poster entry composition — presents the wordmark, the SUBWAY block, the RUN control, the dimmed lane grid, the hazard band, and the best-score label; owns the transition into a run.
• Track renderer — draws the perspective lane grid, the three lane bands, the runner, obstacles, and pickups; owns the visual truth of the Player's position and of incoming hazards.
• Input handler — maps lane-switch, jump, and duck inputs to runner state changes with immediate visual response.
• Run simulation — advances the runner, spawns obstacles and pickups, increases speed over the run, and detects collisions.
• Score and combo readout — the oversized Anton numeral block top-left in yellow with a hard ink outline, and the combo multiplier block top-right in yellow.
• Lane indicators — three flat colour chips above the track showing the occupied lane.
• Ticker bands — the all-caps Archivo marquee above and below the track carrying score, combo, and rotating slogans.
• Death and restart composition — the diagonal scarlet wipe, the full-size death message, the final score, the best score, and the restart control.
• Best-score store — reads and writes the best score in local browser storage.

States

• Loading — the entry composition renders immediately; the track and simulation initialize behind it. There is no network dependency, so no network loading state is required.
• Empty — first-ever visit: the best-score label reads BEST 0 and no run history exists.
• Success — a run in progress with live score, combo, and lane feedback; and a completed run whose score is displayed against the best score.
• Error — if local browser storage is unavailable or blocked, the game remains fully playable and the best score is treated as unavailable for the session rather than blocking play.
• Recovery — after any collision, the death composition appears and the restart control returns the Player to a fresh run in one action, with no intermediate menu.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Start a run from an anonymous entry As a Player, I should be able to start a run immediately from the entry screen without signing in or configuring anything, so that I can begin playing in one action.

• Provenance: explicit (endless-runner core) with required_inference entry mechanics.
• Trigger/input: the Player activates the RUN control on the poster entry composition.
• Observable result: the run begins — the diagonal scarlet wipe sweeps across, the track becomes active, the runner is placed in the centre lane, the score resets to zero, and the speed ramp starts.
• Access state: anonymous; no identity is established or required.
• Failure/recovery: if the run cannot initialize, the entry composition remains and the RUN control stays available for another attempt.
• Continuation: the Player is in an active run and can immediately control the runner.

FR-2 — Switch lanes As a Player, I should be able to switch the runner between the three lanes with an immediate, predictable response, so that I can dodge obstacles at speed.

• Provenance: explicit.
• Trigger/input: a left or right lane-switch input.
• Observable result: the runner snaps to the adjacent lane with a 90ms linear translation and leaves a 3-frame scarlet afterimage; the lane indicator chips update to the occupied lane.
• Access state: anonymous; available only during an active run.
• Failure/recovery: a lane-switch input at the outermost lane produces no movement and no penalty; the runner stays in the current lane.
• Continuation: the Player continues the run in the new lane.

FR-3 — Jump As a Player, I should be able to jump the runner over low obstacles, so that I can clear hazards without changing lanes.

• Provenance: explicit.
• Trigger/input: a jump input.
• Observable result: the runner leaves the ground, clears low obstacles for the duration of the jump, and returns to the grounded state.
• Access state: anonymous; available only during an active run.
• Failure/recovery: a jump input while already airborne does not stack or cancel the jump; the current jump completes.
• Continuation: the Player continues the run, grounded, in the same lane.

FR-4 — Duck As a Player, I should be able to duck the runner under high obstacles, so that I can pass hazards that cannot be jumped.

• Provenance: explicit.
• Trigger/input: a duck input.
• Observable result: the runner enters the ducking state, passes under high obstacles for the duration of the duck, and returns to the standing state.
• Access state: anonymous; available only during an active run.
• Failure/recovery: a duck input while airborne does not apply until the runner is grounded; the input is not silently lost as a penalty.
• Continuation: the Player continues the run, standing, in the same lane.

FR-5 — Encounter obstacles As a Player, I should face obstacles that are clearly readable in time to react, so that collisions feel fair rather than arbitrary.

• Provenance: explicit (obstacles) with required_inference readability mechanics.
• Trigger/input: the run simulation spawns obstacles ahead of the runner as the run progresses.
• Observable result: obstacles appear as flat black-and-cream pictograms (barrier, train, tunnel) drawn with thick 4px strokes and no shading, entering from the far end of the track and approaching the runner.
• Access state: anonymous; active only during a run.
• Failure/recovery: obstacle spawns always leave at least one traversable lane or a valid jump/duck response, so no spawn is unavoidable.
• Continuation: the Player either avoids the obstacle or collides with it (FR-8).

FR-6 — Collect pickups As a Player, I should be able to collect pickups during a run, so that I am rewarded for taking risks and holding a line.

• Provenance: explicit (collectible pickups) with required_inference feedback mechanics.
• Trigger/input: the runner's position overlaps a pickup on the track.
• Observable result: the pickup is collected, the score increases, the score numeral slams to its new value with a hard-cut scale swap, and the combo multiplier advances.
• Access state: anonymous; active only during a run.
• Failure/recovery: a missed pickup is simply passed; it does not reduce score or end the run.
• Continuation: the Player continues the run with the updated score and combo.

FR-7 — Increasing speed and score accumulation As a Player, I should feel the run accelerate and see my score climb, so that the run builds tension and rewards longer survival.

• Provenance: explicit (increasing speed, score).
• Trigger/input: elapsed run time and distance.
• Observable result: the run speed increases progressively over the course of a run, and the score accumulates from distance travelled and pickups collected, displayed live in the score readout.
• Access state: anonymous; active only during a run.
• Failure/recovery: the speed ramp is bounded so that the run remains controllable; it never exceeds a rate the Player cannot respond to.
• Continuation: the Player continues the run at the current speed with the current score.

FR-8 — Collision ends the run As a Player, I should receive an unmistakable, immediate result when I hit an obstacle, so that I understand exactly why the run ended.

• Provenance: explicit (obstacles) with required_inference death-result mechanics.
• Trigger/input: the runner's position overlaps an obstacle.
• Observable result: the run ends; a full-screen diagonal scarlet wipe sweeps across carrying the death message set in Anton at full viewport size; the final score and the best score are shown.
• Access state: anonymous.
• Failure/recovery: the death composition always resolves to the restart composition; it never leaves the Player in a stuck state.
• Continuation: the Player can restart immediately (FR-9).

FR-9 — Immediate restart As a Player, I should be able to restart instantly after a collision, so that a failed run costs me almost no time.

• Provenance: explicit (better user experience: less frustrating) with required_inference restart mechanics.
• Trigger/input: the Player activates the restart control on the death composition.
• Observable result: a fresh run begins immediately — score resets to zero, the runner returns to the centre lane, and the speed ramp restarts — with no intermediate menu or confirmation.
• Access state: anonymous.
• Failure/recovery: if the restart input is not registered, the death composition remains and the restart control stays available.
• Continuation: the Player is in a new active run.

FR-10 — Best score is persisted locally and shown As a Player, I should see my best score on entry and after each run, so that I have a personal target to beat.

• Provenance: required_inference (the accepted score outcome requires a comparable personal best).
• Trigger/input: page load, and the end of any run whose score exceeds the stored best.
• Observable result: the best score is read from local browser storage and displayed as the small all-caps BEST <n> label on entry and on the death composition; when a run's score exceeds it, the stored best is updated and the new value is displayed.
• Access state: anonymous; device-local, not tied to any identity.
• Failure/recovery: if local browser storage is unavailable or blocked, the label shows BEST 0 and the game remains fully playable; no error blocks play.
• Continuation: the Player can start or restart a run with the best score visible.

FR-11 — Readable, colour-coded in-run signals As a Player, I should be able to read my lane, score, and combo from colour and type alone without looking away from the track, so that the interface never costs me a run.

• Provenance: explicit (better user experience: clearer) with required_inference signal mechanics.
• Trigger/input: continuous during a run.
• Observable result: the three lane bands are full-height flat rectangles (teal, ink, teal) with thick cream rules; the live score is an oversized Anton numeral block in yellow with a hard ink outline at the top-left; the combo multiplier sits top-right in a yellow block; three flat colour chips above the track show the occupied lane.
• Access state: anonymous; active only during a run.
• Failure/recovery: no animation obscures a gameplay signal; every animation serves readability.
• Continuation: the Player continues the run with signals continuously legible.

FR-12 — Ticker band carries score, combo, and slogans As a Player, I should see a persistent moving band of score, combo, and slogans, so that momentum is expressed without hiding the track.

• Provenance: required_inference (the accepted score/combo outcome expressed in the accepted visual language).
• Trigger/input: continuous during a run.
• Observable result: an all-caps Archivo marquee scrolls above and below the track, carrying the current score, the combo, and a rotating set of slogans (KEEP RUNNING, NO MERCY, FASTER).
• Access state: anonymous; active only during a run.
• Failure/recovery: with prefers-reduced-motion, the marquees stop and wrap into static rows; every item remains fully readable.
• Continuation: the Player continues the run with the band present.

FR-13 — Combo milestone feedback As a Player, I should receive escalating feedback as my combo grows, so that a strong run feels earned.

• Provenance: required_inference (the accepted combo outcome requires observable escalation).
• Trigger/input: the combo multiplier reaching a milestone threshold.
• Observable result: a stacked word reveal — NICE, ON FIRE, MERCY! — slams in at full size and holds for 400ms.
• Access state: anonymous; active only during a run.
• Failure/recovery: the reveal never covers the runner's lane or an incoming obstacle; it is placed so gameplay signals stay visible.
• Continuation: the Player continues the run with the combo intact.

FR-14 — Reduced-motion support As a Player who prefers reduced motion, I should be able to play with motion reduced, so that the game remains comfortable and fully playable.

• Provenance: required_inference (accessibility of the accepted motion language).
• Trigger/input: the operating system's prefers-reduced-motion setting.
• Observable result: all marquees stop and wrap into static rows; the death wipe becomes an instant cut; the score scale swap and lane afterimage are suppressed.
• Access state: anonymous.
• Failure/recovery: no gameplay signal is lost when motion is reduced; every value remains readable.
• Continuation: the Player plays the full run loop with reduced motion.

4. User Personas

Player

Product context. The Player is the end user of mercy-subway: a broad casual, mobile-first player who plays in short bursts — a commute, a queue, a few spare minutes — and expects to be running within a second of opening the game. They arrive anonymously, with no account, no profile, and no setup, and they may return many times on the same device.

Primary goal. To run as far as possible, dodge obstacles cleanly, collect pickups, and beat their own best score — with the game never costing them a run through unclear signals, sluggish input, or a slow restart.

Distinct accepted responsibilities.

• Starting a run in one action from the entry composition, with no configuration step.
• Controlling the runner's lane position, jumps, and ducks with input that responds immediately and predictably.
• Reading lane position, score, and combo from colour and type alone, without looking away from the track.
• Choosing, moment to moment, between dodging an obstacle and taking a line that collects pickups.
• Surviving an accelerating run and managing the rising difficulty.
• Restarting immediately after a collision and comparing the finished score against their own best.

Relevant inputs and decisions. Lane-switch, jump, and duck inputs; the decision to hold a lane for pickups versus abandon it for safety; the decision to restart immediately or stop playing.

Interactions with other accepted participants. The Player is the only active human participant. They interact with the game runtime, which spawns obstacles and pickups, accelerates the run, and detects collisions, and with local browser storage, which holds their best score on the device. No other human participant is involved, and no other participant acts on the Player's behalf.

Observable success. The Player completes runs with a score they can see, sees that score compared against a persisted best, and can begin the next run in a single action after any collision. Their lane, score, and combo are legible at a glance throughout the run, and no collision feels unavoidable.

What makes this role distinct. The Player's work is entirely reactive and continuous: unlike an operator or administrator, they never configure, review, or manage anything. Their entire responsibility is split-second control under rising speed, and their success is measured by a single number they are trying to beat.

5. Core User Flows

Flow 1 — First visit and first run

1. The Player opens mercy-subway. The Game page loads anonymously; no sign-in, gate, or setup appears.
2. The poster entry composition renders: MERCY in Anton filling the viewport width, a full-width scarlet block holding SUBWAY in cream Anton beneath it, a dimmed perspective lane grid receding behind the type, a hazard-stripe band across the lower third, and a small all-caps BEST 0 label top-right.
3. The Player activates the RUN control cut into the bottom-left corner of the scarlet block.
4. A full-screen diagonal scarlet wipe sweeps across and cuts to the track. The runner is placed in the centre lane, the score reads zero, and the speed ramp begins.
5. The Player switches lanes, jumps, and ducks as obstacles approach, reading lane position from the three colour-coded lane bands and the lane chips above the track.
6. The Player collects pickups. Each pickup slams the yellow Anton score numeral to its new value with a hard-cut scale swap and advances the combo multiplier in the top-right yellow block.
7. The run accelerates. The ticker bands above and below the track scroll the current score, combo, and rotating slogans.
8. On reaching a combo milestone, a stacked word reveal (NICE, ON FIRE, MERCY!) slams in at full size and holds for 400ms without covering the runner's lane or an incoming obstacle.
9. The Player collides with an obstacle. The run ends; the diagonal scarlet wipe sweeps across carrying the death message in Anton at full viewport size, then cuts to the restart composition showing the final score and BEST 0.
10. The Player activates the restart control. A fresh run begins immediately — score reset, runner in the centre lane, speed ramp restarted — with no intermediate menu.
11. Continuation: the Player keeps running, or leaves the page. Their best score remains stored on the device for the next visit.

Flow 2 — Beating the personal best

1. The Player returns to mercy-subway on the same device. The entry composition shows their stored best as BEST <n> top-right.
2. The Player starts a run and plays, holding a line that collects pickups while dodging obstacles.
3. The run's score exceeds the stored best. The score readout continues to climb past it.
4. The Player collides. The death composition appears with the final score and the best score.
5. The stored best is updated to the new score and displayed as the new BEST <n>.
6. Continuation: the Player restarts immediately to try to beat the new best, or leaves the page. The updated best persists on the device.

Flow 3 — Recovering from a frustrating run

1. Mid-run, the Player collides with an obstacle they judged avoidable. The run ends.
2. The death composition appears immediately — no delay, no confirmation dialog, no score-counting animation that must finish first.
3. The Player activates the restart control.
4. A fresh run begins in one action, with the score reset and the runner in the centre lane.
5. Continuation: the Player is running again within moments of the collision, so a failed run costs almost no time.

Flow 4 — Playing with reduced motion

1. The Player's operating system has prefers-reduced-motion enabled.
2. The Player opens mercy-subway and starts a run.
3. The ticker bands do not scroll; they wrap into static rows showing the score, combo, and slogans in full.
4. The score scale swap and the lane-change afterimage are suppressed; the score and lane chips still update to their new values.
5. On collision, the diagonal scarlet wipe becomes an instant cut to the death composition rather than a sweep.
6. Continuation: the Player plays the complete run loop with every gameplay signal still readable.

Flow 5 — Playing when local storage is unavailable

1. The Player opens mercy-subway in a context where local browser storage is blocked or unavailable.
2. The entry composition renders normally with BEST 0.
3. The Player starts a run and plays the full loop — lane switching, jumping, ducking, pickups, scoring, speed ramp, collision, and restart — with no error blocking play.
4. On collision, the death composition shows the final score and BEST 0.
5. Continuation: the Player can restart and keep playing; the best score is simply unavailable for the session rather than treated as a failure.

6. Visuals Colors and Theme

The authoritative creative direction is Paula Scher — typography as architecture, run as a poster. The muse is Paula Scher; the headline idea is that the track is a poster, the lanes are colour-coded bands, and the score and combo readouts are painted signage.

Colour tokens (dark mode)

Proportion target: ~60% ink ground, ~20% scarlet, ~10% yellow, ~5% teal, ~5% cream. No gradients, no glass, no blue anywhere. Blue, indigo, and violet are excluded from the palette entirely.

Typography

• Headings: Anton, all-caps, tightly stacked (line-height 0.86–0.92), set enormous — display type is a graphic object, not a caption. Headlines run flush-left and ragged-right, and may be rotated 90° along the viewport edge as a painted band.
• Body: Archivo.
• Scale: 1.5 modular; display steps 40 / 64 / 96 / 128 / 176. Body 16 / 14 / 12.
• Mobile display: clamp(40px, 13vw, 64px). Desktop display: clamp(72px, 11vw, 176px).
• Body size: fixed at 16px (14px on mobile), line-height 1.5.
• Tracking: tight on display (−0.01em); wide (0.14em) on all-caps micro-labels.
• Weight contrast is binary: Anton at maximum size against Archivo at 14–16px. No serif display faces, no thin light weights, and no Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for any text.

Shape language

• Hard edges only — zero border-radius anywhere.
• Diagonal bands and stacked rectangular colour blocks collide and overlap.
• Rules are thick (4–8px) and structural, never hairlines.
• Lane bands are full-height solid rectangles.
• Buttons are flat rectangles with a 6px offset hard shadow in ink or yellow.
• A repeating hazard-stripe band (scarlet/ink diagonal) marks the start line and danger zones.
• Everything is flat; depth comes from overlap and contrast, never from shadow blur or glow.

Layout

• A poster grid: the game viewport is the central full-bleed block; surrounding chrome is stacked horizontal type bands and colour blocks that read like a Scher poster.
• Left-aligned, asymmetric, with deliberate full-bleed type spanning the viewport.
• Score sits top-left as an oversized Anton numeral block; the combo multiplier sits top-right in a yellow block; lane indicators sit as three flat colour chips above the track.
• The start screen is a full-viewport type composition: MERCY fills the width and SUBWAY stacks beneath it in a scarlet block.
• Mobile (375px): type wraps to two lines; the track fills the whole screen with the HUD floating as small colour chips in the corners.
• Desktop (1280px): the track is a centred 9:16 portrait column with poster type bands running full-bleed to the left and right edges.

Imagery

Typography is the image. No 3D renders, no character illustration, no photography. The runner is a flat scarlet silhouette built from two stacked rectangles and a circle head — a pictogram, not a character. Obstacles are flat black-and-cream pictograms (barrier, train, tunnel) drawn with thick 4px strokes and no shading. Coins are flat yellow circles with a hard ink outline. The track is a perspective grid of solid lane bands. Where atmosphere is needed, it is a halftone-dot texture or a diagonal stripe pattern — never a gradient or glow.

Readability rule. Headlines, wordmarks, labels, numbers, item images, cards, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Crops, bleeds, and off-edge placement are for decoration only — shapes, textures, rules, and background art. Moving content (the ticker marquees) may cross the viewport edge by design, and every item must become fully readable as it passes; with prefers-reduced-motion it stops and shows whole items in wrapped rows.

7. Signature Design Concept

The first screen is a Scher poster, not a game menu.

The public entry is a full-viewport type composition built from three colliding flat blocks:

• MERCY set in Anton at clamp(72px, 16vw, 200px), flush-left, filling the width of the viewport. The wordmark bleeds off the right edge as decoration only — the letters themselves stay whole and readable, and the wordmark scales or wraps so it never leaves the viewport at 375px, 768px, or 1280px.
• Beneath it, a full-width scarlet block (#E8352B) holding SUBWAY in cream Anton (#F5F1E8) at roughly half the display size.
• A yellow rectangular RUN control (#FFC400) cut into the bottom-left corner of the scarlet block, flush with the block's edge, with a 6px hard ink offset shadow.

Behind the type, a dimmed perspective lane grid recedes toward a vanishing point, and a hazard-stripe band runs diagonally across the lower third. Top-right, a small all-caps Archivo label in muted grey reads BEST 0.

Nothing is centred, nothing floats, there is no gradient and no glow — the composition is type, colour blocks, and one hard-edged CTA. The concept recomposes only accepted content, states, and controls: the wordmark, the best-score label, the lane grid that becomes the track, and the single start control.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the stacked MERCY / SUBWAY wordmark over the dimmed perspective lane grid, with the yellow RUN block cut into the scarlet block's corner.
• Input → transformation → outcome thesis: the Player activates RUN; a full-screen diagonal scarlet rectangle sweeps across the viewport; the sweep cuts to the live track with the runner in the centre lane and the score at zero. The poster becomes the track.
• Motion vocabulary: expressive and rhythm-driven, never bouncy. Type marquees slide horizontally as persistent ticker bands above and below the track. Score numerals flip with a hard-cut scale swap (no easing curve, 80ms). Lane changes snap the runner with a 90ms linear translation and leave a 3-frame scarlet afterimage. A full-screen colour-block wipe (scarlet rectangle sweeping diagonally) marks run start and death. Combo milestones trigger a stacked word reveal — NICE, ON FIRE, MERCY! — each word slamming in at full size and holding for 400ms.
• Composed first frame: MERCY flush-left and enormous, the scarlet SUBWAY block beneath it, the RUN control cut into its corner with a hard ink offset shadow, the dimmed lane grid receding behind, the hazard band across the lower third, and BEST 0 top-right in muted grey.
• Reduced-motion state: with prefers-reduced-motion, all marquees stop and wrap into static rows, the death wipe becomes an instant cut, and the score scale swap and lane afterimage are suppressed. Every gameplay signal remains readable and the full run loop remains playable.

9. Non-Functional Requirements

NFR-1 — Responsiveness of input (explicit: "better user experience … more responsive") Lane-switch, jump, and duck inputs must produce a visible state change on the next rendered frame, with no perceptible input lag. Rationale: the accepted requirement is explicitly more responsive play than the reference game.

NFR-2 — Clarity of in-run signals (explicit: "better user experience … clearer") Lane position, score, and combo must be readable from colour and type alone at a glance, without the Player looking away from the track. Rationale: the accepted requirement is explicitly clearer play, and the creative direction's high-contrast flat colour system exists to serve split-second readability.

NFR-3 — Fairness of obstacle spawns (explicit: "better user experience … less frustrating") Obstacle spawns must always leave at least one traversable lane or a valid jump/duck response. No collision may be unavoidable. Rationale: the accepted requirement is explicitly less frustrating play.

NFR-4 — Immediate restart (explicit: "better user experience … less frustrating") Restart after a collision must be a single action with no intermediate menu, confirmation, or blocking animation. Rationale: the accepted requirement is explicitly less frustrating play.

NFR-5 — Smoothness of play (explicit: "better user experience … smoother") The run must render at a stable frame rate on the target mobile-first devices, with no stutter during lane changes, spawns, or score updates. Rationale: the accepted requirement is explicitly smoother play.

NFR-6 — Anonymous, zero-setup entry (required_inference) The Game page must be reachable and playable with no account, sign-in, or configuration step. Rationale: no accepted behavior requires privately owned or resumable actor-specific state; the only durable state is a device-local best score.

NFR-7 — Device-local best-score persistence (required_inference) The best score must persist across visits on the same device using local browser storage, and the game must remain fully playable when that storage is unavailable. Rationale: the accepted score outcome requires a comparable personal best, and no server-side persistence is accepted.

NFR-8 — Reduced-motion support (required_inference) The game must honour prefers-reduced-motion by stopping marquees, wrapping them into static rows, and replacing the death wipe with an instant cut, without losing any gameplay signal. Rationale: accessibility of the accepted motion language.

NFR-9 — Readable content at every viewport (creative direction, authoritative) Headlines, wordmarks, labels, numbers, item images, cards, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Crops and bleeds are for decoration only. Moving ticker content may cross the edge by design and must become fully readable as it passes; with reduced motion it stops and shows whole items.

NFR-10 — No network dependency for play (required_inference) The run loop must not depend on a network request. Rationale: no accepted behavior requires a server, and a network dependency would directly harm the accepted smoothness and responsiveness goals.

10. Tech Stack

• Frontend: React (single-page application) rendering the single Game page.
• Game rendering: HTML5 Canvas for the track, runner, obstacles, and pickups, with the poster chrome (wordmark, score block, combo block, lane chips, ticker bands, death composition) rendered as DOM elements so type stays crisp and readable at every viewport.
• Styling: CSS with the exact palette, Anton and Archivo font families, zero border-radius, and the specified type scale and clamps.
• Persistence: browser localStorage for the best score, with a graceful fallback when unavailable.
• Build tooling: standard React build tooling; no backend service is required.
• Deployment: static hosting of the built assets. Docker/docker-compose and Kubernetes are not required, because the accepted delivery is a single static client-side page with no server component.

11. Assumptions and Constraints

Constraints (explicit, binding)

• The game must be in the style of Subway Surfers but with a better user experience than it. This is a hard constraint from the authoritative source.
• The reference game is used only as a genre/feature reference and domain context. No names, copy, characters, art, or assets from it may be reproduced.
• The creative direction is authoritative for visuals: the exact palette, Anton/Archivo typography, hard edges, zero border-radius, flat imagery, and the listed avoidances (no blue/indigo/violet, no rounded corners, no soft blurred shadows, no glassmorphism, no gradients, no centred headline-plus-button hero, no 3D character renders, no glow effects, no Inter/Roboto/Arial/Helvetica/Poppins/system-ui, no serif display faces, no hover-lift card grids, no decorative motion that obscures gameplay signals).
• The generic indigo/blue-on-white SaaS template is forbidden for this project.

Assumptions (narrow, labeled)

• [Assumption — not specified by user] The game is delivered as a browser-based React application; no native mobile build, console build, or desktop packaging is accepted.
• [Assumption — not specified by user] The three-lane structure, the specific obstacle types (barrier, train, tunnel), and the coin pickup are the concrete instantiation of the accepted endless-runner core, drawn from the genre reference.
• [Assumption — not specified by user] The best score is device-local and anonymous; no cross-device sync or account-bound score is accepted.
• [Assumption — not specified by user] Input is keyboard and touch/swipe, since the audience is mobile-first and desktop-capable; no gamepad support is accepted.
• [Assumption — not specified by user] The combo multiplier is driven by consecutive pickups, as the concrete instantiation of the accepted combo readout in the creative direction.

Exclusions (binding)

• No accounts, sign-in, profiles, or identity establishment of any kind.
• No online multiplayer, cloud sync, remote leaderboards, or server-side persistence.
• No shops, in-app purchases, currencies, characters, or customization.
• No settings, options, or configuration screens.
• No additional pages beyond the single Game page.

12. Glossary

• Endless runner — a game genre in which a character runs forward automatically along a track that never ends, and the player survives as long as possible while difficulty increases.
• Run — one attempt at the game, from start to collision, with its own score, speed progression, and duration.
• Lane — one of three parallel tracks the runner can occupy; switching lanes is the primary lateral control.
• Runner — the flat scarlet pictogram the Player controls, occupying exactly one lane and either grounded, airborne, or ducking.
• Obstacle — a flat black-and-cream pictogram (barrier, train, tunnel) that ends the run on contact.
• Pickup — a flat yellow coin with a hard ink outline that increases score and advances the combo multiplier.
• Score — the accumulated value for the current run, from distance travelled and pickups collected.
• Combo multiplier — the escalating multiplier driven by consecutive pickups, displayed top-right in a yellow block.
• Best score — the highest score achieved on this device, persisted in local browser storage and displayed as BEST <n>.
• Ticker band — the all-caps Archivo marquee above and below the track carrying score, combo, and rotating slogans.
• Hazard-stripe band — the repeating scarlet/ink diagonal stripe marking the start line and danger zones.
• Reduced motion — the prefers-reduced-motion operating-system setting, under which marquees stop and wrap into static rows and the death wipe becomes an instant cut.
• Poster entry composition — the full-viewport Scher-style start screen built from the MERCY/SUBWAY wordmark, the RUN control, the dimmed lane grid, the hazard band, and the best-score label.