Design ideas and owner recollections¶
Historical proposals and decisions: check the roadmap and current source for the latest scope and implementation.
Recorded 2026-10-24. These are the owner's proposed directions, checked against existing docs and selected source paths. These remain proposals unless explicitly promoted. On 2026-10-25 the owner promoted IDEA-02's one-keyboard/device-assignment policy and Input System migration into the architecture-first gameplay rebuild. On 2026-10-26 the owner clarified P1 keyboard-or-pad/P2–P4 pad-only assignment, added button remapping and promoted IDEA-03's four-player capacity into planning; the owner subsequently added shared gameplay-scene composition (IDEA-20) and event-bus design (IDEA-21) to active architecture planning. Other feature proposals remain deferred. No gameplay code was changed or behavior runtime-tested during this recollection pass.
The owner's broader concern about intertwined player setup, controls, saves, audio, spawning, stage creation, and large scripts is already supported by older analyses. It is now tracked as ARCH-01 in the issue register, with a current ownership map. The code is not treated as fixed merely because some classes were previously extracted.
Coverage at a glance¶
| ID | Owner's direction | Existing coverage / implementation |
|---|---|---|
| IDEA-01 | Compact reward cards and a separate description panel for each player | Exact layout newly recorded here. Current cards still contain descriptions; general reward/UI separation was discussed previously. |
| IDEA-02 | Remove split keyboard; one keyboard counts as one input device, with mapping in settings | Confirmed and promoted into active rebuild planning on 2026-10-25; not implemented. Current code retains player-specific keyboard profiles and reads keyboard/gamepad input by player slot. The archived rewrite even proposed keeping two keyboard profiles, so it does not establish this new policy. |
| IDEA-03 | Expand local play from two to four players after player/control setup is improved | Promoted into active rebuild planning on 2026-10-26; not implemented. Already a future ambition in the archived rewrite. Current Unity character selection and reward confirmation still contain explicit two-player assumptions. |
| IDEA-04 | Special presentation when a reward reaches Epic | Existing rarity colors/icons, card animation, and reward particles cover part of the surrounding presentation. The exact requested rarity-triggered effect was not found in the inspected reward path. |
| IDEA-05 | Additional VFX for some skills | Existing skill VFX and feedback are documented. The new additions and their target skills are not yet specified. |
| IDEA-06 | Introduce game modes | No dedicated new-mode design or mode-selection implementation found in the inspected docs/scripts. Difficulty and battle states already exist but do not establish the proposed mode system. |
| IDEA-07 | Introduce runes | A source reminder mentions runes and character shop. No rune design, save model, or dedicated implementation was found in this pass. |
| IDEA-08 | Replace the general shop with character-specific upgrades/progression | Already conceptual in archived planning and the same source reminder. Current code still uses a general shop and shared run modifiers. |
| IDEA-09 | Redesign the menu | Existing menu architecture/refactor notes describe implementation, not this new design brief. |
| IDEA-10 | Publish a better demo on itch.io and Steam | Old demo Git refs and DemoButton exist; a current verified demo build/content contract was not found. A recommended content boundary is recorded below. |
| IDEA-11 | Privacy policy and terms linked to the Tiny Chaos section of the studio website | Newly recorded publishing requirement. Final URLs, policy contents, and service data practices have not been established. |
| IDEA-12 | Improve leaderboard backend eligibility and submitted values | Existing client posts run data. No Steam-ticket authentication was found in that path; server implementation/enforcement is not in the inspected repository. |
| IDEA-13 | Redesign the leaderboard | Existing UI/view/controller and filters are documented. The proposed redesign is not yet specified. |
| IDEA-14 | Repair the tutorial into a proper introduction | Existing separate tutorial scene/scripts are documented; teaching goals and reported failures still need to be reconstructed. |
| IDEA-15 | Stage stories or short comic strips | Tentative. Stage dialogue data/runtime exists; the stage-comic proposal is newly recorded. |
| IDEA-16 | Enemy and character database | Collection data/UI scaffolding and character preview exist. Enemy preview is an empty method; a complete database experience is not established. |
| IDEA-17 | Better stage entrance, death/defeat/clear, boss/miniboss entrance, and revive presentation | Several underlying flows already exist, including revive. The desired presentation improvements need a shared sequence specification. |
| IDEA-18 | Keep each stage's upgrade pool manageable | Existing stage flags and eligibility/weight rules cover part of this. Basic-stage filtering and stage-index data need verification. Player-selected upgrade loadouts are explicitly deferred. |
| IDEA-19 | Redesign in-game UI/UX | Existing HUD/menu/reward structures are documented. This is a broader proposal linked to IDEA-01/04/17, not a duplicate reward-card task. |
| IDEA-20 | One shared gameplay scene, configured by stage ScriptableObjects | Added to active architecture planning on 2026-10-26. LevelData already holds part of the configuration; current arenas still duplicate scene owners. Prefer a shared runtime scene with environment/behavior composition; no scene conversion implemented. |
| IDEA-21 | Introduce an event bus | Added to active architecture planning on 2026-10-26. A small static GameEvents hub and instance state events already exist. Plan typed notifications with explicit application/run lifetimes and compatibility adapters; no new bus implemented. |
IDEA-01: Reward cards and player-specific descriptions¶
Owner intent: make reward cards simpler: icon, name, and limited details. Move the full description out of the cards into two separate frames, one per player. Each player's frame changes as that player moves to another reward. This means two frames total for the current two-player layout, not two per player.
Current evidence: RewardRoller.SetTheRewardCard populates an icon, description, name, rarity text/icon, and colors on every instantiated card. Weapon-evolution descriptions are assembled using the current players' character/weapon data inside the card. UpgradeSelection already tracks separate player selections and markers. No connection from those selections to the proposed independent description panels was found in these paths. RewardUIController is still a placeholder.
Previous coverage: the UI analysis describes current cards and recommends separating reward logic from presentation. It does not specify this layout.
Still to define: which short details remain on cards; each panel's content and inactive-player behavior; the exact update point during navigation/lock-in; and player-specific weapon-evolution text. IDEA-03 would require revisiting the number/layout of panels. GAME-02 remains a separate reward-flow risk; moving descriptions does not establish that its pause conditions are corrected.
IDEA-02: One keyboard and explicit input-device assignment¶
Owner intent: retire split-keyboard multiplayer. Count the keyboard as a single input device/player, with its mapping configured in settings. Additional local players need their own gamepads; the keyboard is not split into two virtual players. The owner explicitly confirmed this policy on 2026-10-25 and promoted its design/Input System migration into the active gameplay rebuild; it is not implemented yet. On 2026-10-26 the owner clarified that only P1 may use keyboard, P1 may alternatively use a pad, P2–P4 require pads, assignment is explicit rather than connection-order-driven, and button remapping is required.
Current evidence: InputManager exposes keyboard and joystick reads indexed by player. GameSettings loads separate P1_Keyboard and P2_Keyboard presets. Player.InputManagement reads joystick axes and falls back to keyboard axes for that same player slot. Settings already contain mapping/preset controls, but that is not a single-device assignment model.
Previous coverage: the archived player-slot proposal explicitly included keyboard_p1 and keyboard_p2. That historical suggestion conflicts with this recollection and should not be carried forward as the current desired policy.
Still to define: joining/assignment flow, device ownership, disconnect/reconnect behavior, menu input versus gameplay input, the concrete assignment/remapping UI and profile schema, and compatibility with saved P1/P2 keyboard settings. The confirmed policy permits one keyboard player plus gamepads, or gamepads alone. Design exact join/reconnect/UI ownership and saved-preset migration in the active rebuild plan; four-player capacity under IDEA-03 is now included in planning, with implementation after its shared-system prerequisites.
IDEA-03: Four-player local play¶
Owner intent: after improving player setup and controller settings, consider increasing local player capacity from two to four. On 2026-10-26 the owner explicitly promoted support for P1–P4 into the planned input/player rebuild, after its shared-system prerequisites. This authorizes design and later implementation, not a claim that the current player count has changed.
Reward policy confirmed during batch 32: keep one shared row, require distinct picks by living players, and offer at least one extra card beyond the number of living participants. Preserve a larger existing offer count: max(existing count, living count + 1). This plans three/four-player choices without changing adequate one/two-player counts. It does not decide scarce-pool fallback, mastery/payout distribution or disconnected-player recovery. See the reward contract.
Previous coverage: Godot architecture and system analysis wanted an architecture ready for 1–4 local players while postponing full four-player UI. Those were cancelled rewrite plans, not evidence of four-player Unity support.
Current evidence: CharacterSelectionUIController toggles one/two-player modes and has fixed two-player loops. UpgradeSelection allocates two tween slots and confirms players 0/1 explicitly. GameInitialization enables existing scene player objects and their status panels. AudioService already allocates four footstep sources; that isolated capacity does not make the game four-player-ready.
Dependencies to investigate: IDEA-02, scene player creation/activation, character selection, active-player tracking, camera/HUD, reward navigation/confirmation and IDEA-01, shared versus per-player modifiers, and gameplay behavior with additional targets/collectors. Better controller assignment alone does not complete this feature. Layout, gameplay rules, and validation scope are still undecided.
IDEA-04: Epic reward presentation¶
Owner intent: add special feedback when a reward reaches Epic. The exact threshold/event is still unspecified; Epic-and-above is a possible reading, not a settled rule.
Current evidence: RewardRoller applies rarity colors/icons and generic card/reward/chest presentation. Its Epic/Legendary/Mythic checks also modify roll weights for luck; those checks are not VFX triggers. The audio/feedback analysis documents existing presentation, but no exact specification for this request was found.
Still to define: qualifying rarities, whether the effect plays on reveal/focus/selection, what visual/audio response is wanted, and which existing assets can be reused. Prefab/animation behavior has not been fully audited; absence of a trigger in this inspected code is not proof that every related visual is absent.
IDEA-05: Skill VFX additions¶
Owner intent: add VFX to some skills. The skills and missing feedback moments have not yet been named.
Current evidence: AbilityHolder (historical script), AbilityResources, and skill prefabs already contain effect behavior/references. The feedback analysis describes existing effects. Their existence does not establish that the desired additions are already implemented.
Still to define: affected skills, what is hard to read or missing, the event/timing to communicate, and available art/effect assets. Check existing behavior first. Repairing a broken existing effect and introducing a new effect should be recorded distinctly so stabilization scope stays clear.
IDEA-06: Game modes¶
Owner intent: introduce game modes. No specific modes or rules have been chosen in this conversation.
Current evidence: GameSession carries characters, player count, stage, difficulty, and modifiers; LevelData carries stage/difficulty-map data. No dedicated mode model or selection flow was found in the inspected project scripts. Existing difficulty options and spawn/boss battle states are not evidence that this proposal is implemented.
Still to define: what changes between modes, entry/exit and win/loss rules, and implications for stage data, progression, saves, leaderboards, and co-op. Do not invent mode names or rule sets during documentation recovery.
IDEA-07: Runes¶
Owner intent: introduce a rune system.
Existing trace: GameSession contains the reminder Later need to change system if from rune and char shop above SetModifiers. This confirms an older intention, not an implementation. No dedicated rune data, selection/equipment flow, or save fields were found in the inspected scripts; PlayerData still contains the existing progression/shop dictionaries.
Still to define: what runes do, how they are obtained and used, whether ownership/loadouts are per character or shared, and their interaction with IDEA-08 and run modifiers. Slots, stats, costs, unlocks, and currencies remain unspecified.
IDEA-08: Character-specific progression replacing the general shop¶
Owner intent: replace general shop upgrades with upgrades/progression driven by each character. This is related to runes, but the relationship has not yet been designed.
Previous coverage: the archived shop analysis and architecture plan already propose character-specific progression and postponing the old shop. They also propose refunding old shop purchases into soul points. That refund policy belonged to the cancelled migration and is not automatically a current Unity decision. The GameSession rune/character-shop reminder is another trace of this direction.
Current evidence: ShopManager stores global shop levels by upgrade type and builds a shared CharacterModifiers object. GameSession stores one modifiers object. No per-character replacement was found in these paths.
Still to define: character ownership/upgrade structure, costs, shared versus character-bound progression, its relationship to runes, and treatment of existing purchases/saves. Preserve the old system's data until a compatibility policy is chosen; documenting its replacement does not authorize deleting it.
IDEA-09: Menu redesign¶
Owner intent: redesign the menu. No replacement layout, style, or navigation map has been chosen yet.
Current coverage: MenuController, MenuView, Page, and existing views/controllers implement the present flow. The maintenance reference and archived menu/UI refactor notes describe that implementation; they do not establish that a new menu design exists.
Still to define: current friction, screen inventory, navigation and controller focus, entry points to settings/tutorial/collection/leaderboard, legal links (IDEA-11), and full/demo differences (IDEA-10). Record desired behavior before visual design. Coordinate with IDEA-13/16/19 rather than creating competing menu proposals.
IDEA-10: A demo for itch.io and Steam¶
Owner intent: distribute a demo on both platforms and choose a useful difference between demo and paid game.
Existing traces: Git contains older Demo-Steam and demo-build refs, and DemoButton temporarily displays NOT AVAILABLE IN DEMO. That is not proof of a current demo build, correct feature gating, store configuration, or save isolation. No existing release/store account was inspected and no demo was published.
Recommended draft, not an owner decision: use one complete, replayable run on the existing first-stage content with Soldier and Knight, the core combat/reward loop, and a real stage-clear endpoint. Reuse an existing boss-containing difficulty schedule after validating its accessibility/balance; do not cut the player off halfway through a run or build a separate mini-game. The intended Stage_1.asset Medium map has a 720-second configured duration, so roughly 10–15 minutes is a design target, not a measured play time. Easy has a different schedule; verify the boss route and the stage-index inconsistencies before adopting a build.
| Demo recommendation | Full-game distinction |
|---|---|
| One stage, two characters, one selected existing difficulty; replay allowed | Other currently released stages, characters, and difficulties. Verify the actual shipped catalog before advertising counts. |
| Core upgrades needed for viable builds, plus the same readable controls/settings and short tutorial introduction | Wider released content and progression; do not advertise proposed runes/modes/character upgrades as existing paid features. |
| Keep currently supported local co-op if it passes acceptance checks | Do not make the proposed four-player system a demo dependency. |
| Local results; no uploads into the full-game ranked leaderboard | Full-game leaderboard eligibility follows IDEA-12. No new demo-only online service is proposed. |
| A clear end screen linking to the paid game and explaining the actual extra content | Sell the released game's breadth, not a deliberately awkward demo. |
This is a product recommendation based on the supplied $4.99 price, small released content set, solo maintenance budget, and existing run structure. It is not a platform requirement or a prediction of conversion. Use the same content contract for both platforms, allowing platform-specific identity/store-link handling. The itch.io demo must run without Steam; SAVE-01 currently makes that a verification/fix dependency. Legitimate non-Steam demo users should not be treated as unauthorized owners of the full game.
Publishing facts checked 2026-10-24: Steam demos use a separate associated App ID and build/release configuration; itch.io supports free demo downloads. See Steam demos and itch.io creator guidance. Existing demo App IDs/releases, if any, must be checked before creating duplicates. No store page setup is approved by this documentation entry.
Still to decide: accept or revise this content boundary; identify the actual first-stage/catalog route and demo build profile; choose save isolation versus compatible import; confirm Steam/demo/full-game App IDs, supported platforms, progression, and store links. Do not fork a second long-lived gameplay codebase for the demo. Shared-source build configuration is a proposed implementation direction, not an existing verified setup.
IDEA-11: Website-hosted privacy policy and terms¶
Owner intent: provide privacy policy and terms pages on the Tiny Chaos area of the studio website, with links from the game. The website is being prepared separately; no URL was supplied or invented here.
Current evidence: no specific privacy/terms implementation or maintained policy document was found in the inspected first-party game docs/scripts. The current leaderboard payload includes a public name, run statistics, character/build-related strings, stage, difficulty, and version. Hosting logs, retention, deletion handling, processors, and website analytics were not inspected. Do not describe the game as collecting no data without checking those systems.
Documentation needed before drafting: operator/contact identity, actual game/backend/website data flows, what is public, storage/providers/retention, support/deletion process, and intended scope of the terms. Policy contents and any acceptance requirement are undecided. A website link is not itself a completed policy or verified legal coverage. This entry records the requirement; it does not draft legal terms, select jurisdiction, assert compliance, or publish pages.
Connections: IDEA-10/12/13 determine demo and score-data behavior; IDEA-09/19 determine link placement. Keep final legal text on the chosen website as the maintained source and record its URL/version here once available, rather than copying conflicting versions into multiple game docs.
IDEA-12: Leaderboard backend eligibility and payload improvement¶
Owner intent: prevent players without the intended Steam entitlement from uploading scores, improve existing submitted values, and add useful values. Exact field changes and eligibility rules are not yet specified.
Current evidence: LeaderboardManager.PostData posts JSON to the configured leaderboard endpoint with a content-type header. No authentication ticket or server-issued session appears in the inspected submission path. LeaderboardData carries statsp1, statsp2, name, difficulty, score, level, kills, version, and stage; CharacterStats contains character/upgrade/stat strings. GameManager.PushLeaderBoardData assembles these values, including string-encoded player data. No backend source was found in the inspected repository, so server admission, validation, logging, and stored schema remain unknown. NET-01 in the issue register tracks that evidence gap; this is not proof that arbitrary uploads succeed.
Recommended boundary to evaluate: verify Steam identity/ticket and intended full-game entitlement on the backend before accepting a ranked submission. A client-side Steam-running check or submitted nickname is not a server identity guarantee. Steam documents backend session-ticket verification and ownership checks in User Authentication and Ownership. Keep server credentials on the server. Authentication establishes eligibility/identity, not that client-reported gameplay scores are legitimate; value validation and abuse handling are separate decisions.
Payload review, not approved new fields: identify stable character/stage/upgrade IDs, units/ranges, player count, build/rules version, and the meaning of existing score/level/kill/stat strings. Candidate additions such as a submission/run ID or run duration need a clear use before adoption. Decide schema versioning, old-record compatibility, duplicate submission behavior, and which fields are public. IDEA-03 and IDEA-06 could affect player/mode representation later; do not preemptively implement them.
Demo conflict to resolve: a Steam demo entitlement is not automatically full-game ownership, and an itch.io demo player may legitimately have no Steam identity. Proposed default from IDEA-10: no demo uploads to the full-game ranking. The owner has not yet approved a separate demo board or alternate non-Steam identity service.
IDEA-13: Leaderboard redesign¶
Owner intent: redesign the leaderboard's presentation and use.
Existing coverage: LeaderboardUIController, LeaderboardView, LeaderboardButton, and the network manager already implement rows/details, loading state, current-rank presentation, and stage/difficulty/character/version filters. The archived refactor summary documents earlier separation of UI responsibilities. That completed refactor is not the owner's newly requested redesign.
Still to define: browsing/comparison goals, meaningful ranking categories, displayed values, player/build detail, controller navigation, identity versus display name, and offline/empty/error states. Align values and eligibility with IDEA-12; redesigning the view does not fix server trust or unclear score semantics.
IDEA-14: A proper tutorial¶
Owner intent: fix the tutorial so it teaches the game properly. Specific broken steps or missing lessons have not yet been recalled/reproduced.
Current evidence: Tutorial.unity and TutorialManager, with separate tutorial player/enemy/spawner/camera scripts, already exist. The archived project overview identifies this separate implementation. Its existence does not demonstrate that the current input, rewards, or progression are taught correctly.
Still to reconstruct: the actual tutorial sequence, each lesson's completion condition, observed failure points, supported input devices, skip/retry/return behavior, and what a player should understand afterward. Check overlap/drift with the main gameplay implementation before choosing repair or replacement. IDEA-02/10/19 affect instructions and UI; the demo needs a compact useful introduction, not a second incompatible tutorial system. Treat specific reproduced failures as issues, while changes to lesson design remain here.
IDEA-15: Stage story or short comics¶
Owner intent: possibly add a story beat or short comic strip when entering/unlocking each new stage. This remains tentative, not a commitment to produce a comic for every stage.
Current evidence: LevelData.StageMap has a dialog reference; DialogTrigger stores actors/messages; DialogManager contains dialogue display logic. The inspected Stage_1 asset's difficulty-map dialogue references are empty. These are partial dialogue foundations, not a verified comic presentation pipeline or completed stage narrative.
Still to decide: whether to do this at all; narrative purpose, stage unlock versus first entry versus every run, art/text format, skip/replay behavior, localization, and available production effort. A comic and an existing dialogue box are different delivery formats. No plot, art scope, or new runtime system is invented in this entry.
IDEA-16: Enemy and character database¶
Owner intent: provide an enemy/character database. The intended player-facing information and discovery rules are not yet defined.
Current evidence: CollectionManager already stores character/enemy catalogs. CollectionUIController routes character/enemy/upgrade selections to CollectionView. The view implements character portrait/name/description/stat preview, but UpdateEnemyPreview is empty. This is partial groundwork, not a verified complete database. CONTENT-08 in the issue register records the placeholder; list population, menu reachability, and scene wiring were not runtime-tested.
Still to define: whether this extends the collection screen, which facts help players, when entries unlock, spoiler handling, localization, sorting/search, and trustworthy data ownership. Prefer documenting the existing collection's gaps before designing another parallel database screen. If "database" instead means an internal authoring tool, that would be a distinct requirement to clarify.
IDEA-17: Stage, character, and encounter presentation¶
Owner intent: improve first appearance in a stage, character death and defeat/clear presentation, boss/miniboss entrances, and character revive. These are grouped as a related presentation pass, not assumed to be minor fixes in every case.
| Moment | Existing source versus desired improvement |
|---|---|
| First character appearance | GameInitialization.PreparePlayer activates/applies scene players; GameManager handles gate/HUD/run opening. The desired entrance animation and input/invulnerability timing remain undefined. |
| Character death | Player.Death marks death and disables the GameObject immediately. No death-animation wait exists in that method. Define the visible sequence and its relationship to surviving co-op players. |
| Defeated / Stage Clear | GameEndManager already has localized clear/game-over titles; GameManager.GameOver owns result flow and tweens. The requested stage/result animation choreography is not specified. |
| Boss/miniboss entrance | SpawnerEventManager.SpawnBoss already stops timers/camera follow, spawns effects/boss, and animates boss UI; BossSpawn provides timed visual/sound/event behavior. Miniboss flow is separate and must be inspected rather than assumed to share that sequence. |
| Revive | UpgradeFunction.REVIVE already reactivates inactive players, restores half health/stamina, camera participation, and some ability/weapon state. This is implemented logic, not a newly absent feature; its correctness and desired animation still need testing/specification. |
Still to define: sequence timing, what gameplay/timers/input continue during each moment, animation/effect assets, camera behavior, and interrupted/co-op cases. Coordinate with GAME-01/02/06 rather than adding new waits over unresolved freeze/pause/spawn behavior. Related skill/reward effects remain in IDEA-04/05; broader HUD redesign is IDEA-19.
IDEA-18: Upgrade-pool control by stage¶
Owner problem: as upgrade content grows, each stage's reward pool may become too diluted to support satisfying choices/builds.
Existing approach: Upgrade already stores appearsInStages, weights/rarity, limits, prerequisites, and unlock fields. GameInitialization.ImportRewardTable checks a stage flag for special upgrades. The basic-upgrade path only checks that the flags array is nonempty/long enough; it never reads the selected flag. RewardRoller adds eligibility checks, weighted selection, luck adjustments, and duplicate handling. These are existing controls, not proof that the resulting pools are curated or applied consistently. GAME-14/15 in the issue register cover the stage-filter/index findings.
Recommended near-term design direction, not implementation approval: first document and validate designer-curated stage pools using the existing stage eligibility mechanism, including basic versus special/boss tables, build-enabling upgrades/prerequisites, and actual draw probabilities. Measure reachable pool sizes and the chance of finding useful follow-ups before adding another progression system. Do not replace dilution with an arbitrary card count or promise a balance fix from a smaller pool alone.
Explicitly deferred: the owner's older idea with friends, where players choose an upgrade loadout to bring before a run. Preserve that history here, but do not include loadout screens/equipment/save rules in current work. Runes and character upgrades do not implicitly reactivate it.
Still to decide: stage themes/eligible content, prerequisite access, character/co-op effects, acceptable variety, and how changes affect existing runs/records. No pool composition or drop-rate rebalance has been chosen.
IDEA-19: In-game UI/UX redesign¶
Owner intent: improve the in-game interface and interaction experience as a whole.
Current coverage: the architecture reference and archived UI-flow analysis locate HUD, status panels, rewards, pause/settings, damage feedback, and game-over responsibilities. They describe the existing interface, not an approved replacement design.
Scope still to define: which information is hard to read/missing, hierarchy and layout, interaction states, controller focus, co-op attribution, feedback, localization/text fit, and supported display sizes. Separate reported broken behavior from a preferred new design. IDEA-01 owns the reward-card/description solution; IDEA-04 owns rarity feedback; IDEA-17 owns entrance/death/result/revive sequences; IDEA-03 is a possible future player-count change. Keep those linked so one HUD redesign does not create duplicate feature lists or silently require four-player support.
IDEA-20: One shared gameplay scene with stage definitions¶
Owner intent: replace a separate gameplay scene for every stage with a shared gameplay scene, describing the common pattern through ScriptableObjects. Distinct stages should reuse that runtime where possible; genuinely different composition can remain supported. Added to active planning on 2026-10-26, with no scene/code/asset migration yet.
Current evidence: LevelData already stores sceneName, progression ordinal, boss, music and per-difficulty duration/spawn/dialog references. GameSession carries the selection. MainMenuManager and GameMenuManager load LevelData.sceneName for normal start/retry; Experimental has a separate menu branch. The scene wiring map shows GameManager, GameInitialization, SpawnerEventManager, PoolManager, Timer, camera and menu owners repeated across the three arenas. It also shows that their migration state differs: the audited Stage 1 has a direct MenuController absent from the Stage 2/3 map. This supports extracting shared composition, not treating the scenes as byte-identical.
Planned direction: one gameplay runtime scene owns composition, camera/HUD bindings, actor anchors and run lifetime. A stage definition references environment prefabs/tile or map-generation configuration, encounter schedules, boss/music, boundaries and spawn-marker conventions, difficulty/clear rules and existing reward/progression identity. Live transforms/components are resolved from the instantiated environment, not stored as scene-object references in a project asset. Use small explicit stage-behavior components when needed, rather than a large stage-number switch. A layout that genuinely requires separate authored content may be composed alongside the same gameplay runtime; do not force all content into one enormous asset/scene or duplicate gameplay managers as an exception.
Stage definition is authoring data. Elapsed time, active wave/boss instances, spawn cursors/flags, generated tiles, current participants and unlock/taken state belong to their runtime/profile owners. SpawnerData currently mixes schedule values with isSpawning/isActive, while StageMap stores isUnlocked; those boundaries must migrate without changing schedules or saves. Preserve existing asset GUIDs, stage ordinals, names, difficulty IDs, save keys, eligibility, maps, timing, random behavior and visuals through adapters where necessary. Do not simply point every current sceneName at one arena and lose its authored differences.
Order and outstanding design: specify definition/runtime/binding contracts and actual per-scene differences in R0; build the smallest shared scene with an isolated development stage request in R1; implement environment/encounter composition in R5b after enemy/combat owners; migrate all released stage content in R8. The dummy arena uses that same runtime with development-only data and entry adapters. Audit nested prefab overrides, tilemaps/generation, camera/bounds/lighting/audio, loading/retry/reset, build references and content inclusion before deleting old scenes. Unique-stage exceptions must name a concrete unmet contract, not exist merely because the old scene was separate.
IDEA-21: Events with explicit ownership and lifetime¶
Owner intent: revisit the event bus originally wanted early in development. Added to active architecture planning on 2026-10-26. It is architecture work, not a new public feature or a request to install a messaging framework.
Current evidence: GameEvents exposes static EnemyDeath, AchievementTrigger, AddDataCount, AddTarget and RemoveTarget events. Player subscribes/unsubscribes target notifications in OnEnable/OnDisable; SpawnerEventManager and GameDataCount similarly consume deaths/counters. AchievementManager subscribes during application initialization. GameStateService also exposes instance OnStateChanged. Events therefore exist already; ownership, payload identity, subscription lifetime and command/notification boundaries need review. No duplicate-listener failure is claimed from these subscriptions alone.
Planned direction: keep one authoritative owner for each command/query, such as applying damage, accepting an upgrade or consuming player input. Publish typed facts at explicit, tested points for interested consumers, such as enemy death, damage resolution, accepted reward and run end. A notification cannot make multiple listeners independently own the same mutation. Separate application-lifetime notifications/adapters from run-lifetime subscriptions. Include run generation, relevant actor/slot/instance identity and required immutable values; reject stale callbacks and pooled-instance reuse. Own subscriptions explicitly and dispose them on teardown; a newly enabled observer queries authoritative current state before relying on later notifications.
Begin with the small event boundary actually required by R1 lifetime/target registration and add event types with the owning systems. Ordinary typed C# events/interfaces are sufficient as the initial design direction; no universal service locator, string-based global command router, async queue or plugin is assumed. Preserve current synchronous order, random calls, achievement/stat keys and publication timing through a temporary GameEvents adapter until all real consumers migrate. Define re-entry, listener-error handling, duplicates and disposal evidence before converting a path. Avoid keeping both the old hub and new boundary delivering the same fact to one consumer.
Outstanding design: source/persistent-subscriber map, application/run ownership table, required event payloads and publication order, late-subscriber/reset policy and adapter removal checks. R0 writes these; R1 implements the minimum lifetime contract; movement/combat/encounter/reward/UI stages add their own notifications and observations. Dummy-arena tests cover repeated retries/unload, missing listeners, late observers and a dead previous run. The bus supports the dependency hierarchy; it does not replace it.