System Requirements Document for run-mumbai

1. Introduction

run-mumbai is a browser-based endless-runner game set on the streets of Mumbai. The player controls a runner who must keep moving through a Mumbai street environment, dodge hazards, and avoid being caught by a pursuing cop.

The game is intended for the Runner (Player) persona and is delivered as an anonymous web experience. The current scope focuses only on starting, playing, failing, and restarting an endless run.

2. System Overview

run-mumbai delivers a custom web game with two application pages:

1. Landing — a public entry surface that introduces the Mumbai endless-runner premise and begins play.
2. Game — the playable endless-runner surface where the player controls the runner, avoids hazards, sees distance survived, experiences the cop chase, and restarts after failure.

The runner travels through Mumbai streets while a cop acts as the pursuing threat. The player uses keyboard controls to steer, jump, and slide around hazards such as traffic, stalls, and puddles. The run continues until the runner collides with a hazard or is caught.

Current Scope

• Endless-runner gameplay set on the streets of Mumbai.
• Browser-based delivery.
• A player-controlled runner.
• A pursuing cop.
• Keyboard-based movement and avoidance controls.
• Street hazards including traffic, stalls, and puddles.
• Distance-survived feedback.
• Failure when the runner collides with a hazard or is caught.
• Restarting a run after failure.

Narrow Exclusions

The current requirements do not establish:

• Player accounts, sign-in, profiles, or saved progress.
• Multiplayer gameplay.
• Purchases, currencies, unlocks, upgrades, or inventories.
• Leaderboards or social sharing.
• Multiple game modes, levels, missions, or maps.
• Custom character creation.
• Mobile-native application delivery.
• Any law-enforcement simulation beyond the cop functioning as the pursuing threat.

2a. Product Interpretation and Delivery Boundary

run-mumbai is an anonymous, application-owned browser game. A player can access both Landing and Game without creating an account or providing identity information.

The game’s current purpose is to provide a replayable Mumbai street chase: the player starts a run, avoids obstacles and hazards, survives for as long as possible, and restarts after being caught or colliding. The cop is a visible and meaningful pursuit threat within gameplay rather than a separate playable participant.

No future expansion is currently committed. Features such as score persistence, new routes, player progression, account features, or additional game modes remain outside the current delivery boundary.

2c. Page Content and Component Coverage

Landing

• Information and state

  • Present the run-mumbai title and the game’s Mumbai street setting.
  • Explain that the player runs through Mumbai streets while a cop pursues them.
  • Introduce the endless-runner objective: avoid hazards and survive for as long as possible.
  • Present keyboard-control guidance for steering, jumping, and sliding.
  • Maintain an initial ready-to-play state before a run is started.

• Primary action

  • Provide a Start action that opens the Game page and begins a new run.

• Supporting actions

  • Allow the player to review the game premise and controls before starting.
  • Allow the player to return to the ready-to-play state if initial game loading fails.

• Domain entities

  • Runner.
  • Cop pursuer.
  • Mumbai street environment.
  • Hazards: traffic, stalls, and puddles.
  • Keyboard controls.

• Component responsibilities

  • A game title and premise panel communicates the setting and chase scenario.
  • A controls panel explains keyboard movement inputs.
  • A Start control initiates gameplay.
  • A loading or launch status indicator communicates whether the game is ready to begin.

• States and recovery

  • Loading: Display that game assets or the play surface are preparing.
  • Ready: Enable Start when the Game experience can begin.
  • Error: Explain that the game could not start if required game resources fail to load.
  • Recovery: Offer the player a way to retry starting the game.

Game

• Information and state

  • Display the active Mumbai street running environment.
  • Display the player-controlled runner.
  • Display the cop as the pursuing threat.
  • Display hazards and obstacles in the runner’s path, including traffic, stalls, and puddles.
  • Display the distance survived during the current run.
  • Maintain clear run states: starting, active, failed, and restarted.

• Primary actions

  • Start a new endless run.
  • Steer the runner using keyboard input.
  • Jump over applicable hazards using keyboard input.
  • Slide under or past applicable hazards using keyboard input.
  • Restart after a collision or after the cop catches the runner.

