System Requirements Document for obby-game-roblox

1. Introduction

obby-game-roblox is an original, browser-based obstacle-course ("obby") game built in the spirit of Roblox obbies — fast, loud, social and a little chaotic — but delivered as its own first-party product rather than as a game hosted on Roblox. The product intent is to let a player drop straight into a course, run, jump and climb through a sequence of obstacles, hit checkpoints, and reach the finish, with a landing surface that sells speed and dare in one glance and a play surface that gets out of the way and lets the course be the star.

The audience is kids, teens and casual players who grew up on Roblox obbies: players who want an immediate, adrenaline-plus-bravado challenge ("can you make the jump?") without installing anything or signing up for a platform. The user (Madani) delegated the build to the assistant; the open questions about browser vs. downloadable delivery and about whether players author courses or the designer authors levels were not answered, so this document resolves them only to the minimum needed to make the accepted core journey — a player plays through an obstacle course and reaches its finish — usable, and keeps everything else out of current scope.

2. System Overview

obby-game-roblox is a single first-party web application with two current destinations:

• Landing — the anonymous public entry surface that explains the original obby game, its audience and its obstacle-course play, and launches a player into a course.
• Play — the core accepted journey: a full-viewport playable obstacle course with a flat HUD, checkpoints, a timer and a finish.

The only accepted active human persona is the Player. There are no other human roles in current scope. The application itself is the system actor that runs the course simulation, tracks the player's progress through obstacles and checkpoints, keeps the timer, and determines when the player has fallen, respawned or finished.

Current delivery is a browser-based game with custom first-party UI. Both destinations are reachable without an account: the accepted journey is a single-session play-through of a course, and nothing in the authoritative requirements establishes durable, privately owned, resumable player state that would require application-owned identity. There is no course-authoring surface, no multiplayer or social layer, no leaderboard persistence requirement, no downloadable client, and no Roblox hosting in current scope.

2a. Product Interpretation and Delivery Boundary

The product is an original obby, not a Roblox experience. It is delivered as a web application the player opens in a browser: the Landing page is public and anonymous, and the Play page is likewise open to any player without an account. The game's defining state — the player's position on the course, the checkpoints reached, the running timer and the finish — lives for the duration of a play session and is owned by the application while that session runs.

The current horizon covers exactly the accepted core: an anonymous player discovers the game on Landing, starts a course, plays through its obstacles, passes checkpoints, recovers from falls by respawning, and reaches the finish with an observable result. Course authoring by players, downloadable distribution, accounts, social features and persistent leaderboards are not part of the current horizon; they are recorded only as future considerations in Section 11 and must not appear as current pages, controls or acceptance criteria.

2b. Source Content Inventory

Not applicable — no reference directive in this request declares a content_source.

2c. Page Content and Component Coverage

Landing

Information and state. The Landing page is the anonymous public entry surface. It presents the game's identity and its obstacle-course premise, communicates the dare ("can you make the jump?"), and offers a direct route into play. It carries no player-specific state and requires no identity.

Primary action. Start playing — the yellow "PLAY NOW" pill with black text and a black arrow, which takes the player to the Play page and begins a course.

Supporting actions and content.

• Full-bleed poster hero: the words "DON'T" / "FALL" stacked in Anton at clamp(56px, 13vw, 168px), each line spanning the full viewport width, the second line set in outline and rotated −3deg, overlapping a solid red rectangle that bleeds off the right edge; a black hazard-tape band runs horizontally behind the type at 40% height.
• A 12px caps line beneath the PLAY NOW pill reading "85 OBSTACLES · 3 CHECKPOINTS · NO MERCY".
• Three flat course cards peeking from the right edge, cut off by the viewport as a promise of more.
• A continuously running course-name ticker between hero and course list that pauses on hover and wraps to static rows under reduced motion.
• Alternating full-bleed colour bands separated by hazard-tape rules: a red band for "how it works", a black band for the course list, a paper band for the leaderboard presentation.
• Section labels in Archivo 700, uppercase, 12px, tracking 0.18em, inside solid black bars with paper-coloured text.

