System Requirements Document for ww2-game

1. Introduction

ww2-game is a browser-based, WW2-themed game built around three explicit user commitments: a cool design, gameplay mechanisms, and animations. The product is not a museum exhibit, not a documentary archive, and not a dry hex wargame. It is a playable instrument: a dark, cold, mechanical command console lit by instrument glow, where the war is rendered as abstract instrumentation — radar scopes, map tables, supply readouts, gun-camera overlays — rather than photographic depiction.

The audience is desktop-first players who expect a game to look like a game the moment it loads and who judge it within the first three seconds. The intended emotional register is night-ops adrenaline: tension, spectacle, and tactile feedback. The single active human role is the Player, who opens the game, plays through its mechanisms, and receives animated feedback until reaching an outcome (win, loss, or completion).

This document defines the current delivery: an anonymous, no-account, first-party browser game with three destinations — Landing, Game, and Results — plus the visual, motion, and interaction system that makes the design "cool" in a way that is specific rather than generic.

2. System Overview

ww2-game is delivered as a first-party custom web application. It has no backend account system, no sign-in, no persistence requirement, and no external service dependency in the current horizon. All three destinations are anonymously reachable.

Actors

• Player (active human, sole persona): initiates play, operates the game's mechanisms, and experiences the outcome.
• Game runtime (system process): executes the simulation loop, resolves player input into state changes, and drives animation and audio-visual feedback. It is not a persona and has no independent product goal.

Accepted behavior

• A Landing destination that presents the game's identity as a live operations table and invites the player to begin.
• A Game destination where the player starts play, uses the game's mechanisms, and receives animated feedback tied to game state.
• A Results destination that shows the player's win, loss, or completion state after play.
• A project-wide visual and motion system: dark instrument palette, luminous hairline panels, circular instruments, tabular-numeral readouts, cinematic motion, and a WebGL hero subject.

Ownership

All three destinations are owned by the application. There is no provider-owned surface, no external destination, and no headless delivery in the current horizon.

Narrow exclusions

• No account creation, sign-in, profile, or identity management.
• No multiplayer, matchmaking, chat, or social features.
• No leaderboards, achievements, or persistent progression.
• No monetization, store, or in-app purchase surface.
• No photographic stock imagery of soldiers, flags, swastikas, or real historical atrocity imagery.
• No blue-indigo accent palette and no light/near-white ground.

2a. Product Interpretation and Delivery Boundary

What is being built. A single-player, browser-delivered WW2-themed game whose "cool" quality comes from a coherent instrument-console aesthetic and from animation that always carries game meaning. The player never needs an account, never leaves the first-party application, and never depends on a third-party service to play.

Delivery and access ownership. The application owns every surface. All three destinations — Landing, Game, and Results — are anonymously reachable with no access requirement. Because no accepted journey requires durable player-specific state to be privately owned, resumed across sessions, or bound to a verified identity, no application-owned identity is introduced. There is no anonymous pre-identity lifecycle to own, and therefore no separate access boundary page.

Current vs. future. Current scope is the three destinations, the gameplay mechanisms, the animation system, and the visual design system described in this document. Anything not listed here — accounts, persistence, multiplayer, leaderboards, additional campaigns or missions beyond the single playable experience, and any external integration — is out of current scope and is not implemented, not routed, and not referenced by current pages.

Design authority. The creative direction is authoritative for visual and motion decisions. Where the direction and a generic convention disagree, the direction wins. Where the direction is silent, this document supplies labeled defaults.

2c. Page Content and Component Coverage

Landing

Purpose and information/state. The anonymous public entry. It presents the game's identity as a live operations table and invites the player to begin. It carries no player-specific state; it is the same for every visitor.

Information shown

• Stacked display headline reading OPERATION / NIGHTFALL in Space Grotesk uppercase, flush-left, second line offset 60px right so it breaks the column.
• A mission clock in IBM Plex Mono with tabular figures, counting above the headline.
• A full-viewport wireframe topographic map table, tilted 12 degrees with CSS perspective, contour lines in #3FD8C9 at 20% opacity.
• A radar sweep rotating slowly at centre-right over concentric rings.
• A faint cyan 12-column, 24px-gutter wireframe grid overlay.
• A continuously scrolling bottom ticker of mission codenames.
• A live radio log that types itself in at 22 characters per second.

