System Requirements Document for duo-games

1. Introduction

duo-games is an offline, two-player game website. It exists so that two people sharing a single device — friends, siblings, couples, coworkers on a break — can sit down and start playing within seconds, with no account, no setup, and no network connection required for gameplay. A single player can also play against a bot at one of three difficulty levels: easy, medium, or hard.

The product intent is deliberately narrow and sharp: a small collection of clean, simple, instantly legible two-player games that are fun, addicting, hooking, and catchy. "Fun" here means instant comprehension — a second player must be able to sit down and understand the board, whose turn it is, and what to do without any onboarding. The audience is casual players of any age, playing locally on one shared screen.

The experience is built around a warm, arcade-cabinet visual language: chunky pixel geometry, crisp colour on a light paper ground, legible symbols with personality, and a strict colour rule where Player One is always red and Player Two is always blue.

2. System Overview

duo-games is delivered as a first-party web application whose gameplay runs entirely locally. There is no server round-trip, no matchmaking service, and no network dependency for any accepted gameplay journey. The application is bundled so that the game catalogue, the bot opponents, and the game session logic are all available locally.

Actors

• Player — the person who opens the site, browses the game catalogue, picks a game, picks a difficulty, picks an opponent, and plays. The Player is also Player One in every session.
• Local Second Player / Friend — the second human who joins the same device session as Player Two. This person needs no account and no separate setup; they simply take the opposing side on the same screen.
• Bot opponent — a locally available non-human opponent that plays at the selected difficulty. This is a system actor, not a persona.

Accepted behavior

The site presents a public entry surface, a browsable game catalogue, a difficulty selection, an opponent selection (a friend or a bot), the game session itself, and a results surface that supports replaying or starting a new game. Every one of these surfaces is anonymously reachable — no identity, account, or sign-in is required anywhere in the product.

Ownership

All accepted human-facing behavior is owned by first-party application pages. There are no provider-owned surfaces, no external destinations, and no headless delivery. Bot behavior is a local system process that supports the Game page; it is never the sole owner of a human-facing capability.

Narrow exclusions

duo-games does not include online multiplayer, matchmaking, accounts, profiles, leaderboards, chat, social features, or any network-dependent gameplay. It does not include single-player-only games. It does not include more than two players in a session.

2a. Product Interpretation and Delivery Boundary

Delivery. duo-games is a website that works offline. The game catalogue, the bot opponents, and all session logic are bundled with the application so that a player can open the site and play a complete match with no network connection. Nothing in the accepted gameplay lifecycle depends on a remote service.

Access. Every surface in duo-games is public and anonymous. The Player does not create an account, does not sign in, and does not own any durable private state that must be resumed across sessions. The Local Second Player / Friend joins the same device session directly, with no account and no separate setup. Because no accepted journey requires application-owned identity, no identity establishment or verification lifecycle is introduced.

Current vs. future. Everything described in this document is current. There is no accepted future horizon in the authoritative requirement thread; no future features are planned or promised here.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state. The public entry surface. Presents the duo-games wordmark, a one-line statement of what the site is (offline, two players, one device), and a live self-playing demonstration board that shows the game language before the Player commits to anything. No identity state; always anonymously reachable.
• Primary actions. "PLAY NOW" — the arcade-key chip button that takes the Player into the game catalogue.
• Supporting actions. None required. The hero is a single-commitment surface.
• Domain entities. Game catalogue (as a preview), demonstration board state, player identity colours (Player One red, Player Two blue).
• Component responsibilities.
  • Hero wordmark block — "DUO GAMES" in Silkscreen caps, stacked across three lines, one line in Player One red, filling the left column.
  • Play chip — 56px tall, 2px ink border, hard 4px offset ink shadow, collapsing and translating 4px down on press.
  • Tracked descriptor line — "OFFLINE · 2 PLAYERS · ONE DEVICE" in 11px uppercase tracked micro-label type.
  • Live demo board card — a white card holding a self-playing 7×6 pixel board with red and blue discs dropping on a stepped 900ms loop, a tabular-numeral score rail, and two facing pixel avatars.
  • Decorative pixel clusters — margin decoration cropped by the viewport edge, never overlapping type or controls.
