System Requirements Document for the-hollow-king

1. Introduction

the-hollow-king is a classic first-person perspective dungeon crawler, delivered together with the concrete, ordered, best-practice production plan needed to build it. The product intent is twofold and inseparable:

1. The game itself — a grid-based, first-person descent through torchlit stone, where a Player assembles a party, explores dungeon levels, fights creatures, completes a main story and side quests, and manages inventory and character progression through a purpose-built user interface.
2. The authored production plan — the requester explicitly asked for the concrete steps, in order, according to best practice, covering main story, side quests, character assets, dungeon assets, creatures, and user interface. That ordered sequence is a first-class deliverable, not background advice.

The audience is the Player, who wants the weight and dread of 1990s grid-based crawlers, and the Game Content Author, who authors and organizes the story, quest, asset, creature, dungeon, and interface content so the Player's journey is playable. The register is grim, tactile, and authored — a physical artefact, a mouldy tome, a wax seal, a dungeon master's notebook — never glossy, neon, or futuristic.

2. System Overview

The system is a single first-party application with twelve cohesive destinations. Eight of them serve the authored production of the game; four of them are the game.

• Landing is the anonymous public entry: it explains the classic first-person dungeon crawler, its intended player experience, and its content-production purpose.
• Production Plan presents the concrete best-practice production sequence and coordinates the required story, quest, asset, creature, dungeon, and interface work.
• Story, Quests, Characters, Dungeons, Creatures, and Interface are the chapter destinations that own creation and revision of each content discipline.
• Dungeon Run is the Player's cohesive first-person exploration, combat, story, side-quest, inventory, and progression experience.
• Character is the Player's character sheet: party-member stats, inventory, equipment, and progression, plus the character journal that tracks every quest.
• Map is the Player's full-page hand-drawn map of the current dungeon level, with the explored shape, the party's position, and the rotating compass rose.
• Journal is the Player's quest log: the main quest and every side quest, each with its objectives, dependencies, completion flow, and completion state.

Actors are the two accepted human personas — Player and Game Content Author — plus the game's own runtime systems (dungeon simulation, combat resolution, quest-state tracking, save/load) which are non-persona system actors. No provider or external destination is accepted for any current behavior.

Current delivery is the full twelve-destination application and the playable dungeon run. Nothing in the accepted thread establishes a future horizon; no future section is therefore asserted.

2a. Product Interpretation and Delivery Boundary

The authoritative request is to build a classic first-person perspective dungeon crawler and to be given the concrete ordered steps, according to best practice, for producing its main story, side quests, character assets, dungeon assets, creatures, and user interface. Both halves are current commitments.

The production half is delivered as first-party authored surfaces: the Production Plan ledger states the ordered sequence, and each chapter destination (Story, Quests, Characters, Dungeons, Creatures, Interface) owns the actual content of its discipline. The game half is delivered as the Dungeon Run destination, which is where the Player's first-person exploration, combat, quest completion, inventory, and progression actually happen, supported by three Player-facing companion destinations: Character (stats, inventory, and the character journal), Map (the full-page hand-drawn level map), and Journal (the quest log for the main quest and all side quests).

Access is deliberately open. The Planning Scope contract records access_requirement: none for every one of the twelve destinations, and no accepted journey requires a human to privately own or resume durable actor-specific state across sessions in a way that would force an application-owned identity boundary. There is therefore no sign-in, no account creation, and no permission tiering in the current product. The Player enters the dungeon directly from the public entry; the Game Content Author works the chapter pages directly. Differentiated visibility or control over shared state is not established by any source, so no role-based access control is specified.

Everything the product does is first-party and in-application. There is no provider-owned surface, no external destination, and no headless delivery mode in the accepted scope.

2b. Source Content Inventory

Not applicable. No reference directive in the supplied material declares content_source authority, so no source content inventory is rendered.

2c. Page Content and Component Coverage

Landing

• Information and state: The public, anonymous first impression. States the game is a classic first-person perspective dungeon crawler, describes the intended player experience (torchlit stone, grid-based descent, dread and weight), and states the content-production purpose of the accompanying plan. No identity, no session, no persisted state.
• Primary actions: Enter the dungeon (proceed to Dungeon Run). Read the "what this is" essay.
• Supporting actions: Follow the numbered production-sequence strip into the Production Plan; move into any chapter destination.
• Domain entities: Game premise, intended player experience, production-sequence summary.
• Component responsibilities: Full-bleed hero with the monumental carved title overlapping the torchlit corridor photograph; a single-column "what this is" essay; a numbered production-sequence strip; a wax-seal entry control.
• States: Loading — hero photograph and type resolve; Empty — not applicable, content is static and always present; Success — visitor reads the premise and either enters the dungeon or opens the production sequence; Error — hero imagery fails to load, in which case the carved title, essay, and entry control remain fully readable on the dark stone ground; Recovery — the entry control and all navigation remain operable without imagery.