Domain entities. Course (name, difficulty tag, obstacle count, checkpoint count), obstacle, checkpoint.

Component responsibilities.

• Poster hero — composes the display type, red block and hazard band; owns the staggered word reveal.
• Play CTA — the single launch control; navigates to Play.
• Course ticker — scrolls course names continuously; pauses on hover; becomes a static wrapping list under prefers-reduced-motion.
• Course cards — flat solid colour blocks (red/yellow/teal) with 3px black borders, giant Anton course names and small isometric line-art thumbnails (black 2px strokes on the card colour); selecting a card triggers a 320ms colour-block wipe and launches that course.
• How-it-works band — red full-bleed band explaining the obstacle-course premise in short poster copy.
• Leaderboard band — paper band presenting the leaderboard area; it is a presentation surface only and does not establish persistent ranking storage in current scope.

States.

• Loading — the page is static poster content; no data fetch is required to render the hero, CTA or course cards.
• Empty — not applicable; the hero and CTA are always present.
• Success — the player sees the poster hero and the PLAY NOW pill and can launch a course.
• Error / recovery — if the Play page cannot be reached, the player remains on Landing with the PLAY NOW pill still available to retry; no error state is invented beyond keeping the launch control usable.

Play

Information and state. The Play page is a full-viewport playable obstacle course with a flat HUD. It shows the current course name, a running timer in tabular numerals, the player's progress through checkpoints, and the player's current lives/attempt state. All HUD text sits in opaque rectangular panels with 3px black borders — never directly over the 3D scene.

Primary action. Play the course: move and jump the player character through the obstacles toward the finish.

Supporting actions and content.

• Black top bar: course name on the left, timer centred in tabular numerals, quit on the right; a hazard-tape underline runs beneath the top bar.
• Bottom-left control legend card: an opaque panel listing the movement and jump controls.
• Checkpoint flags that pop with a 120ms scale when reached.
• A single 140ms red full-screen frame on death/respawn.
• A finish state when the player reaches the end of the course.

Domain entities. Course (name, obstacle sequence, checkpoint positions, finish), player character (position, velocity, grounded state), checkpoint (reached / not reached), timer (elapsed), lives/attempts, run result (finished, elapsed time, checkpoints reached).

Component responsibilities.

• Top bar — displays course name, live timer and quit; quit returns the player to Landing.
• Course renderer — renders the playable course and the player character; the course is the only dimensional element on the product.
• Checkpoint tracker — detects checkpoint contact, pops the flag, records the checkpoint as reached and updates the HUD.
• Respawn controller — on a fall, flashes the 140ms red frame and returns the player to the last reached checkpoint (or the start if none).
• Control legend — static opaque panel describing the controls.
• Finish handler — detects the finish, stops the timer and presents the run result.

States.

• Loading — the course is being prepared; the HUD panels are shown with the course name and a zeroed timer.
• Empty — not applicable; a course always has obstacles and a finish.
• Success — the player reaches the finish; the timer stops and the run result (elapsed time, checkpoints reached) is shown.
• Error / recovery — a fall is not a terminal error: the player respawns at the last checkpoint after the red flash and continues. If the player quits, they return to Landing and can start again.

3. Functional Requirements

FR-1 — Original obby, not a Roblox-hosted game (explicit) As a Player, I should play an original obstacle-course game that is its own product rather than a game hosted on Roblox, so that the experience is a distinct first-party obby.

• Trigger: the player opens the product.
• Observable result: the game is delivered by this application on its own Landing and Play surfaces; no Roblox hosting, Roblox account or Roblox client is involved.
• Access: public, no account.
• Failure/recovery: not applicable — this is a delivery constraint, not a runtime state.
• Continuation: the player proceeds to Landing and then Play.

FR-2 — Discover the game on Landing (required_inference) As a Player, I should land on a public page that tells me what this obby is and dares me to play, so that I know what I am about to attempt and can start immediately.