• States.
  • Loading — the demo board begins its loop immediately; no blocking load state is required.
  • Empty — not applicable; the hero always has content.
  • Success — the Player presses PLAY NOW and arrives at the Games page.
  • Error / recovery — not applicable; there is no network call and no failure mode on this surface.
  • Reduced motion — the demo board renders as a static composed frame and the optional "PRESS START" blink becomes a static outlined chip.

Games

• Information and state. The browsable catalogue of available two-player games. Each game is presented as a tile with a pixel icon, a one-line rule, and a "2P / BOT" chip pair indicating that both opponent modes are supported.
• Primary actions. Select a game tile to proceed to difficulty selection for that game.
• Supporting actions. Return to the Landing surface.
• Domain entities. Game (name, pixel icon, one-line rule, supported opponent modes).
• Component responsibilities.
  • Game tile grid — 1:1 tiles, 3-across on desktop, becoming a 2-across scroll-snap row at 375px.
  • Pixel game icon — 96px, drawn on a 32px grid (for example a tic-tac-toe hash, a connect-four disc, a dots grid, a memory card, a pong paddle).
  • One-line rule — a single sentence describing how the game is played.
  • "2P / BOT" chip pair — square 2px-radius chips indicating supported opponent modes.
  • Tile hover — shifts the tile's hard offset shadow 2px and nothing else.
• States.
  • Loading — the catalogue is bundled locally; tiles render without a network fetch.
  • Empty — not applicable; the catalogue is a fixed bundled set.
  • Success — the Player selects a tile and arrives at the Difficulty page for that game.
  • Error / recovery — not applicable; there is no remote dependency.
  • Reduced motion — hover shadow shift becomes an instant swap.

Difficulty

• Information and state. Difficulty selection for the currently selected game. Three large rows — EASY, MEDIUM, HARD — each with a 5-pip pixel scale and a one-sentence description of the bot at that level.
• Primary actions. Select a difficulty row to proceed to opponent selection.
• Supporting actions. Return to the Games page to change the selected game.
• Domain entities. Difficulty level (easy, medium, hard), pip scale value (EASY 1 pip, MEDIUM 3 pips, HARD 5 pips), bot description.
• Component responsibilities.
  • Difficulty rows — three full-width rows, each a selectable control.
  • 5-pip pixel scale — square 2px-radius pips showing the level's intensity.
  • Bot description line — one sentence describing how the bot plays at that level.
  • Selected-game context — the currently selected game is shown so the Player knows what they are configuring.
• States.
  • Loading — not applicable; difficulty options are fixed.
  • Empty — not applicable.
  • Success — the Player selects a difficulty and arrives at the Opponent page.
  • Error / recovery — not applicable.
  • Reduced motion — selection feedback is an instant swap.

Opponent

• Information and state. Opponent selection for the configured session. A literal split: the left half is "A FRIEND" in Player One red, the right half is "A BOT" in reward yellow. Each half is a full-height button.
• Primary actions. Choose "A FRIEND" to start a local two-human session, or choose "A BOT" to start a session against the bot at the selected difficulty.
• Supporting actions. Return to the Difficulty page to change the difficulty.
• Domain entities. Opponent mode (friend, bot), selected game, selected difficulty.
• Component responsibilities.
  • Friend half — full-height button, Player One red, labelled "A FRIEND".
  • Bot half — full-height button, reward yellow, labelled "A BOT".
  • Session summary — the selected game and difficulty are shown so the Player can confirm the configuration before starting.
  • Local Second Player hand-off cue — when "A FRIEND" is chosen, the surface makes clear that the second player takes the opposing side on this same device, with no account and no separate setup.
• States.
  • Loading — not applicable.
  • Empty — not applicable.
  • Success — the Player chooses an opponent and arrives at the Game page with the session configured.
  • Error / recovery — not applicable.
  • Reduced motion — selection feedback is an instant swap.

Game