Production Plan

• Information and state: The concrete, ordered, best-practice production sequence. Nine numbered steps (01–09) covering main story, side quests, character assets, dungeon assets, creatures, user interface, and the integration and validation work that binds them. Each step carries a status.
• Primary actions: Read the ordered sequence; open the chapter destination that owns a step; mark a step complete.
• Supporting actions: Reorder attention by revisiting a step; return to Landing.
• Domain entities: Production step (number, title, discipline, description, status), discipline reference (Story, Quests, Characters, Dungeons, Creatures, Interface).
• Component responsibilities: Vertical numbered ledger with one full-width row per step, a hand-ruled separator between rows, a wax-seal status stamp per row, and a link from each row into its owning chapter.
• States: Loading — ledger rows resolve in order; Empty — no steps recorded, showing the ordered sequence as unstarted; Success — all nine steps visible in order with their statuses; Error — a step's status cannot be recorded, in which case the step remains visible and its prior status is retained; Recovery — the step can be marked again, and the ledger never loses its ordering.

Story

• Information and state: The main story that structures the dungeon crawler's progression. Owns the story's premise, its progression structure across dungeon levels, and its revisions.
• Primary actions: Create a main story entry; revise it.
• Supporting actions: Review the story against the production sequence; return to Production Plan.
• Domain entities: Main story (premise, progression structure, revision state).
• Component responsibilities: Chapter page with a left-hand marginal number, a large title, and a two-column body/marginalia layout; the story body; a revision control.
• States: Loading — chapter content resolves; Empty — no main story defined yet, showing the chapter as awaiting its first entry; Success — the main story is present and readable as the structure for progression; Error — a revision cannot be saved, in which case the previously saved story remains intact and readable; Recovery — the author can re-enter and save the revision again.

Quests

• Information and state: The side-quest content supporting the main story — each quest's objectives, its dependencies, and its completion flow.
• Primary actions: Create a side quest; define its objectives; define its dependencies; define its completion flow.
• Supporting actions: Review quests against the main story; return to Production Plan.
• Domain entities: Side quest (title, objectives, dependencies, completion flow, completion state).
• Component responsibilities: Chapter page with marginal number and two-column layout; a quest list; a quest detail region holding objectives, dependencies, and completion flow.
• States: Loading — quest list resolves; Empty — no side quests defined, showing the chapter as awaiting its first quest; Success — quests listed with objectives, dependencies, and completion flow readable; Error — a quest cannot be saved, in which case the last saved quest content remains; Recovery — the author can re-enter the quest and save again.

Characters

• Information and state: Character asset planning and organization for the party and supporting characters.
• Primary actions: Plan a character asset; organize characters into party and supporting groups.
• Supporting actions: Review characters against the story and quests; return to Production Plan.
• Domain entities: Character (name, role in party or supporting cast, asset plan, organization group).
• Component responsibilities: Chapter page with marginal number and two-column layout; a character roster; a character detail region holding the asset plan and organization.
• States: Loading — roster resolves; Empty — no characters planned, showing the chapter as awaiting its first character; Success — party and supporting characters organized with their asset plans; Error — a character cannot be saved, in which case the last saved character content remains; Recovery — the author can re-enter and save again.

Dungeons

• Information and state: Dungeon layouts, environmental assets, encounter spaces, and level progression design.
• Primary actions: Define a dungeon layout; define its environmental assets; define its encounter spaces; define its level progression.
• Supporting actions: Review dungeons against the story and creatures; return to Production Plan.
• Domain entities: Dungeon level (layout, environmental assets, encounter spaces, progression position).
• Component responsibilities: Chapter page with marginal number and two-column layout; a level list; a level detail region holding layout, environmental assets, encounter spaces, and progression.
• States: Loading — level list resolves; Empty — no dungeon levels defined, showing the chapter as awaiting its first level; Success — levels listed with layout, assets, encounter spaces, and progression readable; Error — a level cannot be saved, in which case the last saved level content remains; Recovery — the author can re-enter and save again.

Creatures

• Information and state: Creature asset and behavior definitions used to populate dungeon encounters.
• Primary actions: Define a creature asset; define its behavior.
• Supporting actions: Review creatures against dungeon encounters; return to Production Plan.
• Domain entities: Creature (asset definition, behavior definition, encounter assignment).
• Component responsibilities: Chapter page with marginal number and two-column layout; a creature list; a creature detail region holding asset and behavior definitions.
• States: Loading — creature list resolves; Empty — no creatures defined, showing the chapter as awaiting its first creature; Success — creatures listed with asset and behavior definitions readable; Error — a creature cannot be saved, in which case the last saved creature content remains; Recovery — the author can re-enter and save again.

