System Requirements Document for honest-hi

1. Introduction

honest-hi is an original 3D Action-Adventure-Survival game project, built from scratch to commercial studio standards. The product intent is not an idea document or a throwaway prototype: it is a real, structured, runnable, and extensible game project that proves the ability to turn a game concept into a professional-grade 3D title.

The game combines three genres in one experience: Action (real-time combat with attacks, defense, dodging, and special skills), Adventure (an explorable, diverse, dynamic 3D world with a story and main/side missions), and Survival (a hostile environment governed by a day/night cycle and dynamic weather, where the player must endure enemy pressure and manage their own condition).

The audience is twofold:

• Players who expect modern visual fidelity — dynamic lighting, realistic shadows, PBR materials, particle and weather effects, smooth animation, a modern responsive UI, and environment-appropriate sound and music — and who want a tense, dark, high-stakes third-person experience.
• Game Developers / Maintainers who must be able to build, run, test, measure, and extend the project: modular clean architecture, separated gameplay systems, memory and resource management, save/load, event management, settings, error handling, controller and keyboard support, and future extensibility.

The project is delivered as a real game project with a playable prototype, a complete challenge level, an optimization pass, a test suite, and an honest evaluation report that distinguishes implemented, tested, and design-only capabilities.

2. System Overview

honest-hi is a third-person 3D Action-Adventure-Survival game. The player controls a single main character with natural animations and an advanced movement system inside a diverse, dynamic 3D world. The world runs a day/night cycle and dynamic weather. Enemies are driven by a behavior-based AI system with differing behaviors. Combat covers attacks, defense, dodging, and special skills. A progression system advances skills, equipment, and abilities. A story with main and side missions frames the core gameplay loop.

The current delivery is a playable prototype plus one complete challenge level, not a finished commercial title. The prototype must include at minimum: a controllable character, a 3D environment, a third-person camera, a movement and jump system, at least one AI enemy, a combat system, a health bar, a UI, and a simple mission with win and lose conditions. The challenge level must let the player enter the environment, receive a mission, explore, encounter enemies, use the combat system, complete the mission objective, receive a reward, and save progress.

Two active human roles exist in the current product:

• Player — plays the game: moves, explores, fights, takes missions, earns rewards, and saves progress.
• Game Developer / Maintainer — builds, runs, tests, measures, and extends the project, and reports the project against the evaluation criteria.

The game itself is developed with a suitable game engine such as Unreal Engine 5 or Unity. The project's own first-party web surfaces (Landing, Login, and the maintainer-facing Build Test surface) are delivered as a web application; the game runtime is delivered through the chosen engine.

Narrow exclusions and boundaries:

• The project must not be merely an explanation; a real project must be produced as far as the available tools allow.
• Demo or non-runnable code must not be used as the final product.
• Temporary solutions and unstructured code must be avoided.
• Fabricated performance numbers must not be presented.
• If real graphics files cannot be produced, that limitation must be stated explicitly and workable substitutes used.
• Any part requiring external files, tools, or assets must be identified.
• Any resource or tool limitation must be explained honestly.

2a. Product Interpretation and Delivery Boundary

honest-hi is delivered in two layers that must not be confused with each other.

The game layer is the product itself: a 3D Action-Adventure-Survival game built in Unreal Engine 5 or Unity, containing the character, world, camera, movement, enemies, combat, progression, missions, day/night and weather, UI, save/load, settings, and the complete challenge level. This layer is where the player's actual gameplay happens.

The first-party web layer carries the surfaces that surround and support the game: a public Landing surface that presents the game to an anonymous visitor, a Login surface that verifies a returning player before durable progress is loaded or changed and that also admits the maintainer role, and a Build Test surface where the Game Developer / Maintainer verifies implementation, runs repeatable tests, measures performance, and walks the complete challenge-level flow.

Identity and access. The product owns identity. A player establishes their own access before first use (self-service enrollment), and a returning player is verified before any durable player state — saves, progression, settings — is loaded or changed. Maintainer access is established by invitation or provisioning rather than open self-service. The Landing surface is anonymously reachable and carries no protected state. Login is the anonymous entry boundary that establishes access; it does not itself require prior access. All gameplay and maintainer destinations require an established identity, and the game's durable state remains unavailable until that identity is established.

Current versus future. Everything in this document is current unless it appears in Section 11 under future horizons. The current horizon is the playable prototype plus the complete challenge level, with the optimization pass, the test suite, and the evaluation report. Broader content — additional levels, additional enemy archetypes, expanded story arcs, and expanded equipment sets beyond what the prototype and challenge level require — is future work and is not part of current acceptance.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry. Presents the original Action-Adventure-Survival game, its genre identity, its engine, its current status, and its playable mission experience. No protected state is shown or reachable.
• Primary actions: Enter the game experience (proceed to Login to establish access); read the game's genre, engine, and status.
• Supporting actions: Navigate to the sections describing gameplay, graphics, enemy AI, architecture, optimization, testing, and the challenge level.
• Domain entities: Game project, genre, engine, status, mission experience.
• Component responsibilities: Full-viewport hero carrying the game's identity; corner-anchored HUD chrome (mission state, threat meter, vitals, input legend); capability sections for gameplay, graphics, enemy AI, architecture, optimization, testing, and the challenge level; behavior-tree node graph presentation; performance and evaluation summary.
• States: Loading — hero scene initializes with a composed first frame. Empty — not applicable; the surface always carries the game's identity content. Success — visitor understands the game and can proceed to establish access. Error — if the real-time hero cannot initialize, a static hero image is shown in its place and all readable content remains whole. Recovery — the visitor can still read every section and proceed to Login.

Login

• Information and state: Anonymous entry boundary. Establishes access for a self-starting player and verifies a returning player before durable state is loaded or changed. Also admits the invited or provisioned Game Developer / Maintainer.
• Primary actions: Establish access as a new player (self-service enrollment); verify as a returning player; verify as an invited or provisioned maintainer.
• Supporting actions: Recover from a failed verification attempt; return to Landing.
• Domain entities: Player identity, maintainer identity, verification state.
• Component responsibilities: Identity entry and verification controls; role-aware routing to the correct destination after verification; clear error surface for failed verification.
• States: Loading — verification in progress. Empty — no identity entered yet; the surface presents the entry controls. Success — identity established; the actor is routed to their destination (Player to Gameplay; Game Developer / Maintainer to Build Test). Error — verification fails; the failure is stated plainly and the actor may retry. Recovery — retry without losing entered context; return to Landing.

Gameplay

• Information and state: The playable third-person environment. Owns the character's position and movement state, the camera state, the exploration state, and the current input mode.
• Primary actions: Move the character; jump; control the third-person camera; explore the 3D environment; enter and leave combat and encounter contexts.
• Supporting actions: Open Settings; open Save Load; open Progression; open Missions; open World.
• Domain entities: Player character, camera, environment, input device (controller or keyboard).
• Component responsibilities: Character controller with advanced movement; third-person camera rig; environment collision and traversal; input mapping for controller and keyboard; handoff into Combat, Encounters, Missions, and World.
• States: Loading — environment loads in stages; the character is not yet controllable. Empty — not applicable; the environment is always populated. Success — the character is controllable and the camera follows correctly. Error — a load or collision failure is surfaced and the player can retry the load. Recovery — reload the environment or return to the last save.

Combat

