System Requirements Document for pure-wanted

1. Introduction

pure-wanted is a playable car-driving survival game set on Indian streets. It is designed for a Player seeking the noisy, unpredictable energy of real-world Indian traffic rather than a conventional circuit-racing experience.

The current product challenge is to steer and drive through chaotic street traffic for as long as possible. The Player must dodge hazards including auto-rickshaws, buses, and potholes. The game does not involve wheel-to-wheel racing against opponents, a finish line, or competitive racing progression.

2. System Overview

pure-wanted delivers a custom, browser-based driving game experience with three first-party pages:

1. Landing
2. Run
3. Run Result

The Player enters the game anonymously, starts a survival run, controls a car through an Indian street environment, avoids real-world traffic hazards, observes survival time, and receives a result when a collision ends the run.

The Indian street environment is presented as a handcrafted, stylized low-poly world rather than a photorealistic traffic simulation. Traffic density, hazards, vehicle movement, road details, and visual chaos should make the road itself the central gameplay space.

2a. Product Interpretation and Delivery Boundary

The product is an anonymous, single-player survival driving game. No account creation, sign-in, multiplayer opponent system, leaderboard, finish-line race, vehicle-brand licensing, or photorealistic crash depiction is included in the current scope.

The Player begins from the Landing page, where the Indian-street survival experience is introduced and a run can be started. The Run page owns active driving, obstacle avoidance, survival-time display, collision detection, and in-run control. The Run Result page owns the completed-run outcome and the option to begin another survival run.

Current gameplay is limited to surviving through traffic and hazards for as long as possible. The game must not frame the experience as a conventional race against opponents or toward a finish line.

2c. Page Content and Component Coverage

Landing

• Information and world state

  • Full-viewport, low-poly Indian urban night-street scene.
  • A coral player hatchback positioned in the lower-center chase-camera view.
  • Three converging traffic lanes containing visible hazards before gameplay starts.
  • Visible environmental traffic including a cream-and-red bus, yellow-and-green auto-rickshaws, scooters, a striped road barricade, and a clearly lit pothole.
  • The title PURE / WANTED displayed as two large cream heading lines along the left side.
  • Supporting instruction: DODGE. DON'T RACE.

• Primary action

  • START THE RUN control starts a new survival run and moves the Player to the Run page.

• Supporting actions

  • A small upper-right sound/settings cluster may provide only lightweight sound or presentation controls where implemented; it must not introduce account, progression, or adjacent settings-management features.

• Components and responsibilities

  • Full-bleed WebGL/R3F street-scene renderer.
  • Chase-camera composition that shows the player car, traffic, road surface, hazards, and lane flow.
  • Floating top-left wordmark.
  • Skewed sun-yellow roadside-sign Start control with dark support posts and a black arrow pointing into the traffic flow.
  • High-contrast content backing where text overlaps animated traffic.
  • Pre-run traffic animation that visually communicates an active, dangerous road.

• Loading state

  • Show an unobtrusive loading state while the 3D street scene and essential gameplay assets initialize.
  • Keep the Start action unavailable until the playable run can start reliably.

• Error and recovery state

  • If the visual scene cannot initialize, provide a clear retry action on Landing.
  • The recovery action must retry loading the game scene without requiring Player identity or account setup.

• Success state

  • On Start, transition the Player into an active Run with survival time beginning at the run start.

Run

• Information and world state

  • Active survival-driving scene on Indian streets.
  • Player-controlled car visible in the chase-camera road view.
  • Moving traffic and hazards, including auto-rickshaws, buses, and potholes.
  • Ongoing survival time visible in the upper-left HUD.
  • Near-miss multiplier or horn-meter feedback visible in the upper-right HUD when near misses are represented.
  • Road details may include painted lane dividers, concrete dividers, uneven pothole rims, traffic cones, striped barricades, traffic lights, overhead cables, awnings, and abstract multilingual-style street signs.

• Primary actions

  • Steer the car to avoid traffic and road hazards.
  • Accelerate or maintain driving movement as supported by the gameplay input model.
  • Use touch steering controls from lower screen corners on touch-capable devices.

• Supporting actions

  • Use the lower-left pause control when pause behavior is implemented within the active run.
  • Resume the run from a paused state without resetting the current survival time.

• Components and responsibilities

  • Real-time driving scene renderer and collision-state presentation.
  • Keyboard and touch control handling for steering and driving.
  • Lower-corner chevron-shaped touch steering pads.
  • Edge-mounted toy-instrument HUD islands:
    • Stopwatch for survival time.
    • Near-miss horn meter or multiplier.
    • Pause control.
    • Touch steering controls.
  • Collision presentation using a brief freeze-frame, screen-print impact treatment, and transition toward the run result.
  • Responsive camera tilt that follows steering input without obscuring hazards.

