Roadmap: playable game with the new ability system¶

Updated 2026-11-02. This is the plan for the shared scene, stages, player abilities and input. Older plans are historical where they conflict. See the handoff for technical context and the arena comparison for stage differences.

Goal and scope¶

Restore a playable loop in the common scene, then complete the migration and prepare the next version. Keep the existing enemies, rewards, spawner, stage rules and menus; repair their connections and blockers. Use a short, isolated development test stage for fast checks. Defer unrelated redesigns.

Work in connected batches. Use the Unity Editor CLI for focused checks at milestone boundaries; repeat a passing check only when relevant code changes. Record design alternatives for discussion and continue routine work. The owner can test a milestone as soon as it is ready.

For an approved system replacement, first inventory and preserve its authored data, IDs, bindings and required behavior; then remove the legacy implementation and build the new path without a legacy fallback. Record anything not yet moved and finish it in connected batches. Intermediate breakage is acceptable; run checks after a coherent implementation is connected, not as a condition for keeping old code. Apply this to the planned input replacement as well. Do not delete existing enemy, stage, reward or menu systems that are only receiving wiring fixes, or remove old scene content before preserving it.

Current position¶

The shared Gameplay scene now holds the Stage 1 production bindings and starts selected stage data; the original development foundation is retained separately. An offline Linux player run reached Stage 1 through the real menu, exercised combat and rewards, and returned after death; a subsequent Play Again and pause-menu return also worked. The user played part of that run. The game used an isolated profile and offline services; stage completion, Windows/Steam, and normal online integration remain unverified. Controlled Play Mode checks also covered a reward ability, two-player death/revive and sequential Stage 2/3 scene starts.
The 121 inventoried Ability assets have code-owned data, with player-owned state and hook registration. Character, starting, upgrade and evolution references use internal keys. Old Ability assets were archived and removed; Upgrade assets remain. PlayerAbilityBindings holds prefab and effect references. Full behavior has not been traced for every ability.
Unity CLI import and focused Edit Mode checks passed for representative keys, operations, one evolution event, two-player ownership and simulated drone reuse. A controlled Play Mode check passed production setup of two Soldiers with starting Dash/Frenzy, weapon, movement, dash and pause/cooldown behavior. It did not cover the real menu-to-scene transition, physical input, enemy combat, rewards or a full run.
Production movement, Dash, reward selection, pause, Stats and gameplay UI use initial new Input System connections. Main-menu and Tutorial input, remapping/persistence, physical devices, disconnect/reconnect and the held device-switch edge case remain open. The gameplay UI replaces its legacy input module at runtime.
Six broken evolution-target references discovered in the player log now point to their existing matching upgrades. All six links and one controlled Concussive-to-Deadly Impact evolution passed Unity checks; natural evolution and the other five behaviors remain to be tested. Unity confirms Stage 3's authored character-unlock reference is unresolved; Medium completion cannot award that character until its identity is recovered. The serialized GUID is retained. Latest findings and limitations are in playable-path batch 1 and CLI report. The active implementation may include uncommitted changes; inspect the live working tree.
Code review: player progress uses encrypted JSON in player_v2.json.enc; settings are separate in config.json. The new path is Documents/TinyChaos/Main or Beta/{Steam ID or offline} on Windows, and Unity's persistent data directory/TinyChaos/Main or Beta/{Steam ID or offline} elsewhere. The game loads the new player save first, otherwise attempts to migrate player.dat; old files are not deleted by that migration.
Legacy detection and reading now use the same locations. A focused Linux Editor check with temporary files passed fresh-save creation, migration of example progress, encrypted reload, new-save priority, and rejection of an unreadable legacy file without creating a replacement. Both Windows paths were checked with temporary files through the shared path-selection logic, but actual Windows migration and real historical player files remain unverified. The old save remains in place.
PoolManager reuses objects after their return to the pool, including enemies, projectiles and effects. It creates them when needed; no general pre-pooling step was found in the scripts. Performance and reset behavior need measurements and checks before changing the design.
A short Editor-only test run clones the stage appearance and a test enemy in memory, with a 120-second test configuration and an isolated temporary save. It checked combat, a reward, Concussive Impact stun and evolution, freeze expiry, poison/burn damage, a boss spawn and forced defeat, the clear screen, retry and forced player death. It forced the critical hit, evolution counter, boss timing/defeat, end timer and player death. It is an automated test, not yet a separately playable test-stage menu. The runner can select a character and borrow one of three stage appearances; a targeted Archer run with the second appearance passed its configuration checks. All seven character assets passed checks for spawning with their assigned weapon and starting ability, receiving movement, and using and completing a stamina-consuming dash. Each character also passed one starting-effect check: Soldier's Frenzy, Knight's barrier, Star Wanderer's rockets at a harmless test enemy, Priestess's two owned orbs and Celestial's owned sword; Archer's burst preparation used scripted fire events and Miner's special attack used a forced counter. Further individual ability behavior remains open.
Gameplay starts with the gate closed and waits for a fresh press before its timer starts. The short Editor run checked a simulated keyboard on start and simulated gamepad on retry. The result path now continues with local saving if the leaderboard is unavailable; Easy clear uses the configured end time instead of a hard-coded five-minute value. Physical controls, visual presentation and a normal player build remain to be checked.
Fixed skipped simultaneous poison/burn effects, stale burning state after object reuse, and errors when an effect's source has been removed. Five focused checks passed after four failures were reproduced; the wider status-only check passed its unchanged cases and corrected-case checks. Other crowd-control behavior and gameplay feel remain open. An older combined dash/status check reports a dash snapshot mismatch: its fixture reads the old ability object while current dash execution updates separate player-owned state, and it supplies older fixture abilities. It needs migration; its failure alone does not establish a live dash defect.