• Trigger: the player opens the product URL.
• Input: none.
• Observable result: the poster hero ("DON'T" / "FALL"), the "85 OBSTACLES · 3 CHECKPOINTS · NO MERCY" line, the PLAY NOW pill and the peeking course cards are visible.
• Access: anonymous, no account.
• Failure/recovery: if Play cannot be reached, the PLAY NOW pill remains available to retry.
• Continuation: the player selects PLAY NOW or a course card.

FR-3 — Start a course (required_inference) As a Player, I should start a course from Landing with a single action, so that I go from the poster straight into play.

• Trigger: the player activates the PLAY NOW pill or selects a course card.
• Input: the chosen course (or the default course from PLAY NOW).
• Observable result: the Play page opens with the course name in the top bar, the timer at zero and the player at the course start.
• Access: anonymous, no account.
• Failure/recovery: if the course fails to load, the player can quit back to Landing and start again.
• Continuation: the player begins moving through the obstacles.

FR-4 — Move and jump through obstacles (explicit) As a Player, I should move and jump my character through a sequence of obstacles, so that I can attempt the course.

• Trigger: the player uses the movement and jump controls.
• Input: movement and jump input.
• Observable result: the character moves and jumps on the course; the control legend card describes the controls.
• Access: anonymous, no account.
• Failure/recovery: a missed jump causes a fall (see FR-6).
• Continuation: the player continues toward the next obstacle.

FR-5 — Reach checkpoints (explicit) As a Player, I should reach checkpoint flags along the course, so that my progress is recorded and I do not lose everything when I fall.

• Trigger: the player's character contacts a checkpoint flag.
• Observable result: the flag pops with a 120ms scale, the checkpoint is recorded as reached, and the HUD reflects the progress.
• Access: anonymous, no account.
• Failure/recovery: if the player falls before reaching a checkpoint, they respawn at the previous checkpoint or the start.
• Continuation: the player continues toward the next checkpoint or the finish.

FR-6 — Fall and respawn (required_inference) As a Player, I should fall off the course and respawn at my last checkpoint, so that a mistake costs me progress but does not end the run.

• Trigger: the character leaves the course and falls.
• Observable result: a single 140ms red full-screen frame plays, and the character reappears at the last reached checkpoint (or the start if none has been reached).
• Access: anonymous, no account.
• Failure/recovery: this is the recovery path itself; the run continues.
• Continuation: the player retries the obstacle from the checkpoint.

FR-7 — See the timer and course state (explicit) As a Player, I should see the course name, a running timer and my progress in an opaque HUD, so that I always know where I am and how long I have taken.

• Trigger: the Play page is open.
• Observable result: the black top bar shows the course name on the left, the timer centred in tabular numerals, and quit on the right; the HUD panels are opaque with 3px black borders and never sit directly over the 3D scene.
• Access: anonymous, no account.
• Failure/recovery: not applicable to display; the timer continues while the run is active.
• Continuation: the player keeps playing.

FR-8 — Reach the finish and see the result (required_inference) As a Player, I should reach the finish of the course and see that I finished with my elapsed time, so that the run has a clear, observable outcome.

• Trigger: the character reaches the finish.
• Observable result: the timer stops and the run result (finished, elapsed time, checkpoints reached) is presented.
• Access: anonymous, no account.
• Failure/recovery: if the player quits before finishing, no finish result is produced and they return to Landing.
• Continuation: the player can return to Landing and start another course.

FR-9 — Quit a run (explicit) As a Player, I should be able to quit a run from the top bar, so that I can leave a course and go back.

• Trigger: the player activates quit.
• Observable result: the player returns to Landing.
• Access: anonymous, no account.
• Failure/recovery: the run ends without a finish result; the player can start again from Landing.
• Continuation: the player selects PLAY NOW or a course card again.

4. User Personas

Player

Product context. The Player is a kid, teen or casual player who grew up on Roblox obbies and expects a fast, loud, immediate challenge. They arrive with no account and no setup: they open the product in a browser and want to be playing within seconds. They judge the game on whether the dare is legible at a glance and whether the course is fun to attempt and retry.