• Loading state

  • The run begins only after the playable scene, player car, hazards, controls, and timer are ready.
  • The active driving canvas must remain visually clear enough for traffic and potholes to be readable.

• Empty state

  • Not applicable during an active run; hazards and the street-driving environment are core run content.

• Success state

  • The Player continues driving while avoiding hazards, with survival time visibly increasing.

• Error and recovery state

  • If an active-run rendering or input interruption prevents safe continuation, stop the affected run and provide a clear recovery path to start another run.
  • A collision is an expected gameplay-ending condition, not a technical error. It must visibly end the run and proceed to Run Result.

Run Result

• Information and result state

  • Final survival time from the completed run.
  • Collision outcome indicating that traffic or a road hazard ended the run.
  • Wrecked-car or run-ending visual treatment derived from the collision state.
  • Impact language: TRAFFIC GOT YOU.

• Primary action

  • Start another survival run.

• Supporting actions

  • Return to the Landing page only where a clear navigation control is provided without adding unrelated destinations.

• Components and responsibilities

  • Result panel presenting final survival time.
  • Collision aftermath visual that follows the in-run collision freeze-frame.
  • Replay action that initializes a new Run.
  • Clear visual separation between the completed run and the next-run action.

• Loading state

  • Preserve the completed survival time while the result presentation is prepared.

• Success state

  • The Player sees the final survival result and can begin another run.

• Error and recovery state

  • If a completed-run result cannot be displayed correctly, retain or recover the final available survival time where possible and offer the Player a way to start another run.

3. Functional Requirements

FR-1 — Start an Indian-Street Survival Run

As a Player, I should be able to start a car-driving survival run set on Indian streets so that I can enter the real-world traffic dodging challenge.

• Provenance: explicit for the Indian-street car-racing game intent and Start request; required_inference for the Landing-to-Run interaction.
• Trigger/input: The Player selects START THE RUN on Landing.
• Access state: Anonymous access; no account or sign-in is required.
• Required behavior:
  • The system shall present a Landing experience that communicates the Indian-street survival-driving context.
  • The system shall allow the Player to start a survival run from Landing.
  • The system shall initialize the Player into the Run page with an active street-driving scene.
  • The run shall be framed as survival through traffic, not as a race against wheel-to-wheel opponents or toward a finish line.
• Observable result: The Player enters the Run page and can begin attempting to survive through Indian street traffic.
• Failure and recovery: If the playable scene is not ready, the system shall prevent unreliable run start, communicate loading or initialization failure, and provide a retry path.
• Continuation: A successful start continues into active driving under FR-2.

FR-2 — Drive and Dodge Real-World Traffic Hazards

As a Player, I should be able to steer and drive my car through chaotic real-world Indian street traffic so that I can survive as long as possible without colliding.

• Provenance: explicit for real-world traffic, Indian streets, survival/dodging challenge, and named hazards; required_inference for active controls, collision detection, survival timer, and run-ending transition.
• Trigger/input: The Player begins an active run and uses available steering and driving inputs.
• Access state: Anonymous active gameplay.
• Required behavior:
  • The system shall present Indian-street traffic conditions during a run.
  • The system shall include auto-rickshaws, buses, and potholes as traffic hazards.
  • The Player shall be able to steer the car to avoid hazards.
  • The Player shall be able to use driving input appropriate to the active run, including acceleration or continuous forward driving behavior.
  • Touch-capable devices shall provide thumb-friendly steering controls at the lower corners of the Run page.
  • The system shall display the Player’s survival time while the run remains active.
  • The system shall treat collision with relevant traffic or road hazards as the run-ending event.
  • The game shall not introduce a finish line, wheel-to-wheel opponent race, or conventional racing victory condition.
• Observable result: Survival time increases while the Player avoids hazards; a collision visibly ends the run.
• Failure and recovery:
  • When a collision occurs, the system shall provide a clear impact state and preserve the final survival time for the result.
  • If a technical interruption prevents safe active driving, the system shall end or halt the affected run and provide a path to start another run.
• Continuation: Collision proceeds to FR-3. Continued successful avoidance remains within the active Run.

FR-3 — Receive a Completed-Run Result and Retry

As a Player, I should be able to see my final survival result after a collision and start another run so that I can try to survive longer.

