System Requirements Document for shadow-fight-3

1. Introduction

Product intent. shadow-fight-3 is a fully detailed fighting game built to match Shadow Fight 3 as closely as possible in detail and mechanics. It is a dark, cinematic martial-arts fantasy in which silhouette warriors clash in architectural arena voids using steel, sweeping weapon arcs and shadow energy. Combat is the core of the product: fighters meet in encounters, exchange strikes, and each fight resolves to a win or a loss. Around that combat core sits a gear-progression loop — the fighter's weapons, armor, and abilities are equipped and upgraded between fights so the fighter is prepared for the next encounter.

Audience. Players who want visceral, high-drama combat and gear progression — an audience that expects a premium fighting game rather than a utility application. The emotional register is tense, kinetic, premium and slightly mythic.

Scope of this document. This SRD defines the current, buildable product: anonymous entry, self-service enrollment, returning verification, protected combat, and protected loadout preparation, backed by durable server-side fighter progression. It preserves the explicit hard constraint that the game must match Shadow Fight 3 as closely as possible in detail and mechanics, and it records the visual, typographic, layout and motion direction that gives the game its distinct point of view.

2. System Overview

shadow-fight-3 is a first-party, application-owned fighting game delivered as a custom web application with a backend that durably stores fighter progression, equipment, upgrades and fight outcomes.

Actors.

• Player — the active human who enters the arena, fights combat encounters, and advances a fighter through wins and losses.
• Fighter Customizer — the active human who prepares the fighter between fights by equipping and upgrading gear, weapons and abilities.
• Backend services — non-persona system actors that persist progression, equipment, upgrades and fight outcomes, and that resolve and record fight results.

Accepted behavior at a glance.

• Anonymous visitors can learn what the game is from a public entry surface.
• A new player can enroll themselves before first use.
• A returning player can verify identity and resume durable fighter progression and combat access.
• A verified player can start and play combat encounters, and each fight resolves to a win or a loss.
• A verified player (acting as the fighter customizer) can equip and upgrade the fighter's gear, weapons and abilities between fights.
• Durable fighter progression, equipment, upgrades and fight outcomes are executed and stored by the backend.

Narrow exclusions. This document does not define social, chat, guild, marketplace, live-ops, monetization, tournament, or spectator capabilities, and it does not define any page or module beyond the five pages in the page contract. No such capability is accepted by the authoritative requirement thread.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The game is first-party and application-owned. Combat, loadout preparation, enrollment and returning verification are all delivered as custom application surfaces; the backend owns durable state. There is no provider-owned or external-only surface in the current product, and no headless-only delivery path.

Access ownership. The public entry surface is anonymously reachable and explains the game before any identity is established. Enrollment and returning verification are themselves anonymously reachable, because a protected destination cannot own the interaction that establishes access to itself. Combat and loadout preparation are protected: they require a verified identity so that fighter progression, equipment, upgrades and fight outcomes remain bound to the correct player and can be resumed across sessions.

Current vs. future. Everything described in this document is current. No future-horizon capability is accepted by the authoritative thread; nothing in this document should be read as committing to a later phase.

2b. Source Content Inventory

Not applicable. The reference directive for Shadow Fight 3 declares uses: ["feature_reference", "domain_context"] with authority: inspiration_only, and no source material was supplied. No content_source directive exists, so no source content inventory is produced. Shadow Fight 3 supplies only the reference model for the game's detail and mechanics and its domain context; it supplies no product names, copy, facts or capabilities to be reproduced verbatim.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Presents the game's identity as a dark, cinematic martial-arts fighting game: the oversized stacked wordmark SHADOW FIGHT 3, a short statement of what the game is (silhouette fighters, steel, shadow energy, arena combat), and the two entry paths into the product — begin as a new player, or return as an existing player. No protected fighter state is shown or reachable here.
• Primary actions. Enter the Arena — the primary call to action, leading a new player toward enrollment. Continue Fight — the secondary link, leading a returning player toward verification.
• Supporting actions. Navigate to the enrollment surface; navigate to the returning-verification surface. Both are reachable directly from the floating capsule navigation rail.
• Domain entities. None owned. The page reads no fighter, loadout or fight state.
• Component responsibilities.
  • Arena hero — full-bleed dark arena field; a single rendered silhouette fighter occupying the right six columns, lit from behind by a molten-gold rim that bleeds off the right edge; the wordmark set flush-left across the left six columns in Josefin Sans light at clamp(56px, 12vw, 128px), each line offset to follow a shallow diagonal.
  • Curved ember band — a curved ember-coloured diagonal band cutting across the lower third, carrying Enter the Arena pinned bottom-left and Continue Fight as a secondary link.
  • Floating capsule navigation rail — top rail with a gold shadow-arc underline that slides to the active route; collapses to a bottom arc dock on mobile with the same curved indicator.
  • Curved section boundaries — each major section ends in a shallow S-curve or diagonal cut rather than a straight line.
