System Requirements Document for bedwars-multiplayer

1. Introduction

bedwars-multiplayer is a high-performance, multiplayer, web-based Bedwars game modeled exactly after the core mechanics of Minecraft Bedwars. It is built for smooth 60FPS browser performance and "zero-lag" server state syncing, using an authoritative server-client architecture over WebSockets with delta compression and client-side interpolation/prediction.

The product is a competitive voxel PvP experience: players enter a lobby, are automatically grouped into teams (Solo, Doubles, or 4v4v4v4 across Red, Blue, Green, and Yellow), are teleported to team islands when the lobby fills, and fight to break enemy beds while defending their own. It adds a server-side anti-cheat validation suite (movement, hit-register, and interaction verification) and a persistent global leaderboard and player progression system backed by Redis Sorted Sets and long-term persistent storage.

The audience is teens and young adults who grew up on Minecraft Bedwars, streamers, and drop-culture players who expect a streetwear-confident, kinetic, skill-flexing competitive game — not a corporate SaaS dashboard.

2. System Overview

bedwars-multiplayer delivers a browser-played, server-authoritative multiplayer Bedwars game. The frontend renders the game world with React or Next.js paired with HTML5 Canvas or lightweight Three.js WebGL block meshes, avoiding DOM-node lag. The backend is Node.js/TypeScript deployed in the managed Kubernetes namespace, holding short-term session state in memory or Redis for sub-millisecond game loop updates and long-term player records on the native persistent storage volume.

Actors. The active human personas are the Bedwars Player and the Leaderboard Viewer. The system also includes non-persona actors: the authoritative game server (Node.js/TypeScript), Redis (session state and leaderboard ZSET), the native persistent storage volume (long-term player records), and the automated security scanner (build-time gate).

Accepted behavior. Players establish a persistent profile, enter the lobby, are auto-grouped into teams, and are teleported to team islands when the lobby fills. In-match they collect spawned Iron/Gold/Diamond/Emerald, buy from the Item Shop NPC and Team Upgrade NPC, break enemy beds, fight with swords and knockback sticks, and respawn on a 5-second countdown while their bed is intact. The server validates movement, combat, and interaction packets. Persistent profiles log Wins, Kills, Beds Broken, Games Played, and Level/XP, and a Redis ZSET-driven global leaderboard shows the top 100 players filterable by Wins, Beds Broken, and Kills alongside a personal lifetime statistics overlay.

Exclusions. No adjacent account-management capabilities beyond self-service enrollment and returning verification; no team chat, friend lists, or social features; no cosmetic marketplace; no spectator mode; no mobile-native client.

Removed from scope

• None.

2a. Product Interpretation and Delivery Boundary

The product is delivered as a first-party web application. Anonymous visitors reach the Landing page, which explains the multiplayer web-based Bedwars game, its core mechanics, and who it is for. Because persistent player profiles, lifetime statistics, and match participation are application-owned durable state, players establish identity through Sign Up (self-service enrollment) and returning players verify through Login. The Lobby, Leaderboard, Match, Item Shop, and Team Upgrades surfaces require login.

The authoritative game server owns all match state: movement validation, combat resolution, block placement/breaking, resource spawning, bed state, respawn/elimination, and stat recording. Redis holds short-term session state and the leaderboard ZSET; the native persistent storage volume holds long-term player records. The frontend renders and predicts but never authoritatively decides outcomes.

