# Indie FPS Roguelike — Project Plan Last updated: 15 October 2026. This is the current project brief, accepted requirements, roadmap and open acceptance. Read current status and affected accepted requirements before substantial work; follow [AGENTS.md](../AGENTS.md) and the contextual [workflow](AGENT_WORKFLOW.md). Source/assets establish behavior. Linked reports prove only their recorded revision/build/scenarios; proposals and agent opinions do not. The [complete earlier plan and chronology](PROJECT_HISTORY.md) are preserved separately; read history only when a decision, defect or evidence identity requires it. For enemy perception and search tuning, see the [settings reference](ENEMY_AI_SETTINGS.md). ## Current State and Next Step - **13 October enemy AI teardown, implemented on `codex/enemy-ai-rebuild`:** the user requested removal of the old AI and its dedicated tests before a fresh replacement. Autonomous enemy behavior is intentionally unavailable at this checkpoint. The target baseline retains passive damageable networked enemies, player combat/status/Scan, safe spawning, rewards and stage/session plumbing. Retained suites passed (1060 EditMode, 112 PlayMode), all three builds succeeded, and affected local two/four-player checks passed within recorded identity/reuse limits; human acceptance remains open. see the [removal record](superpowers/plans/2026-10-13-enemy-ai-removal.md). - **Replacement direction:** Destiny-inspired ownership with roguelike moving pressure areas; broad encounter guidance and evidence-based individual targeting; no pack-wide cover freeze; bounded pursuit with useful reassignment; no routine teleport/healing; hidden retirement only under the agreed failure policy. Bombardiers use a bounded last-seen-location window before repositioning. The [scenario catalogue](Design/Enemies/2026-10-13-ai-replacement-scenarios.md) records confirmed choices and remaining tuning. Research and scenarios are not an implemented replacement or gameplay acceptance. - **Replacement framework selected, 13 October:** the local manifest and lockfile now pin Unity Behavior **1.0.16** (`com.unity.behavior`). Individual decisions use its graphs and custom C# nodes; encounter/squad guidance, evidence, positioning and validated execution retain their separate ownership. See the [integration design](Design/Enemies/2026-10-13-unity-behavior-rework.md). The isolated M1 foundation is implemented and verified: validated server startup, private graph/capability state, lifecycle/status interruption and stale-callback rejection. Final checks passed 24 native lifecycle/passive cases, 38 retained rule cases, and one genuine stopped-session reload case; Windows release exclusion passed. Three independent perspectives reviewed before and after. Normal enemies remain passive; active NGO hot reload, combat and human acceptance are not established. No custom general-purpose tree runtime/editor is planned. The [implementation checklist](superpowers/plans/2026-10-13-enemy-ai-implementation.md) sequences the shooter foundation, moving pressure, roster and first-stage acceptance, and records exact evidence/limits and deferred M0 prerequisites. M2 perception is now implemented: private lifetime-scoped sight/report/hearing memories, stable targeting/reaction rules and an opt-in Editor view. Fresh final proof passed 39 native M2/lifecycle/passive cases, all 1,074 EditMode cases (including stopped-session reload), and normal/debug/release Windows builds with diagnostic exclusion. Three independent perspectives reviewed before/after; the view's selection side effect was reproduced and fixed. M3 positioning/claims/movement is now implemented in isolated fixtures: evidence-based useful positions, lifetime/action-owned claims, fair bounded planning and one status-constrained movement writer. Fresh frozen proof passed 77 native M3/M1/M2/passive cases, all 1,083 EditMode cases (including stopped-session reload), and normal/debug/release Windows builds with exclusion audits. Three independent perspectives reviewed before/after and cleared the corrected ramp/ownership/yield boundaries. Normal enemies and Play alone remain passive; tests create temporary navigation/services, with no convenient manual M3 sandbox installed. M4 ordinary shooter attack and graph is now implemented at its isolated automated gate: preparation pays once, releases validate sight/muzzle/lifetime/status, recovery survives cancellation, and launched flight remains service-owned. Authored-muzzle cover/stair graph tests and real two/four-peer authority pass. Evidence includes 37 M4 native cases, fresh 93 navigation/projectile/passive cases after a test-only teardown repair, compatible unchanged 1,096 EditMode proof and normal/debug/release exclusion builds. The original 168-case native attempt failed in projectile cleanup; unchanged subset proof is explicitly reused, not presented as a fresh GREEN168. Three independent perspectives and delta rechecks clear the source. M5 now adds an explicit Editor-only shooter sandbox (**ProjectI > Debug > Enemy AI > Shooter sandbox**) with one/three shooters, ordinary player combat, F5/host reset and practical Stop/relaunch. Five scripted cases and opt-in owner diagnostics accompany it; pursuit/disconnected recovery remain partial M6/M7 stubs. Normal stages/Play alone remain passive. Actual human cover feedback exposed stationary remembered-sight planning and missing facing. The focused correction now requires useful investigation, permits supported lateral detours and finishes facing captured personal evidence at a bounded rate without extending its original deadline. That cover checkpoint passes 190 native and 1,103 EditMode leaves with exclusion builds. The shooter now also has an editable native visual Behavior graph and sandbox live-target picker, preserving runtime GUID/file ID, private bindings and decisions. Actual native debugger attach/switch/reset and seek/wait/attack icons match real instance states. Fresh conversion proof passes 86 affected native and 1,106 full EditMode leaves (including genuine stopped-session reload), plus normal/debug/release exclusion builds; 104 unchanged native leaves retain compatible prior proof. Earlier failures and identities stay separate. Three independent pre/post perspectives and compact delta reviews clear the source. A further human-requested tune now keeps short local seeks facing captured personal evidence (4.25 m whole-route cutoff), with shooter-only six-second memory and ±105° sight. Final proof passes 91 affected native and 1,114 full EditMode leaves plus all three exclusion builds; 16 unchanged perception/passive leaves retain separately attributed compatible proof. The manual fixture is reopened for the user's retest. Its existing observation view now shows remembered/expired personal evidence and the accepted move destination/full route in Scene view, opened from the sandbox's inspected shooter. Editor-only observer checks pass two focused native cases and 1,116 full EditMode cases; unchanged E45B player builds are explicitly reused. Human retest/combat/readability, hardware and separate-network acceptance remain pending. The user-requested [M5B local-investigation plan](superpowers/plans/2026-10-13-enemy-ai-implementation.md#m5b--bounded-local-investigation-with-per-enemy-search-strength) is implemented within its isolated automated gate: captured local hypotheses, useful viewpoints/observation, checked history and per-enemy strength replace forced movement. Native coverage is 209 compatible unchanged leaves from the 225-case gate plus the final 17-case sandbox fixture; final full EditMode passes 1,127 including genuine reload. Normal/development/release builds and release exclusion pass. Two/four-peer packaged search/lifecycle checks pass on one build; the normal-menu regression passes ten phases. Query caps/timing are recorded; allocation measurement is unavailable in this Editor. The Editor is ready with one Ordinary shooter, observations and native graph open. Human keep/tune/revert, representative hardware, separate-network/search-active latency and unexpected search-active host-process loss remain pending. See the packet for exact reuse predicates, status-assisted disconnect setup and proof limits. The authorized angled cover-sampling follow-up is implemented: geometry-only samples and expected-height projection address missed pockets, slopes and close stacked floors. Its pre-control gate covers 205 compatible retained + 27 fresh native leaves, 1,127 full EditMode, three audited builds and two/four-peer packaged checks. Later Inspector density, metre radius and degree half-angle controls have compilation/binding/all-three review evidence only: the user explicitly requested no new tests after exposure. One Ordinary shooter is reopened for human keep/tune/revert; that acceptance remains pending. See the [extension record](superpowers/plans/2026-10-13-enemy-ai-implementation.md#m5b-cover-sampling-extension--14-october-2026). The latest authorized batching follow-up removes the one-query-per-request/frame limit while retaining shared FIFO reservations/caps, and exposes shared path/probe budgets in the sandbox Inspector with reset-applied values. All three pre/post reviews clear source; no new tests/builds were authorized at that checkpoint. Earlier automated proof predates this scheduler change. See the packet's [batching handoff](superpowers/plans/2026-10-13-enemy-ai-implementation.md#m5b-shared-query-batching--14-october-2026). The user-approved wall-crossing cone now replaces the extra cover ring: only real wall hits with a bounded far-side exit and supported, clear, reachable floor add assumptions. Cone half-angle, attempted ray count and local metre reach are editable; Ordinary/Weak start at a 30° opening, while Persistent's disabled probes are preserved. All 13 focused native cover cases pass, including ramp/stair tops, slopes, mesh/compound walls, missing floor, open space and Normal/Large stacked floors. Three independent source perspectives clear the slice. The later authorized broader pass verifies all 1,129 EditMode cases with genuine reload, 240 affected native leaves (222 compatible retained passes plus 18 fresh Scenario passes after a stale authored-preset assertion repair), three Windows builds with release exclusion, matching two/four-peer packaged search and ten normal-menu phases. Runtime/assets/tuning are unchanged in that pass. Packaged search is one-process loopback; human/hardware/separate-network/search-active latency and host-process-loss acceptance remain open. See the [integration record](superpowers/plans/2026-10-13-enemy-ai-implementation.md#cone-integrated-verification-follow-up--14-october-2026). A later user-requested follow-up adds an independently captured **Non-cover radial sample count** (0–16) and actual cone hit/miss/unknown query history to the existing memory/movement overlay. Prediction labels identify wall-hit versus normal search sources, including checked points. Shared prediction/budget limits and authored tuning remain; later radial attempts may fill slots left empty by rejected samples. Compilation, Inspector bindings and three source reviews pass. **No tests/builds were run, as requested**; the broader gates above predate this delta, and rendered/behavioral acceptance remains open. See the [follow-up record](superpowers/plans/2026-10-13-enemy-ai-implementation.md#independent-radial-density-and-cone-ray-overlay--14-october-2026). A subsequent wall-hit rejection fix allows the wall entry before the local probe region while retaining all final floor bounds and reachability checks. The new boundary regression plus existing wall/ramp/stair cases pass4/4 at the recorded source; broader suites/builds were omitted under the user's limited-test request. User tuning is preserved. See the [fix record](superpowers/plans/2026-10-13-enemy-ai-implementation.md#wall-entry-rejection-fix--14-october-2026). The authorized retrospective corrections preserve lower-floor ordinary travel and reject actor-blocked current firing holds; diagnostic-only status is excluded from release. That checkpoint's proof includes 145 observed native passes, 103 separately compatible retained passes, 1,129 full EditMode cases, three audited builds and two/four-peer packaged checks. Earlier three-searcher setup qualification remains threshold-sensitive; the observed pass does not establish stability. Optional finding #4 stays deferred, and human retest remains pending. See the [correction record](superpowers/plans/2026-10-15-enemy-ai-retrospective-fixes.md). The [stair/wall correction checkpoint](superpowers/plans/2026-10-15-stair-wall-fix.md) has 64 fresh focused native passes with physical collision checks retained; captured stairs and upper-wall prediction/admission are covered. Narrow ramp-side entry remains physically blocked and unresolved; broader gates and human acceptance remain open. **Latest M5/M5B checkpoint, 15 October:** the user accepts the gameplay, cover/search, ramp firing and corrected stair movement as working well. The final authored Persistent values include 20 s evidence retention, 45 m search travel, near-cover weight 3 and minimum gain 0.05. Bounded firing endpoints recover blocked muzzle positions; planar stepping and action-owned seam steering correct the captured 3 mm-to-9.138 mm native snap and floating-corner progress starvation without weakening safety checks. Final fresh verification passes 1,129/1,129 EditMode with genuine reload and all 261 affected native cases, including ascent/descent, status/push and graph release. Normal/development/release builds and exclusion audits, packaged two/four-peer loopback checks and all ten MainMenu phases pass. M5/M5B are accepted within the documented coverage limits; the scoped local commit is authorized. See the [closure record](superpowers/plans/2026-10-15-firing-position-ramp-fix.md#m5m5b-final-closure--authorized-15-october). That record retains earlier failures, exact identities, review decisions and qualification limits. Normal enemies remain passive; no production promotion. **M6 is a separate task.** - **Spawn director S1/S2 accepted checkpoint, 15 October:** validated credit/composition definitions, reserved ordered mixed groups, bounded saving/scheduling and damageable arrivals are implemented in the opt-in Shooter sandbox. Coverage includes 1,202 EditMode passes, 228 compatible unchanged native passes plus 54 fresh tracer passes after a test-only setup repair, three audited builds and local two/four-player/menu/stage regressions. Actual rendered peer cues retain at least 0.94 s before authoritative readiness in the measured one-process samples. The user explicitly signed off S2 and its elite-pack follow-up on 15 October 2026, closing the end gameplay/readability checkpoint within the opt-in prototype scope. Production bindings remain passive; S4, coordination and M6-SPAWNING-READY remain unchecked. See the [execution record](superpowers/plans/2026-10-15-spawn-director-and-coordination-plan.md#s2-execution--15-october-2026) for identities, preserved failures, provisional tuning and the end playtest. **Elite-pack follow-up, 15 October:** single-type normal packs can replace at most one member using editable per-card chance and fully captured elite cost. Bombardiers are distinct, elite-only cards and may join the ordinary ranged upgrade pool when listed in the active profile. Saving policy and production activation are unchanged. See the [follow-up record](superpowers/plans/2026-10-15-spawn-director-and-coordination-plan.md#elite-pack-follow-up--authorized-15-october-2026) for verification and scoped closure. The [S2 user sign-off](superpowers/plans/2026-10-15-spawn-director-and-coordination-plan.md#s2-user-sign-off--15-october-2026) records acceptance without claiming new hardware or separate-network evidence. Fresh final-source proof passes 1,229 EditMode and 24 native cases; packaged lifecycle, menu and stage checks are explicitly reused for unchanged paths after a finite-cost fix. - **Spawn director S3 implementation checkpoint, 15 October:** the opt-in boss fixture replaces exploration at 40 eligible kills, retains living actors and discards old finances/work. A safely placed passive boss starts its independent reinforcement profile once; terminal cleanup invalidates pending admissions. Boss tuning is provisional (3 credits/s, ceiling 60, initial 0, interval 8 s, add limit 6). Independent pre/post technical, gameplay and design reviews cleared after the S2 fixture boundary was restored. Fresh proof passes 1,234 EditMode and 54 native cases, three audited builds, packaged two/four-player lifecycle, ten menu and 23 normal stage progression phases. One four-player setup timeout is retained; one authorized fresh cohort passed under unchanged limits. End human gameplay acceptance remains open. See the [S3 execution record](superpowers/plans/2026-10-15-spawn-director-and-coordination-plan.md#s3-execution-packet--15-october-2026). Boss attacks (M14), hidden retirement (M7), S4, coordination and production activation remain separate; M6-SPAWNING-READY remains unchecked. - **Director diagnostics follow-up, 15 October:** development-only arrival/boss bank, saving target, next purchase/placement attempts and actual birth history are available through an F6 in-game overlay and **ProjectI > Debug > Enemy AI > Director debug**. The overlay groups spawned members by pack and tier; the Editor window lists the latest 12 individual births. The user accepted the revised grouping at the ASAP checkpoint. Fresh final proof passes 1,242 EditMode and 55 native cases plus three audited builds with diagnostics excluded from Release. Unchanged S3 packaged paths reuse their original evidence; narrow/long-text visual limits are retained in the [follow-up record](superpowers/plans/2026-10-15-spawn-director-and-coordination-plan.md#director-debug-screen-follow-up--15-october-2026). This does not sign off S3 or activate production/S4. - **Normal entry and preservation:** MainMenu into hand-authored VerdantRelay. Preserve manual terrain, saved NavMeshes, asset GUIDs and the user's material changes. PlayTestScene remains a development fixture. Preserve the pinned Unity version and resolved package versions. - **Retained game foundation:** online co-op, player combat, classless loadouts, rewards/stage travel/results/settings remain within their recorded acceptance limits. Permanent ability-unlock persistence remains pending. Prove one stage before expansion. - **Historical AI evidence:** the former modularization, pack, cover-grace, movement, roster-behavior and natural-arrival results describe retired revisions, including baseline `161f6ab`; they are not current-branch AI proof. Their dated records remain available in the [old modularization plan](superpowers/plans/2026-10-11-enemy-ai-modularization-and-behaviour.md) and [arrival report](PACK_ARRIVAL_VALIDATION.md). Teardown grants no new campaign attempts and does not close historical incomplete coverage. - **Remaining acceptance:** replacement AI implementation and human combat/readability, representative hardware and separate-network co-op validation remain open. Current retained-subsystem results are recorded separately from removed AI tests. ## Vision and Scope Build an original stylised low-poly, space-fantasy first-person shooter roguelike with online co-op for up to four players. Target PC initially; other platforms remain undecided. Use Unity 6, Universal Render Pipeline (URP), and C#; use Blender, Git/GitHub, Git LFS, and ChatGPT/Codex for development. Combine responsive aiming and shooting inspired by Destiny 2 with escalating enemy pressure, stacking bonuses, and replayable runs inspired by Risk of Rain 2. These are player-experience references: do not copy assets, characters, names, lore, or distinctive presentation. The setting combines futuristic weapons and technology with mysterious powers, ancient ruins, strange ecosystems, and otherworldly landscapes. Aim for isolation, discovery, beauty, and escalating danger. Give stages distinct atmospheres while preserving a coherent universe. Priorities, in order: playable multiplayer combat; maintainable architecture; simple systems; modular components; performance; Editor iteration; reusable prefabs/ScriptableObjects; minimal dependencies; consistent low-poly art. Use placeholders to prove gameplay before production artwork. ## Gameplay Requirements ### Runs and Encounters - Initially target roughly 20-minute runs across four stages of roughly five minutes each. These are playtesting targets, not rigid timing rules. - Start with handcrafted levels. Decide final layout/generation approaches later. - User's level direction: open, medium-sized floating islands, similar in feel to Risk of Rain. Handcrafted levels preserve an original space-fantasy world; exact biomes, dimensions and topology remain subject to authoring and playtesting. - Each stage needs a distinct visual, atmospheric, and encounter identity; horde combat; tactical elite enemies; and a boss near its end that must be defeated. - Support both single-target and area-damage builds without one consistently dominating every encounter. - Prove one stage before expanding to a full run. ### Weapons and Abilities - Equip two weapons simultaneously and allow switching. Begin with two distinct combat roles. - Planned categories include sniper rifles, hand cannons/pistols, automatic rifles, and semi-automatic rifles. Add categories only when gameplay justifies them. - User requested a refined roster including a heavy hand-cannon pistol and shotgun. The combined plan proposes carbine, hand cannon, shotgun, SMG and marksman roles first, with sniper/launcher options later; two weapons remain equipped. Proposed damage/rate/reload values require measured balance tests. - Prioritise responsive firing, clear hits, satisfying recoil/recovery, distinct handling, and readable audiovisual feedback. Expand after the foundation feels good. - Current classless builds have seven slots: two distinct passives, three distinct normal actives (Q/F/C), one ultimate (Z), and separate melee (V). Loadout validation, serialization, charges/refunds, upgrade eligibility, input and picker/HUD use explicit slot identities. Arc Lance and Shield Pulse join the normal choices; Starfall and Aegis Surge are the first ultimate choices. - Equipped abilities supply effects and contribute to base stats. Make mobility, survivability, and damage trade-offs explicit; an all-movement build should sacrifice survivability and damage potential. - Keep balance values configurable and stat calculations inspectable. Introduce additional stats only for clear gameplay needs. - Use expandable `WeaponDefinition` and `AbilityDefinition` bases with shared damage/rate/ammo/handling and cooldown/effect/stat fields. Concrete subclasses resolve validated host actions; mutable runtime state stays separate from shared assets. - Requested expansion: six passives with gameplay effects and related stat contributions; examples include double jump plus movement speed and a gun-only 20% bonus for five seconds after using an active. Separate attack damage (guns) from ability damage; dodge follows current movement input. Picker groups follow the user's circular P/A1/A2 sketch and describe choices on hover/focus. - Prototype death policy: teammates can revive a downed player by holding E within 3 m and line of sight for 3 seconds, restoring 30% health. Downing clears temporary effects; no bleedout timer in this pass. Host practice reset supports solo/all-downed testing. ### Progression and State Boundaries Players choose core weapons and abilities before a run. In-run bonuses strengthen or modify that build through stats, effects, and synergies; they must not replace equipped core abilities. Implemented run scope: enemy kills have a random chance to drop tiered upgrade choices, with common base-stat improvements and less common effects such as independently stacking shot-damage-scaled bleed, extra on-hit projectiles and additional active-ability charges. The combined plan recommends personal choices from shared co-op drop events, host-owned rewards/stats, uncapped authored upgrade ranks with finite numerical representation and restrictions preventing recursive damage effects. Proposed loot/rarity rates were adopted as initial tuning defaults. Add synchronized stage advancement, an upper-corner completed-stage count and stage-dependent enemy toughness. Preserve run upgrades between stages. The proposed downed/revive policy retains run upgrades while any teammate can revive the player; final team defeat snapshots a summary (kills, damage, upgrades, stages and other run statistics) before clearing run state and returning to menu. This distinguishes temporary downing from final death. Checkpoint recovery and stage-scaling defaults are implemented; balance acceptance remains pending. Permanent progression unlocks abilities that expand future choices. Death removes run bonuses and temporary stat increases/effects while retaining ability unlocks. Do not assume persistent currency, permanent stat upgrades, retained loot, or weapon progression without a new request. Keep permanent unlocks, equipped loadouts, base stats, and temporary run modifiers distinct. Use ScriptableObjects for shared authoring definitions where appropriate; mutable player/run state must not live in shared asset definitions. ## Multiplayer Architecture Multiplayer is foundational: the first playable prototype must support online co-op, rather than retrofitting networking after a complete single-player game. Before choosing a stack, compare suitable options using current official documentation. Explain hosting, authority, service dependencies, operating costs, and practical limitations. Record the decision and rationale. The foundation selected the existing Unity NGO/Multiplayer Services stack after comparison with Mirror and Photon Fusion; rationale, versions, licenses, costs, and limitations are in `Docs/NETWORKING_DECISION.md`. The server or authoritative host owns shared gameplay outcomes: damage, enemy state, spawning, stage progression, and run rewards. Clients supply input and responsive local presentation. Validate requests at the authoritative boundary and avoid conflicting copies of shared state. Preserve responsive aiming, movement, and shooting. Introduce prediction, interpolation, reconciliation, or lag compensation only where the chosen stack and gameplay require them. Validate session joining/leaving, two-player and four-player play, movement, weapons, damage, abilities, enemy spawning/death, boss/stage progression, latency, and disconnects early. Decide disconnect and host-loss behaviour explicitly rather than assuming host migration. ## Proposed Development Milestones These milestones sequence the agreed scope, not commitments to dates. The selected networking stack is recorded below. Plan each substantial feature using the current workflow after inspecting the affected systems. ### 1. Project and Network Foundation — In progress - Inspect installed/connected tools and relevant Unity skills; confirm project, Editor version, and play-mode state when available. - Choose and pin the Editor/packages, record the networking decision, and configure the URP project, Git ignores, and appropriate LFS patterns. - Establish a greybox arena, player spawn, online session flow, and basic networked first-person movement. - Record reproducible setup, test, and build steps. **Completion evidence:** clean project opening and a PC build; actual two-player and four-player join, movement, leave, and disconnect checks, with limitations recorded. ### 2. Responsive Combat and Classless Builds — Implemented; human acceptance pending - Implement aiming, firing, switching, two distinct weapons, hit feedback, and authoritative damage. - Implement all seven ability slots using a small representative ability set. - Make build stat contributions and trade-offs visible and configurable. - Add the minimal combat HUD and co-op player information. **Completion evidence:** players can equip builds and use weapons/abilities together; shared damage stays consistent; local responsiveness and latency behaviour are checked in play. ### 3. One Complete Playable Stage — Stage loop implemented; permanent progression pending - Add bounded horde spawning, a basic enemy, an elite, and an end-of-stage boss. - Add a small set of temporary bonuses, stage completion, and a basic transition. - Implement basic permanent ability-unlock persistence and the specified death/reset boundaries. **Completion evidence:** a co-op group can complete the stage; elite/boss outcomes and rewards agree across peers; death removes temporary bonuses while unlocks survive reload. Include single-target and area-damage builds in playtests. ### 4. Validate and Refine the Foundation — Pending - Use the implemented [debug test arena](superpowers/plans/2026-10-08-debug-test-arena.md) for repeatable manual scenarios and automated regressions alongside full-stage/multiplayer acceptance; preserve its development-only entry and cleanup. See [setup and recorded evidence](DEBUG_TEST_ARENA.md). - Tune movement, weapon feel, encounter pressure, ability trade-offs, and initial pacing from playtests. - Exercise latency, disconnects, joining/leaving, and progression boundaries. - Profile representative four-player horde combat; address measured bottlenecks. - Confirm HUD legibility across resolutions/aspect ratios and establish the reusable visual/asset workflow. **Completion evidence:** a playable PC prototype with recorded multiplayer checks, profiling observations, remaining defects, and known limitations. Set concrete performance budgets from the chosen target hardware rather than inventing them now. ### 5. Expand Toward a Four-Stage Run — Pending - Build three additional stages with distinct atmosphere, encounters, and bosses using the proven systems. - Expand weapons, abilities, enemies, and bonus synergies only where they add meaningful choices. - Evaluate level-generation options, additional platforms, and production art after foundation validation. **Completion evidence:** a complete replayable run with temporary-state reset, permanent unlock persistence, balanced encounter variety, and four-player validation. Revisit the 20-minute pacing target using playtest results. ## Art and Asset Pipeline The first enemy faction is the ivory/purple/amber Hollow Knights concept, with the upright **Ivory Wraith Cannon** selected for the ordinary ranged enemy and its elite variant. The crawling melee design and alternate crystal/biomechanical stage factions remain art directions for later work. The ranged Wraith uses imported idle/walk/run clips, arm-excluding head/body reactions, and host-cued procedural cannon aiming/recoil. Body/head damage volumes are authored separately from the mesh and skeleton. See [Ivory Wraith setup and validation](IVORY_WRAITH_SETUP.md); remote animation acceptance remains pending. Maintain low polygon counts, clear silhouettes, large readable shapes, stylised proportions, simple geometry/materials, flat colours or gradients, restrained texture detail, and a coherent palette. Distinguish stages through colour, lighting, silhouettes, and composition. Enemies, projectiles, hazards, pickups, and interactables must remain readable during crowded first-person combat. Avoid photorealistic PBR assets unless intentionally converted to the style. Search existing project assets and reputable libraries first when practical: Kenney, Unity Asset Store, Fab, Poly Haven, and suitable alternatives. Verify licences before recommending/importing. Record source, creator, licence, attribution requirements, and modifications. Do not purchase assets or begin paid generation without explicit authorisation. For generated 2D art, prefer ChatGPT Image Generation. For 3D, prefer Meshy, consider Tripo where appropriate, and clean up in Blender. Preserve editable sources and generation provenance where available. Before production use, inspect generated meshes for topology, polygon count, scale, pivot, normals, UVs, materials, hidden geometry, collision, LODs, rigging, and animation needs. Minimise geometry without damaging silhouettes; avoid unnecessary subdivisions and invisible detail. Prefer one material and shared palettes when practical. Use 1 Unity unit = 1 metre, apply Blender transforms before export, and choose FBX/GLB according to the supported import workflow. Use URP-compatible materials with simple colours, restrained roughness/specular variation, shared palettes, or vertex colours. Avoid oversized textures, unique 4K textures on small props, excessive material slots, and complex Shader Graphs without a clear benefit. ## UI and Performance Default to UI Toolkit unless another system has a specific benefit. Use clean shapes, simple icons, a limited palette, clear typography/hierarchy, and minimal noise. Never bake text into generated images. Support different resolutions/aspect ratios. Requested settings foundation: an expandable local menu for field of view and mouse sensitivity, accessible from menu and in-run UI, with persistence and correct ADS/camera-recreation behaviour. Settings must not globally pause co-op gameplay or leak gameplay input through open panels. See the combined plan for proposed ranges/defaults. The combat HUD should communicate health/defensive resources, weapons/ammunition, active ability availability/cooldowns, objectives/boss state, and relevant co-op information. Add elements only when they support decisions. Avoid unnecessary Update loops, allocations, runtime searches, material instances, high-poly meshes, excessive physics objects, unbounded spawning, and unnecessary network messages. Do not replicate safely derivable client data. Use bounded spawning and pooling where appropriate for enemies, projectiles, and effects. Optimise using measurements from representative four-player horde combat. ## Development and Validation Workflow Use [AGENTS.md](../AGENTS.md) for project invariants and the reading route; [AGENT_WORKFLOW.md](AGENT_WORKFLOW.md) for experiment briefs, risk-based reviews, prototype promotion, delegation and stopping; [TESTING.md](TESTING.md) and relevant [catalogue entries](TEST_CATALOGUE.md) for exact checks and evidence. Consult [SETUP.md](SETUP.md) for Editor/session/build operations. Read only documents relevant to the task boundary. Current review selection supersedes generic blanket defaults in older plans, while specific feature requirements and acceptance gates remain binding. The [local development-reference wiki](Wiki/index.md) describes systems and 91 catalogue entries using source-derived static snapshots. Its [tooling](../Tools/Wiki/README.md) and [validation record](Wiki/development/wiki-validation.md) are documentation evidence; Editor exporting and public hosting remain outside that implementation. Refresh/check snapshots after changing linked sources; documentation checks do not validate gameplay. Research current Unity/networking APIs, packages, asset licences and platform requirements using official/primary sources when relevant. Explain dependencies, cost and maintenance; pin versions and never upgrade silently. Preserve Unity assets/metas/GUIDs and use supported Editor operations. Separate automated, Editor, built-player, human and hardware evidence. ## Agent Roles and Model Policy The lead owns architecture, integration, coordination and final reporting, with game-design, art-direction and pipeline assistance as needed. The single current [model/delegation policy](AGENT_WORKFLOW.md#model-policy) supersedes earlier defaults; select models/reasoning explicitly and report unavailability before substitution. Lead uses Sol 6.1 / Ultra; substantial delegated test execution uses Sol 6.1 / Medium under exclusive Editor ownership, with check selection/evidence acceptance retained by the lead. Playable implementation slices start with the user's ASAP-versus-end human playtesting choice; supplied timing counts. Use the project-local [projecti-slice skill](../.agents/skills/projecti-slice/SKILL.md) for implementation. Read-only reviews, documentation, research and lookups use [task routing](AGENT_WORKFLOW.md#task-routing), without routine playable checkpoints. Existing risk-based post-review includes Ponytail correctness/completeness/simplicity; authorized implementation/documentation tasks receive scoped local commits after required reviews/checks unless explicitly deferred, with pending human acceptance explicit and no automatic push. See [slice closure](AGENT_WORKFLOW.md#slice-closure-and-local-commits). Beyond required independent reviews, delegate only when benefit justifies coordination, with narrow scope and explicit ownership. ## Open Decisions Final title; production hosting/service scale and budgets; eventual movement prediction/ authority refinement; later stage death/re-entry rules; enemy designs; target hardware/ performance budgets; save storage/schema; production assets; final level-generation approach; additional platforms. Foundation versions, stack, player hosting, pre-run joining, host loss, initial weapon/ability choices and prototype teammate revives are recorded decisions. Resolve remaining choices when needed, not as an extra prerequisite for unrelated work. ## Keeping This Plan Useful Across Chats Keep this brief current when requirements, decisions, roadmap or acceptance change. Link scoped plans/evidence instead of accumulating every run or status update here. Keep accepted requirements distinct from proposals and implementation distinct from proof. Record dates, source/build identity, checks, omissions and next action in the linked task record. Retain superseded decisions and failed attempts in history/evidence rather than silently rewriting rationale. Historical applicability depends on compatible source/assets/builds/settings. This file persists in the repository, not automatic memory in inaccessible chats. For another checkout, sync the documentation or provide it explicitly. [The frozen prior plan](PROJECT_HISTORY.md) retains all original headings, detailed statuses and dated decisions with their original links. ### Decision and Progress Log - **15 October 2026 — scoped local commit authorization:** completed authorized tasks may commit owned changes locally after required reviews/checks, without a separate confirmation. Preserve unrelated work, explicit leave-uncommitted requests and human commit/promotion gates. Automatic pushing remains prohibited; historical records remain unchanged. See the [policy update](LOCAL_COMMIT_POLICY_2026-10-15.md). - **15 October 2026 — contextual implementation references:** implementation packet, human timing, experiments and verification handoff now load from `projecti-slice` references; shared workflow anchors/policies remain accessible. Instruction evaluation and research moved off the routine reading path. See [preservation and checks](CONTEXT_SPLIT_2026-10-15.md). - **15 October 2026 — implementation skill and task routing:** `projecti-slice` coordinates authorized implementation using canonical policy. Mandatory human timing is limited to playable implementation; retrospective reviews stay read-only and documentation/lookup work avoids the implementation ceremony. Required risk-based reviews and explicit human approvals remain intact. See the [validation record](SLICE_SKILL_2026-10-15.md). - **14 October 2026 — slice closure and review timing:** user approved Sol 6.1 / Ultra leadership, Sol 6.1 / Medium test execution, Ponytail checks within existing post-review, scoped automatic local commits and a human-review timing question at every slice start. ASAP pauses dependent work at a safe reviewable checkpoint; end supports away/overnight work without treating silence as acceptance. See the [change record](WORKFLOW_UPDATE_2026-10-14.md) for checks and limits. The [prior decision/progress log](PROJECT_HISTORY.md#decision-and-progress-log) and [prior status chronology](PROJECT_HISTORY.md#current-state-and-next-step) remain available at their original heading names. This forwarding section preserves the existing brief anchor. - **11 October 2026 — agent workflow refinement:** the user approved risk-scaled reviews, isolated exploratory prototypes with full affected integration gates on promotion, and documentation checks/read-only walkthroughs only. A single compact task packet connects player intent, hypothesis, implementation and evidence. Detailed policy is contextual; the current brief is separated from the frozen prior plan. See [implementation decisions, verification and limits](AGENT_WORKFLOW_EVALUATION.md). This does not close any outstanding gameplay acceptance or grant new campaign attempts.