• Supporting actions

  • View current distance survived while the run is active.
  • View a clear failure result when the run ends.
  • Return to a new run without requiring an account or saved state.

• Domain entities

  • Runner.
  • Cop pursuer.
  • Current run.
  • Distance survived.
  • Mumbai street path.
  • Traffic.
  • Street stalls.
  • Puddles.
  • Collision.
  • Caught state.

• Component responsibilities

  • The game viewport renders the runner, street environment, hazards, and pursuing cop.
  • The keyboard input handler translates valid player input into steer, jump, and slide actions.
  • The run controller advances the endless run while the player remains active.
  • The hazard controller presents hazards for the player to avoid.
  • The chase controller represents the cop’s pursuit during the run.
  • The distance display shows the current distance survived.
  • The failure overlay communicates whether the run ended through collision or being caught.
  • The restart control resets the run to a playable starting state.

• States and recovery

  • Loading: Display that the game scene is preparing before player control begins.
  • Starting: Reset the runner, cop, hazards, and distance before a new run becomes active.
  • Active run: Accept keyboard input, update the runner’s state, show hazards, and update distance survived.
  • Collision failure: End the active run when the runner collides with a hazard and present a restart option.
  • Caught failure: End the active run when the cop catches the runner and present a restart option.
  • Restart success: Begin a fresh run with distance reset for the new run.
  • Error: Communicate if the playable scene cannot load or initialize.
  • Recovery: Allow retrying the Game experience or returning to Landing if the game cannot be initialized.

3. Functional Requirements

FR-1 — Mumbai Endless-Runner Game

As a Runner (Player), I should be able to play an endless-runner game set on the streets of Mumbai so that I can keep running and survive for as long as possible.

• Provenance: explicit.
• Trigger/Input: The player starts a run from Landing or restarts from the Game failure state.
• Access state: Anonymous public browser access; no account is required.
• Required behavior:
  • The system shall deliver the game in a web browser.
  • The system shall present an endless-running experience set on Mumbai streets.
  • The system shall keep the run active until a defined failure condition occurs.
  • The system shall show the player’s distance survived during an active run.
• Observable result: The player can see the runner moving through a Mumbai street environment and can observe the current distance survived.
• Failure and recovery: If the playable game cannot load, the system shall communicate the loading failure and provide a retry path. If a run ends, the player shall be able to restart.
• Continuation: The player continues the active run while avoiding hazards or begins a fresh run after failure.

FR-2 — Player Avoidance Controls

As a Runner (Player), I should be able to steer, jump, and slide with keyboard input so that I can dodge Mumbai street hazards and keep the run alive.

• Provenance: required_inference.
• Rationale: Keyboard-controlled steering, jumping, and sliding are indispensable mechanics for the accepted endless-runner gameplay and defined player responsibility.
• Trigger/Input: During an active run, the player presses the designated keyboard controls.
• Access state: Anonymous public browser access; controls are available only while a run is active.
• Required behavior:
  • The system shall accept keyboard input for steering the runner.
  • The system shall accept keyboard input for making the runner jump.
  • The system shall accept keyboard input for making the runner slide.
  • The system shall present hazards that the player must avoid, including traffic, stalls, and puddles.
  • The system shall update the runner’s visible movement state in response to valid player input.
• Observable result: The player can see the runner steer, jump, or slide in response to keyboard input and can avoid hazards when the correct action is taken.
• Failure and recovery: If the runner collides with a hazard, the system shall end the run and show the collision result. The player shall be able to restart.
• Continuation: Successful avoidance allows the player to continue the same endless run and increase distance survived.

FR-3 — Cop Pursuit and Run Failure

As a Runner (Player), I should experience a cop chasing the runner so that the chase is a meaningful threat during the Mumbai street run.

• Provenance: explicit.
• Trigger/Input: The player begins an active run.
• Access state: Anonymous public browser access.
• Required behavior:
  • The system shall include a cop as the pursuing threat during gameplay.
  • The system shall visibly represent the cop’s pursuit of the runner during the run.
  • The system shall end the run if the cop catches the runner.
  • The system shall distinguish a caught result from an active run state.