• Information and state: The focused combat context. Owns attack, defense, dodge, and special-skill state, and the player's and enemy's combat condition.
• Primary actions: Attack; defend; dodge; use special skills.
• Supporting actions: Read combat feedback; disengage and return to Gameplay.
• Domain entities: Attack, defense, dodge, special skill, combat condition, damage.
• Component responsibilities: Combat input handling; attack resolution; defense and dodge windows; special-skill activation and cost; damage and hit feedback; combat outcome reporting to HUD and Missions.
• States: Loading — combat context initializes. Empty — no combat active; the player may engage. Success — the combat action resolves and its result is observable. Error — an invalid or unavailable action is rejected with clear feedback. Recovery — the player may disengage, dodge, or defend to recover position.

Encounters

• Information and state: Enemy encounters and the behavior-driven experience. Owns enemy detection state (field of view and sound), patrol state, pursuit and search state, cover state, group cooperation state, and reaction to environment events.
• Primary actions: Observe enemy behavior; evade or engage; exploit cover and group behavior.
• Supporting actions: Read the threat state; return to Gameplay or enter Combat.
• Domain entities: Enemy, detection (field of view, sound), patrol route, pursuit, search, cover, group cooperation, environment event, behavior tree.
• Component responsibilities: Behavior-tree-driven decision system; perception (sight and sound); patrol, chase, and search behaviors; cover selection in combat; group cooperation coordination; environment-event reaction; differing enemy behaviors.
• States: Loading — encounter and AI systems initialize. Empty — no enemies present in the current area. Success — enemy behavior is observable and consistent with its state. Error — an AI or navigation failure is surfaced and the encounter can be reset. Recovery — reset the encounter or return to the last save.

Missions

• Information and state: Mission receipt, objective tracking, completion, and reward progression. Owns the active mission, its objectives, its win and lose conditions, and the reward state.
• Primary actions: Receive a mission; track objectives; complete the mission objective; receive the reward.
• Supporting actions: Review main and side missions; read win and lose conditions.
• Domain entities: Mission (main, side), objective, win condition, lose condition, reward.
• Component responsibilities: Mission issuance; objective state tracking; win/lose evaluation; reward granting; handoff to Progression and Save Load.
• States: Loading — mission data loads. Empty — no mission active; the player may receive one. Success — the objective completes and the reward is granted. Error — a mission state failure is surfaced and the mission can be restarted. Recovery — restart the mission or return to the last save.

HUD

• Information and state: The in-game health bar and responsive gameplay information interface. Owns the player's health display and the gameplay information presented during play.
• Primary actions: Read health and gameplay information.
• Supporting actions: Read mission and threat indicators.
• Domain entities: Health bar, gameplay information, mission indicator, threat indicator.
• Component responsibilities: Health bar rendering; responsive layout across viewports; gameplay information presentation; legibility of all labels and numbers at every viewport.
• States: Loading — HUD initializes with the gameplay session. Empty — no gameplay session active; HUD is not shown. Success — health and information update correctly with gameplay state. Error — a HUD rendering failure is surfaced without blocking gameplay. Recovery — HUD reinitializes with the session.

Save Load

• Information and state: Durable save creation and loading so the player can resume progress. Owns save slots and the saved state of progression, mission state, and settings.
• Primary actions: Create a save; load a save; resume progress.
• Supporting actions: Review existing saves; return to Gameplay.
• Domain entities: Save, save slot, saved progression, saved mission state, saved settings.
• Component responsibilities: Save serialization; load deserialization; save integrity checking; error handling for corrupt or missing saves.
• States: Loading — save or load operation in progress. Empty — no saves exist yet; the player may create one. Success — the save is written or the load restores the expected state. Error — a corrupt or missing save is reported and the player may choose another or start fresh. Recovery — retry the operation or select a different save.

Settings

• Information and state: Player-adjustable game configuration and supported input or presentation settings. Owns the current configuration values.
• Primary actions: Adjust settings; apply settings; restore defaults.
• Supporting actions: Review current values; return to Gameplay.
• Domain entities: Setting, configuration value, input setting, presentation setting.
• Component responsibilities: Setting presentation; validation of accepted values; persistence of settings; error handling for invalid values.
• States: Loading — current settings load. Empty — not applicable; defaults are always present. Success — the setting is applied and persists. Error — an invalid value is rejected with clear feedback. Recovery — restore defaults or re-enter a valid value.

World

• Information and state: The explorable dynamic world presentation, including day/night and weather conditions. Owns the current time-of-day state and the current weather state.
• Primary actions: Explore the world; observe the day/night cycle; observe dynamic weather.
• Supporting actions: Return to Gameplay; observe environment effects.
• Domain entities: World, environment, time of day, weather condition, particle effect.
• Component responsibilities: Day/night cycle; dynamic weather; particle and weather effects; dynamic lighting and realistic shadows; PBR material presentation; explorable environment presentation; staged environment loading.
• States: Loading — world and environment load in stages. Empty — not applicable; the world is always present. Success — the world renders with correct lighting, materials, and conditions. Error — a rendering or load failure is surfaced and the world can be reloaded. Recovery — reload the world or return to the last save.

Progression

• Information and state: Management and advancement of skills, equipment, and abilities. Owns the player's current skills, equipment, and abilities and their advancement state.
• Primary actions: Advance skills; advance equipment; advance abilities.
• Supporting actions: Review current skills, equipment, and abilities; return to Gameplay.
• Domain entities: Skill, equipment, ability, advancement.
• Component responsibilities: Progression state presentation; advancement application; persistence of progression; handoff from Missions on reward.
• States: Loading — progression state loads. Empty — no advancement available yet. Success — the advancement is applied and observable. Error — an unavailable advancement is rejected with clear feedback. Recovery — return to Gameplay or reload the progression state.

Build Test

• Information and state: Maintainer verification of implementation, repeatable tests, performance measurement, and the complete challenge-level flow. Owns test results, performance measurements, and the evaluation report.
• Primary actions: Run the test suites (movement and collision, combat, AI, save/load, UI, performance under high-traffic conditions); run performance measurement; walk the complete challenge-level flow; produce the evaluation report.
• Supporting actions: Review identified bugs and their fixes; review repeatable tests; review the distinction between implemented, tested, and design-only capabilities.
• Domain entities: Test, test result, bug, fix, performance measurement, evaluation criterion, evaluation report.
• Component responsibilities: Test execution and result reporting; performance measurement method and results; bug identification and fix tracking; evaluation report generation across architecture quality, code quality and readability, gameplay quality, graphics quality, enemy AI, performance and optimization, stability and bug count, and extensibility and maintainability.
• States: Loading — test and measurement environment initializes. Empty — no test run yet; the maintainer may start one. Success — tests and measurements complete and results are reported with real evidence. Error — a test or measurement failure is reported with its cause. Recovery — re-run the failing test or measurement.

3. Functional Requirements

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

Game Design

FR-1 — Original genre-combining game. As a Player, I should play an original game that combines Action, Adventure, and Survival, so that the experience delivers all three genres in one title. Provenance: explicit. Lifecycle: initiated by the Player starting play; observable result is a game whose mechanics, world, and pacing express all three genres; failure is a build that omits one of the genres; continuation is play across the world and missions. Acceptance: the game's mechanics, world, and progression demonstrably include real-time action combat, explorable adventure content, and survival pressure from environment and enemies.

FR-2 — Diverse, dynamic 3D world with third-person camera. As a Player, I should explore a 3D world with diverse and dynamic environments through a third-person camera, so that I can see and navigate the world from behind my character. Provenance: explicit. Lifecycle: initiated by the Player moving the character; observable result is the camera following the character in third person through varied environments; failure is a camera that clips, loses the character, or fails to follow; continuation is continued exploration. Acceptance: the camera remains third-person, follows the character, and the environments are visibly diverse and dynamic.