Interface

• Information and state: The user-interface design for first-person play, combat, inventory, and character progression.
• Primary actions: Define the first-person play interface; define the combat interface; define the inventory interface; define the character-progression interface.
• Supporting actions: Review the interface design against the dungeon run; return to Production Plan.
• Domain entities: Interface specification (surface area — first-person play, combat, inventory, progression — and its design).
• Component responsibilities: Chapter page with marginal number and two-column layout; a surface-area list; a specification detail region.
• States: Loading — specification list resolves; Empty — no interface specification defined, showing the chapter as awaiting its first entry; Success — all four surface areas specified and readable; Error — a specification cannot be saved, in which case the last saved specification remains; Recovery — the author can re-enter and save again.

Dungeon Run

• Information and state: The Player's cohesive first-person experience. Current dungeon level, party composition and condition, active combat state, inventory contents, character progression, main-story progress, and side-quest progress.
• Primary actions: Move through the dungeon in first-person view; fight creatures; complete main-story objectives; complete side quests; manage inventory; advance character progression.
• Supporting actions: Consult the hand-drawn minimap; open the parchment party ledger; return to Landing.
• Domain entities: Party, party member (stats, condition, progression), dungeon level, encounter, creature, combat state, inventory item, main-story objective, side quest and its completion state.
• Component responsibilities: Full-viewport first-person view; bottom HUD bar; right-hand parchment party ledger; top-left hand-drawn minimap with rotating compass rose; quill cursor over interactive story elements.
• States: Loading — the dungeon level and party state resolve; Empty — no party assembled, in which case the Player is directed to assemble one before descending; Success — the Player explores, fights, completes objectives and quests, and progresses; Error — a combat or progression state cannot be recorded, in which case the last consistent party and dungeon state is retained and the Player is returned to it; Recovery — the Player resumes from the retained state and continues the descent.

3. Functional Requirements

FR-01 — Build a classic first-person perspective dungeon crawler (explicit) As a Player, I should descend through a classic first-person perspective dungeon crawler so that I experience grid-based exploration, combat, and progression in torchlit stone.

• Trigger/input: The Player enters the dungeon from the public entry.
• Observable result: A first-person view of the current dungeon level, with the party ledger, HUD, and minimap present.
• Access state: Public; no identity required.
• Failure/recovery: If the level or party state cannot be resolved, the last consistent state is retained and the Player is returned to it.
• Continuation: The Player moves, fights, and progresses through the level.
• Owner: Dungeon Run.

FR-02 — Provide concrete, ordered, best-practice production steps (explicit) As a Game Content Author, I should see the concrete production steps presented in order, according to best practice, so that I can produce the game's content in a defensible sequence.

• Trigger/input: The author opens the Production Plan.
• Observable result: A numbered ledger of steps, in order, each with its discipline and status.
• Access state: Public; no identity required.
• Failure/recovery: If a step's status cannot be recorded, the step remains visible with its prior status.
• Continuation: The author opens the chapter destination that owns a step.
• Owner: Production Plan.

FR-03 — Cover main story, side quests, character assets, dungeon assets, creatures, and user interface in the ordered steps (explicit) As a Game Content Author, I should find every one of the six named disciplines represented in the ordered production steps so that no required content area is left unplanned.

• Trigger/input: The author reads the Production Plan ledger.
• Observable result: Steps addressing main story, side quests, character assets, dungeon assets, creatures, and user interface, each linked to its owning chapter.
• Access state: Public; no identity required.
• Failure/recovery: If a discipline's step is missing or unlinked, the ledger shows the gap rather than silently omitting it.
• Continuation: The author opens the owning chapter for that discipline.
• Owner: Production Plan.

FR-04 — Define the main story before implementing its gameplay objectives (required_inference) As a Game Content Author, I should define the main story that structures progression before its gameplay objectives are implemented, so that objectives are derived from an established structure rather than invented ad hoc.

• Trigger/input: The author opens Story and creates or revises the main story.
• Observable result: A main story entry describing the premise and the progression structure across dungeon levels.
• Access state: Public; no identity required.
• Failure/recovery: If a revision cannot be saved, the previously saved story remains intact and readable.
• Continuation: The author proceeds to define side quests and objectives against that structure.
• Owner: Story.

FR-05 — Define side-quest content, objectives, dependencies, and completion flow (required_inference) As a Game Content Author, I should define each side quest's objectives, its dependencies, and its completion flow so that side content supports the main story and can actually be completed.