• Observable result: The player sees the cop pursuing the runner and receives a clear caught result if the cop catches them.
• Failure and recovery: When caught, the system shall stop the active run, preserve the distance survived for the displayed result of that run, and provide a restart action.
• Continuation: The player may start a new run after being caught.

FR-4 — Start and Restart Gameplay

As a Runner (Player), I should be able to start and restart a run so that I can begin playing and try again after being caught or colliding.

• Provenance: required_inference.
• Rationale: A start action and a restart action are indispensable for entering and resuming the accepted browser-based endless-runner lifecycle.
• Trigger/Input: The player selects Start on Landing or Restart after a failure.
• Access state: Anonymous public browser access.
• Required behavior:
  • The Landing page shall provide a Start action.
  • Selecting Start shall navigate the player to Game and begin a new run.
  • The Game page shall provide a restart action after collision failure or caught failure.
  • Restarting shall create a fresh run state.
  • A fresh run shall reset the displayed distance survived for the new run.
• Observable result: The player enters an active run after Start or Restart and can control the runner.
• Failure and recovery: If a new run cannot initialize, the system shall show an understandable error state and provide a retry path.
• Continuation: After successful initialization, the player proceeds with the active run.

4. User Personas

Runner (Player)

• Provenance: required_inference.
• Product context: The Runner is the person playing run-mumbai in a web browser. They control a character sprinting through the streets of Mumbai while a cop pursues them.
• Primary goal: Survive for as long as possible and increase the distance survived before being caught or colliding with a hazard.
• Distinct responsibilities:
  • Start a run from the public Landing page.
  • Use keyboard input to steer, jump, and slide.
  • Recognize and react to traffic, stalls, puddles, and other presented hazards.
  • Respond to the visible cop pursuit by continuing to avoid hazards.
  • Review the end-of-run outcome and restart after failure.
• Relevant inputs and decisions:
  • Decide when to steer, jump, or slide based on the approaching street environment.
  • Decide to restart after a collision or caught result.
• Interaction with other accepted participants: The player does not interact with another human participant. The cop is a game-controlled pursuing threat whose visible pursuit affects the player’s run outcome.
• Observable success: The player remains in the active run, avoids hazards, is not caught by the cop, and sees distance survived increase.

5. Core User Flows

Flow 1 — Start a Mumbai Street Run

1. The Runner (Player) opens Landing in a web browser.
2. Landing presents the run-mumbai premise: an endless run through Mumbai streets while a cop chases the runner.
3. The player reviews the available keyboard guidance for steering, jumping, and sliding.
4. The player selects Start.
5. The application opens Game and initializes a new run.
6. Game displays the runner, Mumbai street environment, pursuing cop, hazards, and the initial distance-survived state.
7. The player enters the active run and can use keyboard controls.

Failure and recovery: If the Game experience cannot initialize, the application displays an error state and gives the player a way to retry beginning the run or return to Landing.

Flow 2 — Avoid Hazards During an Active Run

1. The Runner (Player) is in an active run on Game.
2. Game presents hazards along the Mumbai street path, including traffic, stalls, and puddles.
3. The player observes an approaching hazard.
4. The player uses keyboard input to steer, jump, or slide as appropriate for the hazard.
5. Game visibly updates the runner’s movement.
6. If the runner avoids the hazard, the run continues.
7. Game continues updating and displaying the distance survived.
8. The player continues responding to subsequent hazards for as long as the run remains active.

Failure and recovery: If the runner collides with a hazard, Game ends the run, displays the collision outcome and distance survived, and provides Restart.

Flow 3 — Experience the Cop Chase and Recover After Being Caught

1. The Runner (Player) begins or continues an active run on Game.
2. Game visibly represents a cop pursuing the runner.
3. The player continues steering, jumping, and sliding to avoid hazards and keep the run alive.
4. If the cop catches the runner, Game ends the active run.
5. Game displays a caught result and the distance survived for that completed run.
6. The player selects Restart.
7. Game resets the run state, including the distance display, runner position, cop chase state, and hazard sequence needed for a fresh run.
8. The player begins a new active run.

6. Visuals Colors and Theme

The user did not provide a detailed visual direction beyond the Mumbai street setting, endless-runner inspiration, web delivery, and cop chase. The following presentation choices are [Default — not specified by user] and must support the established Mumbai street-chase context without creating additional product scope.