FR-3 — Main character with natural animations and advanced movement. As a Player, I should control a main character with natural animations and an advanced movement system, so that movement feels responsive and believable. Provenance: explicit. Lifecycle: initiated by the Player's movement input; observable result is natural animation and advanced movement (including jump); failure is animation or movement that breaks or becomes unresponsive; continuation is continued traversal. Acceptance: the character animates naturally across movement states and the movement system supports advanced traversal including jumping.

FR-4 — Enemies with AI and differing behaviors. As a Player, I should face enemies that have AI and behave differently from one another, so that encounters require different responses. Provenance: explicit. Lifecycle: initiated by the Player entering an encounter; observable result is enemies acting on their own AI with distinguishable behaviors; failure is enemies that do not act or act identically; continuation is continued encounter play. Acceptance: at least one AI enemy exists in the prototype, and enemy behaviors differ across the encounter set.

FR-5 — Combat system with attacks, defense, dodging, and special skills. As a Player, I should use a combat system that includes attacks, defense, dodging, and special skills, so that combat has depth and counterplay. Provenance: explicit. Lifecycle: initiated by the Player engaging in combat; observable result is each of the four combat capabilities resolving with observable effect; failure is an unavailable or non-resolving combat action; continuation is continued combat or disengagement. Acceptance: attacks, defense, dodging, and special skills are each usable and each produce an observable result.

FR-6 — Progression system for skills, equipment, and abilities. As a Player, I should advance my skills, equipment, and abilities, so that my character grows over the course of play. Provenance: explicit. Lifecycle: initiated by the Player earning advancement; observable result is an applied advancement to skills, equipment, or abilities; failure is an advancement that cannot be applied; continuation is continued play with the advanced state. Acceptance: skills, equipment, and abilities can each be advanced and the advancement is observable and persists.

FR-7 — Day/night cycle and dynamic weather. As a Player, I should experience a day/night cycle and dynamic weather conditions, so that the world changes over time and conditions matter. Provenance: explicit. Lifecycle: initiated by the passage of play time; observable result is a changing time of day and changing weather; failure is a cycle or weather system that stalls or does not render; continuation is continued play under the new conditions. Acceptance: the day/night cycle progresses and weather conditions change dynamically during play.

FR-8 — Engaging story with main and side missions. As a Player, I should experience an engaging story delivered through main and side missions, so that my play has narrative purpose. Provenance: explicit. Lifecycle: initiated by the Player receiving a mission; observable result is mission content that advances the story; failure is a mission that cannot be received or completed; continuation is the next mission. Acceptance: the game contains main missions and side missions, and mission content carries the story.

FR-9 — Detailed specification of mechanics, story, level design, and core loop. As a Game Developer / Maintainer, I should have all game mechanics, the story, the level design, and the core gameplay loop specified in detail, so that the project is buildable and extensible. Provenance: explicit. Lifecycle: initiated by the maintainer designing the project; observable result is a detailed specification of mechanics, story, level design, and core loop; failure is a specification with gaps; continuation is implementation against the specification. Acceptance: mechanics, story, level design, and the core gameplay loop are each specified in detail.

Graphics and Environment Design

FR-10 — Modern visual standards. As a Player, I should see a 3D environment built to modern visual standards, so that the game looks like a contemporary title. Provenance: explicit. Lifecycle: initiated by the Player viewing the world; observable result is dynamic lighting with realistic shadows, PBR materials, particle and weather effects, smooth animations, explorable environments, a modern responsive UI, and environment-appropriate sound effects and music; failure is a missing or broken visual or audio element; continuation is continued play. Acceptance: dynamic lighting and realistic shadows, PBR materials, particle and weather effects, smooth animations, explorable environments, a modern responsive UI, and environment-appropriate sound effects and music are each present.

FR-11 — 3D modeling, shaders, lighting, and optimization techniques with honest substitutes. As a Game Developer / Maintainer, I should use 3D modeling, shaders, lighting, and appropriate optimization techniques, and where real graphics files cannot be produced I should state that limitation and use workable substitutes, so that the visual pipeline is real and honestly reported. Provenance: explicit. Lifecycle: initiated by the maintainer building the visual pipeline; observable result is applied modeling, shader, lighting, and optimization techniques, or a stated limitation with workable substitutes; failure is an unstated limitation or a non-working substitute; continuation is continued pipeline work. Acceptance: the techniques are applied, and any inability to produce real graphics files is explicitly stated alongside the substitutes used.

Enemy AI

FR-12 — Player detection via field of view and sound. As a Player, I should be detected by enemies through their field of view and through sound, so that stealth and noise both matter. Provenance: explicit. Lifecycle: initiated by the Player entering an enemy's field of view or making sound; observable result is the enemy detecting the Player; failure is detection that never triggers or triggers without cause; continuation is the enemy's next behavior. Acceptance: enemies detect the Player both by field of view and by sound.

FR-13 — Intelligent patrolling. As a Player, I should observe enemies patrolling intelligently, so that their movement is purposeful rather than random. Provenance: explicit. Lifecycle: initiated by enemies being idle; observable result is purposeful patrol movement; failure is stalled or purely random patrol; continuation is patrol until detection. Acceptance: enemies patrol along purposeful routes.

FR-14 — Chasing and searching for the player. As a Player, I should be chased and searched for by enemies, so that evasion has consequences. Provenance: explicit. Lifecycle: initiated by detection; observable result is the enemy chasing the Player and searching for them when the Player is lost; failure is a chase that never starts or a search that never resolves; continuation is capture, loss of the Player, or return to patrol. Acceptance: enemies chase the Player after detection and search for the Player when the Player is no longer directly perceived.

FR-15 — Taking cover in combat. As a Player, I should see enemies take cover during combat, so that firefights have tactical structure. Provenance: explicit. Lifecycle: initiated by combat; observable result is enemies moving to and using cover; failure is enemies that never use cover; continuation is continued combat. Acceptance: enemies take cover during combat.

FR-16 — Group cooperation among enemies. As a Player, I should face enemies that cooperate as a group, so that groups are more dangerous than isolated enemies. Provenance: explicit. Lifecycle: initiated by multiple enemies engaging the Player; observable result is coordinated group behavior; failure is enemies acting in complete isolation; continuation is continued group engagement. Acceptance: enemies in a group cooperate with one another.

FR-17 — Reaction to environment events. As a Player, I should see enemies react to events in the environment, so that the world and the AI are connected. Provenance: explicit. Lifecycle: initiated by an environment event; observable result is an enemy reaction; failure is an event that produces no reaction; continuation is the enemy's next behavior. Acceptance: enemies react to environment events.

FR-18 — Behavior-based decision system with explained architecture. As a Game Developer / Maintainer, I should implement a behavior-based decision system using a Behavior Tree or another suitable method, and explain its architecture, so that enemy decisions are structured and understandable. Provenance: explicit. Lifecycle: initiated by the maintainer implementing the AI; observable result is a behavior-based decision system with a documented architecture; failure is an undocumented or unstructured decision system; continuation is extension of the AI. Acceptance: the decision system is behavior-based, uses a Behavior Tree or another suitable method, and its architecture is explained.

Programming and Architecture

FR-19 — Development with a suitable game engine. As a Game Developer / Maintainer, I should develop the project with a suitable game engine such as Unreal Engine 5 or Unity, so that the project is built on a professional foundation. Provenance: explicit. Lifecycle: initiated by the maintainer setting up the project; observable result is a project built in the chosen engine; failure is a project that cannot be built or run in the engine; continuation is continued development. Acceptance: the project is developed in Unreal Engine 5 or Unity.

