Eonevolve Learning
Unity and DevelopmentUnity and codeIntermediate~6 min

Scene Flow and Persistent Managers: Avoiding the God Object

Snapshot

~80 sec

Some state - a run's score, the active save slot - needs to survive a scene change. A narrow persistent manager carries exactly that, and nothing else, across scenes. Piling every cross-scene responsibility into one object is how a helpful manager turns into a god object.

You will learn

  • Explain why some GameObjects need to survive a scene load and most do not.
  • Use a guarded singleton so a persistent manager is never duplicated after a reload.
  • Recognize when a manager has grown past its original narrow responsibility.

Target outcome

You can name the one thing a persistent manager should own, and one thing it should not.

Visual walkthrough

Visual walkthrough

~6 min

  1. Three ideas behind clean scene flow

    • Scene load

      Loading a new scene destroys the previous scene's objects by default.

    • DontDestroyOnLoad

      Marks a GameObject to survive across scene loads instead of being destroyed.

    • God object

      A single manager that has accumulated unrelated responsibilities because it was already "the persistent one."

  2. A guarded singleton with one job

    Invented run-score tracker. The guard clause prevents a duplicate instance from surviving a reload; the manager owns only RunScore, nothing else.

    Languagecsharp
    public sealed class GameSession : MonoBehaviour
    {
        public static GameSession Instance { get; private set; }
    
        public int RunScore { get; private set; }
    
        private void Awake()
        {
            if (Instance != null && Instance != this)
            {
                Destroy(gameObject);
                return;
            }
            Instance = this;
            DontDestroyOnLoad(gameObject);
        }
    
        public void AddScore(int amount) => RunScore += amount;
    }

    Code annotations

    1. Lines 7-12

      Guard against duplicates

      If an Instance already exists when a new one wakes up (e.g. after reloading the first scene), the new duplicate destroys itself.

      Effect: Exactly one GameSession survives across every scene load, never two.

    2. Line 13

      Mark this object persistent

      DontDestroyOnLoad keeps this specific GameObject alive across scene changes.

      Effect: RunScore keeps its value when the player moves from gameplay to a results scene.

  3. Spot the scope creep

    Your GameSession manager started with just RunScore. Six months later it also loads scenes, plays music, and saves settings. What should happen before adding a seventh responsibility?

    Expected reasoning

    Split the accumulated responsibilities into their own narrow managers (a SceneLoader, an AudioManager, a SettingsStore) before adding more. GameSession has already drifted into a god object; growing it further makes every future change riskier than it needs to be.

Go deeper