Skip to content

Archived on 2026-10-24. This is a historical implementation note, not current setup instructions or an active task list. Original claims, code examples, file paths, and completion statements have not all been revalidated. Use the current documentation and issue register for maintenance decisions.

Tiny-Chaos GameManager Refactor Plan

Objectives

  • Break up Assets/Script/Manager/Game/GameManager.cs (≈1.2K LOC) into focused, testable components.
  • Align runtime script locations/names with the high-level structure outlined in docs/file_tree.md (Core, GameSystem, UI, etc.).
  • Preserve existing behaviours (initialization, rewards, UI updates, end-game flow) while improving readability and future extensibility.

Current State & Pain Points

  • GameManager currently performs initialization, player leveling, reward rolling, UI updating, game flow control, game over handling, and stage unlock persistence in a single MonoBehaviour.
  • Responsibilities cross multiple conceptual folders from the planned tree (Core, GameSystem, UI), making it hard to reason about ownership and dependencies.
  • Reward/level logic mixes data (tables, queues), view elements (buttons, FX), and orchestration; reroll UI is tightly coupled to progression state.
  • File structure under Assets/Script/Manager/Game/ does not yet mirror the documented tree (e.g., Core/GameSystem folders), so refactors should also prepare for moving scripts into their target namespaces.

Target Component Breakdown

Concern Key Responsibilities (today) Proposed Component Target Folder/Namespace
Game state orchestration Central truth for isPaused, IsBossDefeated, isRerollReward, etc.; broadcast transitions GameStateService + GameStateEvents GameSystem/GameState
Game session orchestration Awake/Start lifecycle, hooking into GameInitialization, pausing, ticking, coordinating other services GameSessionController (MonoBehaviour) Core/Game (maps to docs Core)
Player leveling & XP Track level/EXP, apply pills/buffs, trigger reward queue PlayerProgressService (pure class or MonoBehaviour) GameSystem/Progression
Reward generation & reroll Manage reward tables, queues, FX, reroll amount RewardRoller + RewardUIController Logic in GameSystem/Rewards, UI in UI/GameHUD
Game HUD updates Score/level text, XP bar animation, player status widgets GameHUDController UI
Game end handling End-game coroutine, GameEndManager, stage unlock GameEndFlow Core/Game
Stage unlock persistence Update achievements/unlocks post-run StageUnlockService Core/Progression

Initial refactor will keep these components under Assets/Script/Manager/Game/ for minimal disruption, but classes should be placed in folders/namespaces that map 1:1 with the eventual Core / GameSystem / UI split. Moving files can follow once behaviour is stable.

Milestones

  1. Game State Extraction (New First Task)
  2. Define a dedicated GameStateService (serializable class or ScriptableObject) that owns all session flags (isPaused, IsBossDefeated, isDisplayingReward, isRerollReward, isRewardEvent, IsGameOver, IsBossFight, IsBonusTime, etc.).
  3. Provide safe mutators/events (e.g., SetPaused(bool), BeginRewardRoll(), CompleteRewardRoll()) so dependent systems no longer poke GameManager booleans directly.

  4. Replace inline field usage across GameManager with calls into the new service and expose read-only accessors for other classes that currently reference the flags.

  5. Baseline Extraction (Progression + Rewards)

  6. Introduce GameSessionController that owns MonoBehaviour lifecycle (Awake/Start/Update) but now consumes GameStateService.
  7. Move leveling/EXP fields & logic (level, exp, AddExp, CheckLevelUp, FuturePills, RPGBuff, etc.) into PlayerProgressService. Inject dependencies (Player[], UpgradeSelection, events) via constructor or serialized reference.
  8. Move reward queue/table logic into RewardRoller, exposing high-level events (OnRewardReady, OnRewardUIRequested) and using the game-state API to gate transitions.

  9. Keep GameManager temporarily as facade that wires these services together and forwards Unity events.

  10. UI/FX Decoupling

  11. Extract score/level/xp UI updates & XP bar tweening into GameHUDController.
  12. Extract reward/chest UI (buttons, FX, reroll button state) into RewardUIController that listens to RewardRoller.

  13. Ensure UI controllers live under UI as per docs.

  14. Game Over & Stage Unlock Modules

  15. Move coroutine-heavy game over flow plus stage unlock logic into GameEndFlow and StageUnlockService.

  16. Provide clear async API so GameSessionController simply triggers them.

  17. File/Namespace Alignment

  18. Physically move new scripts into folders that mirror docs/file_tree.md, updating namespaces/usings accordingly.
  19. Update docs/readmes + any assembly definitions if needed.

Validation Strategy

  • Regression test by running in-editor play mode: level-up, reward rolling, reroll, boss kill, stage unlock, and game over sequences.
  • Add lightweight unit tests (where feasible) for PlayerProgressService and RewardRoller once they become POCOs.
  • Use Unity profiler or logging to ensure no additional allocations per frame.

Open Questions / To Confirm

  • Should reward data be ScriptableObjects (if not already) to let RewardRoller be data-driven?
  • Is there a central event bus planned (per docs/CoreREADME.md), or should these components communicate via direct refs for now?
  • Preferred namespace prefixes (e.g., TinyChaos.Core vs. Core) to bake into new classes?

Once you review/approve this plan, I’ll start with Milestone 1, focusing on carving out the progression/reward services from GameManager.