• Trigger/input: The author opens Quests and creates a side quest.
• Observable result: A side quest with readable objectives, dependencies, and completion flow.
• Access state: Public; no identity required.
• Failure/recovery: If the quest cannot be saved, the last saved quest content remains.
• Continuation: The author defines the next quest or returns to the Production Plan.
• Owner: Quests.

FR-06 — Plan and organize character assets for the party and supporting characters (required_inference) As a Game Content Author, I should plan and organize character assets for the party and supporting characters so that every character the Player meets has a defined asset plan.

• Trigger/input: The author opens Characters and plans a character asset.
• Observable result: A character roster with party and supporting characters organized and their asset plans recorded.
• Access state: Public; no identity required.
• Failure/recovery: If a character cannot be saved, the last saved character content remains.
• Continuation: The author plans the next character or returns to the Production Plan.
• Owner: Characters.

FR-07 — Define dungeon layouts, environmental assets, encounter spaces, and level progression (required_inference) As a Game Content Author, I should define dungeon layouts, environmental assets, encounter spaces, and level progression so that the dungeon is a designed place rather than an empty shell.

• Trigger/input: The author opens Dungeons and defines a level.
• Observable result: A dungeon level with readable layout, environmental assets, encounter spaces, and progression position.
• Access state: Public; no identity required.
• Failure/recovery: If the level cannot be saved, the last saved level content remains.
• Continuation: The author defines the next level or returns to the Production Plan.
• Owner: Dungeons.

FR-08 — Define creature assets and behaviors used to populate encounters (required_inference) As a Game Content Author, I should define creature assets and behaviors so that dungeon encounters are populated with creatures that have both a look and a way of acting.

• Trigger/input: The author opens Creatures and defines a creature.
• Observable result: A creature with a readable asset definition and behavior definition.
• Access state: Public; no identity required.
• Failure/recovery: If the creature cannot be saved, the last saved creature content remains.
• Continuation: The author defines the next creature or returns to the Production Plan.
• Owner: Creatures.

FR-09 — Specify the user interface for first-person play, combat, inventory, and progression (required_inference) As a Game Content Author, I should specify the user interface for first-person play, combat, inventory, and character progression so that the Player's four core interaction areas are designed before the journey is complete.

• Trigger/input: The author opens Interface and specifies a surface area.
• Observable result: A specification covering first-person play, combat, inventory, and progression.
• Access state: Public; no identity required.
• Failure/recovery: If the specification cannot be saved, the last saved specification remains.
• Continuation: The author specifies the next surface area or returns to the Production Plan.
• Owner: Interface.

FR-10 — Produce and integrate character, dungeon, and creature assets before validating the dungeon run (required_inference) As a Game Content Author, I should have character, dungeon, and creature assets produced and integrated before the dungeon run is validated, so that validation exercises real content rather than placeholders.

• Trigger/input: The author completes the asset chapters and marks the corresponding production steps.
• Observable result: The dungeon run presents integrated characters, dungeon levels, and creatures.
• Access state: Public; no identity required.
• Failure/recovery: If an asset is not integrated, the dungeon run shows the gap rather than substituting invented content.
• Continuation: The author validates the run and returns to the Production Plan.
• Owner: Production Plan, with the asset chapters supplying the content.

FR-11 — Assemble a party and descend in first-person view (required_inference) As a Player, I should assemble a party and descend through dungeon levels in first-person view so that I can begin the crawl.

• Trigger/input: The Player enters the dungeon from the public entry.
• Observable result: A first-person view of the current dungeon level with the assembled party shown in the party ledger.
• Access state: Public; no identity required.
• Failure/recovery: If no party is assembled, the Player is directed to assemble one before descending.
• Continuation: The Player moves through the level.
• Owner: Dungeon Run.

FR-12 — Fight creatures in the dungeon (required_inference) As a Player, I should fight the creatures that populate dungeon encounters so that I can survive and advance.

• Trigger/input: The Player encounters a creature in the dungeon.
• Observable result: A resolved combat outcome reflected in party condition and creature state.
• Access state: Public; no identity required.
• Failure/recovery: If a combat state cannot be recorded, the last consistent party and dungeon state is retained and the Player is returned to it.
• Continuation: The Player continues exploring, or recovers from the outcome.
• Owner: Dungeon Run.

FR-13 — Complete the main story through the dungeon (required_inference) As a Player, I should complete the main story's objectives as I descend so that the authored progression structure is realized in play.

• Trigger/input: The Player reaches and satisfies a main-story objective in the dungeon.
• Observable result: Main-story progress advances and is visible to the Player.
• Access state: Public; no identity required.
• Failure/recovery: If progress cannot be recorded, the last consistent progress state is retained.
• Continuation: The Player continues toward the next objective.
• Owner: Dungeon Run.