• States.
  • Loading — the hero renders its composed first frame immediately; arena layers resolve progressively without blocking the wordmark or the two entry controls.
  • Empty — not applicable; the page has no collection.
  • Success — the visitor understands what the game is and can choose either entry path.
  • Error — if hero imagery fails to load, the dark arena field, the wordmark and both entry controls remain fully rendered and usable.
  • Recovery — imagery retries in the background; the page never blocks on it.

Sign Up

• Information and state. Anonymous self-service enrollment for a player beginning the game for the first time. Collects the minimum identity information needed to create a durable player record, and states plainly that enrollment creates the fighter progression that will be resumed later.
• Primary actions. Submit enrollment to create the player's identity and durable fighter record.
• Supporting actions. Navigate to returning verification if the visitor already has an identity; return to the public entry surface.
• Domain entities. Player identity; the newly created fighter record that progression will attach to.
• Component responsibilities.
  • Enrollment form — identity fields with inline validation, capsule or soft-rect controls with 2px radii, gold focus states.
  • Submission control — primary CTA in molten gold #C9A227.
  • Cross-link — a clear path to returning verification.
• States.
  • Loading — submission control enters a pending state; the form is not double-submittable.
  • Empty — the form begins empty with no pre-filled identity values.
  • Success — the player's identity and durable fighter record are created, and the player proceeds into protected play.
  • Error — invalid or incomplete fields are reported inline against the offending field; a rejected submission preserves everything the player already typed.
  • Recovery — the player corrects the reported field and resubmits without re-entering the rest of the form.

Login

• Information and state. Anonymous returning verification for a player who already has an identity and durable fighter progression. States that verifying resumes the player's fighter, equipment, upgrades and fight history.
• Primary actions. Submit credentials to verify identity and resume protected access.
• Supporting actions. Navigate to enrollment if the visitor has no identity; return to the public entry surface.
• Domain entities. Player identity; the resumed fighter record and its progression.
• Component responsibilities.
  • Verification form — identity fields with inline validation and gold focus states.
  • Submission control — primary CTA in molten gold #C9A227.
  • Cross-link — a clear path to enrollment.
• States.
  • Loading — submission control enters a pending state; the form is not double-submittable.
  • Empty — the form begins empty.
  • Success — identity is verified and the player is returned to protected play with their fighter progression intact.
  • Error — incorrect or unrecognized credentials produce a clear, non-revealing failure message; entered values are preserved.
  • Recovery — the player retries, or follows the cross-link to enrollment if they have no identity.

Fight