Every agentic code pass runs through the automated security scanner to guarantee secure, unprotected API-free WebSocket routes. The Project Manager Agent breaks the work into a sprint plan covering UI/Canvas setup, WebSocket connection, Gameplay Logic, Anti-Cheat loop, and Leaderboard processing. These are build-time and delivery-time obligations, not player-facing product behavior.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous first impression. Oversized "BEDWARS" display headline in Anton, flush-left, with quotation marks in safety-orange and the wordmark bleeding past the right edge behind a diagonal hazard-stripe band. Isometric voxel bed render on a concrete-grey plinth with hard cast shadow and one orange rim light. Vertical stack of three rectangular mode cards ("SOLO", "DOUBLES", "4v4v4v4") each tagged with a small label and a team-colour chip row. Bottom-left hard rectangular "PLAY" CTA with 4px orange offset shadow and monospace player-count readout.
• Primary actions: Enter Sign Up; enter Login.
• Supporting actions: Read core mechanics summary; view mode cards.
• Domain entities: Mode (Solo, Doubles, 4v4v4v4); team colours (Red, Blue, Green, Yellow).
• Component responsibilities: Hero headline, hazard-stripe band, voxel bed render, mode cards, PLAY CTA, online-count readout.
• States: Loading (static render); empty (n/a); success (renders); error (fallback static layout); recovery (retry navigation).

Login

• Information/state: Returning verification form for players with existing persistent profiles.
• Primary actions: Submit credentials; verify identity.
• Supporting actions: Navigate to Sign Up; return to Landing.
• Domain entities: Player profile.
• Component responsibilities: Credential form, submit control, error display, link to Sign Up.
• States: Loading (submitting); empty (blank form); success (redirect to Lobby); error (invalid credentials message); recovery (retry).

Lobby

• Information/state: Full-bleed composition with oversized "BEDWARS" headline locked to the left edge, hazard-stripe band cutting diagonally across the top-right, mode-select cards stacked as overlapping label-and-tag arrangement. Shows current team assignment and lobby fill status. Hosts the Leaderboard menu entry.
• Primary actions: Join lobby; select mode (Solo, Doubles, 4v4v4v4); open Leaderboard.
• Supporting actions: View team assignment (Red, Blue, Green, Yellow); view lobby fill status.
• Domain entities: Lobby, Team, Mode, Player.
• Component responsibilities: Mode-select cards, team chip display, fill-status readout, Leaderboard menu entry, WebSocket connection indicator.
• States: Loading (connecting to authoritative server); empty (waiting for players); success (lobby filled, teleport to team islands); error (connection failure); recovery (reconnect).

Sign Up

• Information/state: Self-service enrollment form for new players establishing a persistent profile.
• Primary actions: Submit enrollment; create profile.
• Supporting actions: Navigate to Login; return to Landing.
• Domain entities: Player profile (Wins, Kills, Beds Broken, Games Played, Level/XP initialized).
• Component responsibilities: Enrollment form, submit control, error display, link to Login.
• States: Loading (submitting); empty (blank form); success (redirect to Lobby); error (validation or conflict message); recovery (retry).

Leaderboard

• Information/state: Single full-width table with tabular numerical ranks, rectangular filter tabs ("WINS" / "BEDS" / "KILLS"), and a personal-stats sticker panel that slides up from the bottom rotated -2deg with a visible tape strip. Shows top 100 players globally.
• Primary actions: Re-sort ranking by Wins, Beds Broken, or Kills; view personal lifetime statistics overlay.
• Supporting actions: Return to Lobby.
• Domain entities: Global ranking (top 100), Player profile stats.
• Component responsibilities: Ranking table, filter tabs, personal-stats sticker panel, Redis ZSET query display.
• States: Loading (fetching ZSET); empty (no rankings yet); success (table renders); error (fetch failure); recovery (retry).

Match