• Information and state. The live offline two-player session. A centred square board capped at min(92vw, 640px), with Player One's panel above and Player Two's panel below, score rails on the outer edges, and a persistent "REMATCH" chip. The active player's panel is visually distinguished, and the selected difficulty is echoed as a chip in the game header.
• Primary actions. Make a move on the board when it is your turn.
• Supporting actions. "REMATCH" to restart the current game; leave the session to return to the catalogue.
• Domain entities. Board state, turn state, move count, score (Player One vs Player Two), selected game, selected difficulty, opponent mode, player identity colours (Player One red, Player Two blue).
• Component responsibilities.
  • Board — the play surface, sized and centred per the layout rules.
  • Player One panel — above the board, red identity, shows Player One's score and active state.
  • Player Two panel — below the board, blue identity, shows Player Two's score and active state.
  • Score rails — outer edges, tabular numerals.
  • Turn indicator — a small pixel avatar pair (red and blue) showing whose turn it is.
  • Difficulty chip — echoes the selected level (EASY 1 pip, MEDIUM 3, HARD 5) so the level is readable mid-match.
  • "REMATCH" chip — persistent, restarts the current game.
  • Bot opponent — a local system process that produces moves for Player Two when the bot mode is selected, at the selected difficulty.
  • Local Second Player input — when the friend mode is selected, the second human provides Player Two's moves directly on the same device.
• States.
  • Loading — the session initialises locally; no network fetch.
  • Empty — the board renders in its starting configuration.
  • Success — a move is applied, the turn hands off, and the active-player panel flips with a 2-frame blink.
  • Win — a 6-frame pixel confetti of 8px squares fires from the board edge, and the session transitions to the Results surface.
  • Error / recovery — not applicable; there is no remote dependency and no failure mode in the accepted lifecycle.
  • Reduced motion — the turn hand-off blink becomes an instant swap and the win confetti becomes a static composed state.

Results

• Information and state. The completed session summary. A stepped pixel banner with the win count as the largest number on the page, plus the final score and the session configuration (game, difficulty, opponent mode).
• Primary actions. "REMATCH" to replay the same configuration; "NEW GAME" to return to the catalogue and start a different session.
• Supporting actions. Return to the Landing surface.
• Domain entities. Final score (Player One vs Player Two), win count, session configuration (game, difficulty, opponent mode), winner identity.
• Component responsibilities.
  • Stepped pixel banner — the win banner with pixel-corner trims.
  • Win count — the largest number on the page, tabular numerals.
  • Final score line — Player One red vs Player Two blue, tabular numerals.
  • Session configuration summary — game, difficulty chip, opponent mode.
  • "REMATCH" and "NEW GAME" controls — arcade-key buttons.
  • Decorative pixel clusters — margin decoration cropped by the viewport edge, never overlapping type or controls.
• States.
  • Loading — not applicable.
  • Empty — not applicable; the surface only appears after a completed session.
  • Success — the Player chooses REMATCH or NEW GAME and continues.
  • Error / recovery — not applicable.
  • Reduced motion — the banner renders as a static composed state.

3. Functional Requirements

FR-1. Build a game website. As a Player, I should be able to open duo-games as a website and immediately understand that it is a place to play games.

• Provenance: explicit
• Trigger / input: The Player opens the site.
• Observable result: The Landing surface renders with the duo-games wordmark, the offline/two-player/one-device descriptor, and a live demonstration board.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable; no network dependency.
• Continuation: The Player can press PLAY NOW to enter the catalogue.

FR-2. Games must be playable offline. As a Player, I should be able to play a complete match with no network connection.

• Provenance: explicit
• Trigger / input: The Player starts and plays a session.
• Observable result: The catalogue, the bot opponents, and all session logic are available locally; no gameplay step performs a network request.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable; there is no remote dependency to fail.
• Continuation: The Player can complete a full match and reach the Results surface offline.

FR-3. Support 2-player games. As a Player, I should be able to play games that are designed for exactly two players.

• Provenance: explicit
• Trigger / input: The Player selects a game from the catalogue.
• Observable result: The selected game is a two-player game with Player One and Player Two sides.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable.
• Continuation: The Player proceeds to difficulty and opponent selection.

FR-4. Support playing with a friend (local second human player). As a Player, I should be able to choose "A FRIEND" and have a second human join the same device session as Player Two.