• Provenance: required_inference, necessary to provide a usable observable outcome after the explicitly required survival run ends through collision.
• Trigger/input: The Player collides with traffic or a road hazard during an active run.
• Access state: Anonymous completed-run state.
• Required behavior:
  • The system shall stop the active run when a collision ends it.
  • The system shall present the Player’s final survival time on Run Result.
  • The collision result shall visibly communicate that traffic ended the run, including the TRAFFIC GOT YOU impact treatment.
  • The system shall provide an action to start another survival run.
• Observable result: The Player sees the completed-run outcome and the final survival time.
• Failure and recovery: If the result presentation cannot be fully rendered, the system shall preserve the available final survival time where possible and provide a replay path.
• Continuation: Starting another run returns the Player to a newly initialized Run.

4. User Personas

Player

• Provenance: required_inference from the accepted single-player driving and survival gameplay.
• Product context: The Player enters pure-wanted anonymously to drive through a stylized Indian street environment filled with real-world traffic conditions.
• Primary goal: Survive for as long as possible by steering through chaotic traffic and avoiding collisions.
• Distinct responsibilities:
  • Start a survival run.
  • Read the road, traffic movement, and hazard placement.
  • Steer and drive the car through auto-rickshaws, buses, potholes, and other visible road obstacles.
  • React to near misses and collision risk while monitoring survival time.
  • Review the final survival time when a collision ends the run.
  • Start another run after receiving a result.
• Relevant inputs and decisions:
  • Select whether to start a run.
  • Choose steering input to avoid hazards.
  • Make immediate driving decisions based on traffic movement, lane openings, potholes, and road barriers.
  • Select whether to retry after a completed run.
• Interactions with other accepted participants: None. Traffic and hazards are gameplay elements, not human participants.
• Observable success: The Player remains active in the run, avoids collisions, and achieves a longer visible survival time before a collision ends the attempt.

5. Core User Flows

Flow 1 — Start a Survival Run

1. The Player opens Landing with anonymous access.
2. Landing presents the full-viewport Indian-street scene, including the player car, real-world traffic hazards, and the PURE / WANTED title.
3. The Player sees the message DODGE. DON'T RACE. and the START THE RUN roadside-sign control.
4. The Player selects START THE RUN.
5. The application confirms that essential gameplay assets and controls are ready.
6. If initialization succeeds, the application opens Run and begins the survival timer.
7. If initialization fails, Landing communicates the issue and offers the Player a retry action.

Flow 2 — Survive Through Traffic

1. The Player begins on Run with the player car visible in the Indian-street driving scene.
2. The Player sees moving traffic and hazards including auto-rickshaws, buses, and potholes.
3. The Player observes the survival timer in the upper-left HUD.
4. The Player uses steering controls to move the car away from traffic and road hazards.
5. On touch devices, the Player uses the lower-corner chevron steering controls.
6. The Player continues making driving decisions as traffic and hazards occupy the road.
7. The application updates visible survival time while the Player remains collision-free.
8. When near-miss feedback is represented, the Player sees the near-miss multiplier or horn meter in the upper-right HUD.
9. If the Player pauses the run through the lower-left pause control, the current run state and survival time remain available for resumption.
10. If the Player avoids hazards, the run continues.
11. If the Player collides with traffic or a pothole, the application freezes the impact moment briefly, communicates the collision, records the final survival time, and proceeds to Run Result.

Flow 3 — Review a Collision Result and Retry

1. The Player arrives on Run Result after a collision.
2. The application presents the TRAFFIC GOT YOU collision outcome.
3. The Player sees the final survival time from the completed run.
4. The Player selects the action to start another run.
5. The application initializes a new anonymous survival run.
6. The Player returns to Run and begins a fresh attempt with a new survival timer.

6. Visuals Colors and Theme

Muse: Bruno Simon
Headline: A playable Indian street survival world after Bruno Simon

Visual Direction

pure-wanted shall use an immediate, mischievous, tactile arcade-survival style. The road world must be the primary interface rather than content placed inside a conventional application shell. The visual experience should celebrate dense Indian-street energy through low-poly craft, readable hazards, playful road geometry, and responsive physical feedback.

The game must avoid polished circuit-racing fantasy, chrome supercar aesthetics, esports styling, generic SaaS layout patterns, blue or indigo primary UI, white-background dashboard presentation, stock traffic photography, real vehicle logos, and photorealistic crash imagery.

Color Tokens

Color distribution should approximate:

• Charcoal asphalt: 55%.
• Deep green-black surfaces: 20%.
• Cream type and markings: 15%.
• Traffic coral: 7%.
• Auto-rickshaw yellow: 3%.

Blue must not be used as a primary UI color.

Typography