Primary action

• A hard-edged orange rectangle (#FF6B2C) with a black uppercase label, pinned bottom-left directly beneath the headline, that begins play and navigates to Game.

Supporting actions

• None required. No secondary CTA, no subtext paragraph above the fold, no centred stack.

Domain entities

• Mission codename (display string, e.g. "NIGHTFALL").
• Mission clock (elapsed time, tabular).
• Radio log entry (timestamped line of text).
• Map contour (decorative geometry, not player state).

Component responsibilities

• Hero scene layer: renders the tilted topographic map table and the WebGL hero subject; receives cursor-driven parallax at 6px.
• Radar instrument: renders concentric rings at 25/50/75/100% opacity and a rotating conic-gradient beam; receives cursor-driven parallax at 10px; friendly blips cyan, hostile blips orange, pulsing at different rates.
• Headline block: per-word opacity stagger at 40ms on entry.
• Mission clock: digit-roll animation at 120ms per digit change.
• Primary CTA: hard-edged rectangle, orange fill, black uppercase label, focus state in #3FD8C9.
• Bottom ticker: continuous horizontal scroll of mission codenames.
• Radio log: self-typing text at 22 characters per second.
• HUD layer: corner-tick panels with four 12px L-shaped cyan strokes and a 25%-opacity hairline edge; receives 0px parallax.

States

• Loading: the void background (#070B0E) renders immediately; the WebGL hero subject fades in as it becomes ready; the headline and CTA are present and readable before the hero finishes.
• Empty: not applicable — the Landing has no collection that can be empty.
• Success: the player activates the primary CTA and arrives at Game.
• Error / recovery: if the WebGL hero subject fails to initialize, the Landing falls back to the static topographic map and radar rendered as CSS/SVG, with the headline, clock, ticker, radio log, and CTA fully functional. The player is never blocked from starting play.
• Reduced motion: the radar sweep stops, particles freeze, panels are simply present, and the ticker becomes a wrapped or horizontally scrollable row so every codename can be brought fully into view.

Game

Purpose and information/state. The interactive gameplay destination. The player starts the WW2-themed game here, operates its mechanisms, and receives animated feedback tied to game state. The centre of the viewport is always the scene, never a content column.

Information shown

• Left instrument rail (320px desktop): radar scope, ammo dial, squad status.
• Right intel column (320px desktop): objectives, radio log.
• Bottom command strip: primary action on the left, live radio log typing on the right.
• Centre scene: the playable view, full-bleed.
• Mission clock and casualty counter as large IBM Plex Mono tabular figures.

Primary action

• The primary action in the bottom command strip, which advances the current mission state (for example, committing an order or firing). Its label and availability reflect the current game state.

Supporting actions

• Selecting a unit or position in the scene.
• Reading objectives and squad status.
• Pausing or abandoning the current run, which ends play and moves to Results.

Domain entities

• Mission: the current playable scenario, with an objective set and a running clock.
• Objective: a discrete goal with a completion state (pending / complete / failed).
• Unit: a friendly or hostile entity with a position, a status, and a NATO-style geometric pictogram.
• Ammo: a countable resource with a current and maximum value.
• Squad: the set of friendly units with an aggregate status.
• Casualty: a running count of lost units.
• Radio log entry: a timestamped line of in-game text.
• Run outcome: win, loss, or completion, produced when the mission ends.

Component responsibilities

• Scene renderer: draws the playable view and the WebGL hero subject; receives cursor-driven parallax at 6px.
• Radar scope: concentric rings, rotating beam, cyan friendly blips, orange hostile blips.
• Ammo dial: circular instrument with a large tabular numeral and a 120ms digit-roll on change.
• Squad status panel: per-unit status rows with geometric pictograms.
• Objectives panel: objective rows with completion state.
• Radio log: self-typing lines at 22 characters per second.
• Command strip: primary action plus a 1px scanline wipe across the whole strip on any state change.
• Damage/state flash: a 180ms cyan-to-orange flash plus a 1px scanline wipe across the affected panel.
• HUD layer: corner-tick panels, 0px parallax.

States

• Loading: the scene and HUD panels slide in from their edges with 400ms cubic-bezier(0.16,1,0.3,1); instruments show their initial values.
• Empty: not applicable — a run always begins with a defined mission state.
• Success: the mission reaches a win or completion state; the player is taken to Results with that outcome.
• Error / recovery: if the scene renderer fails, the HUD, instruments, command strip, and radio log remain operable and the run can still be resolved to an outcome. If the player abandons the run, the current state is resolved as an abandoned outcome and the player is taken to Results.
• Reduced motion: the radar sweep stops, particles freeze, panels are simply present, and all state changes are instant colour swaps rather than flashes and wipes.

Results

Purpose and information/state. The outcome destination. It shows the player's win, loss, or completion state after play, with the run's figures presented as instrument readouts.

Information shown

• The run outcome (win / loss / completion / abandoned) as a prominent headline.
• Final mission clock value.
• Final casualty count.
• Final ammo state.
• The objective list with each objective's final completion state.
• The final radio log.

Primary action

• Play again, which starts a new run and returns the player to Game.

Supporting actions

• Return to Landing, which navigates back to the public entry.

Domain entities

• Run outcome.
• Final mission clock.
• Final casualty count.
• Final ammo state.
• Objective list with final states.
• Final radio log.

Component responsibilities

• Outcome headline: Space Grotesk uppercase, flush-left, set large.
• Instrument readouts: IBM Plex Mono tabular figures for clock, casualties, and ammo, with digit-roll on entry.
• Objective summary list: rows with final completion state.
• Radio log replay: the run's log, readable in full.
• Action row: Play again as the primary action, Return to Landing as the supporting action.

States

• Loading: the outcome headline and readouts appear first; the radio log fills in.
• Empty: not applicable — a Results view is only reached after a run resolves.
• Success: the player chooses Play again and a new run begins, or chooses Return to Landing.
• Error / recovery: if the run's detailed figures are unavailable, the outcome headline and the two actions still render, so the player is never stranded.
• Reduced motion: readouts appear without digit-roll; all values are present immediately.

3. Functional Requirements

FR-1 — WW2-themed game

As a Player I should open a WW2-themed game so that I can play a game whose subject, tone, and presentation are recognizably WW2.

• Provenance: explicit
• Trigger / input: the Player navigates to the application.
• Observable result: the Landing renders a WW2 command-console presentation — operations-table map, radar scope, mission codenames, mission clock — and the Game renders WW2-framed units, objectives, and instruments.
• Access state: anonymous, no access requirement.
• Failure / recovery: if the WebGL hero subject fails, the static map and radar fallback renders and the game remains playable.
• Continuation: the Player proceeds to Game.
• Acceptance: the Landing and Game both present WW2-framed instrumentation, and no surface presents a non-WW2 theme.

FR-2 — Cool design

As a Player I should see a cool, deliberate visual design so that the game looks like a game the moment it loads.

• Provenance: explicit
• Trigger / input: any page render.
• Observable result: the dark instrument palette (#070B0E ground, #101820 glass panels, #3FD8C9 friendly glow, #FF6B2C hostile channel, #E8F0F4 text), Space Grotesk headings, IBM Plex Sans body, IBM Plex Mono tabular numerals, corner-tick panels, and circular instruments are applied consistently.
• Access state: anonymous, no access requirement.
• Failure / recovery: if a font fails to load, the layout remains readable and no text or control is clipped or overlapped at 375px, 768px, or 1280px.
• Continuation: the Player continues into play.
• Acceptance: no blue-indigo accent, no light/near-white ground, no centred headline + subtext + button hero, no gradient-blob backdrop, and no grid of identical hover-lift cards appears anywhere.

FR-3 — Gameplay mechanisms

As a Player I should operate the game's mechanisms so that my decisions change the state of the run.

• Provenance: explicit
• Trigger / input: the Player selects a unit or position and activates the primary action in the bottom command strip.
• Observable result: the mission state changes — objectives advance, ammo decrements, squad status updates, casualties increment, and the radio log records the event.
• Access state: anonymous, no access requirement.
• Failure / recovery: if the scene renderer fails, the HUD, instruments, command strip, and radio log remain operable and the run can still be resolved.
• Continuation: the Player continues until the mission resolves to an outcome.
• Acceptance: player input produces a visible change in at least one instrument readout and in the radio log.

FR-4 — Animations

As a Player I should receive animated feedback tied to game state so that the game feels tactile and alive.

• Provenance: explicit
• Trigger / input: any state change, page entry, or pointer movement.
• Observable result: panels slide in from their edges with 400ms cubic-bezier(0.16,1,0.3,1); damage and state changes fire a 180ms cyan-to-orange flash plus a 1px scanline wipe across the affected panel; numerals tick with a 120ms digit-roll; type reveals by per-word opacity stagger at 40ms; a slow radar sweep and drifting particle dust run at 8–14s loops; cursor position drives a 6–10px three-layer parallax.
• Access state: anonymous, no access requirement.
• Failure / recovery: under prefers-reduced-motion, the sweep stops, particles freeze, panels are simply present, and all state changes are instant colour swaps.
• Continuation: the Player continues play with the same information available.
• Acceptance: every glow, sweep, or flash maps to a game fact; no decorative animation carries no state meaning.

FR-5 — Start play from the Landing

As a Player I should begin play from the Landing so that I can enter the game without any setup.

• Provenance: required_inference
• Trigger / input: the Player activates the orange primary CTA pinned bottom-left beneath the headline.
• Observable result: the application navigates to Game and a run begins with initial instrument values.
• Access state: anonymous, no access requirement.
• Failure / recovery: if navigation fails, the CTA remains present and re-activatable.
• Continuation: the Player plays the run.
• Acceptance: activating the CTA always reaches Game with a defined initial mission state.

FR-6 — Read live mission state

As a Player I should read live mission state from the instruments so that I can make informed decisions.

• Provenance: required_inference
• Trigger / input: any change in mission state.
• Observable result: the radar scope, ammo dial, squad status, objectives panel, mission clock, casualty counter, and radio log all reflect the current state.
• Access state: anonymous, no access requirement.
• Failure / recovery: if a panel fails to update, the remaining instruments and the radio log still convey the state.
• Continuation: the Player acts on the information.
• Acceptance: no instrument displays a value that contradicts the current mission state.

FR-7 — Resolve the run to an outcome

As a Player I should reach a win, loss, or completion state so that my run has a definite end.

• Provenance: required_inference
• Trigger / input: the mission's objectives resolve, or the Player abandons the run.
• Observable result: the run resolves to win, loss, completion, or abandoned, and the application navigates to Results.
• Access state: anonymous, no access requirement.
• Failure / recovery: if the run cannot be resolved normally, abandoning the run still produces an outcome and reaches Results.
• Continuation: the Player reviews the outcome.
• Acceptance: every run reaches Results with exactly one outcome.

FR-8 — Review the outcome

As a Player I should see my outcome and final figures on Results so that I understand how the run ended.

• Provenance: required_inference
• Trigger / input: arrival at Results.
• Observable result: the outcome headline, final mission clock, final casualty count, final ammo state, objective list with final states, and the final radio log are displayed.
• Access state: anonymous, no access requirement.
• Failure / recovery: if detailed figures are unavailable, the outcome headline and both actions still render.
• Continuation: the Player chooses Play again or Return to Landing.
• Acceptance: the displayed outcome matches the run that just ended.

FR-9 — Play again or return

As a Player I should start a new run or return to the Landing so that I can keep playing or step away.

• Provenance: required_inference
• Trigger / input: the Player activates Play again or Return to Landing on Results.
• Observable result: Play again starts a fresh run and navigates to Game with reset instruments; Return to Landing navigates to Landing.
• Access state: anonymous, no access requirement.
• Failure / recovery: if navigation fails, both actions remain present and re-activatable.
• Continuation: the Player plays a new run or leaves the game.
• Acceptance: Play again always produces a fresh run with reset state, never a resumed prior run.

4. User Personas

Player

Product context. The Player is the sole active human role in ww2-game. They arrive at a browser game with no account, no onboarding, and no prior state. They are desktop-first and they judge the product in the first three seconds: if it does not look like a game immediately, they leave. They want spectacle, tension, and tactile feedback — not a museum exhibit and not a dry hex wargame.

Primary goal. To play a WW2-themed game whose design, mechanisms, and animations feel cool and coherent, and to reach a definite outcome.

Distinct accepted responsibilities.

• Initiating play from the Landing by activating the primary CTA.
• Operating the game's mechanisms: selecting units or positions and committing actions through the bottom command strip.
• Reading live mission state from the instrument rail, intel column, and command strip.
• Driving the run to a win, loss, or completion state, or abandoning it.
• Reviewing the outcome and final figures on Results.
• Choosing to play again or return to the Landing.

Relevant inputs and decisions.

• Which unit or position to select in the scene.
• When to commit the primary action, given ammo, squad status, and objectives.
• Whether to continue the run or abandon it.
• Whether to start a new run or leave after reviewing the outcome.

Interactions with other accepted participants. The Player is the only active human participant. The game runtime is a system process that resolves the Player's input into state changes and animation; it has no independent goal and never initiates a human-facing action. There is no other human counterparty, recipient, or beneficiary in the current scope.

Observable success. The Player reaches Results with a win, loss, or completion outcome; the final figures match the run; and every animation they saw mapped to a game fact they could act on.

Constraints carried from source. No account, no sign-in, no persistence, no multiplayer. The Player's experience is anonymous and session-scoped.

5. Core User Flows

Flow 1 — Enter the game and begin a run

1. The Player opens the application and arrives at Landing anonymously.
2. The void background (#070B0E) renders immediately; the headline OPERATION / NIGHTFALL appears with a per-word opacity stagger at 40ms, flush-left, second line offset 60px right.
3. The mission clock above the headline begins counting in IBM Plex Mono tabular figures.
4. The wireframe topographic map table renders tilted 12 degrees, contour lines in #3FD8C9 at 20% opacity; the radar sweep rotates at centre-right; the bottom ticker scrolls mission codenames; the radio log types itself in at 22 characters per second.
5. The Player moves the cursor; the map table drifts 6px, the radar 10px, and the HUD 0px, so the interface reads as a physical console.
6. The Player activates the hard-edged orange CTA pinned bottom-left beneath the headline.
7. The application navigates to Game; the scene and HUD panels slide in from their edges with 400ms cubic-bezier(0.16,1,0.3,1); instruments show their initial values.
8. Next step: the Player reads the instruments and begins operating the mechanisms.

Failure / recovery. If the WebGL hero subject fails to initialize, the Landing falls back to a static topographic map and radar rendered as CSS/SVG; the headline, clock, ticker, radio log, and CTA remain fully functional and the Player is never blocked from starting play.

Flow 2 — Operate the mechanisms and read live state

1. The Player is in Game with a run in progress.
2. The Player reads the left instrument rail (radar scope, ammo dial, squad status) and the right intel column (objectives, radio log).
3. The Player selects a unit or position in the centre scene.
4. The Player activates the primary action in the bottom command strip.
5. The mission state changes: objectives advance, ammo decrements, squad status updates, and the radio log records the event at 22 characters per second.
6. A 180ms cyan-to-orange flash and a 1px scanline wipe cross the affected panel; the ammo dial's numeral ticks with a 120ms digit-roll.
7. Next step: the Player reads the updated state and decides the next action, repeating steps 3–6 until the mission resolves.

Failure / recovery. If the scene renderer fails, the HUD, instruments, command strip, and radio log remain operable; the Player can still commit actions and resolve the run.

Flow 3 — Resolve the run and review the outcome

1. The Player's mission reaches a win, loss, or completion state, or the Player chooses to abandon the run.
2. The run resolves to exactly one outcome.
3. The application navigates to Results.
4. The outcome headline appears in Space Grotesk uppercase, flush-left and set large.
5. The final mission clock, casualty count, and ammo state render as IBM Plex Mono tabular figures with digit-roll on entry.
6. The objective list shows each objective's final completion state; the final radio log is readable in full.
7. Next step: the Player chooses Play again or Return to Landing.

Failure / recovery. If the run's detailed figures are unavailable, the outcome headline and both actions still render, so the Player is never stranded on an empty Results view.

Flow 4 — Play again or return to the Landing

1. The Player is on Results after reviewing the outcome.
2. The Player activates Play again.
3. A fresh run begins and the application navigates to Game with reset instruments — never a resumed prior run.
4. Next step: the Player plays the new run from Flow 2.

Alternative. At step 2, the Player instead activates Return to Landing and arrives back at Landing in its anonymous entry state.

Failure / recovery. If navigation fails, both actions remain present and re-activatable.

Flow 5 — Reduced-motion play

1. The Player has prefers-reduced-motion enabled and arrives at Landing.
2. The radar sweep stops, particles freeze, and panels are simply present rather than sliding in.
3. The bottom ticker becomes a wrapped or horizontally scrollable row so every mission codename can be brought fully into view.
4. The Player activates the CTA and enters Game.
5. In Game, all state changes are instant colour swaps rather than flashes and wipes; the radar sweep and particles remain still.
6. The Player operates the mechanisms and reads the same live state as in Flow 2.
7. Next step: the Player resolves the run and reviews the outcome as in Flow 3, with readouts appearing without digit-roll.

Failure / recovery. No information is lost in reduced-motion mode; every value and control available in the animated mode remains available.

6. Visuals Colors and Theme

Muse and headline. Gleb Kuznetsov — Cinematic future tech, but it's 1943, and the war room is the interface. Dark-void grounds, luminous HUD strokes, glassy data panels, and scroll-scrubbed camera motion translated into a WW2 command interface: radar scopes, map tables, supply readouts, gun-camera overlays.

Color tokens (dark mode)

Forbidden. Any blue-indigo accent (#2563EB, #4F46E5, #7C3AED and neighbours) and any light or near-white ground.

Typography

• Headings: Space Grotesk 500/700, uppercase; tracking +0.08em on micro-labels and -0.02em on big display lines; headlines set huge and flush-left, never centred.
• Body: IBM Plex Sans.
• Numerals: IBM Plex Mono 600 with tabular figures for mission timers, ammo counts, and casualty figures — numbers are the ornament.
• Scale: 1.25 modular with a display jump — 112 / 72 / 44 / 28 / 18 / 15.
• Display: clamp(52px, 9vw, 128px).
• Section heads: clamp(30px, 4.4vw, 56px).
• Body: 17px desktop / 16px mobile, line-height 1.55.
• Mono data: 13–15px with +0.06em tracking.
• Forbidden: Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui for headings or body.

Shape language

Thin luminous strokes over hard rectangles: 1px cyan hairlines that trace panel edges and break at the corners; 2px corner ticks instead of full borders; 4–6px radii only on controls. Circular instruments everywhere — radar rings, ammo dials, compass bezels — with concentric rings at 25/50/75/100% opacity. No soft blobs, no drop-shadow cards; depth comes from opacity stacking and blurred glow, not elevation.

Layout

Full-bleed dark scene with floating glass HUD panels pinned to the edges: a left instrument rail (radar, ammo, squad status), a right intel column (objectives, radio log), and a bottom command strip carrying the primary action. The centre of the viewport is always the scene, never a content column. Panels are 320px wide on desktop and collapse to a single bottom sheet plus a top status bar at 375px. The grid is a 12-column, 24px-gutter overlay, visible on the Landing as a faint cyan wireframe.

Imagery

No stock photos and no clip art. The visual is generated: a wireframe topographic map table with contour lines, a radial radar scope with sweeping beam and blip markers, animated supply-route arcs, and a low-poly silhouette skyline of a 1943 city rendered as cyan edge-lines on the void. Unit icons are geometric NATO-style pictograms drawn as 1.5px strokes — never illustrative characters. Grain and scanline overlays at 4–6% opacity sit above everything to kill digital flatness.

7. Signature Design Concept

The Landing is a live operations table, not a marketing hero.

A full-viewport wireframe topographic map fills the frame, tilted 12 degrees with CSS perspective, its contour lines drawn in #3FD8C9 at 20% opacity. A radar sweep rotates slowly at centre-right over concentric rings. Over the left third, a stacked display headline reads OPERATION / NIGHTFALL in Space Grotesk uppercase at clamp(52px, 9vw, 128px), flush-left, with the second line offset 60px right so it breaks the column. A mission clock in IBM Plex Mono sits above it, counting. The primary CTA is a hard-edged orange rectangle (#FF6B2C) with a black uppercase label, pinned bottom-left directly beneath the headline — no centred stack, no gradient blob, no subtext paragraph above the fold. Along the bottom edge, a thin ticker of mission codenames scrolls continuously.

Signature moves carried through the whole product

1. Live radar sweep as the dominant element — a rotating conic-gradient beam over concentric rings, with friendly blips in cyan and hostile blips in orange pulsing at different rates.
2. Corner-tick panels instead of bordered cards — each HUD panel is drawn with four 12px L-shaped cyan strokes at its corners and a 25%-opacity hairline edge, so panels feel like cut glass rather than rounded cards.
3. Tabular-numeral instruments — the ammo dial, mission clock, and casualty counter are large IBM Plex Mono figures that tick with a 120ms digit-roll animation, making numbers the loudest typographic element after the headline.
4. Cursor-driven three-layer parallax — the map table drifts 6px, the radar 10px, and the HUD 0px against pointer movement, so the interface reads as a physical console you are leaning over.
5. Bottom command strip that behaves like a field radio — the primary action sits left, the live radio log types itself in on the right at 22 characters per second, and any state change wipes a 1px scanline across the whole strip.

Avoid. Centred headline + subtext + button heroes, gradient-blob backdrops, grids of identical hover-lift cards, photographic stock imagery of soldiers, flags, swastikas, or real historical atrocity imagery, rounded soft cards with drop shadows, pastel palettes, playful bounce easing, and any decorative animation that carries no state meaning.

8. Interaction Model & Motion Direction

Interaction Model: Animated

Motion Tempo: cinematic

Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject. The live operations table: a tilted wireframe topographic map with a rotating radar sweep at centre-right, rendered as a real-time WebGL/R3F subject over the void.
• Input → transformation → outcome thesis. Cursor movement and elapsed time are the inputs. Cursor position transforms the three-layer parallax (map 6px, radar 10px, HUD 0px); elapsed time advances the radar sweep, the drifting particle dust, the mission clock, the scrolling codename ticker, and the self-typing radio log. The outcome is a console that reads as physical and live — the player leans over a war room table rather than looking at a page.
• Motion vocabulary. Slow continuous radar sweep and drifting particle dust at 8–14s loops; panel entry from edges at 400ms cubic-bezier(0.16,1,0.3,1); per-word opacity stagger at 40ms; 120ms digit-roll on numerals; 180ms cyan-to-orange flash plus 1px scanline wipe on state change.
• Composed first frame. The void #070B0E fills the viewport. The topographic map is already present, tilted 12 degrees, contour lines at 20% opacity. The radar beam is mid-rotation. OPERATION / NIGHTFALL is set flush-left over the left third, second line offset 60px right. The mission clock counts above it. The orange CTA sits bottom-left beneath the headline. The codename ticker runs along the bottom edge. Grain and scanline overlays sit at 4–6% opacity above everything.
• Reduced-motion state. The radar sweep stops, particles freeze, panels are simply present rather than sliding in, and all state changes are instant colour swaps. The codename ticker becomes a wrapped or horizontally scrollable row so every codename can be brought fully into view. The headline, clock, radio log, and CTA remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

• Object. A single crafted real-time scene: a wireframe topographic map table with contour lines, a radial radar scope with a rotating conic-gradient beam and blip markers, and a low-poly silhouette skyline of a 1943 city rendered as cyan edge-lines on the void.
• Defining state shown. The radar sweep and its blips are the product's defining state — friendly blips in cyan, hostile blips in orange, pulsing at different rates — so the hero shows the game's core instrument rather than a decorative object.
• Material and light. Cyan edge-lines at 20–25% opacity on #070B0E; no photographic textures; depth from opacity stacking and blurred glow, not elevation.
• Camera. Fixed with a 12-degree tilt; cursor-driven parallax moves the map 6px and the radar 10px against pointer movement.
• Performance and fallback. The scene must not block the headline, clock, ticker, radio log, or CTA from rendering and being operable. If WebGL is unavailable or the scene fails to initialize, the static CSS/SVG topographic map and radar render in its place with identical information.

9. Non-Functional Requirements

• NFR-1 — Readability at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Provenance: explicit (creative direction).
• NFR-2 — Panel collapse. HUD panels collapse to a single bottom sheet plus a top status bar at 375px rather than cropping. Provenance: explicit (creative direction).
• NFR-3 — Reduced motion. Under prefers-reduced-motion, the radar sweep stops, particles freeze, panels are simply present, and all state changes are instant colour swaps; moving and scrollable content provides a usable static arrangement. Provenance: explicit (creative direction).
• NFR-4 — Contrast. Text #E8F0F4 on #070B0E clears 15:1; on #101820 it clears 13:1. #5A6B75 is used only for labels on glass, never for body copy. Provenance: explicit (creative direction).
• NFR-5 — Accent discipline. #FF6B2C is used on under 8% of pixels so it always means danger. Provenance: explicit (creative direction).
• NFR-6 — Meaningful animation. Every glow, sweep, or flash maps to a game fact; decorative animation that carries no state meaning is excluded. Provenance: explicit (creative direction).
• NFR-7 — Anonymous access. No destination requires an account, sign-in, or identity. Provenance: required_inference (no accepted journey requires durable player-specific state).
• NFR-8 — No external dependency for play. The game is fully playable without any third-party service. Provenance: required_inference (no external service is accepted in the source).
• NFR-9 — Desktop-first, mobile-usable. The experience is designed desktop-first and remains fully usable and readable at 375px. Provenance: explicit (creative direction).

10. Tech Stack

• Frontend: React (web), single-page application with three routes — Landing, Game, Results.
• 3D / hero rendering: WebGL via React Three Fiber (with Drei helpers) for the Landing hero subject, with a CSS/SVG fallback when WebGL is unavailable.
• Styling: CSS with custom properties for the color, type, and spacing tokens defined in Section 6; clamp() for fluid type; cubic-bezier(0.16,1,0.3,1) for panel entry.
• Fonts: Space Grotesk (headings), IBM Plex Sans (body), IBM Plex Mono (tabular numerals), self-hosted.
• State: client-side run state only; no server persistence in the current horizon.
• Build and delivery: static build served as a first-party web application.

No backend, database, container orchestration, or Kubernetes is required by any accepted requirement in the current horizon.

11. Assumptions and Constraints

Assumptions

• A-1 [Default — not specified by user] The game is single-player and session-scoped; no run state survives a page reload.
• A-2 [Default — not specified by user] The game is delivered as a web application; no native desktop or mobile build is required.
• A-3 [Default — not specified by user] Audio is not required by any accepted requirement and is therefore out of current scope.
• A-4 [Default — not specified by user] The single playable mission is named "NIGHTFALL" for presentation purposes; the name is display content, not a product capability.
• A-5 [Default — not specified by user] The game is playable with mouse and keyboard; touch input is supported only to the extent the responsive layout allows.

Constraints

• C-1 No account creation, sign-in, profile, or identity management is implemented.
• C-2 No multiplayer, matchmaking, chat, or social features are implemented.
• C-3 No leaderboards, achievements, or persistent progression are implemented.
• C-4 No monetization, store, or in-app purchase surface is implemented.
• C-5 No photographic stock imagery of soldiers, flags, swastikas, or real historical atrocity imagery is used; the war is rendered as abstract instrumentation.
• C-6 No blue-indigo accent (#2563EB, #4F46E5, #7C3AED and neighbours) and no light or near-white ground is used.
• C-7 Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body.
• C-8 No centred headline + subtext + button hero, gradient-blob backdrop, or grid of identical hover-lift cards is used.
• C-9 No rounded soft cards with drop shadows, pastel palettes, playful bounce easing, or springy micro-interactions are used.
• C-10 No readable label, number, or control is clipped, overlapped, or pushed off-screen at 375px, 768px, or 1280px.

12. Glossary

• Command strip — the bottom HUD bar in Game carrying the primary action on the left and the self-typing radio log on the right.
• Corner-tick panel — a HUD panel drawn with four 12px L-shaped cyan strokes at its corners and a 25%-opacity hairline edge, instead of a full border or a rounded card.
• Digit-roll — the 120ms animation applied to a tabular numeral when its value changes.
• Friendly blip — a cyan radar marker representing a friendly unit.
• Hostile blip — an orange radar marker representing an enemy unit.
• Instrument rail — the left HUD column in Game containing the radar scope, ammo dial, and squad status.
• Intel column — the right HUD column in Game containing objectives and the radio log.
• Mission — the current playable scenario, with an objective set and a running clock.
• Mission clock — the tabular-numeral timer counting elapsed mission time.
• Operations table — the Landing's full-viewport wireframe topographic map, tilted 12 degrees, that serves as the hero scene.
• Outcome — the resolved end state of a run: win, loss, completion, or abandoned.
• Radio log — the self-typing text feed at 22 characters per second that records in-game events.
• Run — one continuous play session from the Landing CTA to Results.
• Scanline wipe — the 1px horizontal wipe that crosses an affected panel or the command strip on a state change.
• Squad status — the aggregate and per-unit status readout of friendly units.
• Tabular figures — monospaced numerals that do not shift width as digits change, used for all instrument readouts.