• Provenance: explicit
• Trigger / input: The Player selects "A FRIEND" on the Opponent surface.
• Observable result: The Game surface starts with Player One and Player Two both controlled by humans on the same device; Player Two's panel is present and the turn indicator shows whose turn it is.
• Access state: Anonymous; the Local Second Player / Friend needs no account and no separate setup.
• Failure / recovery: Not applicable.
• Continuation: The two players alternate turns until the session completes and the Results surface appears.

FR-5. Support playing against a bot. As a Player, I should be able to choose "A BOT" and play against a locally available bot opponent.

• Provenance: explicit
• Trigger / input: The Player selects "A BOT" on the Opponent surface.
• Observable result: The Game surface starts with Player One controlled by the human and Player Two controlled by the local bot; the bot produces moves on its turns.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable; the bot runs locally.
• Continuation: The session completes and the Results surface appears.

FR-6. Offer difficulty levels: easy, medium, and hard. As a Player, I should be able to choose easy, medium, or hard difficulty for the selected game.

• Provenance: explicit
• Trigger / input: The Player selects a difficulty row on the Difficulty surface.
• Observable result: The chosen difficulty is recorded for the session and is echoed as a chip in the Game header.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable.
• Continuation: The Player proceeds to opponent selection with the difficulty applied.

FR-7. Design should be clean, simple, fun, addicting, hooking, catchy, and super fun. As a Player, I should experience an interface that is legible in three seconds, with chunky controls, crisp colour, and a playful arcade register that makes me want one more round.

• Provenance: explicit
• Trigger / input: The Player interacts with any surface.
• Observable result: Every surface uses the pixel-geometry design language, the Player One red / Player Two blue identity rule, the arcade-key button treatment, and the restrained stepped motion described in the Visuals and Interaction sections.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable.
• Continuation: The Player can move fluidly between surfaces without onboarding.

FR-8. The game must be bundled or otherwise available locally so gameplay has no network dependency. As a Player, I should be able to play without the site reaching out to a server.

• Provenance: required_inference
• Trigger / input: The Player loads and plays the site.
• Observable result: The catalogue, bot logic, and session logic are bundled with the application and execute locally.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable.
• Continuation: All accepted journeys remain executable offline.

FR-9. A local second player must be able to join the same device session without an account. As a Local Second Player / Friend, I should be able to sit down at the same device and take Player Two's side without creating an account or performing any separate setup.

• Provenance: required_inference
• Trigger / input: The Player selects "A FRIEND" on the Opponent surface.
• Observable result: Player Two's panel is active on the Game surface and the Local Second Player / Friend can make Player Two's moves directly.
• Access state: Anonymous; no account, no sign-in, no separate setup.
• Failure / recovery: Not applicable.
• Continuation: The Local Second Player / Friend plays the full match and sees the Results surface.

FR-10. Bot opponents must be available locally for the selected difficulty. As a Player, I should be able to play against a bot that behaves according to the difficulty I selected, without any network call.

• Provenance: required_inference
• Trigger / input: The Player selects "A BOT" on the Opponent surface with a chosen difficulty.
• Observable result: The local bot produces Player Two's moves at the selected difficulty, and the difficulty chip in the Game header reflects the selection.
• Access state: Anonymous; no identity required.
• Failure / recovery: Not applicable; the bot runs locally.
• Continuation: The session completes and the Results surface appears.

4. User Personas

Player

Product context. The Player is the person who opens duo-games. They may be alone and looking for a quick match against a bot, or they may be sitting next to someone they want to play with. They are a casual player of any age, and they arrive with no patience for onboarding, menus, or setup. They want to be in a game within seconds.

Primary goal. Start a clean, simple, fun, addicting two-player session quickly — either against a friend on the same device or against a bot at easy, medium, or hard difficulty — and be able to replay it immediately.

Distinct accepted responsibilities.

• Opens the site and reads the entry surface.
• Browses the game catalogue and selects a game.
• Selects a difficulty (easy, medium, or hard) for the selected game.
• Chooses an opponent: a friend or a bot.
• Plays as Player One in the session.
• Decides whether to rematch or start a new game after the session completes.