FR-14 — Complete side quests (required_inference) As a Player, I should complete side quests alongside the main story so that the supporting content is playable.

• Trigger/input: The Player satisfies a side quest's objectives in the dungeon.
• Observable result: The side quest's completion state changes and is visible to the Player.
• Access state: Public; no identity required.
• Failure/recovery: If completion cannot be recorded, the quest remains incomplete and the Player can satisfy it again.
• Continuation: The Player takes on the next side quest or continues the main story.
• Owner: Dungeon Run.

FR-15 — Manage inventory through the user interface (required_inference) As a Player, I should manage my inventory through the game's user interface so that what the party carries is under my control.

• Trigger/input: The Player opens the inventory through the interface.
• Observable result: Inventory contents are visible and change as the Player manages them.
• Access state: Public; no identity required.
• Failure/recovery: If an inventory change cannot be recorded, the last consistent inventory state is retained.
• Continuation: The Player returns to exploration.
• Owner: Dungeon Run.

FR-16 — Advance character progression through the user interface (required_inference) As a Player, I should advance my characters' progression through the game's user interface so that the party grows as the descent continues.

• Trigger/input: The Player advances a character through the interface.
• Observable result: The character's progression state changes and is visible in the party ledger.
• Access state: Public; no identity required.
• Failure/recovery: If a progression change cannot be recorded, the last consistent progression state is retained.
• Continuation: The Player continues the descent with the advanced party.
• Owner: Dungeon Run.

FR-17 — Consult the hand-drawn minimap and party ledger during the run (required_inference) As a Player, I should consult the hand-drawn minimap and the parchment party ledger during the run so that I can orient myself and read the party's condition without leaving the first-person view.

• Trigger/input: The Player reads the minimap or opens the party ledger.
• Observable result: The minimap shows the current level's explored shape with a rotating compass rose; the ledger shows party stats and condition.
• Access state: Public; no identity required.
• Failure/recovery: If the minimap or ledger cannot be rendered, the first-person view and its controls remain fully usable.
• Continuation: The Player resumes moving through the level.
• Owner: Dungeon Run.

4. User Personas

Player

The Player is the person the dungeon is built for. Their product context is the first-person view itself: they are inside the dungeon, not looking at it from outside, and every piece of information they need — party condition, inventory, progression, story and quest progress, and where they are — must reach them without breaking that view.

Their primary goal is to progress through the dungeon and complete the main story and the side quests. Their distinct accepted responsibilities are: assembling a party and descending; moving through dungeon levels in first-person view; fighting the creatures that populate encounters; completing main-story objectives; completing side quests; managing inventory; and advancing character progression. Their relevant inputs and decisions are which party to bring, how to handle each encounter, what to carry, and where to invest progression.

They interact with the Game Content Author only indirectly and asynchronously: the Author's story, quests, characters, dungeons, creatures, and interface specifications are the material the Player's run is made of. The Player never edits that material, and the Author never plays the run on the Player's behalf.

Observable success for the Player is a descent in which the party survives encounters, the main story advances, side quests complete, and the party grows stronger — all legible through the first-person view, the HUD, the minimap, and the parchment party ledger.

What makes this role different from the Game Content Author is that the Player consumes authored content under pressure and in real time, while the Author produces it deliberately and out of time. The Player's work is decision-making inside a running dungeon; the Author's work is construction before any run exists.

Game Content Author

The Game Content Author is the role the requester occupies when asking for concrete, ordered, best-practice steps to create the game's main story, side quests, character assets, dungeon assets, creatures, and user interface. Their product context is the production plan and its chapter destinations — a working document, not a play session.

Their primary goal is a complete, coherent set of story, quest, asset, creature, and UI content that makes the Player's journey playable. Their distinct accepted responsibilities are: reading and working the ordered production sequence; creating and revising the main story that structures progression; defining side-quest content, objectives, dependencies, and completion flow; planning and organizing character assets for the party and supporting characters; defining dungeon layouts, environmental assets, encounter spaces, and level progression; defining creature assets and behaviors; and specifying the user interface for first-person play, combat, inventory, and progression.

Their relevant inputs and decisions are the ordering of the production sequence, the content of each discipline, and the dependencies between them — in particular that the main story and side-quest structure are defined before their gameplay objectives are implemented, and that character, dungeon, and creature assets are produced and integrated before the dungeon run is validated.

They interact with the Player only through the finished content: the Author's decisions become the dungeon the Player descends into. Observable success for the Author is a production sequence that is concrete and correctly ordered, and a set of chapters that together describe a playable game.

What makes this role different from the Player is that the Author's unit of work is a decision about content that will be experienced later by someone else, and their measure of success is coherence and completeness across six disciplines rather than survival and progress inside one run.