• Information and state. Protected combat surface. Owns starting a combat encounter and playing it through to resolution. Shows the player's fighter on the left fighter column, the arena stage in the centre, and the opponent on the right opponent column. Displays both fighters' health as luminous curved strokes with a gold crescent cap, and the player's shadow energy as a matching curved stroke. Displays the encounter's outcome once the fight resolves.
• Primary actions. Start a combat encounter; perform the fighter's combat actions during the encounter; acknowledge the resolved outcome.
• Supporting actions. Return to loadout preparation between fights; leave the encounter.
• Domain entities. Fighter (player's), Opponent fighter, Encounter, Health state, Shadow energy state, Fight outcome (win or loss), Fight record.
• Component responsibilities.
  • Left fighter column — the player's fighter, its health stroke and its shadow-energy stroke.
  • Centre stage — the arena void with sweeping curved architecture, lit by a single warm rim light; the combat field where strikes, weapon arcs and shadow-energy effects resolve.
  • Right opponent column — the opponent fighter and its health stroke, using ember #E4572E for the opponent's side and for damage and danger states.
  • Curved health and shadow-energy strokes — luminous curved strokes with a gold crescent cap, draining with a liquid ease rather than a snap; never flat rectangles.
  • Outcome panel — presents the resolved win or loss, the encounter's result, and the continuation into the next fight or back into loadout preparation.
• States.
  • Loading — the arena and both fighters resolve before the encounter becomes interactive; the encounter cannot be acted on until it is ready.
  • Empty — no encounter is in progress; the surface offers starting one.
  • Success — the encounter resolves to a win; the outcome is recorded and the player continues.
  • Error* — if the encounter cannot be started or its result cannot be recorded, the player is told plainly and the encounter is not counted as played.
  • Recovery — the player can restart the encounter or return to loadout preparation; a fight whose result failed to record is not silently treated as a win or a loss.

Loadout

• Information and state. Protected preparation surface. Owns recurring preparation between fights: equipping and upgrading the fighter's gear, weapons and abilities. Presents the fighter at the centre of a circular gear carousel, with equipped items orbiting on curved spokes and upgrade levels shown as arc segments on the ring. Shows each item's current upgrade level and the effect of the next upgrade.
• Primary actions. Equip a gear, weapon or ability item to the fighter; upgrade an equipped or owned item.
• Supporting actions. Inspect an item's current level and next-level effect; return to combat when the fighter is prepared.
• Domain entities. Fighter, Gear item, Weapon item, Ability item, Equipped set, Upgrade level, Upgrade cost or requirement.
• Component responsibilities.
  • Central fighter figure — the fighter rendered at the centre of the ring, updating as equipment changes.
  • Curved equipment ring — a circular carousel with equipped items on curved spokes; upgrade levels rendered as arc segments on the ring itself.
  • Item detail panel — the selected item's identity, current level, and the effect of upgrading it.
  • Equip and upgrade controls — capsule or soft-rect controls with 2px radii; gold #C9A227 for active and focus states; muted #6E7480 for disabled states.
• States.
  • Loading — the ring and the fighter's current equipped set resolve before equip and upgrade controls become active.
  • Empty — the fighter has no item in a slot; the slot is shown as an empty spoke with a clear invitation to equip.
  • Success — the item is equipped or upgraded, the fighter figure and the ring's arc segments update, and the change is durably recorded.
  • Error — an equip or upgrade that cannot be completed reports why (for example, an unmet requirement) and leaves the previous equipped set and levels unchanged.
  • Recovery — the player selects a different item or meets the reported requirement and retries; no partial equip or partial upgrade is left behind.

3. Functional Requirements

Each requirement is a distinct story point with its provenance, lifecycle facts and observable acceptance.

FR-1 — Anonymous entry to the game. As an anonymous visitor, I should be able to learn what shadow-fight-3 is and choose how to enter it, so that I can decide whether to begin or return.

• Provenance: required_inference (public entry surface).
• Trigger: the visitor opens the game.
• Observable result: the public entry surface presents the game's identity as a dark, cinematic martial-arts fighting game and offers both entry paths — begin as a new player, or return as an existing player.
• Access state: anonymous; no protected fighter state is shown or reachable.
• Failure/recovery: if hero imagery fails, the wordmark and both entry controls remain fully rendered and usable.
• Continuation: the visitor proceeds to enrollment or to returning verification.

FR-2 — Self-service enrollment before first use. As a new player, I should be able to enroll myself before first use, so that I have an identity and a durable fighter record to progress.

• Provenance: required_inference (identity access surface; required to make the accepted journey executable).
• Trigger: the visitor chooses to begin as a new player.
• Observable result: the player's identity and durable fighter record are created, and the player proceeds into protected play.
• Access state: anonymous entry; the enrollment interaction is reachable without an existing identity.
• Failure/recovery: invalid or incomplete fields are reported inline against the offending field, and everything already typed is preserved for correction and resubmission.
• Continuation: the player enters protected play with a fighter record ready for combat and loadout preparation.

FR-3 — Returning verification before resuming protected progression and combat. As a returning player, I should be able to verify my identity, so that I can resume my durable fighter progression and combat access.

• Provenance: required_inference (identity access surface; required to make the accepted journey executable).
• Trigger: the player chooses to return as an existing player.
• Observable result: identity is verified and the player resumes protected play with their fighter progression, equipment, upgrades and fight history intact.
• Access state: anonymous entry; the verification interaction is reachable without an active session.
• Failure/recovery: incorrect or unrecognized credentials produce a clear, non-revealing failure message with entered values preserved; the player retries or follows the cross-link to enrollment.
• Continuation: the player resumes combat and loadout preparation.

FR-4 — Start and play a combat encounter. As a Player, I should be able to start and play a combat encounter, so that I can fight an opponent in the arena.

• Provenance: explicit (the game must be playable as a fighting game with combat encounters between fighters).
• Trigger: the verified player starts an encounter.
• Observable result: the arena stage loads with the player's fighter on the left fighter column and the opponent on the right opponent column, both fighters' health shown as luminous curved strokes with a gold crescent cap, and the player's shadow energy shown as a matching curved stroke; the player performs combat actions and the encounter plays out.
• Access state: protected; requires a verified identity.
• Failure/recovery: if the encounter cannot be started, the player is told plainly and the encounter is not counted as played; the player can restart it or return to loadout preparation.
• Continuation: the encounter resolves to a win or a loss.

FR-5 — Fight resolution to a win or a loss. As a Player, I should see each fight resolve to a win or a loss, so that I know the outcome and can continue.

• Provenance: explicit (combat encounters between fighters; the fight resolves to a win or loss outcome).
• Trigger: the encounter reaches its end condition.
• Observable result: the outcome panel presents the resolved win or loss, health strokes drain with a liquid ease rather than a snap, and the outcome is recorded against the player's fighter.
• Access state: protected; requires a verified identity.
• Failure/recovery: if the result cannot be recorded, the player is told plainly and the fight is not silently treated as a win or a loss; the player can replay the encounter.
• Continuation: the player continues into the next fight or returns to loadout preparation.

FR-6 — Equip the fighter's gear, weapons and abilities. As a Fighter Customizer, I should be able to equip my fighter's gear, weapons and abilities, so that the fighter is prepared for subsequent fights.

• Provenance: required_inference (recurring preparation between fights, per the accepted loadout responsibility).
• Trigger: the player opens loadout preparation between fights and selects an item.
• Observable result: the item is equipped to the fighter, the central fighter figure and the curved equipment ring update to reflect the equipped set, and the change is durably recorded.
• Access state: protected; requires a verified identity.
• Failure/recovery: an equip that cannot be completed reports why and leaves the previous equipped set unchanged; no partial equip is left behind.
• Continuation: the player returns to combat with the updated loadout.

FR-7 — Upgrade the fighter's gear, weapons and abilities. As a Fighter Customizer, I should be able to upgrade my fighter's gear, weapons and abilities, so that the fighter grows stronger for subsequent fights.

• Provenance: required_inference (recurring preparation between fights, per the accepted loadout responsibility).
• Trigger: the player selects an owned or equipped item and chooses to upgrade it.
• Observable result: the item's upgrade level advances, the arc segments on the curved equipment ring update to show the new level, and the change is durably recorded.
• Access state: protected; requires a verified identity.
• Failure/recovery: an upgrade that cannot be completed reports why (for example, an unmet requirement) and leaves the item's level unchanged; no partial upgrade is left behind.
• Continuation: the player continues preparing or returns to combat.

FR-8 — Durable backend execution of progression, equipment, upgrades and fight outcomes. As the system, I should durably execute and store fighter progression, equipment, upgrades and fight outcomes, so that a player's fighter is preserved and correctly bound to that player across sessions.

• Provenance: required_inference (required to make the accepted journeys executable).
• Trigger: enrollment creates a fighter record; a fight resolves; an item is equipped or upgraded.
• Observable result: progression, equipment, upgrades and fight outcomes are persisted server-side and remain bound to the correct player identity.
• Access state: backend execution supporting protected surfaces; no human interacts with this capability directly.
• Failure/recovery: a failed write is surfaced to the initiating surface as a plain failure rather than a silent success.
• Continuation: the persisted state is available the next time the player verifies identity.

4. User Personas

Player

Product context. The Player is the person who plays the game. They arrive at the public entry surface without an identity, decide the game is worth their time, and either enroll as a new player or verify as a returning one. Once inside, their working context is the arena: a dark architectural void with sweeping curved architecture, lit by a single warm rim light, where their fighter faces an opponent.

Primary goal. To fight through the game's combat encounters and advance their fighter — entering fights, playing them out, and seeing each one resolve to a win or a loss.

Distinct accepted responsibilities. The Player owns starting combat encounters and playing them to resolution. They are the only actor who initiates a fight and the only actor who experiences its outcome. They also own the decision to return to loadout preparation between fights when their fighter needs to be stronger.

Relevant inputs and decisions. The Player decides whether to begin or return at the public entry surface; supplies identity information at enrollment or verification; chooses when to start an encounter; performs combat actions during the encounter; and decides, after each resolved outcome, whether to continue into the next fight or return to loadout preparation.

Interactions with other accepted participants. The Player interacts with the Fighter Customizer role as the same human in a different working context: the Player's decision to return to loadout preparation hands off to the Fighter Customizer's equip-and-upgrade work, and the Fighter Customizer's completed preparation hands back to the Player as a fighter ready to fight. The Player also depends on backend services to record each fight outcome so that progression survives across sessions.

Observable success. The Player completes fights and progresses: each encounter resolves to a win or a loss, the outcome is recorded, and the fighter's state carries forward into the next encounter.

Fighter Customizer

Product context. The Fighter Customizer is the role the same human takes on between fights. Their working context is the loadout surface: the fighter stands at the centre of a circular gear carousel, with equipped items orbiting on curved spokes and upgrade levels shown as arc segments on the ring. This is a preparation context, not a combat context — nothing here is a fight.

Primary goal. To produce an equipped, upgraded fighter who is ready to fight.

Distinct accepted responsibilities. The Fighter Customizer owns equipping the fighter's gear, weapons and abilities, and owns upgrading those items. They inspect an item's current level and the effect of the next upgrade, decide what to equip, and decide what to upgrade. They do not start or play encounters.

Relevant inputs and decisions. The Fighter Customizer selects items from the curved equipment ring, reads each item's current level and next-level effect, decides which items to equip into the fighter's set, and decides which items to upgrade given their requirements.

Interactions with other accepted participants. The Fighter Customizer receives the handoff from the Player's decision to prepare between fights, and hands back a fighter ready for combat. They depend on backend services to durably record the equipped set and upgrade levels so that preparation is not lost.

Observable success. The fighter is equipped and upgraded, the central fighter figure and the ring's arc segments reflect the change, the change is durably recorded, and the fighter is ready for the next fight.

5. Core User Flows

Flow A — A new player enrolls and enters the arena

1. The visitor opens shadow-fight-3 and lands on Landing, anonymously reachable.
2. The visitor reads the game's identity — silhouette fighters, steel, shadow energy, arena combat — presented as the oversized stacked wordmark SHADOW FIGHT 3 over a full-bleed dark arena, with a single rendered silhouette fighter on the right lit by a molten-gold rim.
3. The visitor chooses Enter the Arena, the primary call to action pinned bottom-left on the curved ember band.
4. The visitor arrives at Sign Up, anonymously reachable, and completes the enrollment form.
5. On submission, the player's identity and durable fighter record are created, and the player proceeds into protected play.
6. Failure/recovery: if a field is invalid or incomplete, the error is reported inline against that field and everything already typed is preserved; the visitor corrects it and resubmits.
7. Continuation: the player enters protected play with a fighter record ready for combat and loadout preparation.

Flow B — A returning player verifies and resumes

1. The returning player opens shadow-fight-3 and lands on Landing.
2. The player chooses Continue Fight, the secondary link on the curved ember band.
3. The player arrives at Login, anonymously reachable, and submits their credentials.
4. On success, identity is verified and the player resumes protected play with their fighter progression, equipment, upgrades and fight history intact.
5. Failure/recovery: incorrect or unrecognized credentials produce a clear, non-revealing failure message with entered values preserved; the player retries, or follows the cross-link to Sign Up if they have no identity.
6. Continuation: the player resumes combat and loadout preparation.

Flow C — The Player fights an encounter to a resolved outcome

1. The verified Player enters Fight, a protected surface.
2. The arena stage loads: the player's fighter on the left fighter column, the opponent on the right opponent column, both health strokes rendered as luminous curved strokes with a gold crescent cap, and the player's shadow energy as a matching curved stroke. The encounter is not interactive until it is ready.
3. The Player starts the encounter and performs combat actions; strikes, weapon arcs and shadow-energy effects resolve on the centre stage.
4. Health strokes drain with a liquid ease rather than a snap as damage lands; the opponent's side and damage states use ember #E4572E.
5. The encounter reaches its end condition and resolves to a win or a loss.
6. The outcome panel presents the resolved outcome, and the outcome is recorded against the player's fighter.
7. Failure/recovery: if the encounter cannot be started, or its result cannot be recorded, the Player is told plainly and the encounter is not counted as played; the Player can restart it or return to loadout preparation. A fight whose result failed to record is never silently treated as a win or a loss.
8. Continuation: the Player continues into the next fight, or returns to Loadout to prepare.

Flow D — The Fighter Customizer prepares the fighter between fights

1. After a resolved fight, the Player decides the fighter needs to be stronger and enters Loadout, a protected surface.
2. The fighter appears at the centre of the circular gear carousel, with equipped items orbiting on curved spokes and upgrade levels shown as arc segments on the ring. The ring and the current equipped set resolve before equip and upgrade controls become active.
3. The Fighter Customizer selects an item on the ring and reads its identity, current level, and the effect of the next upgrade in the item detail panel.
4. The Fighter Customizer equips the item. The central fighter figure and the curved equipment ring update to reflect the new equipped set, and the change is durably recorded.
5. The Fighter Customizer selects an item to upgrade and confirms. The item's upgrade level advances, the arc segments on the ring update to show the new level, and the change is durably recorded.
6. Failure/recovery: an equip or upgrade that cannot be completed reports why — for example, an unmet requirement — and leaves the previous equipped set and levels unchanged; no partial equip or partial upgrade is left behind. The Fighter Customizer selects a different item or meets the reported requirement and retries.
7. Continuation: the Fighter Customizer returns to Fight with an equipped, upgraded fighter ready for the next encounter.

Flow E — Backend execution preserves the fighter

1. Enrollment creates the player's fighter record.
2. A fight resolves and its outcome is written against that fighter.
3. An item is equipped or upgraded and the equipped set and upgrade levels are written.
4. Progression, equipment, upgrades and fight outcomes remain bound to the correct player identity and are available the next time the player verifies identity at Login.
5. Failure/recovery: a failed write is surfaced to the initiating surface as a plain failure rather than a silent success.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Zaha Hadid. Headline idea: Fluid parametric grandeur — a shadow fighter carved from sweeping light.

Mode. Dark mode only.

Colour tokens (exact hex, by role).

White-on-charcoal and gold-on-charcoal both exceed 4.5:1 at body size. Gold is never used for long body copy.

Typography.

• Headings: Josefin Sans — wide, light-to-regular weights (300/400), generous tracking for micro-labels, tightening to 0.02em for large display. Uppercase for arena names, fighter names and section eyebrows; sentence case for narrative copy.
• Body: Jost.
• Scale: 1.333 modular — 128 / 96 / 72 / 56 / 40 / 28 / 20 / 16 / 14, with clamp() on every display size so 375px never overflows.
• Hero wordmark: clamp(56px, 12vw, 128px).
• Section hierarchy: 40 / 28 / 20 / 16 / 14.

Shape language. Continuous parametric curves and sweeping arcs. Section boundaries are not straight — they are shallow S-curves or diagonal cuts. Buttons and chips are capsule or soft-rect with 2px radii; larger panels use 24–32px radii with one corner pulled into a larger curve. Progress bars are arc segments or curved strokes, not flat rectangles. A recurring shadow arc motif — a thin luminous crescent — acts as a divider, a tab indicator and a health-bar cap.

Spacing rhythm. An asymmetric editorial grid on a 12-column base. Every section alternates between a full-bleed dark field (#0B0C10) and a slightly raised surface (#16181D) separated by a curved boundary, creating a continuous architectural flow down the page.

Imagery style. High-contrast silhouette photography and rendered 3D forms: a lone fighter in a wide stance, weapon arcs caught as motion trails, shadow-energy wisps rendered as luminous curves. Arenas are dark architectural voids with sweeping curved architecture, lit by a single warm rim light. No stock people, no cartoon clip art, no gradient blobs. Icons are thin-stroke geometric pictograms with one curved detail.

Explicitly avoided. Blue/indigo primary or accent on white; a centred hero with headline + subtext + blue button + gradient blob; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui for headings or body; a grid of identical hover-lift cards with uniform rounded corners; flat rectangular health bars and straight-edged section dividers; cartoon or chibi fighter art, stock photography of real people, or clip-art icons; glassmorphism blur panels and neon cyan/violet glows; decorative motion that cannot be reduced to a static, fully readable layout under prefers-reduced-motion. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Readable text and controls. 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 they cover no readable text or control. Where the direction asks readable text or a control to be cropped, clipped, covered or run off an edge, the text or control stays whole and the gesture is carried by imagery or decoration instead.

7. Signature Design Concept

The arena is the composition. The public entry is not a headline over a button; it is the arena itself, composed as a single architectural gesture.

• Full-bleed dark arena. The #0B0C10 void fills the viewport. A single rendered silhouette fighter dominates the right six columns, lit from behind by a molten-gold rim that bleeds off the right edge — the light source is outside the frame, so the figure reads as carved from sweeping light rather than placed on a background.
• Oversized diagonal wordmark. The left six columns carry SHADOW FIGHT 3 in Josefin Sans light at clamp(56px, 12vw, 128px), set flush-left with tight leading, each line offset to follow a shallow diagonal. The final line bleeds slightly off the left edge as a graphic gesture while remaining fully readable at 375px through clamp and wrapping.
• Curved ember band. A curved #E4572E diagonal band cuts across the lower third, carrying Enter the Arena pinned bottom-left as the primary CTA and Continue Fight as a secondary link. The band is the only saturated ember mass on the page, so the eye travels wordmark → fighter → band → CTA.
• Floating capsule navigation rail. A top rail with a gold shadow-arc underline that slides to the active route; on mobile it docks as a bottom arc with the same curved indicator.
• Curved section boundaries. Every major section ends in a shallow S-curve or diagonal cut rather than a straight line, so the page reads as one continuous architectural flow rather than a stack of blocks.

No centred headline, no blue button, no gradient blob. The composition is the arena.

8. Interaction Model & Motion Direction

Interaction Model: Parallax Motion Tempo: cinematic Hero Dimensionality: layered_2d

Landing Hero Motion Brief.

• Focal subject: the lone silhouette fighter on the right six columns, rim-lit in molten gold, with shadow-energy wisps rendered as luminous curves and weapon arcs caught as motion trails.
• Input → transformation → outcome thesis: as the visitor scrolls, the arena layers drift at different rates and the camera pans slowly across the fighter silhouette; the wordmark's diagonal lines hold their offset while the arena moves behind them, so the visitor's scroll is transformed into a slow camera move through the arena, and the outcome is that the visitor arrives at the curved ember band with Enter the Arena and Continue Fight fully legible and ready.
• Motion vocabulary: slow parallax drift of the arena layers; a scroll-linked camera pan across the fighter silhouette; curved mask wipes rather than fades at section transitions; a subtle rim-light sweep along a card's curved edge on hover; health bars that drain with a liquid ease, never a snap.
• Composed first frame: the arena void at rest, the fighter fully lit by the gold rim bleeding off the right edge, the wordmark set flush-left across the left six columns on its shallow diagonal, and the curved ember band already carrying both entry controls — a complete, readable composition before any motion begins.
• Reduced-motion state: under prefers-reduced-motion, parallax and wipes stop. The hero sits in a static, fully readable layout: the composed first frame is the final frame, the wordmark and both entry controls remain whole and uncovered, and any horizontally arranged content wraps into rows or becomes a horizontally scrollable row whose further items are reached by scrolling.

9. Non-Functional Requirements

NFR-1 — Reference fidelity. The game must be a fighting game closely modeled on Shadow Fight 3, matching it as closely as possible in detail and mechanics. Provenance: explicit hard constraint. Rationale: this is the authoritative product commitment and the standard against which the game's combat, progression and presentation are judged.

NFR-2 — Combat responsiveness. Combat encounters must accept and resolve the player's combat actions without perceptible input lag, so that strikes, weapon arcs and shadow-energy effects read as the direct consequence of the player's input. Provenance: required_inference. Rationale: a fighting game whose combat does not respond to input in real time cannot deliver the accepted combat encounter.

NFR-3 — Durable, correctly bound progression. Fighter progression, equipment, upgrades and fight outcomes must be persisted server-side and remain bound to the correct player identity across sessions. Provenance: required_inference. Rationale: the accepted journeys require that a returning player resumes their fighter, and that a fight outcome is not lost or misattributed.

NFR-4 — Protected state is not reachable anonymously. Combat and loadout preparation require a verified identity; no protected fighter state is exposed on the anonymously reachable surfaces. Provenance: required_inference. Rationale: durable actor-specific progression must remain bound to the correct participant.

NFR-5 — Accessible, whole text and controls. Readable 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. Provenance: explicit (creative direction). Rationale: the direction's cropping and bleeding gestures apply to imagery and decoration, never to readable text or controls.

NFR-6 — Reduced-motion compliance. All motion respects prefers-reduced-motion: parallax and wipes stop, and content sits in a static, fully readable layout. Provenance: explicit (creative direction). Rationale: decorative motion must never be the only way to reach content.

NFR-7 — Contrast. White-on-charcoal and gold-on-charcoal both exceed 4.5:1 at body size; gold is never used for long body copy. Provenance: explicit (creative direction). Rationale: the dark palette must remain legible at body size.

10. Tech Stack

No technology choices are specified by the authoritative requirement thread or the Planning Scope. The following are the minimum coherent choices for the accepted product, labeled as defaults.

• Frontend: React — [Default — not specified by user]. Rationale: a custom-UI, application-owned product with five custom pages and a motion-heavy, layered-2D hero.
• Backend: Python / FastAPI — [Default — not specified by user]. Rationale: the accepted product requires backend execution for durable fighter progression, equipment, upgrades and fight outcomes.
• Storage: a persistent datastore appropriate to durable player, fighter, equipment, upgrade and fight-outcome records — [Default — not specified by user]. Rationale: NFR-3 requires progression to survive across sessions and remain bound to the correct player.
• Containerization: Docker / docker-compose — [Default — not specified by user]. Rationale: a single coherent local and deployment composition for the frontend, backend and datastore.
• Orchestration: Kubernetes is not required by any accepted requirement and is not included — [Default — not specified by user].

11. Assumptions and Constraints

Constraints (binding).

• The game must be a fighting game closely modeled on Shadow Fight 3, matching it as closely as possible in detail and mechanics. This is an explicit hard constraint and applies project-wide.
• The public entry surface is anonymously reachable; combat and loadout preparation require a verified identity.
• Durable fighter progression, equipment, upgrades and fight outcomes are executed and stored by the backend.
• The creative direction is authoritative for visuals, colour, typography, shape, layout, imagery and motion, including its explicit avoid-list and its readable-text-and-controls rule.

Assumptions (narrow, labeled).

• Assumption: the game is delivered as a first-party custom web application with an application-owned backend. Basis: delivery_shape.custom_ui = true and delivery_shape.app_owned_identity = true in the Planning Scope.
• Assumption: enrollment is self-service and returning verification uses credentials the player established at enrollment. Basis: the accepted requirement that the player completes self-service enrollment before first use and returning verification before resuming protected progression and combat.
• Assumption: the Player and the Fighter Customizer are two working contexts of the same human, not two separately authenticated accounts. Basis: the accepted persona catalog and the handoff between preparation and combat.
• Assumption: the reference directive for Shadow Fight 3 is inspiration_only and supplies only the reference model for detail and mechanics and its domain context; no verbatim names, copy, facts or assets are reproduced from it. Basis: the declared uses and authority of the reference directive.
• Assumption: no social, chat, guild, marketplace, live-ops, monetization, tournament or spectator capability is in scope. Basis: no such capability is accepted by the authoritative requirement thread.

Unspecified qualifiers retained. The authoritative thread does not specify a platform target, a content rating, a monetization model, a matchmaking model, a roster size, or a number of arenas, weapons, armor pieces or abilities. These remain unspecified and are not invented here.

12. Glossary

• Arena — the dark architectural combat void with sweeping curved architecture, lit by a single warm rim light, in which a combat encounter takes place.
• Combat encounter — a single fight between the player's fighter and an opponent, started on the Fight surface and played through to a resolved win or loss.
• Fight outcome — the resolved result of a combat encounter: a win or a loss, recorded against the player's fighter.
• Fighter — the player's combatant, whose progression, equipment and upgrade levels are durably bound to the player's identity.
• Fighter Customizer — the accepted active human role that prepares the fighter between fights by equipping and upgrading gear, weapons and abilities.
• Gear / weapon / ability item — an equippable or upgradable item belonging to the fighter; items orbit on curved spokes of the loadout's equipment ring.
• Health stroke — a fighter's health rendered as a luminous curved stroke with a gold crescent cap, draining with a liquid ease rather than a snap.
• Loadout — the fighter's currently equipped set of gear, weapons and abilities.
• Player — the accepted active human role that enters the arena, fights combat encounters, and advances a fighter through wins and losses.
• Shadow arc — the recurring thin luminous crescent motif used as a divider, a tab indicator and a health-bar cap.
• Shadow energy — the player's combat resource, rendered as a luminous curved stroke matching the health stroke.
• Upgrade level — the current advancement level of an item, shown as an arc segment on the loadout's curved equipment ring.