FR-20 — Modular clean architecture with separated gameplay systems. As a Game Developer / Maintainer, I should build a modular, clean architecture with separated gameplay systems, so that the project is maintainable and extensible. Provenance: explicit. Lifecycle: initiated by the maintainer designing the architecture before implementation; observable result is a modular architecture with separated gameplay systems; failure is tangled or unstructured code; continuation is implementation against the architecture. Acceptance: the architecture is modular, gameplay systems are separated, and the architecture is designed before implementation.

FR-21 — Memory and resource management. As a Game Developer / Maintainer, I should manage memory and resources, so that the game runs within reasonable resource budgets. Provenance: explicit. Lifecycle: initiated by the maintainer implementing resource handling; observable result is managed memory and resource usage; failure is unbounded growth or leaked resources; continuation is continued development. Acceptance: memory and resources are managed as part of the architecture.

FR-22 — Save and load system. As a Player, I should save and load the game, so that I can resume my progress. Provenance: explicit. Lifecycle: initiated by the Player saving or loading; observable result is a written save or a restored state; failure is a corrupt or missing save; continuation is resumed play. Acceptance: the game can save and load, and the loaded state matches the saved state.

FR-23 — Event management. As a Game Developer / Maintainer, I should have an event management system, so that systems communicate without tight coupling. Provenance: explicit. Lifecycle: initiated by a system raising an event; observable result is the event being delivered to its listeners; failure is a lost or duplicated event; continuation is continued system operation. Acceptance: an event management system exists and systems communicate through it.

FR-24 — Settings system. As a Player, I should adjust game settings, so that I can configure the game to my preference. Provenance: explicit. Lifecycle: initiated by the Player changing a setting; observable result is the applied and persisted setting; failure is a setting that does not apply or persist; continuation is continued play. Acceptance: a settings system exists, settings apply, and settings persist.

FR-25 — Error handling. As a Game Developer / Maintainer, I should have error handling, so that failures are surfaced and contained rather than crashing the game. Provenance: explicit. Lifecycle: initiated by a failure condition; observable result is a handled error with a clear surface; failure is an unhandled crash; continuation is recovery. Acceptance: error handling exists and failures are surfaced and contained.

FR-26 — Controller and keyboard support. As a Player, I should play with a controller or a keyboard, so that I can use my preferred input device. Provenance: explicit. Lifecycle: initiated by the Player using an input device; observable result is correct input handling for both controller and keyboard; failure is an unsupported or mis-mapped input; continuation is continued play. Acceptance: both controller and keyboard input are supported.

FR-27 — Future extensibility. As a Game Developer / Maintainer, I should be able to extend the project in the future, so that the project can grow beyond the current scope. Provenance: explicit. Lifecycle: initiated by the maintainer adding new content or systems; observable result is an extension that fits the architecture without restructuring; failure is an extension that requires breaking the architecture; continuation is continued extension. Acceptance: the architecture supports future extension.

FR-28 — Specified folder structure, files, classes, and inter-system relationships with real code. As a Game Developer / Maintainer, I should have the folder structure, main files, classes, and inter-system relationships specified, with code that is real, coherent, and as runnable as possible, so that the project can be built and understood. Provenance: explicit. Lifecycle: initiated by the maintainer documenting and writing the project; observable result is a specified structure and real, coherent, runnable code; failure is demo or non-runnable code presented as the product; continuation is continued development. Acceptance: folder structure, main files, classes, and inter-system relationships are specified, and the code is real, coherent, and as runnable as possible.

Playable Gameplay

FR-29 — Playable prototype with the required minimum. As a Player, I should play a runnable prototype that includes a controllable character, a 3D environment, a third-person camera, a movement and jump system, at least one AI enemy, a combat system, a health bar, a UI, and a simple mission with win and lose conditions, so that the game is actually playable. Provenance: explicit. Lifecycle: initiated by the Player launching the prototype; observable result is all nine required elements present and working; failure is any missing element; continuation is play through the mission. Acceptance: all nine elements are present and functional in the prototype.

FR-30 — Build steps, required files, and run instructions. As a Game Developer / Maintainer, I should have all build steps, required files, and the method for running the project, so that the project can be built and run. Provenance: explicit. Lifecycle: initiated by the maintainer building the project; observable result is a successful build and run following the documented steps; failure is a missing step or file; continuation is running the project. Acceptance: build steps, required files, and run instructions are provided and sufficient to build and run the project.

Optimization

FR-31 — Reasonable performance on mid-range systems. As a Player, I should get reasonable performance on a mid-range system, so that the game is playable without high-end hardware. Provenance: explicit. Lifecycle: initiated by running the game on a mid-range system; observable result is reasonable performance; failure is performance that makes the game unplayable; continuation is continued play. Acceptance: the game performs reasonably on mid-range systems.

FR-32 — Optimization across frame rate, RAM/VRAM, draw calls, object and resource management, LOD and culling, staged loading, physics and AI. As a Game Developer / Maintainer, I should examine and optimize frame rate, RAM and VRAM usage, draw call count, object and resource management, LOD and culling, staged environment loading, and physics and AI, so that the game meets its performance target. Provenance: explicit. Lifecycle: initiated by the maintainer profiling the game; observable result is each of the seven areas examined and optimized; failure is an unexamined area; continuation is re-measurement. Acceptance: each of the seven areas is examined and optimized.

FR-33 — Specified performance measurement method without fabricated numbers. As a Game Developer / Maintainer, I should have the performance measurement method specified and should not present fabricated numbers, so that performance claims are trustworthy. Provenance: explicit. Lifecycle: initiated by the maintainer measuring performance; observable result is a specified measurement method and real measurements; failure is a fabricated number; continuation is reporting. Acceptance: the measurement method is specified and no fabricated numbers are presented.

Testing and Bug Fixing

FR-34 — Tests for movement and collision, combat, AI, save/load, UI, and performance under high-traffic conditions. As a Game Developer / Maintainer, I should have tests designed for movement and collision, combat, AI, save/load, UI, and performance under high-traffic conditions, so that each system is verified. Provenance: explicit. Lifecycle: initiated by the maintainer running the tests; observable result is test results for each of the six areas; failure is an untested area; continuation is fixing and re-testing. Acceptance: tests exist for all six areas.

FR-35 — Bug identification, fixes, and repeatable tests. As a Game Developer / Maintainer, I should identify likely bugs, propose fixes, and write repeatable tests that confirm the fixes, so that stability is verifiable. Provenance: explicit. Lifecycle: initiated by a suspected or observed bug; observable result is an identified bug, a proposed fix, and a repeatable test that confirms the fix; failure is a bug without a repeatable test; continuation is re-running the test. Acceptance: likely bugs are identified, fixes are proposed, and repeatable tests confirm the fixes.

Final Challenge

FR-36 — One complete level with the eight-step player flow. As a Player, I should play one complete level in which I can enter the environment, receive a mission, explore the environment, encounter enemies, use the combat system, complete the mission objective, receive a reward, and save my progress, so that the full gameplay loop is playable end to end. Provenance: explicit. Lifecycle: initiated by the Player entering the level; observable result is all eight steps completed in order; failure is a step that cannot be completed; continuation is the reward and the saved progress. Acceptance: all eight steps are completable in one level.

Rules and Evaluation

FR-37 — Produce a real project, not an explanation. As a Game Developer / Maintainer, I should produce a real project as far as the tools allow rather than merely explaining, so that the deliverable is an actual project. Provenance: explicit. Lifecycle: initiated by the maintainer building the project; observable result is a real project; failure is an explanation-only deliverable; continuation is continued building. Acceptance: a real project is produced as far as the tools allow.