• Heading font: Baloo 2 ExtraBold.
• Body font: Nunito Sans.
• Score numerals: Baloo 2 Bold with tabular numerals enabled.
• Heading treatment: Mixed case, tight leading, slight negative tracking, and oversized road-sign-like commands.
• Desktop type scale: 96 / 64 / 42 / 28 / 20 / 16 px.
• Mobile type scale: 64 / 46 / 34 / 25 / 19 / 16 px.

Shape and Surface Language

• Interface corners shall use an 18 px radius.
• HUD components shall use rounded, toy-like capsule forms.
• In-world objects shall remain angular, chunky, faceted, and tactile.
• Vehicles shall have visible low-poly facets and broad soft shadows.
• Road objects shall feel hand-placed and imperfect, including uneven pothole rims, painted lane dividers, squat traffic cones, striped barricades, and road markings.
• Text over moving traffic must use solid, high-contrast backing surfaces where necessary for readability.

Layout

• Landing: Full-viewport driving scene; floating wordmark in the upper-left; compact sound/settings cluster in the upper-right; asymmetrical Start plaque near the lower-right.
• Run: Open road remains central. HUD occupies four edge zones:
  • Survival timer: upper-left.
  • Near-miss multiplier or horn meter: upper-right.
  • Pause: lower-left.
  • Touch steering controls: lower corners.
• Run Result: Result panel overlays or follows the collision aftermath while retaining the road-world visual identity.

Imagery and Environment

The game shall use a handcrafted low-poly Indian urban road scene with:

• Painted buses.
• Yellow-and-green auto-rickshaws.
• Delivery scooters.
• Potholes with pooled rainwater.
• Concrete dividers.
• Overhead cables.
• Storefront awnings.
• Traffic lights.
• Dense vehicle silhouettes.
• Warm streetlamp pools.
• Multilingual-style abstract street-sign shapes that do not imitate real brands.

7. Signature Design Concept

The public Landing experience shall act as the first second of a run.

A full-bleed, slightly tilted low-poly night street fills the viewport in a chase-camera view. A coral hatchback sits low and central, facing three converging lanes of traffic. A looming cream-and-red bus, yellow-green auto-rickshaws, scooters, a barricade, and a lit pothole establish the survival challenge before the Player presses Start.

PURE / WANTED appears as two enormous cream Baloo 2 lines along the left edge. Moving buses and auto-rickshaws physically pass in front of portions of the lettering, making the traffic world feel present and active. The START THE RUN control is a sun-yellow skewed roadside sign mounted on two dark posts in the lower-right, with a black arrow pointing directly into the traffic flow. The instruction DODGE. DON'T RACE. sits beneath the control.

This composition uses accepted gameplay content only: the player car, Indian street hazards, survival framing, and the Start action.

8. Interaction Model & Motion Direction

Interaction Model: Animated
Motion Tempo: cinematic
Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: A coral player hatchback on a low-poly Indian night street, viewed from a chase-camera angle and surrounded by buses, auto-rickshaws, scooters, barricades, and potholes.
• Input → transformation → outcome thesis: The Player selects START THE RUN; the pre-run street scene shifts from a slow living roadway into active survival driving; the Player enters the Run with traffic hazards, steering input, and survival time active.
• Motion vocabulary: Physics-led suspension bounce, varied traffic speeds, soft headlight sweeps on asphalt, dust puffs under braking, minor steering-responsive camera tilt, crisp collision freeze-frames, brief camera shake, and smash-cut result reveal.
• Composed first frame: The coral car is positioned in the lower center at approximately one-third of viewport height, aimed toward three converging traffic lanes. Cream PURE / WANTED title lines sit along the left edge and are partially masked by passing traffic. The yellow roadside Start sign occupies the lower-right.
• Reduced-motion state: Present a static isometric street still with non-shaking UI feedback. Avoid camera tilt, collision shake, and animated traffic effects that could disorient the Player or reduce hazard readability.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

Build a compact real-time WebGL/R3F low-poly street scene representing the defining product state: a Player car attempting to enter dense Indian street traffic and avoid hazards.

The scene shall include:

• A coral low-poly player hatchback with a subtle idle suspension bounce.
• At least one cream-and-red bus.
• Yellow-and-green auto-rickshaws.
• Scooters or comparable traffic silhouettes.
• A readable pothole with pooled rainwater.
• Lane markings, barricades, traffic lights, storefront awnings, overhead cables, and warm streetlamp pools.
• A chase-camera composition with shallow steering-responsive movement.
• Environmental mint #72C8A2 and bus red #C63B32 used only as restrained in-world accents.

The scene must remain readable at speed and must not portray crashes photorealistically or imitate real vehicle brands.

