Skip to content

Tiny Chaos overhaul milestones

Historical milestone plan. The current roadmap and status supersede its implementation and testing statements.

Updated 2026-10-29. This is a dependency and verification plan, not a claim that any milestone passes. Current changes are uncompiled, have not been imported into Unity, and have not been exercised in gameplay. Implement the connected ability work first; begin the first Editor pass when its main integrations are mostly complete.

For the updated ability-system scope and the first Unity pass, use the ability system plan. The owner now wants to begin that pass once the main ability integrations are mostly complete, without waiting for perfection or a full test campaign.

How to read the order

A focused player or ability check can use a controlled development scene and does not inherently require the full stage or spawner. An end-to-end stage check does require a functioning player, enemy spawning, stage timing and the necessary game services together. Treat the order below as a dependency guide, not evidence that every subsystem must be redesigned before any smaller check can run.

1. Authored content and project readiness

  • Scope: retain ScriptableObject values, script/asset GUIDs, prefab and scene references, and serialized upgrade callbacks while replacing player logic. Resolve source-level missing references and record intentional behavior changes.
  • Before verification: finish a coherent source implementation and its asset integrations. Existing source searches do not prove Unity will import the assets.
  • Later check: open/import the project, resolve compiler and serialization diagnostics, and inspect representative character, ability, weapon and scene bindings. Compilation is not a gameplay pass.

2. Run setup, character and player assembly

  • Scope: player identity, character setup, first weapon, stats, ability ownership, run lifetime, one/two-player isolation and teardown. The production GameInitialization currently loads reward data, prepares stage/spawn data and then prepares players before opening the gate; the development run has a separate player preparation path.
  • Dependencies: authored data and basic services, plus a scene or controlled fixture able to create a player. A full enemy spawner is not required for a focused assembly check.
  • Later check: fresh and reused players, two-player setup, first weapon, starting abilities, cancellation and teardown. Verify that character-ready is not signalled before weapon and stat preparation finishes.

3. Movement, input and player life

  • Scope: movement and dash ownership, input connection, health/stamina, damage, shields, death and revival. Consolidate scene and movement-driver routes and replace the remaining AbilityHolder dependencies. Input redesign remains its own connected workload.
  • Dependencies: milestone 2 player setup and a controlled way to provide commands and damage. Production input, camera and scene integration need their own follow-up.
  • Later check: movement/dash costs and cancellation, input ownership, damage stages, shield removal, death/revive and co-op isolation.

4. Weapons, abilities and companions

  • Scope: ability identity and acquisition, hooks, cooldown/charge rules, stat contributions, weapons, attack preparation/impact, projectile pooling and companion ownership. Remove legacy ability-specific branches and retire AbilityHolder as its callers and serialized bindings move. Sky Ying Sword and Abyss Orb have owned summon behavior; their upgrade, suspension and pool interactions remain unverified.
  • Dependencies: milestones 2–3; a controlled target or damage receiver can validate focused behavior without a full stage. The remaining assets, stat projection and their connected upgrade and presentation paths still need migration.
  • Later check: authored asset identity, duplicate/evolution behavior, hook order, removal and ongoing work, different cooldown styles, projectile ownership and reuse, character weapons/companions and two-player isolation.

5. Enemies, spawning and stage

  • Scope: enemy behavior and targeting, spawn data, spawn timing, stage lifecycle and completion. Redesign these as their own workload; make only required integration changes while the player work is underway.
  • Current dependency evidence: GameInitialization.PrepareSpawnAndGameManagerData supplies the selected level's creep/special spawn data, duration and boss to SpawnerEventManager. GameManager.OpenGate starts the timer and spawner timer after player preparation. These are current source paths, not proof that a complete stage works.
  • Dependencies: authored stage data, pool/services, and the player/enemy combat connection. Stage progression and spawner behavior need to be available together for a full stage run.
  • Later check: spawn timing and populations, target selection, enemy damage/marking, stage completion and teardown.

6. Rewards, upgrades, UI and GameManager integration

  • Scope: reward tables and selection, acquisition/evolution callbacks, UI identity and cooldown displays, pause, run results and the necessary GameManager responsibilities. The current initializer prepares reward tables before player preparation; PlayerManager raises reward requests to GameManager/RewardRoller. These are existing source dependencies, not a reason to preserve the current architecture.
  • Dependencies: player and ability ownership, authored upgrade data, and a controlled way to trigger rewards. Full-run validation also needs milestone 5. Decide GameManager's final boundaries from its actual responsibilities rather than assuming the entire manager must be rewritten at once.
  • Later check: reward availability and authored/runtime identity, duplicate/evolution selection, pause/resume, per-player UI, end-of-run reporting and teardown.

7. Connected run and platform qualification

  • Scope: production scene entry through a complete run, including the above services, inputs, enemies, stage and rewards.
  • Dependencies: milestones 1–6 connected and individually ready. Do not claim a complete run from a partial development scene.
  • Later check: one/two-player production flow, death/revive and rewards, scene transitions, repeated runs, supported controllers and Linux; Windows/Steam checks on the owner's intended machine.

Documentation after implementation

Once the source is logically ready for the first Editor pass, audit the current documents against the implementation. Keep one clear current authoring/reference guide and one current milestone/status view; remove duplicate explanations and shorten excessive prose without dropping rules or dependencies. Mark older plans and evidence as historical, archive material only where appropriate, and preserve useful investigation/verification records. Do not present old behavior notes as current contracts. Update links when documents are moved or consolidated.

Current source-level follow-up

  • Keep each stat's sources and formulas visible in the central stat calculation, with ability state owned by its behavior. Preserve calculation order and the distinction between live and captured values.
  • Trace ability removal, reacquisition and retained behavior state through stats, upgrades and presentation; ensure removed abilities do not leave unintended effects.
  • Finish moving visual bindings and dash input out of AbilityHolder, and reconcile the scene and run-participant setup paths.
  • Trace upgrade evolution, rewards and weapon setup against runtime ability identity and the authored assets. Resolve player reuse, potion timers, and companion restoration across suspension and teardown.
  • Review evolution ownership: its timers still belong to the evolution service and counter-based requirements read shared game counters. Decide per-player and cancellation behavior before changing it.
  • Inventory the remaining ability-specific branches, projectile and enemy interactions before declaring the source ready for Unity. Preserve the existing authored values and serialized references throughout.