Next work and testing plan¶

The owner does not want agent testing of real stages. Use the shared gameplay systems in a short test stage; copy stage appearance into the test setup when useful. Do not run or change real stages for this testing. A short test cannot establish real-stage balance or gameplay feel.

Test stage and test enemy. Keep the short Editor-only setup available for focused checks and test-stage return coverage. The owner prefers to test further abilities manually for now. Distinguish natural behavior from forced shortcuts. Keep normal player data and production stage settings safe. An interactive test-stage menu has not been built.
Transition. Check the closed-gate and press-to-play behavior visually in a player build, including first frame, retry and return. The simulated keyboard/gamepad and stopped timer passed the Editor check; the owner still needs to check a physical gamepad.
Save safety. Expand disposable-example checks to actual Windows migration and representative historical files when available, including both old Windows locations and merge cases. Check settings and keybinding persistence separately. Never use or overwrite a real profile for test runs.
Character and ability coverage. The owner prefers to test further abilities manually for now. Record their results and the conditions they provide; leave untested combinations open. Earlier automated checks covered each character's basic setup and one starting effect, not every ability behavior. See the ability checklist for results and remaining coverage.
Controls and crowd control. Complete keyboard and gamepad remapping, persistence, conflict/cancel/reset and device re-detection. Check crowd-control effects against test enemies, fix reproducible failures and record effects that need design decisions.
AI authoring instructions. As the systems become stable, document how to create and verify enemies, characters, abilities, upgrades and stages, using the existing project documentation and real examples. Keep IDs and authored data safe.

Owner's physical-device checklist: test a real gamepad; remap and use keyboard and gamepad bindings; reconnect/re-detect the gamepad and verify it is assigned correctly. Simulated input does not replace this check. The owner can also judge balance, gameplay feel and visual quality.

Later improvements to discuss¶

Make ability definitions easier to read, hide internal IDs from normal editing, and add safe defaults. The saved task preserves existing IDs and upgrade codes.
Measure pool usage and reuse/reset behavior; consider targeted pre-pooling or optimization only where it helps.
Review enemy code and spawning efficiency using evidence, while preserving behavior the owner likes. Discuss a replacement spawning system only after identifying a concrete need.
Consider whether an enemy/character creation tool would save enough time to justify making and maintaining it.
Add player spawn animation and a center-out tile-flip wave for the digital-world effect.
Redesign the reward screen with compact cards, visible category/rarity cues, a separate changing description, and rarity-based entrance effects. Locking a reward for the next roll/reward is a separate future feature.
Plan character portraits alongside a per-character shop/upgrades and rune system.
Add player death animation, game-over effects such as slow motion/grayscale, and stage-completion effects.