• Information/state: In-match play surface. Strict 3-zone HUD: left = team bed status column (Alive/Broken/Eliminated), centre = match timer + kill feed, right = inventory strip. Renders voxel world with modern web lighting, particle effects on block destruction, smooth camera transitions. Sound effects for block breaking, purchasing, bed destruction, and combat impacts.
• Primary actions: Move; break/place blocks; attack enemies with swords or knockback sticks; collect spawned resources; open Item Shop NPC; open Team Upgrade NPC; break enemy beds; respawn on 5-second countdown.
• Supporting actions: View kill feed; view match timer; view team bed status; view inventory.
• Domain entities: Match, Team, Bed, Resource spawner (Iron, Gold, Diamond, Emerald), Player inventory, Kill feed entry, Match timer.
• Component responsibilities: Canvas/WebGL renderer, HUD (bed status column, timer, kill feed, inventory strip), input handler, client-side prediction/interpolation, WebSocket client, sound system, particle system.
• States: Loading (joining match); empty (pre-match countdown); success (active play); error (disconnect); recovery (reconnect or elimination); bed-broken flash (300ms #FF5A00 at 12% opacity plus 2px screen shake).

Item Shop

• Information/state: Full-height right-side drawer with hazard-stripe header and 3-column item grid where each item is a label card. Opened from Item Shop NPC.
• Primary actions: Trade Iron/Gold for weapons, blocks (wool, wood, obsidian), tools (shears, pickaxes), and armor.
• Supporting actions: Close drawer; view currency balance.
• Domain entities: Shop item, Currency (Iron, Gold), Player inventory.
• Component responsibilities: Drawer container, hazard-stripe header, item label cards, purchase controls, currency display.
• States: Loading (opening); empty (insufficient currency); success (purchase confirmed, sound plays); error (purchase rejected); recovery (retry).

Team Upgrades

• Information/state: Full-height right-side drawer with hazard-stripe header and 3-column item grid. Opened from Team Upgrade NPC.
• Primary actions: Trade Diamonds for permanent team buffs: Sharpened Swords, Reinforced Armor, Haste, and Traps.
• Supporting actions: Close drawer; view Diamond balance; view active team buffs.
• Domain entities: Team upgrade, Currency (Diamond), Team buff state.
• Component responsibilities: Drawer container, hazard-stripe header, upgrade label cards, purchase controls, Diamond display, active-buff display.
• States: Loading (opening); empty (insufficient Diamonds); success (upgrade applied, sound plays); error (purchase rejected); recovery (retry).

3. Functional Requirements

FR-1 (explicit). As a Bedwars Player, I should play a multiplayer web-based Bedwars game modeled on the core mechanics of Minecraft Bedwars, rendered with React or Next.js plus HTML5 Canvas or lightweight Three.js WebGL block meshes.

• Trigger: Player opens the game in a browser.
• Observable result: The game renders with Canvas/WebGL, avoiding DOM-node lag.
• Access: Login required for Match; Landing is anonymous.
• Failure/recovery: Renderer failure shows a fallback and retry.
• Continuation: Player proceeds to Lobby.

FR-2 (explicit). As a Bedwars Player, I should experience an authoritative server-client architecture over WebSockets with delta compression and client-side interpolation/prediction for responsive movement, block-breaking, and combat.

• Trigger: Player connects and plays.
• Observable result: Movement, block-breaking, and combat feel responsive even on high-ping connections.
• Access: Login required.
• Failure/recovery: Disconnect shows reconnect state.
• Continuation: Player resumes play after reconnect.

FR-3 (explicit). As a Bedwars Player, I should have the backend run on Node.js/TypeScript deployed in the managed Kubernetes namespace, with short-term session state in memory or Redis for fast game-loop updates and long-term player records on the native persistent storage volume.

• Trigger: Server processes match and profile data.
• Observable result: Session state updates sub-millisecond; long-term records persist.
• Access: System process.
• Failure/recovery: Redis or storage failure surfaces an error state.
• Continuation: Server retries or degrades gracefully.

FR-4 (explicit). As a Bedwars Player, I should be automatically grouped into teams (Solo, Doubles, or 4v4v4v4 across Red, Blue, Green, and Yellow) and teleported to team islands when the lobby fills.

• Trigger: Player joins Lobby and lobby fills.
• Observable result: Player is assigned to a team and teleported to a team island.
• Access: Login required.
• Failure/recovery: Lobby fill failure keeps player waiting.
• Continuation: Match begins.

FR-5 (explicit). As a Bedwars Player, I should see timed resource spawners produce Iron and Gold at base islands and Diamond and Emerald at neutral middle/side islands.

• Trigger: Match timer advances.
• Observable result: Resources spawn at the correct islands on schedule.
• Access: Login required.
• Failure/recovery: Spawner failure is logged and retried.
• Continuation: Player collects resources.

FR-6 (explicit). As a Bedwars Player, I should open an Item Shop NPC interactive visual menu where I trade Iron/Gold for weapons, blocks (wool, wood, obsidian), tools (shears, pickaxes), and armor.

• Trigger: Player interacts with Item Shop NPC.
• Observable result: Item Shop drawer opens; purchase deducts currency and adds item.
• Access: Login required.
• Failure/recovery: Insufficient currency or rejected purchase shows error.
• Continuation: Player returns to Match.

FR-7 (explicit). As a Bedwars Player, I should open a Team Upgrade NPC interactive menu where I trade Diamonds for permanent team buffs: Sharpened Swords, Reinforced Armor, Haste, and Traps.

• Trigger: Player interacts with Team Upgrade NPC.
• Observable result: Team Upgrades drawer opens; purchase deducts Diamonds and applies permanent team buff.
• Access: Login required.
• Failure/recovery: Insufficient Diamonds or rejected purchase shows error.
• Continuation: Player returns to Match.

FR-8 (explicit). As a Bedwars Player, I should see each team has a physical Bed on its island; while intact, team members respawn infinitely after a 5-second countdown, and once an enemy breaks the bed, respawning is permanently disabled for that team.

• Trigger: Player dies or enemy breaks bed.
• Observable result: Respawn countdown or permanent elimination.
• Access: Login required.
• Failure/recovery: Bed-broken event triggers flash and shake.
• Continuation: Player respawns or is eliminated.

FR-9 (explicit). As a Bedwars Player, I should experience real-time hit registration, damage calculations, and visual velocity knockback when striking an enemy with swords or knockback sticks.

• Trigger: Player attacks enemy.
• Observable result: Damage applied, knockback velocity shown.
• Access: Login required.
• Failure/recovery: Rejected hit shows no damage.
• Continuation: Combat continues.

FR-10 (explicit). As a Bedwars Player, I should have the server validate movement packets with strict speed and coordinate tracking, rejecting movement exceeding maximum possible walking/knockback velocity (Fly Hack and Speed Hack protection).

• Trigger: Player sends movement packet.
• Observable result: Invalid movement rejected.
• Access: System process.
• Failure/recovery: Rejection logged; player position corrected.
• Continuation: Player continues.

FR-11 (explicit). As a Bedwars Player, I should have the server validate combat packets, rejecting hits beyond a strict maximum block reach or with line-of-sight obstructed by solid blocks (Reach and KillAura protection).

• Trigger: Player sends combat packet.
• Observable result: Invalid hit rejected.
• Access: System process.
• Failure/recovery: Rejection logged.
• Continuation: Combat continues.

FR-12 (explicit). As a Bedwars Player, I should have the server verify click rates (CPS checks) and only allow block placement or breaking when I am within interacting range and possess the matching tool in my active server-side inventory.

• Trigger: Player sends interaction packet.
• Observable result: Invalid interaction rejected.
• Access: System process.
• Failure/recovery: Rejection logged.
• Continuation: Player continues.

FR-13 (explicit). As a Bedwars Player, I should have individual player profiles persist across sessions, logging total Wins, Kills, Beds Broken, Games Played, and current Level/XP.

• Trigger: Match ends or stats change.
• Observable result: Profile updated on persistent storage.
• Access: Login required.
• Failure/recovery: Storage failure retried.
• Continuation: Profile available next session.

FR-14 (explicit). As a Leaderboard Viewer, I should see a real-time global leaderboard driven by a Redis Sorted Set (ZSET) that instantly pulls and displays the top 100 players globally, filterable by Wins, Beds Broken, and Kills.

• Trigger: Viewer opens Leaderboard or changes filter.
• Observable result: Top 100 ranking displayed.
• Access: Login required.
• Failure/recovery: Fetch failure shows error and retry.
• Continuation: Viewer re-sorts or returns to Lobby.

FR-15 (explicit). As a Leaderboard Viewer, I should see the main lobby include a clean, visual Leaderboard menu showing global rankings alongside an overlay summarizing my personal lifetime statistics.

• Trigger: Viewer opens Leaderboard from Lobby.
• Observable result: Rankings plus personal-stats sticker panel.
• Access: Login required.
• Failure/recovery: Overlay fetch failure shows error.
• Continuation: Viewer returns to Lobby.

FR-16 (explicit). As a Bedwars Player, I should see visuals using a clean, high-fidelity voxel or styled low-poly aesthetic mimicking Minecraft with modern web lighting, particle effects on block destruction, and smooth camera transitions.

• Trigger: Match renders.
• Observable result: Voxel visuals with lighting, particles, camera transitions.
• Access: Login required.
• Failure/recovery: Renderer fallback.
• Continuation: Play continues.

FR-17 (explicit). As a Bedwars Player, I should see a real-time, scannable HUD showing current player inventory, team bed status (Alive/Broken/Eliminated), a match timer, and kill feeds.

• Trigger: Match active.
• Observable result: HUD updates in real time.
• Access: Login required.
• Failure/recovery: HUD reconnect state.
• Continuation: Play continues.

FR-18 (explicit). As a Bedwars Player, I should hear sound effects for block breaking, purchasing items, bed destruction, and combat impacts.

• Trigger: Corresponding event occurs.
• Observable result: Sound plays.
• Access: Login required.
• Failure/recovery: Audio failure silent.
• Continuation: Play continues.

FR-19 (required_inference). As a new player, I should self-service enroll to establish a persistent player profile.

• Trigger: Player opens Sign Up.
• Observable result: Profile created.
• Access: Anonymous.
• Failure/recovery: Validation error shown.
• Continuation: Redirect to Lobby.

FR-20 (required_inference). As a returning player, I should verify my identity before entering the protected lobby and match.

• Trigger: Player opens Login.
• Observable result: Session established.
• Access: Anonymous.
• Failure/recovery: Invalid credentials error.
• Continuation: Redirect to Lobby.

FR-21 (required_inference). As a Bedwars Player, I should have an authoritative server session established over WebSockets before match participation.

• Trigger: Player enters Lobby.
• Observable result: WebSocket session active.
• Access: Login required.
• Failure/recovery: Reconnect.
• Continuation: Match participation.

FR-22 (required_inference). As a Bedwars Player, I should have Redis-backed session state and leaderboard ZSET available for live match and rankings.

• Trigger: Match or leaderboard query.
• Observable result: State and rankings available.
• Access: System process.
• Failure/recovery: Retry.
• Continuation: Play continues.

FR-23 (required_inference). As a Bedwars Player, I should have the native persistent storage volume available for long-term player records.

• Trigger: Profile write.
• Observable result: Record persisted.
• Access: System process.
• Failure/recovery: Retry.
• Continuation: Profile available.

4. User Personas

Bedwars Player

• Product context: Joins the lobby, is auto-assigned to a Solo, Doubles, or 4v4v4v4 team (Red, Blue, Green, Yellow), and is teleported to a team island when the lobby fills.
• Primary goal: Win the match and accumulate Wins, Kills, Beds Broken, Games Played, and Level/XP on a persistent profile.
• Distinct responsibilities: Collect spawned Iron/Gold/Diamond/Emerald; buy from Item Shop and Team Upgrade NPCs; break enemy beds; fight with swords and knockback sticks; respawn on a 5-second countdown while their bed is intact.
• Inputs/decisions: Mode selection, team assignment, purchase decisions, combat targeting, bed-breaking strategy.
• Interactions: With teammates (shared team buffs, bed defense), enemies (combat, bed breaking), NPCs (Item Shop, Team Upgrade).
• Observable success: Match win and updated persistent stats.

Leaderboard Viewer

• Product context: From the main lobby, opens the Leaderboard menu to view the top 100 players globally.
• Primary goal: Quickly compare their personal record against global rankings.
• Distinct responsibilities: Re-sorts the ranking by Wins, Beds Broken, or Kills; reads an overlay summarizing their own lifetime statistics.
• Inputs/decisions: Filter selection (Wins, Beds Broken, Kills).
• Interactions: With the Leaderboard table and personal-stats overlay.
• Observable success: Clear comparison of personal record against global rankings.

5. Core User Flows

Flow 1: New Player Enrollment and First Match

1. Player opens Landing (anonymous) and reads the core mechanics summary and mode cards.
2. Player selects "PLAY" and is routed to Sign Up.
3. Player submits enrollment; profile is created with Wins, Kills, Beds Broken, Games Played, and Level/XP initialized.
4. Player is redirected to Lobby (login required); WebSocket session established.
5. Player selects a mode (Solo, Doubles, 4v4v4v4); lobby fills.
6. Player is auto-assigned to a team (Red, Blue, Green, Yellow) and teleported to a team island.
7. Match begins; HUD shows inventory, bed status, timer, kill feed.
8. Failure/recovery: If WebSocket disconnects, player sees reconnect state and resumes.

Flow 2: Returning Player Login

1. Player opens Landing and selects Login.
2. Player submits credentials on Login.
3. On success, player is redirected to Lobby with persistent profile loaded.
4. Failure/recovery: Invalid credentials show error; player retries or navigates to Sign Up.

Flow 3: In-Match Resource Collection and Shopping

1. Player is in Match; timed spawners produce Iron/Gold at base islands and Diamond/Emerald at neutral middle/side islands.
2. Player collects resources.
3. Player interacts with Item Shop NPC; Item Shop drawer opens.
4. Player trades Iron/Gold for weapons, blocks (wool, wood, obsidian), tools (shears, pickaxes), or armor; purchase sound plays.
5. Player interacts with Team Upgrade NPC; Team Upgrades drawer opens.
6. Player trades Diamonds for Sharpened Swords, Reinforced Armor, Haste, or Traps; permanent team buff applied.
7. Failure/recovery: Insufficient currency shows error; player returns to Match.

Flow 4: Combat and Bed Breaking

1. Player encounters enemy in Match.
2. Player strikes with sword or knockback stick; server validates reach and line-of-sight; damage and knockback applied.
3. Player breaks enemy bed; bed-broken flash (300ms #FF5A00 at 12% opacity plus 2px screen shake) and sound play.
4. Enemy team's respawning is permanently disabled.
5. Failure/recovery: Rejected hit shows no damage; player repositions.

Flow 5: Death and Respawn

1. Player dies in Match.
2. If bed intact, 5-second respawn countdown begins; player respawns.
3. If bed broken, respawning permanently disabled; player is eliminated.
4. Failure/recovery: Disconnect during countdown shows reconnect state.

Flow 6: Leaderboard Viewing

1. Player in Lobby opens Leaderboard menu.
2. Leaderboard loads top 100 players globally from Redis ZSET.
3. Viewer re-sorts by Wins, Beds Broken, or Kills using rectangular filter tabs.
4. Viewer reads personal-stats sticker panel (rotated -2deg with tape strip) summarizing lifetime statistics.
5. Failure/recovery: Fetch failure shows error and retry; viewer returns to Lobby.

6. Visuals Colors and Theme

Muse: Virgil Abloh. Headline: "BEDWARS" — the game is a product launch, the lobby is a drop, the match is a head-to-head battle.

Palette (dark mode):

• Background: #0E0E0E
• Surface: #1A1A1A
• Text: #F4F1EA (12:1 contrast at body size)
• Primary: #FF5A00 (safety orange — primary CTAs, kill-feed hits, bed-broken alerts, highlighted team)
• Accent: #FFD400 (hazard yellow — currency gold/diamond, hover states)
• Muted: #7A7A7A (metadata, timestamps)
• Hairline borders: #2A2A2A
• Team colours (small square chips only, never full panels): Red #E23A3A, Blue #3A7DE2, Green #3FCB68, Yellow #FFD400

Typography:

• Headings: Anton, all-caps, tight tracking (-0.02em), huge scale, quotation marks around key word ("BEDWARS", "DROP", "WIN").
• Secondary headings: Space Grotesk 700 in caps with +0.08em letterspacing as label text.
• Monospace numerals: Space Mono for HUD timer and leaderboard ranks.
• Body: Space Grotesk.
• Scale: 1.5 modular with heavy display jump: 40/64/96/128 for display; 14/16/20/24 for UI. Hero headline clamp(56px, 12vw, 148px). HUD micro-labels 11px uppercase, +0.14em tracking.

Shape language: Hard 0px corners on all panels and buttons except the primary CTA which gets a 2px offset shadow (deliberate print misregistration). Hazard-stripe dividers (45° repeating-linear-gradient of #FF5A00 and #0E0E0E at 12px pitch) between major sections. Exposed grid lines as 1px #2A2A2A rules. Every card carries a small uppercase tag in the top-left corner like a garment label. Buttons are rectangular with a 1px #F4F1EA border and a 4px hard offset shadow in #FF5A00 on hover.

Layout: Asymmetric 12-column grid with type allowed to break the grid. Lobby is a full-bleed composition: oversized "BEDWARS" headline locked to the left edge, hazard-stripe band cutting diagonally across the top-right, mode-select cards stacked as overlapping label-and-tag arrangement. Match HUD is a strict 3-zone layout: left = team bed status column, centre = match timer + kill feed, right = inventory strip. Shop and Team Upgrade open as full-height right-side drawers with hazard-stripe header and 3-column item grid where each item is a label card. Leaderboard is a single full-width table with tabular numerals, filter pills as rectangular tabs, and a personal-stats overlay that slides in from the bottom as a sticker-style panel with a rotated -2deg tag.

Imagery: Voxel/low-poly Minecraft-style block renders treated as product photography: a single isometric bed block on concrete-grey ground with hard directional light, an emerald and diamond crystal macro shot, a wool-block stack in team colours. All imagery desaturated to industrial grey with one saturated accent object per frame. No stock people, no gradient blobs, no glass panels. Texture overlays: subtle concrete grain, construction-tape stripes, halftone dots on the display headline.

7. Signature Design Concept

The public entry (Landing) is a full-bleed near-black ground split by a diagonal hazard-stripe band from top-right to centre-left. The dominant element is the word "BEDWARS" set in Anton at clamp(56px, 12vw, 148px), flush-left, with opening and closing quotation marks rendered in safety-orange and the letters in off-white — the headline spans the viewport and slightly overflows the right edge behind the stripe. Beneath it, a single isometric voxel bed render sits on a concrete-grey plinth with a hard cast shadow, lit by one orange rim light. To the right, a vertical stack of three rectangular mode cards ("SOLO", "DOUBLES", "4v4v4v4") each tagged with a small label and a team-colour chip row. Bottom-left: a hard rectangular "PLAY" CTA with a 4px orange offset shadow and a monospace player-count readout ("2,481 ONLINE"). No centred headline, no blue button, no gradient.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The oversized "BEDWARS" wordmark and the isometric voxel bed render on its concrete plinth.
• Input→transformation→outcome thesis: On load, the hazard-stripe band drifts horizontally at 8s linear infinite as a subtle ticker; the wordmark and bed render settle into place; hovering the PLAY CTA snaps the 4px offset shadow to 0px in 120ms with a 1px translate lift.
• Motion vocabulary: Snappy and mechanical. Hover lifts are 1px translate with the offset shadow snapping to 0px in 120ms. Kill-feed entries slide in from the right with a 60ms step and hold. Shop drawer opens with a 180ms cubic-bezier(0.2, 0.8, 0.2, 1) slide. Hazard-stripe bands drift horizontally at 8s linear infinite. Bed-broken event triggers a 300ms full-screen flash in #FF5A00 at 12% opacity plus a hard 2px screen shake.
• Composed first frame: Near-black ground, diagonal hazard-stripe band top-right to centre-left, "BEDWARS" flush-left with orange quotation marks, isometric bed render on plinth with orange rim light, three mode cards stacked right, PLAY CTA bottom-left with monospace online count.
• Reduced-motion state: Disable stripe drift and screen shake; keep only opacity fades. Provide a usable static arrangement with mode cards wrapped into rows or horizontally scrollable so each item can be brought fully into view.

9. Non-Functional Requirements

• NFR-1 (explicit): Optimized for smooth 60FPS browser performance and zero-lag server state syncing.
• NFR-2 (explicit): Graphics rendering must avoid DOM-node lag by using Canvas or WebGL rather than DOM nodes.
• NFR-3 (explicit): The backend must be deployed in the managed Kubernetes namespace.
• NFR-4 (explicit): Short-term session state lives in memory or Redis; long-term player records use the native persistent storage volume.
• NFR-5 (explicit): Server-side anti-cheat must reject movement packets exceeding maximum possible walking/knockback velocity.
• NFR-6 (explicit): Server-side anti-cheat must reject combat hits beyond a strict maximum block reach or with line-of-sight obstructed by solid blocks.
• NFR-7 (explicit): Server-side anti-cheat must verify click rates (CPS) and require interacting range plus the matching tool in the active server-side inventory for block placement/breaking.
• NFR-8 (explicit): Every agentic code pass must run through the automated security scanner to guarantee secure, unprotected API-free WebSocket routes.
• NFR-9 (explicit): The Project Manager Agent must break the work into a sprint plan covering UI/Canvas setup, WebSocket connection, Gameplay Logic, Anti-Cheat loop, and Leaderboard processing.
• NFR-10 (explicit): Readable text and controls stay whole at every viewport (375px, 768px, 1280px); headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container, wrapping or scaling to fit; no other element covers any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, as long as it covers no readable text or control. Moving and scrollable content may cross the viewport or container edge by design; with prefers-reduced-motion, provide a usable static arrangement.

10. Tech Stack

• Frontend: React or Next.js paired with HTML5 Canvas or lightweight Three.js WebGL block meshes.
• Networking: Authoritative server-client architecture over WebSockets with delta compression and client-side interpolation/prediction.
• Backend: Node.js/TypeScript deployed in the managed Kubernetes namespace.
• Session state: In-memory or Redis for sub-millisecond game loop updates.
• Leaderboard: Redis Sorted Set (ZSET).
• Long-term storage: Native persistent storage volume for player records.
• Build gate: Automated security scanner on every agentic code pass.

11. Assumptions and Constraints

• A-1: Self-service enrollment and returning verification are required to establish and resume persistent player profiles (required_inference).
• A-2: The authoritative server session is established over WebSockets before match participation (required_inference).
• A-3: Redis is available for session state and leaderboard ZSET (required_inference).
• A-4: The native persistent storage volume is available for long-term player records (required_inference).
• C-1: No adjacent account-management capabilities beyond enrollment and verification.
• C-2: No team chat, friend lists, social features, cosmetic marketplace, spectator mode, or mobile-native client.
• C-3: The generic indigo/blue-on-white SaaS template is forbidden.
• C-4: Team colours appear only as small square chips, never as full panels.

12. Glossary

• Bedwars: A competitive multiplayer game mode where teams defend a bed and attempt to break enemy beds.
• Bed: A physical object on each team's island; while intact, team members respawn infinitely after a 5-second countdown.
• Spawner: A timed resource generator at base islands (Iron, Gold) or neutral middle/side islands (Diamond, Emerald).
• Item Shop NPC: An interactive NPC opening a menu to trade Iron/Gold for weapons, blocks, tools, and armor.
• Team Upgrade NPC: An interactive NPC opening a menu to trade Diamonds for permanent team buffs.
• ZSET: Redis Sorted Set used to drive the global leaderboard.
• CPS: Clicks per second, used in anti-cheat interaction verification.
• Delta compression: Network technique sending only state changes.
• Client-side interpolation/prediction: Techniques to smooth and anticipate server state for responsive feel.