Visual Theme

Theme: Mumbai Monsoon Street Sprint [Default — not specified by user]

The visual direction should evoke a stylized Mumbai street at high speed: warm city lights, dark asphalt, monsoon puddles, roadside stalls, moving traffic, and energetic pursuit tension. The visual treatment should be original and should not copy the visual assets, characters, branding, or layouts of Subway Surfers.

Color Tokens

• Night Asphalt: #17191D — primary game-background and road-depth color.
• Mumbai Charcoal: #292C31 — secondary street-surface and interface panel color.
• Monsoon Blue-Grey: #415463 — distant buildings, shadows, and environmental depth.
• Signal Amber: #F2A33A — primary action, distance emphasis, and warm street lighting.
• Monsoon Teal: #2AA8A1 — active gameplay highlight and safe-state accent.
• Brake-Light Red: #D94A45 — caught, collision, urgency, and error states.
• Puddle Blue: #6DA9C8 — puddle and reflective wet-surface accent.
• Market Coral: #E66F55 — street-stall awnings and environmental accents.
• Streetlight Cream: #F8E9C7 — high-contrast primary text and street-light glow.
• Mist Grey: #C4CBD0 — supporting text and non-critical interface detail.

Typography

• Heading font: Teko, sans-serif [Default — not specified by user]
  • Use for the game title, distance display, caught state, collision state, and action labels.
• Body font: Noto Sans, sans-serif [Default — not specified by user]
  • Use for instructions, control guidance, loading text, and errors.
• Type scale:
  • Display title: 64 px desktop, 44 px smaller browser widths.
  • Page heading: 40 px desktop, 32 px smaller browser widths.
  • Game distance: 36 px desktop, 28 px smaller browser widths.
  • Section heading: 24 px.
  • Body copy: 16 px.
  • Supporting instruction text: 14 px.

Shape and Spacing Language

• Use slightly rounded corners rather than highly rounded cards: 8 px radius for panels and 6 px radius for controls.
• Use road-sign and transit-inspired rectangular UI shapes.
• Use a 4 px spacing base with primary spacing intervals of 8 px, 12 px, 16 px, 24 px, 32 px, and 48 px.
• Keep the game viewport visually dominant and reduce non-game interface clutter.
• Use high contrast between gameplay information and the darker Mumbai street environment.

Imagery Style

• Use stylized, original 2D or layered-2D environmental art.
• Represent Mumbai through street-level atmosphere—wet roads, local stalls, traffic silhouettes, overhead signs, warm lighting, and dense urban depth—without asserting specific real-world locations or landmarks not supplied in the requirements.
• The runner and cop should have distinct readable silhouettes during motion.
• Hazards must be visually recognizable early enough for player response.

7. Signature Design Concept

“The Chase Lane”

The Landing page opens with an original layered Mumbai street scene that forms a central road corridor receding into the distance. The runner appears in the foreground lane, while the cop is framed farther behind in the same corridor. Traffic silhouettes, stall canopies, and reflective puddles establish the hazards the player will face.

The Start control sits at the road’s visual vanishing point as a high-contrast Signal Amber road-sign-style button. Keyboard control guidance is arranged as compact directional and action keycaps beneath it. This composition uses only accepted content: the Mumbai setting, runner, cop chase, hazards, and Start action.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: A runner moving through a stylized Mumbai street corridor with a cop visibly pursuing from behind.
• Input → transformation → outcome thesis: Selecting Start transforms the static pre-run street composition into the active Game run, where the player’s keyboard input controls steering, jumping, and sliding to avoid hazards and survive longer.
• Motion vocabulary: Short forward-moving street layers, passing traffic silhouettes, puddle reflections, subtle stall-sign sway, and restrained pursuit movement behind the runner.
• Composed first frame: The initial Landing frame shows the runner centered on a wet asphalt lane, the cop framed at a visible distance behind, roadside stalls and traffic at the edges, the game title above, and Start with control guidance in the lower visual region.
• Reduced-motion state: Disable continuous environmental movement and use a static layered street illustration. Preserve clear visual hierarchy, the runner, the cop, the premise, keyboard guidance, and Start functionality.