FR-38 — No demo or non-runnable code as the final product. As a Game Developer / Maintainer, I should not use demo or non-runnable code as the final product, so that the delivered product actually runs. Provenance: explicit. Lifecycle: initiated by the maintainer delivering the product; observable result is runnable code; failure is demo or non-runnable code presented as the product; continuation is delivery. Acceptance: the final product is not demo or non-runnable code.

FR-39 — Identify parts requiring external files, tools, or assets. As a Game Developer / Maintainer, I should identify any part that requires external files, tools, or assets, so that dependencies are known. Provenance: explicit. Lifecycle: initiated by the maintainer reviewing the project; observable result is an identified list of external requirements; failure is an unidentified dependency; continuation is dependency resolution. Acceptance: every part requiring external files, tools, or assets is identified.

FR-40 — Design the architecture before implementation. As a Game Developer / Maintainer, I should design the architecture before implementation, so that implementation follows a plan. Provenance: explicit. Lifecycle: initiated by the maintainer starting work; observable result is a designed architecture preceding implementation; failure is implementation without a design; continuation is implementation. Acceptance: the architecture is designed before implementation begins.

FR-41 — Implement and test each system independently. As a Game Developer / Maintainer, I should implement and test each system independently, so that each system is verified in isolation. Provenance: explicit. Lifecycle: initiated by the maintainer implementing a system; observable result is an independently implemented and tested system; failure is an untested system; continuation is the next system. Acceptance: each system is implemented and tested independently.

FR-42 — Avoid temporary solutions and unstructured code. As a Game Developer / Maintainer, I should avoid temporary solutions and unstructured code, so that the project remains maintainable. Provenance: explicit. Lifecycle: initiated by the maintainer writing code; observable result is structured, non-temporary code; failure is a temporary solution or unstructured code; continuation is continued development. Acceptance: no temporary solutions or unstructured code are used.

FR-43 — Honestly explain resource or tool limitations. As a Game Developer / Maintainer, I should honestly explain any resource or tool limitations, so that the project's boundaries are clear. Provenance: explicit. Lifecycle: initiated by encountering a limitation; observable result is an honest explanation of the limitation; failure is a hidden or misrepresented limitation; continuation is work within the stated limits. Acceptance: resource and tool limitations are honestly explained.

FR-44 — Report against the eight evaluation criteria. As a Game Developer / Maintainer, I should report the project against architecture quality, code quality and readability, gameplay quality, graphics quality, enemy AI, performance and optimization, stability and bug count, and extensibility and maintainability, so that the project's standing is clear. Provenance: explicit. Lifecycle: initiated by the maintainer completing the project; observable result is a report covering all eight criteria; failure is a missing criterion; continuation is the final evaluation. Acceptance: all eight criteria are reported.

FR-45 — Real evidence per criterion, distinguishing implemented, tested, and design-only. As a Game Developer / Maintainer, I should provide real evidence from the project for each criterion and distinguish implemented, tested, and design-only capabilities, so that the report is truthful. Provenance: explicit. Lifecycle: initiated by the maintainer writing the report; observable result is real evidence per criterion with the three capability states distinguished; failure is an unsupported claim or a conflated capability state; continuation is the final report. Acceptance: each criterion carries real project evidence and each capability is marked implemented, tested, or design-only.

Identity and Access

FR-46 — Player self-service enrollment before first use. As a Player, I should establish my own access before first use, so that my progress can be bound to me. Provenance: required_inference. Lifecycle: initiated by the Player on the anonymous Login surface; observable result is an established player identity; failure is a failed enrollment; continuation is entry to Gameplay. Acceptance: a new Player can establish access without prior provisioning.

FR-47 — Returning verification before loading or changing durable player state. As a Player, I should be verified on return before my durable state is loaded or changed, so that my saves, progression, and settings remain bound to me. Provenance: required_inference. Lifecycle: initiated by the returning Player on the anonymous Login surface; observable result is a verified identity and access to durable state; failure is a failed verification; continuation is entry to Gameplay with the correct state. Acceptance: durable player state is not loaded or changed before verification succeeds.

FR-48 — Invitation or provisioning for Game Developer / Maintainer access. As a Game Developer / Maintainer, I should receive access by invitation or provisioning, so that maintainer access is not open self-service. Provenance: required_inference. Lifecycle: initiated by an invitation or provisioning action; observable result is an established maintainer identity; failure is an unprovisioned attempt; continuation is entry to Build Test. Acceptance: maintainer access is established by invitation or provisioning.

FR-49 — Backend persistence for saves, progression, settings, and test evidence. As a Game Developer / Maintainer, I should have backend persistence for saves, progression, settings, and test evidence, so that durable state survives across sessions. Provenance: required_inference. Lifecycle: initiated by a save, progression change, settings change, or test run; observable result is persisted state; failure is a persistence failure; continuation is retrieval of the persisted state. Acceptance: saves, progression, settings, and test evidence persist across sessions.

4. User Personas

Player

Product context. The Player is the single active human role inside the game. They launch honest-hi, control the main character in a third-person 3D world, and play through the Action-Adventure-Survival experience: exploring diverse and dynamic environments, fighting enemies with a combat system built on attacks, defense, dodging, and special skills, taking main and side missions, earning rewards, and saving progress.

Primary goal. Complete the final challenge level's mission loop: enter the environment, receive a mission, explore, encounter enemies, fight, complete the objective, receive the reward, and save progress.

Distinct accepted responsibilities. The Player moves and jumps the character, controls the third-person camera, explores the world, engages and disengages combat, uses attacks, defense, dodging, and special skills, faces enemies whose AI detects them by sight and sound and whose behaviors differ, receives and tracks missions, completes objectives, receives rewards, advances skills, equipment, and abilities, adjusts settings, and saves and loads progress. The Player also experiences the day/night cycle and dynamic weather, and reads the health bar and gameplay information on the HUD.

Relevant inputs and decisions. The Player decides when to explore, when to engage, when to defend or dodge, when to use a special skill, when to take a mission, when to advance progression, and when to save. The Player inputs through a controller or a keyboard.

Interactions with other accepted participants. The Player's only in-game counterparties are the AI enemies, which are not human personas. The Player interacts with the Game Developer / Maintainer only indirectly: the maintainer builds, tests, and extends the game the Player plays, and the maintainer's Build Test surface verifies the same challenge-level flow the Player performs.

Observable success. The Player completes all eight steps of the challenge level in one session, sees the reward granted, and sees the progress saved and correctly restored on return.

What makes this role different. The Player is the only role that experiences the game as a game: their work is play, their decisions are tactical and exploratory, and their success is measured by completing the mission loop rather than by verifying the project.

Game Developer / Maintainer

Product context. The Game Developer / Maintainer is the role that builds, runs, tests, measures, and extends honest-hi. The source explicitly requires a modular, clean, extensible architecture with separated gameplay systems, save/load, event management, settings, error handling, controller and keyboard support, and future extensibility, plus repeatable tests and performance measurement.

Primary goal. Deliver a real, runnable, testable, extensible project and report it honestly against the eight evaluation criteria, distinguishing implemented, tested, and design-only capabilities.

Distinct accepted responsibilities. The maintainer designs the architecture before implementation; implements and tests each system independently; specifies folder structure, main files, classes, and inter-system relationships; writes real, coherent, runnable code; avoids temporary solutions and unstructured code; identifies parts requiring external files, tools, or assets; states any inability to produce real graphics files and uses workable substitutes; specifies the performance measurement method and avoids fabricated numbers; designs tests for movement and collision, combat, AI, save/load, UI, and performance under high-traffic conditions; identifies likely bugs, proposes fixes, and writes repeatable tests; and produces the evaluation report with real evidence per criterion.

Relevant inputs and decisions. The maintainer decides the engine (Unreal Engine 5 or Unity), the architecture, the module boundaries, the AI decision method (Behavior Tree or another suitable method), the optimization targets, the test design, and the honest reporting of limitations.