Primary goal. Play through an obstacle course and reach its finish.

Distinct accepted responsibilities.

• Reading the Landing poster to understand what the obby is and that it is a dare.
• Starting a course with a single action.
• Moving and jumping through the obstacle sequence.
• Reaching checkpoint flags to bank progress.
• Recovering from a fall by respawning at the last checkpoint and retrying.
• Watching the timer and course state in the HUD.
• Reaching the finish and seeing the run result.
• Quitting a run to return to Landing.

Relevant inputs and decisions. Movement and jump input; the choice of course (PLAY NOW or a course card); the decision to retry after a fall or to quit.

Interactions with other accepted participants. The Player is the only accepted human persona. The application is the counterparty: it runs the course, records checkpoints, keeps the timer, triggers the respawn and determines the finish. There is no other human participant in current scope.

Observable success. The Player reaches the finish, the timer stops, and the run result is shown; or the Player quits and returns to Landing able to start again.

Constraints and provenance. This persona is required_inference from the Planning Scope: the product is an obstacle-course game, so the primary human role is someone who plays through courses. No biography, demographics, permissions or account requirements are asserted.

5. Core User Flows

Flow A — Discover the game and start a course

1. The Player opens the product URL in a browser. No account is required.
2. Landing renders the poster hero: "DON'T" / "FALL" in Anton, the second line in outline and rotated −3deg over a red block, with the hazard-tape band behind the type. The words reveal with a staggered slide-up (40ms stagger).
3. The Player reads the "85 OBSTACLES · 3 CHECKPOINTS · NO MERCY" line and sees the course ticker running and the course cards peeking from the right edge.
4. The Player activates the yellow PLAY NOW pill (or selects a course card, which triggers the 320ms colour-block wipe).
5. Play opens with the course name in the black top bar, the timer at zero and the Player at the course start.
6. Failure/recovery: if Play cannot be reached, the Player stays on Landing and the PLAY NOW pill remains available to retry.

Flow B — Play the course, hit checkpoints and finish

1. On Play, the Player reads the bottom-left control legend card and begins moving and jumping.
2. The Player attempts each obstacle in sequence; the timer runs in the top bar in tabular numerals.
3. When the Player's character contacts a checkpoint flag, the flag pops with a 120ms scale and the checkpoint is recorded; the HUD reflects the progress.
4. The Player continues through the remaining obstacles toward the finish.
5. When the Player reaches the finish, the timer stops and the run result (finished, elapsed time, checkpoints reached) is presented.
6. The Player returns to Landing and can start another course.

Flow C — Fall, respawn and retry

1. Mid-course on Play, the Player misses a jump and the character falls off the course.
2. A single 140ms red full-screen frame plays.
3. The character reappears at the last reached checkpoint (or the start if none has been reached).
4. The Player retries the obstacle from that checkpoint; the timer continues.
5. The Player either continues to the finish (Flow B, step 5) or quits (Flow D).

Flow D — Quit a run

1. On Play, the Player activates quit in the top bar.
2. The run ends without a finish result and the Player returns to Landing.
3. The Player can start again via PLAY NOW or a course card (Flow A, step 4).

6. Visuals, Colors and Theme

Muse and headline. Paula Scher — Typography as a playground you can fall off. Obby culture is poster culture: giant stacked words, hard colour blocks, hazard-tape energy, zero politeness. Scher's typographic maximalism gives the game a loud, ownable identity while her flat, hard-edged system stays cheap to render and never competes with the 3D course itself.

Colour tokens (light mode).

Proportion: ~60% paper, 25% black type/rules, 10% red blocks, 5% yellow. No gradients, no translucency, no shadows.

Typography.