Phase A — ready to test the first playable run¶

1. Preserve stage data and set up one shared scene¶

Add stage-specific map and appearance configuration to existing LevelData: rule tiles, ornament prefab lists and weights, spacing and any required generation settings, camera background, tilemap material, volume profile and vignette settings. Preserve existing boss, music, stage/difficulty IDs, spawners, duration and unlock data. Upgrade appearance remains configured on each Upgrade asset and is filtered using the stage index.
Use one camera-following map generator and a common tilemap/ornament parent, initialized from the selected stage before generation. Preserve destructible ornaments, including authored weights and duplicate entries. Check the first-generation weight initialization and the old scenes' painted tiles before deciding how to handle them.
Bring existing production managers, player slots, pool, camera, HUD, stage timer, spawner, and Stage 1 gameplay menu/controller/gate and their serialized events into the common scene. Preserve normal post-processing as well as Stage 2's vignette and distinct material. Do not copy the legacy player sorting overrides solely to match older arenas.
Route stage selection and retry to the common scene while retaining the selected LevelData and difficulty. Ensure one owner performs initialization and that visual state, generated objects and listeners reset when a run ends.

Ready to check: Unity imports; one selected stage loads with the expected tiles, appearance and data; startup references resolve and retry/return do not retain previous stage state. Stage 2/3 can use later checks once their data is migrated.

2. Connect player setup and basic controls¶

Connect production character selection, player preparation, weapon, stats, health/stamina, camera, HUD, starting Dash and character ability to the common scene. Respect preparation order and independent player state.
Bring across Stage 1's actual menu wiring, not a claim it already uses new input. Preserve existing input data before removing the legacy input implementation. Implement the minimum new input connections described in task 6 here so movement and menus can be checked; finish remapping, persistence and broader device coverage in Phase B.
Make movement, dash, weapon use, pause and menu/reward selection reachable with available input. Fix startup, pause and back-navigation blockers found on the path.

Ready to check: selected player spawns, moves, dashes with the correct stamina/cooldown, attacks and can pause/resume; no assertion of physical-device or all-character coverage without checking it.

3. Wire combat, enemies and the stage loop¶

Connect the existing spawner, enemy targeting/damage, player attacks, drops, stage timer and boss/finish path. Fix references and logic only where the shared scene or player overhaul exposes a blocker.
Check death, existing revive action, pause, return and retry. Preserve music transitions and chosen stage data. Avoid inventing a replacement enemy or stage system.

Ready to check: enemies spawn and receive player damage; enemies can damage the player; stage timing, death or completion and menu return work in one run.

4. Connect reward and representative abilities¶

Trace a real reward from table selection through Upgrade → ability acquisition → registered hook → weapon/impact → enemy. Check prerequisites, cooldown display and player ownership.
Fix actual blockers in connected batches. Check at least a starting character ability, a reward ability, a weapon/hit effect and one nonstandard cooldown or charge. Keep upgrade IDs separate from permanent backend ability codes.
Confirm no double-execution from old and new ability logic. Keep effects in AB_ behaviors and use the established hook/scope contracts; do not add a named central ability factory.

First playable milestone: the shared gameplay scene starts; a player can move, dash, attack and take damage; enemies spawn; at least one reward grants a working ability; pause, end/death and return/retry work. Use the short test setup for further checks, and distinguish it from an ordinary full-length run. This permits known issues elsewhere; record them clearly.

Phase B — ready to improve and broaden coverage¶

5. Complete stage content in the shared scene¶

Map all three stages' authored generator settings, materials, background colors, volume profiles, vignette, music, spawners, bosses and progression IDs. Check Stage 3's character-unlock reference in Unity.
Use short test configurations with at least two stage appearances sequentially to verify cleanup and no appearance, generated-map, spawn or state leakage. Confirm the tilemap material/shader and imported visuals in Unity. Keep old arenas until their relevant content and behavior are accounted for.

Ready to check: test configurations load their chosen stage appearance in the same scene and reset correctly. Do not claim a real stage or its full completion has been tested from this evidence.