Relevant inputs or decisions. Which game to play; which difficulty to play at; whether to play with a friend or against a bot; whether to rematch or start a new game.

Interactions with other accepted participants. The Player initiates the session and, when "A FRIEND" is chosen, hands the device to the Local Second Player / Friend who takes Player Two's side. When "A BOT" is chosen, the Player's opponent is the local bot rather than another human.

Observable success. The Player reaches the Game surface with the chosen game, difficulty, and opponent, plays a full match, sees the Results surface with the win count and final score, and can immediately rematch or start a new game.

What makes this role's work different. The Player is the session initiator and always occupies Player One. They own every configuration decision — game, difficulty, opponent — and they own the continuation decision after the match. Their work is about getting into a game fast and keeping the "one more round" loop going.

Local Second Player / Friend

Product context. The Local Second Player / Friend is the second human in a two-player session. They are physically present at the same device and join the session that the Player has already configured. They did not open the site, did not browse the catalogue, and did not choose the difficulty — they simply sit down and play.

Primary goal. Play a full match as Player Two against the Player, on the same device, without needing their own account or any separate setup.

Distinct accepted responsibilities.

• Joins the same device session as Player Two when the Player selects "A FRIEND".
• Reads the board and the turn indicator to know when it is their turn.
• Makes Player Two's moves directly on the shared device.
• Sees the outcome of the match on the Results surface.

Relevant inputs or decisions. Which move to make on their turn; whether to continue playing when the Player chooses to rematch.

Interactions with other accepted participants. The Local Second Player / Friend plays directly against the Player, alternating turns on the same device. They depend on the Player having configured the session, but they take their own independent actions once the session begins.

Observable success. They are able to take Player Two's side immediately, play a complete match, and see the result — all without creating an account or performing any separate setup.

What makes this role's work different. The Local Second Player / Friend is a participant, not an initiator. Their work is entirely inside the Game surface: reading the board, reading whose turn it is, and making moves. They never configure the session, never browse the catalogue, and never choose a difficulty. Their experience must be legible in three seconds because they arrive mid-flow with no onboarding.

5. Core User Flows

Flow A — Player starts a session against a bot

1. The Player opens duo-games. The Landing surface renders with the "DUO GAMES" wordmark, the "OFFLINE · 2 PLAYERS · ONE DEVICE" descriptor, and the live self-playing demonstration board.
2. The Player presses the PLAY NOW arcade-key chip. The button translates 4px down and its offset shadow collapses on press.
3. The Games surface appears with the bundled catalogue of two-player game tiles, each showing a pixel icon, a one-line rule, and a "2P / BOT" chip pair.
4. The Player selects a game tile. The tile's hover shadow shift is the only hover effect.
5. The Difficulty surface appears for the selected game, showing three rows — EASY (1 pip), MEDIUM (3 pips), HARD (5 pips) — each with a one-sentence bot description.
6. The Player selects a difficulty row. The selection is recorded for the session.
7. The Opponent surface appears as a literal split: left half "A FRIEND" in Player One red, right half "A BOT" in reward yellow.
8. The Player selects A BOT. The session is configured with the selected game, difficulty, and bot opponent.
9. The Game surface appears with the centred square board, Player One's panel above, Player Two's panel below, score rails on the outer edges, the difficulty chip in the header, and the persistent "REMATCH" chip.
10. The Player makes Player One's moves. On Player Two's turns, the local bot produces moves at the selected difficulty. Each turn hand-off flips the active-player panel with a 2-frame blink.
11. When the session completes, a 6-frame pixel confetti of 8px squares fires from the board edge and the Results surface appears with the stepped pixel banner, the win count as the largest number on the page, the final score, and the session configuration.
12. The Player chooses REMATCH to replay the same configuration, or NEW GAME to return to the catalogue. Either way, the loop continues.

Failure / recovery: Not applicable. The session runs entirely locally with no network dependency, so there is no failure mode in the accepted lifecycle.

Flow B — Player starts a session with a friend, and the friend joins

