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
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."
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
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.
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.
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
- Unity Scripting API: Object.DontDestroyOnLoadReference for keeping a GameObject alive across scene loads.