9. Non-Functional Requirements

NFR-1 — Hazard Readability

• Provenance: explicit creative direction.
• The system shall maintain clear visual distinction between the player car, traffic hazards, potholes, lane markings, and road barriers.
• Motion, lighting, and camera behavior shall not make hazards difficult to read during active driving.
• Text placed over active traffic shall use a high-contrast backing surface when required for legibility.

NFR-2 — Reduced-Motion Support

• Provenance: explicit creative direction.
• The system shall respect reduced-motion preferences.
• Reduced-motion presentation shall use a static isometric street still and non-shaking UI feedback.
• Reduced-motion behavior shall avoid camera shake, disorienting traffic animation, and steering-driven camera movement.

NFR-3 — Responsive Input Presentation

• Provenance: explicit creative direction.
• The system shall provide thumb-friendly steering controls at the lower corners of touch-capable devices.
• The active road view shall remain substantially unobstructed by controls and HUD components.

NFR-4 — Visual Safety and Brand Independence

• Provenance: explicit creative direction.
• The system shall not use photorealistic crash imagery.
• The system shall not show real vehicle logos.
• The system shall not present documentary depictions of dangerous real-world road behavior.
• Street signs shall use abstract multilingual-style forms rather than real brands or real-world signage reproductions.

NFR-5 — Gameplay Framing

• Provenance: explicit user requirement and planning constraint.
• The game shall maintain a survival-and-dodging framing.
• The system shall not use a conventional racing finish line, opponent leaderboard framing, or track-day visual language.

10. Tech Stack

Client and Gameplay Rendering

• React for the browser application interface and page routing.
• Three.js / React Three Fiber (R3F) for the required real-time WebGL Landing hero and playable low-poly street world.
• Drei, where needed, for R3F scene composition, assets, lighting helpers, and interaction support.
• HTML/CSS for HUD, Start control, result panel, accessible text, and responsive touch-control overlays.

Runtime

• Modern web browser with WebGL support for the 3D street scene.
• Touch input support for mobile steering controls.
• Keyboard input support where desktop steering controls are implemented.

Deployment

• Docker and docker-compose for reproducible local development and deployment packaging.

No backend service, persistent storage, account system, leaderboard service, or Kubernetes deployment is required by the current scope.

11. Assumptions and Constraints

Constraints

• Explicit: The game is set on Indian streets with real-world traffic.
• Explicit: The central challenge is dodging chaotic traffic to survive as long as possible.
• Explicit: Auto-rickshaws, buses, and potholes are required traffic hazards.
• Explicit: The game is not a competitive wheel-to-wheel race to a finish line.
• Explicit: The visual direction must avoid generic blue or indigo primary UI on a white SaaS-style layout.
• Explicit: The landing and gameplay visual direction uses a low-poly, handcrafted Indian-street world.
• Explicit: Real vehicle logos and photorealistic crash imagery are excluded.
• Explicit: The product requires a real-time WebGL/R3F hero subject as part of the visual direction.

Assumptions

• [Required inference] The Player uses the game without creating an account because no identity, saved progression, multiplayer interaction, or durable player-specific state is required by the current scope.
• [Required inference] A collision ends a survival run because survival time must have a clear completion condition.
• [Required inference] The survival timer resets when the Player begins another run.
• [Default — not specified by user] The application should be delivered as a responsive browser game.
• [Default — not specified by user] Audio controls may be minimal and optional; no music library, account-linked sound preferences, or advanced settings area is in current scope.

Future Scope Exclusions

The following are not current requirements and must not be added to current pages, flows, or acceptance behavior:

• Multiplayer racing.
• Wheel-to-wheel opponent systems.
• Finish lines or lap-based racing.
• Leaderboards.
• User accounts or sign-in.
• Vehicle purchasing, upgrades, garages, or customization.
• Persistent progression.
• Real-brand vehicles or signage.
• Photorealistic traffic simulation.
• Additional maps, cities, or game modes.

12. Glossary

• Auto-rickshaw: A three-wheeled passenger vehicle represented as an Indian-street traffic hazard in the game.
• Collision: A gameplay event in which the Player car hits relevant traffic or a road hazard, ending the current survival run.
• Indian street: The stylized urban road setting containing real-world traffic elements such as buses, auto-rickshaws, potholes, scooters, barriers, and street infrastructure.
• Near miss: A close avoidance event represented through optional in-run multiplier or horn-meter feedback.
• Player: The single active human persona who starts, controls, survives through, and retries driving runs.
• Run: One active survival-driving attempt beginning when the Player starts the game and ending on collision.