1. The Player opens duo-games and presses PLAY NOW on the Landing surface.
2. The Player selects a game tile on the Games surface.
3. The Player selects a difficulty row on the Difficulty surface.
4. On the Opponent surface, the Player selects A FRIEND. The surface makes clear that the second player takes the opposing side on this same device, with no account and no separate setup.
5. The Game surface appears with Player One's panel above the board and Player Two's panel below it. Player One is red, Player Two is blue.
6. The Local Second Player / Friend sits down at the same device. They need no account and no separate setup — Player Two's side is already active and waiting.
7. The Local Second Player / Friend reads the board and the turn indicator (the small red and blue pixel avatar pair) to know when it is their turn, and makes Player Two's moves directly on the shared device.
8. The Player and the Local Second Player / Friend alternate turns. Each turn hand-off flips the active-player panel with a 2-frame blink, so both players can always see whose turn it is.
9. When the session completes, the pixel confetti fires and the Results surface appears. Both players see the stepped pixel banner, the win count, the final score, and the session configuration.
10. The Player chooses REMATCH to play the same configuration again, or NEW GAME to return to the catalogue. The Local Second Player / Friend continues playing as Player Two if the Player rematches.

Failure / recovery: Not applicable. The session runs entirely locally with no network dependency, so there is no failure mode in the accepted lifecycle.

Flow C — Player changes the configuration before starting

1. On the Difficulty surface, the Player decides the selected game is not the one they want and returns to the Games surface.
2. The Player selects a different game tile.
3. The Difficulty surface appears for the newly selected game, and the Player selects a difficulty row.
4. On the Opponent surface, the Player changes their mind about the opponent and selects the other option.
5. The Game surface appears with the updated configuration, and the session proceeds as in Flow A or Flow B.

Failure / recovery: Not applicable. Configuration changes are local and immediate.

Flow D — Player replays after a completed session

1. The Results surface shows the stepped pixel banner, the win count as the largest number on the page, the final score, and the session configuration.
2. The Player presses REMATCH. The Game surface restarts with the same game, difficulty, and opponent.
3. The session proceeds as in Flow A or Flow B, and the Results surface appears again when it completes.
4. Alternatively, the Player presses NEW GAME and returns to the Games surface to start a different session.

Failure / recovery: Not applicable.

6. Visuals, Colors, and Theme

The visual system follows the supplied creative direction: charming clarity, pixel-perfect, after Susan Kare. The muse is Susan Kare, and the headline idea is that fun here means instant comprehension, not decoration — small legible symbols with personality, grids you can feel, chunky controls, and crisp colour on a light ground.

Colour tokens (light mode)

No blue or indigo in the brand layer. No gradients anywhere.

Typography

• Headings: Silkscreen, caps, 700, tight 0.02em tracking. Used for game titles and the hero wordmark as a graphic mass rather than a paragraph voice.
• Body: Space Grotesk 400/500/700, with tabular numerals for scores, timers, and move counts.
• Micro-labels: Space Grotesk 700, 11px, 0.14em tracking, uppercase — for example PLAYER 1, EASY, BOT.
• Scale: 1.25 modular — 13 / 16 / 20 / 25 / 32 / 40 / 56 / 72, with display steps as clamp. Hero wordmark clamp(56px, 13vw, 128px); game-tile titles clamp(24px, 5vw, 40px); body 16px mobile / 18px desktop; labels 11–13px.

Shape language

Chunky pixel geometry: 4px and 8px steps only, 2px solid ink borders on every card and button, 8px radii on cards, square 2px-radius chips for tags and pips, and stepped "pixel-corner" trims on hero blocks and the win banner. Buttons are 56px tall with a hard 4px offset shadow in ink; pressing translates the button 4px down and removes the shadow, like a physical arcade key. No pill buttons, no blurred glass, no soft ambient shadows.

Layout

A 12-column grid on a warm paper ground with a 2px ink rule under the header and between sections.