9. Non-Functional Requirements

NFR-1 — Browser Delivery

• Requirement: run-mumbai shall be delivered as a web game playable in a browser.
• Provenance: explicit.
• Rationale: Browser delivery is an explicit project constraint.

NFR-2 — Anonymous Access

• Requirement: Landing and Game shall be accessible without account creation, sign-in, or player identity establishment.
• Provenance: required_inference.
• Rationale: The accepted page-access contract defines no access requirement for both pages, and the current game lifecycle does not require durable player-specific continuity.

NFR-3 — Responsive Gameplay Feedback

• Requirement: During an active run, the visual response to valid keyboard steering, jumping, and sliding input shall be sufficiently immediate for the player to make real-time hazard-avoidance decisions.
• Provenance: required_inference.
• Rationale: Timely visible feedback is indispensable to the accepted keyboard-controlled endless-runner experience.

NFR-4 — Clear Failure Communication

• Requirement: The system shall communicate whether a run ended through collision or being caught and shall provide a restart path after either outcome.
• Provenance: required_inference.
• Rationale: Distinguishing and recovering from the accepted failure conditions is necessary for a usable replayable run lifecycle.

NFR-5 — Reduced-Motion Presentation

• Requirement: The Landing experience shall provide a reduced-motion visual state that preserves game information and Start functionality without requiring continuous decorative motion.
• Provenance: basic_default.
• Rationale: This is an accessibility-oriented presentation default and does not alter gameplay requirements.

10. Tech Stack

The user specified browser delivery but did not specify implementation technologies.

• Frontend: React [Default — not specified by user]
  • Provides the browser application shell, Landing page, Game page, interface states, and keyboard event handling.
• Game rendering: HTML Canvas or browser-native rendering within the React application [Default — not specified by user]
  • Supports the runner, cop chase, hazards, street environment, and distance display.
• Styling: CSS or a compatible CSS-based styling approach [Default — not specified by user]
  • Supports the Mumbai street theme, responsive layout, visual states, and reduced-motion presentation.
• Backend: Not required for the current anonymous, non-persistent game scope.
• Storage: Not required for the current scope because accounts, saved progress, and persistent scores are not established.
• Deployment: Static web hosting compatible with browser delivery [Default — not specified by user].

11. Assumptions and Constraints

Constraints

• The game shall be delivered as a web browser experience. [explicit]
• The setting shall be the streets of Mumbai. [explicit]
• The game shall be an endless runner. [explicit]
• A cop shall chase the runner as the pursuing threat. [explicit]
• The current custom page contract consists only of Landing and Game, in that order.
• Landing and Game shall be anonymously accessible without an access requirement.
• The current scope shall not add player accounts, persistent progress, multiplayer, purchases, levels, maps, or game modes.

Assumptions

• Keyboard controls are the current required input method because keyboard steering, jumping, and sliding are established for the browser game lifecycle. [required_inference]
• Traffic, stalls, and puddles are representative Mumbai street hazards within the current game environment. [required_inference]
• Distance survived is scoped to the current run only and is not required to persist after the player leaves or refreshes the browser. [required_inference]
• The cop is game-controlled and is not an active human persona. [required_inference]
• The implementation will use original visuals and gameplay presentation rather than copying Subway Surfers assets, branding, characters, or proprietary content. [basic_default]

12. Glossary

• Active Run: The playable state in which the runner moves through the Mumbai street environment, hazards appear, the cop pursues, and distance survived increases.
• Caught State: The failure state reached when the pursuing cop catches the runner.
• Collision: A run-ending contact between the runner and a hazard.
• Cop Pursuer: The game-controlled cop that chases the runner during gameplay.
• Distance Survived: The visible measure of how far the player has progressed during the current run.
• Endless Runner: A game format in which the player continues moving forward until a failure condition ends the run.
• Hazard: An obstacle or dangerous street element the runner must avoid, including traffic, stalls, and puddles.
• Landing: The public entry page that introduces run-mumbai and provides the Start action.
• Game: The public playable page where the player controls the runner, avoids hazards, experiences the cop chase, and restarts after failure.
• Runner: The player-controlled character moving through Mumbai streets.