Interactions with other accepted participants. The maintainer's work produces the game the Player plays. The maintainer verifies the same challenge-level flow the Player performs, and reports on the systems the Player uses.

Observable success. The project builds and runs; each system is independently tested; performance is measured by a specified method with no fabricated numbers; the evaluation report covers all eight criteria with real evidence and correctly distinguishes implemented, tested, and design-only capabilities.

What makes this role different. The maintainer's work is engineering and verification, not play: their success is measured by architecture quality, code quality and readability, test coverage, honest measurement, and extensibility, and their access is established by invitation or provisioning rather than open self-service.

5. Core User Flows

Flow 1 — Player discovers the game and establishes access

1. The Player arrives at Landing anonymously. The surface presents the original Action-Adventure-Survival game, its genre, its engine, its status, and its playable mission experience.
2. The Player reads the capability sections covering gameplay, graphics, enemy AI, architecture, optimization, testing, and the challenge level.
3. The Player chooses to enter the game experience and proceeds to Login.
4. On Login, a first-time Player establishes access through self-service enrollment (FR-46). A returning Player is verified before any durable state is loaded or changed (FR-47).
5. Observable result: identity is established and the Player is routed to Gameplay.
6. Failure and recovery: if verification fails, the failure is stated plainly and the Player may retry without losing entered context, or return to Landing.
7. Continuation: the Player enters Gameplay with the correct durable state.

Flow 2 — Player explores the world and moves the character

1. The Player is in Gameplay with an established identity.
2. The Player moves the character and jumps using a controller or keyboard (FR-26, FR-29).
3. The third-person camera follows the character through the diverse, dynamic 3D world (FR-2).
4. The character animates naturally across movement states (FR-3).
5. The Player observes the day/night cycle and dynamic weather through World (FR-7).
6. Observable result: the character traverses the environment and the world's conditions change over time.
7. Failure and recovery: if the environment fails to load or a collision failure occurs, the failure is surfaced and the Player may reload the environment or return to the last save.
8. Continuation: the Player continues exploring or proceeds to an encounter.

Flow 3 — Player encounters enemies and observes their AI

1. The Player is exploring in Gameplay and enters an area with enemies.
2. Encounters presents enemies whose behavior is driven by the behavior-based decision system (FR-18).
3. The Player is detected when they enter an enemy's field of view or make sound (FR-12).
4. The Player observes enemies patrolling intelligently before detection (FR-13), then chasing and searching for them after detection (FR-14).
5. The Player observes enemies taking cover in combat (FR-15), cooperating as a group (FR-16), and reacting to environment events (FR-17).
6. Observable result: enemy behavior is observable and consistent with the enemy's current state, and differing enemy behaviors are distinguishable (FR-4).
7. Failure and recovery: if an AI or navigation failure occurs, the failure is surfaced and the encounter can be reset, or the Player may return to the last save.
8. Continuation: the Player evades, engages in Combat, or continues exploring.

Flow 4 — Player fights using the combat system

1. The Player engages an enemy and enters Combat.
2. The Player attacks (FR-5).
3. The Player defends against an incoming attack (FR-5).
4. The Player dodges (FR-5).
5. The Player uses a special skill (FR-5).
6. The Player reads the health bar and gameplay information on HUD (FR-29).
7. Observable result: each combat action resolves with an observable effect, and the Player's and enemy's combat condition update.
8. Failure and recovery: an invalid or unavailable action is rejected with clear feedback; the Player may dodge or defend to recover position, or disengage.
9. Continuation: the Player continues combat, disengages back to Gameplay, or proceeds to complete a mission objective.

Flow 5 — Player receives a mission, completes it, and receives a reward

1. The Player enters the environment and receives a mission through Missions (FR-8, FR-36).
2. The Player tracks the mission's objectives and reads its win and lose conditions (FR-29).
3. The Player explores the environment and encounters enemies (FR-36).
4. The Player uses the combat system to overcome the enemies (FR-5, FR-36).
5. The Player completes the mission objective (FR-36).
6. Observable result: the mission's win condition is satisfied and the reward is granted (FR-36).
7. Failure and recovery: if the mission's lose condition is met, the mission can be restarted; if a mission state failure occurs, it is surfaced and the mission can be restarted or the Player may return to the last save.
8. Continuation: the Player advances progression with the reward.

Flow 6 — Player advances skills, equipment, and abilities

1. The Player has earned a reward from a completed mission.
2. The Player opens Progression and reviews current skills, equipment, and abilities.
3. The Player advances a skill, an item of equipment, or an ability (FR-6).
4. Observable result: the advancement is applied and observable, and it persists.
5. Failure and recovery: an unavailable advancement is rejected with clear feedback; the Player may return to Gameplay or reload the progression state.
6. Continuation: the Player returns to Gameplay with the advanced state.

Flow 7 — Player saves and resumes progress

1. The Player opens Save Load.
2. The Player creates a save (FR-22).
3. Observable result: the save is written and the saved state includes progression, mission state, and settings.
4. The Player later returns, is verified on Login (FR-47), and loads the save.
5. Observable result: the loaded state matches the saved state and the Player resumes progress.
6. Failure and recovery: a corrupt or missing save is reported and the Player may choose another save or start fresh.
7. Continuation: the Player resumes play from the restored state.

Flow 8 — Player adjusts settings

1. The Player opens Settings.
2. The Player adjusts a supported input or presentation setting (FR-24).
3. Observable result: the setting is applied and persists.
4. Failure and recovery: an invalid value is rejected with clear feedback; the Player may restore defaults or re-enter a valid value.
5. Continuation: the Player returns to Gameplay with the applied setting.

Flow 9 — Game Developer / Maintainer establishes access and verifies the project

1. The Game Developer / Maintainer receives access by invitation or provisioning (FR-48).
2. The maintainer proceeds to Login and is verified.
3. Observable result: the maintainer is routed to Build Test.
4. Failure and recovery: an unprovisioned attempt fails and the failure is stated plainly.
5. Continuation: the maintainer begins verification work.

Flow 10 — Game Developer / Maintainer runs tests, measures performance, and reports

1. The maintainer is in Build Test with an established identity.
2. The maintainer runs the test suites for movement and collision, combat, AI, save/load, UI, and performance under high-traffic conditions (FR-34).
3. The maintainer reviews identified bugs, proposed fixes, and the repeatable tests that confirm the fixes (FR-35).
4. The maintainer runs performance measurement using the specified method, with no fabricated numbers (FR-33), covering frame rate, RAM and VRAM usage, draw calls, object and resource management, LOD and culling, staged environment loading, and physics and AI (FR-32).
5. The maintainer walks the complete challenge-level flow — enter environment, receive mission, explore, encounter enemies, use combat, complete objective, receive reward, save progress (FR-36) — to verify the Player's end-to-end path.
6. The maintainer produces the evaluation report across architecture quality, code quality and readability, gameplay quality, graphics quality, enemy AI, performance and optimization, stability and bug count, and extensibility and maintainability (FR-44), with real evidence per criterion and each capability marked implemented, tested, or design-only (FR-45).
7. Observable result: test results, performance measurements, and the evaluation report are produced with real evidence.
8. Failure and recovery: a test or measurement failure is reported with its cause and can be re-run.
9. Continuation: the maintainer fixes, re-tests, and extends the project.

6. Visuals Colors and Theme

The creative direction is authoritative for this section: Cinematic future tech for a survival action world, with Gleb Kuznetsov as the muse. The register is a launch trailer, not a SaaS landing page — dark voids, glowing volumetric forms, HUD-like data, and motion as the hero.