• Landing: hero wordmark bleeding left, a live 2-up demo board on the right, then a 3-across grid of game tiles that becomes a 2-across scroll-snap row at 375px.
• Games: tiles are 1:1 with a 96px pixel icon, a one-line rule, and a "2P / BOT" chip pair.
• Difficulty: three big rows (EASY / MEDIUM / HARD), each with a 5-pip scale and a one-sentence bot description.
• Opponent: a literal split — left half "A FRIEND" (red), right half "A BOT" (yellow), each half a full-height button.
• Game: a centred square board capped at min(92vw, 640px) with Player One's panel above and Player Two's below, score rails on the outer edges, and a persistent "REMATCH" chip.
• Results: a stepped pixel banner with the win count as the largest number on the page.

Imagery

Everything is drawn, nothing is photographed: 32px-grid pixel icons for each game (tic-tac-toe hash, connect-four disc, dots grid, memory card, pong paddle), 8px-square confetti, chunky arrow and chevron glyphs, and a small pixel avatar pair (red and blue) that appears in the turn indicator. Decorative pixel clusters sit in the margins of the hero and results banner, cropped by the viewport edge, and never overlap type or controls.

Readability rule

Headlines, wordmarks, labels, numbers, cards' 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. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The public entry is a two-tone arcade poster, not a centred SaaS hero.

Left 60%. The wordmark "DUO GAMES" in Silkscreen caps at clamp(56px, 13vw, 128px), set in three stacked lines filling the column edge to edge, with the second line in Player One red #E5433C and the third in ink #171717. Beneath it, a single 56px chip button "PLAY NOW" with a hard ink offset shadow, and an 11px tracked line reading "OFFLINE · 2 PLAYERS · ONE DEVICE".

Right 40%. A white card holding a live, self-playing 7×6 pixel board — red and blue discs dropping on a 900ms loop with a stepped tick, a score rail above it reading "P1 3 — 2 P2" in tabular numerals, and two pixel avatars facing each other. The card is rotated 0deg on mobile (stacked under the wordmark, board capped at min(92vw, 420px)) and sits flush to the right viewport edge on desktop, bleeding 24px off-screen so the composition is asymmetric.

Ground. Warm paper #F4EFE3 with a faint 8px pixel grid at 4% ink. The only saturated masses are the red wordmark line and the board discs.

The concept recomposes only accepted content, states, and controls: the wordmark, the descriptor line, the PLAY NOW control, the demonstration board, the score rail, and the pixel avatars. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The live self-playing 7×6 pixel board in the white card on the right, with red and blue discs dropping on a stepped 900ms loop, a tabular score rail above it, and two facing pixel avatars.
• Input → transformation → outcome thesis. The page loads → the demo board begins its stepped 900ms drop loop, discs landing one at a time and the score rail ticking in tabular numerals → the Player sees the game language in motion before committing, and presses PLAY NOW to enter the catalogue.
• Motion vocabulary. Restrained and frame-based: 80–140ms stepped transitions with steps(4) easing so state changes tick rather than glide. The demo board drops discs on a stepped 900ms loop. The optional "PRESS START" blink on the hero CTA is a single-frame blink. No parallax, no float, no continuous loops beyond the demo board and the optional blink.
• Composed first frame. The wordmark stacked across three lines on the left, the PLAY NOW chip beneath it, the descriptor line under that, and the white demo-board card on the right with a disc mid-drop and the score rail reading "P1 3 — 2 P2".
• Reduced-motion state. All steps become instant swaps and the blink becomes a static outlined chip. The demo board renders as a static composed frame with a disc mid-drop and the score rail visible.

9. Non-Functional Requirements

NFR-1. Offline gameplay. Gameplay must have no network dependency. The catalogue, bot opponents, and session logic are bundled or otherwise available locally. (Provenance: explicit — "make it an offline game".)

NFR-2. Two-player capability. Every game in the catalogue must be two-player capable, with Player One and Player Two sides. (Provenance: explicit — "make it 2 player games".)

NFR-3. Difficulty selection. Difficulty must be selectable among easy, medium, and hard. (Provenance: explicit — "easy medium hard".)

NFR-4. Opponent selection. The opponent must be either a friend (local second player) or a bot. (Provenance: explicit — "play with a friend or with a bot".)

NFR-5. Legibility in three seconds. Every surface must be readable at a glance so a second player can sit down and play with zero onboarding. (Provenance: explicit — "clean simple fun addicting hooking catchy super fun".)