5. Core User Flows

Flow A — The Game Content Author works the ordered production sequence

1. The Game Content Author arrives at Landing and reads what the product is: a classic first-person perspective dungeon crawler, and a content-production plan for building it.
2. The author follows the numbered production-sequence strip into Production Plan.
3. On Production Plan, the author reads the vertical numbered ledger — steps 01 through 09, each a full-width row with a hand-ruled separator and a wax-seal status stamp. The steps cover main story, side quests, character assets, dungeon assets, creatures, and user interface, in order.
4. The author opens the step that owns the main story and is taken to Story.
5. On Story, the author creates the main story: its premise and the progression structure that will carry the Player across dungeon levels. The story is saved and reads back as the structure for progression.
6. Failure/recovery: if the revision cannot be saved, the previously saved story remains intact and readable, and the author re-enters and saves again.
7. The author returns to Production Plan and marks the story step complete. The wax-seal status stamp animates in stop-motion frames.
8. The author opens the step that owns side content and is taken to Quests.
9. On Quests, the author creates a side quest and defines its objectives, its dependencies, and its completion flow, against the main story just established. The quest is saved and reads back with all three parts.
10. Failure/recovery: if the quest cannot be saved, the last saved quest content remains, and the author re-enters and saves again.
11. The author returns to Production Plan, marks the quest step complete, and continues down the ledger.
12. The author proceeds through Characters (planning and organizing character assets for the party and supporting characters), Dungeons (defining layouts, environmental assets, encounter spaces, and level progression), Creatures (defining creature assets and behaviors), and Interface (specifying first-person play, combat, inventory, and progression), marking each step complete as it is finished.
13. Once character, dungeon, and creature assets are produced and integrated, the author validates the dungeon run against real content rather than placeholders, and returns to Production Plan to close out the sequence.

Flow B — The Player descends into the dungeon

1. The Player arrives at Landing and reads the premise: a first-person descent in nine chapters, torchlit stone, dread and weight.
2. The Player activates the wax-seal entry control and enters Dungeon Run.
3. On Dungeon Run, the Player assembles a party. The party appears in the parchment party ledger on the right, with Cinzel caps headers and stat rows.
4. Failure/recovery: if no party is assembled, the Player is directed to assemble one before descending.
5. The Player descends into the first dungeon level. The first-person view fills the screen; the hand-drawn ink minimap sits top-left with its compass rose rotating in 8-frame steps; the HUD bar runs along the bottom.
6. The Player moves through the level. The quill cursor leaves a faint ink trail as it moves over interactive story elements.
7. The Player encounters a creature. Combat resolves, and the outcome is reflected in party condition in the ledger and in the creature's state.
8. Failure/recovery: if a combat state cannot be recorded, the last consistent party and dungeon state is retained and the Player is returned to it, then continues.
9. The Player reaches a main-story objective and satisfies it. Main-story progress advances and is visible.
10. The Player satisfies a side quest's objectives. The quest's completion state changes and is visible; the completion stamp animates with a two-frame ink-bleed.
11. Failure/recovery: if quest completion cannot be recorded, the quest remains incomplete and the Player can satisfy it again.
12. The Player opens the inventory through the interface, manages what the party carries, and returns to exploration.
13. The Player advances a character's progression through the interface. The change is visible in the party ledger.
14. Failure/recovery: if an inventory or progression change cannot be recorded, the last consistent state is retained.
15. The Player continues the descent, repeating exploration, combat, quest completion, inventory management, and progression until the main story and the side quests are complete.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Stefan Sagmeister. Headline register: handmade provocation carved from stone and candlelight — a physical artefact, a mouldy tome, a wax seal, a dungeon master's notebook.

Palette (dark mode, exact tokens by role):

Proportion: 70% dark ground, 20% parchment text, 8% red, 2% amber. No blue anywhere. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography: Headings in Cinzel at 700–900 weight, all-caps, wide 0.08em tracking, used at monumental scale for page titles and dungeon-level numerals. Body copy in EB Garamond 400/500 at 18–21px with 1.6 line-height, giving the read of a printed bestiary. Labels and numbers in Cinzel 600 caps at 12–13px with 0.14em tracking. No sans-serif anywhere; the whole product reads as carved and typeset, not rendered.

Type scale: 1.333 modular — 128 / 96 / 72 / 54 / 40 / 30 / 22 / 18 / 16. Mobile display 56px, desktop 128px for the hero title; section titles 40px mobile to 72px desktop; body 18px mobile to 21px desktop.