6. Complete new Input System and keybindings¶

Phase A starts this task: preserve existing binding data and required input behavior, then remove the legacy input implementation and connect the existing new-input foundations. Connect per-player sessions and assigned devices to production movement, dash and player actions, plus existing menu, pause, reward navigation and Unity UI. Do not retain a legacy input fallback; incomplete intermediate integration is acceptable. Complete the remaining work below in this phase.
Complete keybinding UI/capture, conflict and cancel handling, default/reset behavior, accepted-change persistence and legacy profile compatibility. Update displayed control glyphs. Confirm expected behaviors from existing contracts before changing saved bindings.
Preserve the current one/two-player playable baseline. The planned assignment is P1 keyboard or gamepad and P2–P4 separate gamepads; four-player gameplay, layouts and full device support remain separate scope unless explicitly required for the version.

Ready to check: a player can navigate, move, attack and dash with assigned controls; change a key, save/restart and use it; cancel/reset works; two players do not share device input accidentally. Physical keyboard/gamepad and disconnect/reconnect checks are still necessary where devices are available.

7. Finish and verify remaining ability/player paths¶

Review active gameplay abilities in connected families, especially data-only definitions and their generic stat operations, shared-script/evolution cases, weapon/projectile hooks, stat effects, removal and reacquisition. Do not count an AB_ file alone as a completed ability or invent a remaining count.
Check differing cooldowns such as Luster Burst and Ground Breaker, companions and pooled ownership, death/revive, two-player isolation and evolution timers/shared counters. Preserve the owner's central stat calculation and special timing.
Check ability UI/icons, reward prerequisites, existing Upgrade identity and backend reporting code resolution. Preserve permanent four-character backend codes; do not assign codes to dash or character abilities, or turn Revive into an equipped ability.
Separate active Resources content from development-only abilities and unresolved drafts; record what is deferred and why.

Ready to check: the targeted active abilities and player lifecycle behaviors have traced implementations and focused evidence; unresolved behavior is listed, not assumed complete.

Phase C — ready to update the new version¶

8. End-to-end verification and documentation¶

Run representative short test games through the common scene: selection, spawning, combat, rewards/evolution, death or clear, progression handling, retry and return. Check one/two-player paths, each character and stage appearances as available. Record shortcuts, untested real-stage behavior and unresolved defects; do not run real stages as agent tests.
Check reflection-based ability lookup in the intended build, including IL2CPP/code stripping, and validate relevant backend/icon reporting without changing saved IDs. The owner builds Windows/Steam on another machine; report platform checks separately from Linux CLI.
Consolidate the ability authoring guide, hook/scope list, data inventory and this roadmap. Shorten repeated documentation; archive obsolete plans only when useful information and links are preserved. Keep Unity asset archive and recovery material.
Prepare a reviewed checkpoint and version/release work when the owner requests it. A first playable run is not a release certification; unresolved blockers and platform coverage must be visible before calling an update ready.

Ready for a new-version update: the intended release scope has a documented playable run, stage and input coverage, checked save/ID compatibility and platform results, plus an agreed list of non-blocking issues. Do not claim this status merely from compilation.

Boundaries and preservation¶

Permanent four-character ability reporting codes, Upgrade IDs, authored values, Unity references, stage/difficulty IDs, progression saves and existing recovery data must be preserved. Dash and character abilities need no invented backend codes. Revive is an upgrade action.
Old Ability assets are archived in ability-assets-2026-10-30.zip; recovery scenes may still need them. Do not restore the old holder/factory as a fallback or delete old arena content before migration.
Stage 2 vignette/profile and tilemap material, camera backgrounds, destructible ornaments, and Stage 3 duplicate ornament weighting need deliberate preservation. Player sorting differences between the old scenes can be ignored per owner direction; use the current intended player rendering setup.
Unity CLI may add a Linux toolchain package. Preserve exact pre-run package/settings bytes and restore only attributable changes after the Editor exits. Avoid normal saves, backend and real profile writes during controlled checks; see the handoff.
No reliable hours or quota estimate exists until common-scene startup and reward-to-enemy gameplay are exercised. Do not label all abilities complete or the game playable based solely on source presence or the controlled fixture.