Headline direction. The public entry carries the wordmark HONEST-HI set in Space Grotesk 700 at clamp(48px, 9vw, 132px), stacked over three uppercase micro-labels — GENRE / ENGINE / STATUS — separated by hairline cyan rules.

Palette (dark mode).

Deep near-black navy ground (#05070C) carries 70% of the surface. Glass panels float at #0B1018 with 1px luminous strokes at 12% white. Electric cyan (#00E5FF) is the primary signal — HUD lines, active states, the player health bar, focus rings. Magenta (#FF2D6F) is reserved for danger: enemy aggro indicators, boss health, damage numbers, the "threat" state. Body text is #E6F0FF at 15:1 on background; muted metadata (#5A6B82) is used only for secondary labels at 4.6:1 minimum.

Typography.

• Headings: Space Grotesk — wide geometric grotesque, uppercase for micro-labels with 0.18em tracking, mixed-case display at 700 weight with tight -0.02em tracking for hero headlines. Headlines are set large and confident, never decorative.
• Body: IBM Plex Mono.
• Scale: 1.25 modular — 44 / 34 / 26 / 18 / 15 / 13.
• Hero display: clamp(48px, 9vw, 132px).
• Section headers: clamp(28px, 4vw, 56px).
• HUD labels: 12px uppercase tracked.
• Body: 15px / 1.65.

Shape language. Full-bleed dark canvas with floating glass panels (16px radius, 1px rgba(230,240,255,0.12) stroke, backdrop-filter: blur(18px)). Thin luminous cyan strokes draw HUD frames, corner brackets, and radial reticles. Hard-edged data chips (4px radius) sit next to soft glass cards to create tension between instrument and interface. Diagonal 1px scan lines at 8% opacity cross section boundaries.

Layout. Asymmetric radial composition: the hero is a full-viewport 3D scene with UI anchored to the four corners like a HUD — top-left: mission state; top-right: threat meter; bottom-left: player vitals; bottom-right: input legend. Content sections break the radial grid with a 12-column base, but every section opens with an uppercase micro-label and a hairline cyan rule that spans the column. Data-dense capability sections use a 3-up glass panel grid, never identical hover-lift cards — each panel has a different internal composition (one is a stat readout, one is a behavior-tree diagram, one is a code sample).

Imagery. One crafted real-time 3D subject in the hero: a low-poly-but-detailed survival character silhouette standing in a volumetric fog field, lit by a single cyan rim light and a magenta enemy glow in the deep background. Supporting imagery is abstract 3D — a rotating behavior-tree node graph, a particle field sampled from the day/night cycle, a wireframe terrain scan. No stock photography, no flat clip art, no device mockups.

Readable text and controls. Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. 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, it stops and shows whole items: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.

Forbidden. The generic indigo/blue-on-white SaaS template is forbidden for this project. Centred headline + subtext + blue CTA + gradient blob hero; grids of identical hover-lift cards; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for any text; blue-indigo (#0057FF / #2563EB / #4F46E5 / #6366F1 / #7C3AED) as primary or accent on a white ground; white or near-white page background; flat clip-art or stock photography in the hero; bouncy or springy micro-interactions; decorative gradient blobs or floating pastel shapes.

7. Signature Design Concept

The hero is the game engine, not a screenshot of it.

The public entry is a full-viewport WebGL scene (Three.js / React Three Fiber): a dark volumetric fog field with a single 3D character silhouette at 40% viewport height, off-center right at the 62% column, lit by a cyan rim light from the left and a magenta glow bleeding from the deep background. The left 38% is a solid #05070C colour block carrying the oversized HONEST-HI headline in Space Grotesk 700 at clamp(48px, 9vw, 132px), stacked over the three uppercase micro-labels GENRE / ENGINE / STATUS separated by hairline cyan rules. The CTA sits pinned beneath the headline as a hard-edged cyan chip with a corner bracket, not a pill. A HUD frame of thin cyan corner brackets wraps the viewport edges. No centred headline, no gradient blob, no blue button.

The signature moves that carry the concept through the page:

• A full-viewport WebGL hero with a real-time 3D character in volumetric fog, orbited by a slow cinematic camera and lit by cyan/magenta rim lights.
• Corner-anchored HUD chrome (mission state, threat meter, vitals, input legend) framing every section like a heads-up display, with thin cyan corner brackets that persist across scroll as a navigation affordance.
• The behavior-tree section rendered as an interactive 3D node graph the user can orbit — the AI architecture is the visual, not a diagram in a box.
• Oversized uppercase micro-labels with 0.18em tracking sitting above hairline cyan rules that span the full column width, creating a rhythmic instrument-panel cadence down the page.
• A scroll-scrubbed camera dolly: as the user scrolls, the hero camera pushes forward through the fog field, revealing the environment layers behind the character — motion is the storytelling device.

This concept only recomposes accepted content, states, and controls. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: a low-poly-but-detailed survival character silhouette standing in a volumetric fog field, lit by a single cyan rim light from the left and a magenta enemy glow bleeding from the deep background.
• Input → transformation → outcome thesis: as the user scrolls, the hero camera pushes forward through the fog field, revealing the environment layers behind the character; the slow orbit continues, light sweeps across the glass panels every 6s, type reveals stagger word-by-word with 40ms offsets, and data readouts count up. The outcome is that the user reads the game's identity while the scene itself demonstrates the engine's real-time capability.
• Motion vocabulary: continuous slow orbit of the hero scene; light sweeps across glass panels every 6s; scroll-scrubbed camera dolly that pushes through the environment as the user reads; staggered word-by-word type reveals with 40ms offsets, never bounce; data readouts that count up.
• Composed first frame: the character silhouette at 40% viewport height, off-center right at the 62% column, in volumetric fog; the left 38% is a solid #05070C block carrying the HONEST-HI headline over the three micro-labels; the CTA chip sits beneath the headline; thin cyan corner brackets wrap the viewport edges.
• Reduced-motion state: prefers-reduced-motion stops the orbit, freezes the scan, and swaps the scroll-scrub for a static hero image; all readable text and controls remain whole and fully legible.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

• Crafted real-time object/scene: a compact volumetric fog field containing one character silhouette, a cyan rim light, and a magenta background glow — the product's defining state (a lone survivor under threat in a dark world) rendered as a real-time scene rather than a static image.
• Why it is the defining state: the game's core is a third-person survivor facing AI enemies in a dynamic, dark world; the hero scene shows exactly that state.
• Constraints: the scene must initialize to a composed first frame, must not cover any readable text or control, and must degrade to a static hero image under prefers-reduced-motion or when WebGL is unavailable.

9. Non-Functional Requirements

NFR-1 — Performance on mid-range systems. The game must perform reasonably on mid-range systems. Provenance: explicit. Rationale: the source states the game must perform well on mid-range systems as far as possible.

NFR-2 — Measured, not fabricated, performance. Performance must be measured by a specified method, and fabricated numbers must not be presented. Provenance: explicit. Rationale: the source requires the measurement method to be specified and forbids fabricated numbers.

NFR-3 — Optimization coverage. Frame rate, RAM and VRAM usage, draw call count, object and resource management, LOD and culling, staged environment loading, and physics and AI must each be examined and optimized. Provenance: explicit. Rationale: the source enumerates these seven optimization areas.

NFR-4 — Modular, clean, extensible architecture. The architecture must be modular and clean, with separated gameplay systems, memory and resource management, save/load, event management, settings, error handling, controller and keyboard support, and future extensibility. Provenance: explicit. Rationale: the source enumerates these architectural requirements.

NFR-5 — Real, coherent, runnable code. Code must be real, coherent, and as runnable as possible; demo or non-runnable code must not be used as the final product; temporary solutions and unstructured code must be avoided. Provenance: explicit. Rationale: the source's rules section states these constraints directly.

NFR-6 — Honest limitation reporting. Any resource or tool limitation, and any inability to produce real graphics files, must be stated honestly, with workable substitutes used where real graphics files cannot be produced. Provenance: explicit. Rationale: the source requires honest explanation of limitations and workable substitutes.

NFR-7 — External dependency identification. Any part requiring external files, tools, or assets must be identified. Provenance: explicit. Rationale: the source requires external dependencies to be identified.

NFR-8 — Independent system implementation and testing. Each system must be implemented and tested independently. Provenance: explicit. Rationale: the source requires independent implementation and testing per system.

NFR-9 — Architecture before implementation. The architecture must be designed before implementation. Provenance: explicit. Rationale: the source requires architecture design to precede implementation.

NFR-10 — Test coverage across six areas. Tests must cover movement and collision, combat, AI, save/load, UI, and performance under high-traffic conditions. Provenance: explicit. Rationale: the source enumerates these six test areas.

NFR-11 — Repeatable bug-confirmation tests. Likely bugs must be identified, fixes proposed, and repeatable tests written to confirm the fixes. Provenance: explicit. Rationale: the source requires repeatable tests for bug confirmation.

NFR-12 — Evidence-based evaluation. The evaluation report must cover all eight criteria with real project evidence, distinguishing implemented, tested, and design-only capabilities. Provenance: explicit. Rationale: the source requires real evidence per criterion and the three-way capability distinction.

NFR-13 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, and no other element may cover any part of them. Provenance: explicit (creative direction). Rationale: the creative direction states this as a binding readability rule.

NFR-14 — Reduced-motion support. Under prefers-reduced-motion, the hero orbit stops, the scan freezes, and the scroll-scrub is replaced by a static hero image; moving and scrollable content stops and shows whole items. Provenance: explicit (creative direction). Rationale: the creative direction specifies the reduced-motion behavior.

NFR-15 — Durable state persistence. Saves, progression, settings, and test evidence must persist across sessions. Provenance: required_inference. Rationale: required to make the accepted save/resume and evaluation journeys executable.

10. Tech Stack

Game layer (source-specified).

• Game engine: Unreal Engine 5 or Unity — the source explicitly names these as suitable engines (FR-19).
• Enemy AI: Behavior Tree or another suitable method, with its architecture explained (FR-18).
• Visual pipeline: 3D modeling, shaders, lighting, PBR materials, dynamic lighting and realistic shadows, particle and weather effects, and appropriate optimization techniques (FR-10, FR-11).
• Input: controller and keyboard support (FR-26).

First-party web layer (Landing, Login, Build Test).

• Frontend: React with Three.js / React Three Fiber for the WebGL hero and the interactive behavior-tree node graph.
• Backend: Python / FastAPI for identity, saves, progression, settings, and test-evidence persistence (FR-49).
• Storage: a persistent datastore for player identity, saves, progression, settings, and test evidence.
• Containerization: Docker / docker-compose for the web layer and its datastore.
• Orchestration: Kubernetes only if deployment requires it; not required by the current scope.

Typography and styling. Space Grotesk (headings) and IBM Plex Mono (body), loaded as web fonts; CSS custom properties for the palette tokens in Section 6.

11. Assumptions and Constraints

Assumptions

• A-1. The game engine is chosen from Unreal Engine 5 or Unity; the specific choice is made by the Game Developer / Maintainer during architecture design. [Assumption — engine choice left open by source]
• A-2. The AI decision method is a Behavior Tree or another suitable method; the specific method is chosen by the maintainer and its architecture is explained. [Assumption — method left open by source]
• A-3. Where real graphics files cannot be produced, workable substitutes are used and the limitation is stated. [Assumption — source-permitted substitute path]
• A-4. The current horizon is the playable prototype plus one complete challenge level, with the optimization pass, the test suite, and the evaluation report. [Assumption — scope bounded by the source's prototype and challenge-level requirements]
• A-5. Player identity is established by self-service enrollment, and maintainer identity by invitation or provisioning. [Assumption — required_inference from the accepted journeys]

Constraints

• C-1. Do not merely explain; produce a real project as far as the tools allow. Provenance: explicit.
• C-2. Do not use demo or non-runnable code as the final product. Provenance: explicit.
• C-3. Identify any part requiring external files, tools, or assets. Provenance: explicit.
• C-4. Design the architecture before implementation. Provenance: explicit.
• C-5. Implement and test each system independently. Provenance: explicit.
• C-6. Avoid temporary solutions and unstructured code. Provenance: explicit.
• C-7. Honestly explain any resource or tool limitations. Provenance: explicit.
• C-8. If real graphics files cannot be produced, state that limitation and use workable substitutes. Provenance: explicit.
• C-9. Specify the performance measurement method and avoid fabricated numbers. Provenance: explicit.
• C-10. For each evaluation criterion, provide real evidence and distinguish implemented, tested, and design-only capabilities. Provenance: explicit.
• C-11. Optimize for reasonable performance on mid-range systems. Provenance: explicit.
• C-12. The generic indigo/blue-on-white SaaS template is forbidden for this project. Provenance: explicit (creative direction).
• C-13. Readable text and controls stay whole at every viewport; imagery, decoration, and motion may be cropped or bled but must cover no readable text or control. Provenance: explicit (creative direction).

Future Horizons

• Additional levels beyond the complete challenge level.
• Additional enemy archetypes beyond those required for the prototype and challenge level.
• Expanded story arcs beyond the main and side missions required for the current horizon.
• Expanded equipment sets beyond those required for the progression system in the current horizon.

12. Glossary

• Action-Adventure-Survival — the combined genre of honest-hi: real-time combat (Action), an explorable world with story and missions (Adventure), and a hostile environment with day/night and weather pressure (Survival).
• Behavior Tree — a structured, behavior-based decision method for enemy AI, or another suitable method with an explained architecture.
• Challenge level — the single complete level in which the player enters the environment, receives a mission, explores, encounters enemies, uses combat, completes the objective, receives a reward, and saves progress.
• Combat system — the system covering attacks, defense, dodging, and special skills.
• Core gameplay loop — the repeating cycle of exploration, encounter, combat, mission progress, reward, and progression.
• Day/night cycle — the dynamic progression of time of day in the world.
• Draw call — a single rendering command issued to the GPU; its count is one of the optimization areas.
• Dynamic weather — changing weather conditions in the world, with associated particle and weather effects.
• Field of view (FOV) — the visual cone through which an enemy detects the player.
• Game Developer / Maintainer — the active human role that builds, runs, tests, measures, extends, and reports on the project.
• HUD — the in-game heads-up display carrying the health bar and responsive gameplay information.
• LOD — level of detail; a technique for reducing rendering cost at distance, one of the optimization areas.
• Main mission — a story-critical mission.
• Mid-range system — the hardware class on which the game must perform reasonably.
• PBR — physically based rendering; the material standard required for the environment.
• Player — the active human role that plays the game.
• Progression system — the system for advancing skills, equipment, and abilities.
• Prototype — the runnable minimum version containing a controllable character, a 3D environment, a third-person camera, movement and jump, at least one AI enemy, a combat system, a health bar, a UI, and a simple mission with win and lose conditions.
• Save/load system — the system that writes and restores durable game state.
• Side mission — a non-story-critical mission.
• Staged environment loading — loading the environment in stages rather than all at once; one of the optimization areas.
• Third-person camera — the camera that follows the character from behind.
• Win/lose condition — the condition that determines mission success or failure.