Shape language: Hard edges and hand-cut geometry. No rounded cards, no pills, no soft shadows. Panels are rectangles with 1px #7A6A5A hairline borders and corner notch marks like a drafting plate. Buttons are rectangular with a 2px #C1272D border and a wax-seal circular stamp for confirmation states. Section dividers are hand-ruled horizontal lines with small irregularities. Composition deliberately breaks the grid: a heading overlaps a stone photograph, a quest card sits at a 1.5-degree rotation, a map fragment bleeds off the left edge.

Layout: Asymmetric editorial grid on a 12-column base with a 4/8-pt spacing rhythm. Landing: full-bleed hero photograph with an oversized carved title overlapping the image on the left two-thirds, then a single-column "what this is" essay, then a numbered production-sequence strip. Production Plan: a vertical numbered ledger (01–09) with each step as a full-width row, a rule line, and a status stamp. Story, Quests, Characters, Dungeons, Creatures, Interface: each is a chapter page with a left-hand marginal number, a large Cinzel title, and a two-column body/marginalia layout. Dungeon Run: full-viewport first-person view with a bottom HUD bar, a right-hand parchment party ledger, and a top-left hand-drawn minimap. At 375px the grid collapses to one column, marginalia moves inline, and the HUD bar stacks into two rows.

Imagery: Photographed handmade typography — letters carved into slate, burned into wood, pressed into wet clay, stamped in wax. Stone textures, torchlit corridors, cracked leather, rusted iron, parchment with foxing. Character portraits are high-contrast photographic cutouts with a halftone grain, not vector illustration. Creature art is charcoal-on-paper style with visible stroke marks. Dungeon maps are hand-drawn ink on parchment with coffee stains. No 3D renders, no glossy UI mockups, no gradient blobs.

Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, and cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion follow the creative direction: a photograph, artwork, shape, texture, or animation may be cropped, bled off an edge, rotated, overlapped, or cut exactly 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 and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. With prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

The carved title as the hero image. On Landing, a full-bleed photograph of a torchlit stone corridor recedes into black, shot at an angle so the left wall dominates. Over the left two-thirds sits a monumental Cinzel title — THE HOLLOW KING — set at clamp(56px, 12vw, 128px), all-caps, #EFE3D0, with the word HOLLOW carved as if chiselled into the stone: a 2px inner shadow and a subtle stone texture. The title is not placed on top of the image; it is cut into it.

Beneath the title, a single line of EB Garamond italic at 21px: "A first-person descent in nine chapters." At the bottom left, a rectangular wax-seal button reading ENTER THE DUNGEON with a #C1272D border and a red seal stamp. The right third of the hero is empty dark space with a vertical rule and a small Cinzel 12px label: CHAPTER 01 — THE GATE. A slow torch flicker moves across the stone. Nothing is centred; nothing is a gradient blob.

This concept recomposes only accepted content — the game's premise, its first-person descent, its chapter structure, and the entry into the dungeon — and introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the torchlit stone corridor photograph, with the carved Cinzel title THE HOLLOW KING cut into it — the title is the hero image, not an overlay on it.
• Input → transformation → outcome thesis: as the visitor scrolls, the stone photograph and the carved title separate by up to 24px of scroll-linked parallax, so the title reads as a physical object standing proud of the wall behind it; the outcome is that the visitor perceives the game as an excavated artefact and reaches the ENTER THE DUNGEON seal.
• Motion vocabulary: stop-motion frame-based reveals at 8–12fps for stamps and seals; 180–260ms crossfades for page transitions; a slow 6-second torch flicker across the stone; a 2px #7A6A5A rule that sweeps left-to-right on section transitions; a marginal chapter number that stamps in from 1.4 scale.
• Composed first frame: the corridor photograph full-bleed and angled, the carved title overlapping the left two-thirds, the italic line beneath it, the wax-seal entry control bottom-left, the vertical rule and CHAPTER 01 — THE GATE label in the right third, and the torch flicker mid-sweep across the left wall.
• Reduced-motion state: all frame-based reveals become instant state changes and the torch flicker becomes a static warm vignette; the parallax offset is removed and the title sits flat against the photograph; the entry control and all navigation remain fully operable.

9. Non-Functional Requirements

NFR-01 — Classic first-person perspective (explicit) The game must be a classic first-person perspective dungeon crawler. Rationale: explicit hard constraint in the authoritative user evidence. This governs the Dungeon Run destination's view and movement model.

NFR-02 — Concrete, ordered, best-practice steps (explicit) The production steps must be concrete and presented in order, according to best practice. Rationale: explicit hard constraint in the authoritative user evidence. This governs the Production Plan ledger's structure and ordering.

NFR-03 — Story and quest structure precede objective implementation (required_inference) The main story and side-quest structure must be defined before their gameplay objectives are implemented. Rationale: required to make the accepted production journey executable without adding a product capability.