NFR-6. Responsive readability. Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. (Provenance: explicit — creative direction readability rule.)

NFR-7. Reduced motion. With prefers-reduced-motion, all stepped transitions become instant swaps, the "PRESS START" blink becomes a static outlined chip, and the demo board renders as a static composed frame. (Provenance: explicit — creative direction motion rule.)

NFR-8. No identity requirement. No surface in duo-games requires an account, sign-in, or identity establishment. (Provenance: required_inference — no accepted journey requires application-owned identity.)

NFR-9. No network-dependent features. No accepted capability may depend on a remote service, matchmaking, or online multiplayer. (Provenance: explicit — "make it an offline game".)

10. Tech Stack

• Frontend: React, delivered as a bundled web application. The game catalogue, bot logic, and session logic run entirely client-side so that gameplay has no network dependency.
• Styling: CSS with the token system described in Section 6 — Silkscreen and Space Grotesk typefaces, the specified hex palette, 2px ink borders, 4px/8px pixel geometry, and hard offset shadows.
• Bot opponents: Local client-side logic, parameterised by the selected difficulty (easy, medium, hard).
• Storage: No persistent storage is required. No accepted journey requires durable state across sessions, and no identity is established.
• Backend: None required for accepted gameplay. No server round-trip, matchmaking service, or remote API is part of any accepted journey.
• Deployment: Static hosting of the bundled application is sufficient, since gameplay is fully local.

[Default — not specified by user] for the specific build tooling, bundler, and static host; these are implementation details that do not affect accepted behavior.

11. Assumptions and Constraints

Assumptions

• [Assumption] The game catalogue is a fixed, bundled set of two-player games. The authoritative thread does not name specific games, so the catalogue contents are left to implementation within the two-player, friend-or-bot, easy/medium/hard constraints.
• [Assumption] "Offline" means no network dependency for gameplay. The site itself may be loaded once and then played without a connection; the accepted constraint is that gameplay has no network dependency.
• [Assumption] The Local Second Player / Friend is physically present at the same device. The authoritative thread specifies "play with a friend" in the context of an offline, single-device product.
• [Assumption] No accounts, profiles, leaderboards, chat, or social features are part of the product, because no accepted journey requires them and no identity is established.

Constraints

• Games must work offline (no network dependency for gameplay). (explicit)
• Games must be 2-player capable. (explicit)
• Difficulty must be selectable among easy, medium, and hard. (explicit)
• Opponent must be either a friend (local second player) or a bot. (explicit)
• The design must be clean, simple, fun, addicting, hooking, catchy, and super fun. (explicit)
• The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit — creative direction)
• No blue or indigo in the brand layer; no gradients anywhere. (explicit — creative direction)
• Player One is always #E5433C; Player Two is always #2F6FB5 and is used only inside the game/state layer. (explicit — creative direction)

12. Glossary

• duo-games — The offline, two-player game website described in this document.
• Player — The accepted persona who opens the site, configures a session, and plays as Player One.
• Local Second Player / Friend — The accepted persona who joins the same device session as Player Two, with no account and no separate setup.
• Bot — A locally available non-human opponent that plays at the selected difficulty. A system actor, not a persona.
• Session — A single configured match: one game, one difficulty, one opponent mode, played to completion.
• Difficulty — One of easy, medium, or hard, selected before the session begins and echoed as a chip in the Game header.
• Opponent mode — Either "A FRIEND" (local second human player) or "A BOT" (local bot opponent).
• Player One — The human who initiated the session; always red #E5433C.
• Player Two — The opposing side; always blue #2F6FB5. Controlled by the Local Second Player / Friend or by the bot.
• Arcade-key button — A 56px-tall button with a 2px ink border and a hard 4px offset ink shadow that collapses and translates the button 4px down on press.
• Pixel icon — A drawn icon on a 32px grid, used for game tiles and UI glyphs. Emoji are not used as the icon system.
• Pip scale — The 5-pip pixel scale showing difficulty intensity: EASY 1 pip, MEDIUM 3 pips, HARD 5 pips.
• Rematch — Restarting the current session with the same game, difficulty, and opponent mode.