• Headings: Anton, all-caps, tracking −0.01em, leading 0.86, stacked into 2–3 lines that each fill the column edge to edge; occasional single words rotated −3deg and set in outline (text-stroke).
• Section labels: Archivo 700, uppercase, 12px, tracking 0.18em, inside solid black bars with paper-coloured text.
• Body: Archivo.
• Scale (1.5 modular display rhythm): hero clamp(56px, 13vw, 168px) Anton; section heads clamp(40px, 7vw, 88px); sub-heads 28/24px Archivo 800; body 17/16px Archivo 400 with 1.55 leading; micro-labels 12px caps.
• On mobile the hero headline drops to two stacked words per line so nothing exceeds the viewport.

Shape language. Hard edges only: 0px radius everywhere except 999px pill buttons. Solid colour blocks, 4px and 8px black rules, diagonal hazard bands (45deg repeating-linear-gradient in black/yellow) as section dividers, and rotated type blocks that deliberately break the column. The play surface is a flat HUD: rectangular panels with 3px black borders, no blur, no glass.

Layout. Poster grid: 12-column base at 1280px, 6-column at 768px, single column at 375px. Landing opens with a full-bleed type composition, then alternating full-bleed colour bands (red band = "how it works", black band = course list, paper band = leaderboard) separated by hazard-tape rules. Play is a full-viewport canvas with a black top bar (course name left, timer centre in tabular numerals, quit right) and a bottom-left control legend card; all HUD text sits in opaque panels so it never sits on the 3D scene.

Imagery. Typography is the image. Course cards are flat colour blocks with the course name set huge in Anton and a small isometric line-drawn course thumbnail (black 2px strokes on the card colour). Small pixel-free pictograms for checkpoints, timer and lives drawn as flat black/white glyphs. No photography, no 3D renders on the marketing surface — the only dimensional imagery is the playable course itself.

Readable-text rule. Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling 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 as the direction asks, as long as it covers no readable text or control. The ticker may cross the viewport edge by design; under prefers-reduced-motion it becomes a usable static arrangement (wrapping rows or horizontal scrolling) so each item can be brought fully into view.

7. Signature Design Concept

"The poster you fall off." The Landing page is a single asymmetric Scher poster on warm paper #F2EDE3. The words DON'T / FALL are set in Anton at clamp(56px, 13vw, 168px), each line spanning the full viewport width; the second line is set in outline and rotated −3deg, overlapping a solid #E63329 rectangle that bleeds off the right edge. A black hazard-tape band runs horizontally behind the type at 40% height. Bottom-left: a yellow #F5C518 pill "PLAY NOW" with black text and a black arrow, under a 12px caps line "85 OBSTACLES · 3 CHECKPOINTS · NO MERCY". Bottom-right: three flat course cards peeking from the right edge, cut off by the viewport as a promise of more. Nothing is centred — the composition is a poster, not a SaaS hero. The signature move is that the type itself is the playground: the outline word and the red block read as a ledge and a gap, so the poster performs the dare it is selling. The concept recomposes only accepted Landing content and controls; it adds no behaviour, page or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: the stacked Anton words "DON'T" / "FALL", the second line in outline and rotated −3deg over the red block, with the hazard-tape band behind.
• Input → transformation → outcome thesis: on load, each line of Anton slides up 24px with a 40ms stagger and resolves into the full-bleed poster; the course ticker then runs continuously beneath the hero, pausing on hover, so the page reads as a live dare rather than a static page.
• Motion vocabulary: staggered word reveals (24px slide-up, 40ms stagger), a continuous horizontal course-name ticker that pauses on hover, 320ms colour-block wipes on course-card selection, and a 90ms snap on button press. Motion feels printed and snappy — no bouncy spring easing.
• Composed first frame: warm paper ground, the two Anton lines at final position, the red block bleeding off the right edge, the hazard band at 40% height, the yellow PLAY NOW pill bottom-left and the three course cards peeking bottom-right.
• Reduced-motion state: all reveals resolve immediately to their final state; the ticker becomes a wrapping static list of course names.

In-game motion. Checkpoint flags pop with a 120ms scale; the death/respawn flash is a single 140ms red full-screen frame. Under prefers-reduced-motion these resolve to their final state without the scale or flash animation.