NFR-04 — Asset production and integration precede run validation (required_inference) Character, dungeon, and creature assets must be produced and integrated before the dungeon run can be validated. Rationale: required to make the accepted production journey executable without adding a product capability.

NFR-05 — Interface coverage before journey completion (required_inference) The user interface must support first-person exploration, combat, inventory, and progression before the playable journey is complete. Rationale: required to make the accepted production journey executable without adding a product capability.

NFR-06 — Readable text and controls at every viewport (explicit, from creative direction) Headlines, wordmarks, labels, numbers, and cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: explicit accessibility constraint in the supplied creative direction.

NFR-07 — Reduced-motion support (explicit, from creative direction) With prefers-reduced-motion, all frame-based reveals become instant state changes, the torch flicker becomes a static warm vignette, and a usable static arrangement is provided for any moving or scrollable content. Rationale: explicit accessibility constraint in the supplied creative direction.

NFR-08 — Contrast (explicit, from creative direction) Parchment text #EFE3D0 is used at body size on both the #0E0B09 ground and the #1C1613 surface for AAA contrast. Rationale: explicit constraint in the supplied creative direction.

10. Tech Stack

No technology choices are stated in the authoritative user requirement thread or the Planning Scope contract. The following are coherent defaults, labeled as such, and are not product behavior:

• Frontend: React with a component-based structure for the nine destinations. [Default — not specified by user]
• Backend: Python with FastAPI, serving the production-plan and chapter content and the dungeon-run state. [Default — not specified by user]
• Storage: A relational store for production steps, story, quests, characters, dungeons, creatures, and interface specifications, plus the dungeon-run state. [Default — not specified by user]
• Packaging: Docker with docker-compose for local development and deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by any accepted constraint and is therefore not included. [Default — not specified by user]

11. Assumptions and Constraints

Constraints (binding):

1. The game must be a classic first-person perspective dungeon crawler. (explicit)
2. The production steps must be concrete and presented in order, according to best practice. (explicit)
3. The ordered steps must cover main story, side quests, character assets, dungeon assets, creatures, and user interface. (explicit)
4. The creative direction is authoritative for visuals, color, typography, shape, layout, motion, and imagery, including its explicit prohibitions: no blue or indigo anywhere; no Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for any text; no rounded cards, pill buttons, glassmorphism, or hover-lift card grids; no gradient-blob heroes, neon glows, or futuristic HUD chrome; no centred headline + subtext + button SaaS hero composition; no smooth 60fps easing on every element; no vector character illustration or flat clip-art creatures; no white or near-white page grounds. (explicit)

Assumptions (narrow, labeled):

1. The nine destinations in the Planning Scope contract are the complete and final information architecture; no additional destination is required by any accepted journey. (required_inference)
2. Access is open across all nine destinations, consistent with the contract's access_requirement: none for every surface; no accepted journey requires durable actor-specific state that would force an identity boundary. (required_inference)
3. The Player and the Game Content Author are the only active human roles; the game's runtime systems are non-persona system actors. (required_inference)
4. The production sequence is presented as nine numbered steps, matching the creative direction's ledger of 01–09 and the hero's "nine chapters." (required_inference)
5. No future-horizon requirements are established by the authoritative thread, so no future section is asserted. (required_inference)

12. Glossary

• Classic first-person perspective dungeon crawler — A grid-based dungeon game played from the party's own viewpoint, in the tradition of 1990s crawlers: torchlit stone, stepwise movement, encounter-driven combat, and a party the player assembles and advances.
• Dungeon Run — The destination that owns the Player's cohesive first-person exploration, combat, story, side-quest, inventory, and progression experience.
• Production Plan — The destination that owns the concrete, ordered, best-practice production sequence and coordinates the six content disciplines.
• Chapter destination — One of Story, Quests, Characters, Dungeons, Creatures, or Interface; each owns creation and revision of its discipline's content.
• Production step — One numbered entry (01–09) in the Production Plan ledger, carrying a title, its discipline, a description, and a status.
• Main story — The narrative structure that governs the dungeon crawler's progression across levels.
• Side quest — Supporting content with its own objectives, dependencies, and completion flow.
• Character asset — The planned and organized representation of a party member or supporting character.
• Dungeon level — A designed dungeon space with a layout, environmental assets, encounter spaces, and a position in level progression.
• Creature — An asset and behavior definition used to populate dungeon encounters.
• Interface specification — The design of one of the four Player-facing surface areas: first-person play, combat, inventory, or character progression.
• Party ledger — The parchment character sheet on the Dungeon Run page showing party stats and condition.
• Wax-seal status stamp — The confirmation control on a Production Plan row, animating in stop-motion frames when a step is marked complete.