9. Non-Functional Requirements

• NFR-1 — Originality and hosting boundary (explicit): The game must be an original obby experience, not a Roblox-hosted game. No Roblox account, Roblox client or Roblox hosting is part of the product.
• NFR-2 — Browser delivery (required_inference): The game runs in a browser with no install step, because the accepted journey is a player opening the product and playing immediately.
• NFR-3 — Anonymous access (required_inference): Landing and Play are reachable without an account; the accepted single-session play-through does not require durable, privately owned player state.
• NFR-4 — Readable text and controls at every viewport (explicit): Headlines, labels, numbers, card text and controls stay whole and inside the viewport and their container at 375px, 768px and 1280px; no other element covers them. Moving content may cross the viewport edge by design but every item must become fully readable as it passes, and reduced motion must provide a usable static arrangement.
• NFR-5 — HUD legibility over the course (explicit): All HUD text sits in opaque rectangular panels with 3px black borders; no HUD text is laid directly over the 3D scene.
• NFR-6 — Reduced motion (explicit): Under prefers-reduced-motion, the ticker becomes a wrapping static list and all reveals resolve to final state.
• NFR-7 — Flat rendering discipline (explicit): No gradients, glassmorphism, blurred panels or soft drop shadows; the playable course is the only dimensional element.
• NFR-8 — Responsive poster grid (explicit): 12-column base at 1280px, 6-column at 768px, single column at 375px; on mobile the hero headline drops to two stacked words per line.

10. Tech Stack

• Frontend: React (web) — the Landing poster and the Play surface with its flat HUD.
• 3D course rendering: a browser 3D renderer for the playable course and player character (the course is the only dimensional element; the marketing surface stays flat).
• Backend: Python/FastAPI — serves the application and any course/run endpoints needed by the Play surface.
• Storage: no persistent player-account or leaderboard storage is required in current scope; course definitions may be served from the backend.
• Packaging: Docker / docker-compose for the frontend and backend services.
• Kubernetes: not required for the current single-application deployment.

11. Assumptions and Constraints

Assumptions.

• A-1 (required_inference): The product is delivered as a browser-based game, since the user did not answer the browser-vs-downloadable question and browser delivery is the minimum that makes the accepted play journey usable without an install.
• A-2 (required_inference): Courses are authored by the designer and shipped with the product; player course-authoring was not accepted and is out of current scope.
• A-3 (required_inference): A play session is anonymous and single-session; no account, profile or persistent leaderboard is required by the accepted journey.
• A-4 (required_inference): The Landing leaderboard band is a presentation surface only; persistent ranking storage is not established in current scope.

Constraints.

• C-1 (explicit): The game must be an original obby experience, not a Roblox-hosted game.
• C-2 (explicit): The palette, fonts, surfaces, tone and layout in Section 6 are binding; the generic indigo/blue-on-white SaaS template is forbidden.
• C-3 (explicit): Readable text and controls stay whole at 375px, 768px and 1280px; decoration may bleed but must never cover readable text or controls.

Future considerations (not current scope). Player course authoring, downloadable distribution, accounts and persistent leaderboards, and multiplayer/social features are recorded only as open possibilities; they must not appear as current pages, controls or acceptance criteria.

12. Glossary

• Obby — an obstacle course game in which a player runs, jumps and climbs through a sequence of obstacles to reach a finish.
• Course — a named sequence of obstacles with checkpoints and a finish.
• Obstacle — a single jump, gap, climb or hazard the player must pass.
• Checkpoint — a flag on the course that records the player's progress and serves as the respawn point after a fall.
• Respawn — returning the player character to the last reached checkpoint (or the start) after a fall.
• Run — one attempt at a course, from start to finish or quit, with its own timer.
• HUD — the flat, opaque on-screen panels showing course name, timer, progress and controls during play.
• Hazard tape — the black/yellow 45deg diagonal band used as a section divider and as the in-game top-bar underline.
• PLAY NOW pill — the yellow #F5C518 pill with black text and a black arrow that launches a course from Landing.