📝 Lesson 4.1: Game State and Managers

What Is a Manager?

As a game grows, some responsibilities don't belong to any single GameObject. "The current score" isn't the player's job or the UI's job — it's game-wide state. A manager is a component that owns one such cross-cutting concern and offers a central place to read and change it.

The challenge: if there's one GameManager, how does the player, the UI, an enemy — anyone — reach it? You could wire a [SerializeField] reference into every script (Lesson 1.3), but that's tedious for something everything needs. The singleton pattern gives one globally-reachable access point.

The Singleton Pattern

A singleton guarantees a class has exactly one instance and exposes it through a static Instance property, so any script can call GameManager.Instance.AddScore(10) from anywhere.

using UnityEngine;

public class GameManager : MonoBehaviour
{
    // The single, globally-accessible instance.
    public static GameManager Instance { get; private set; }

    public int Score { get; private set; }

    void Awake()
    {
        // Enforce a single instance: if one already exists, destroy this duplicate.
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
    }

    public void AddScore(int amount)
    {
        Score += amount;
        Debug.Log($"Score: {Score}");
    }
}

Surviving Scene Loads

By default, loading a new scene destroys every GameObject in the old one — including your manager. But score, settings, and audio should carry from the menu into the level and between levels. DontDestroyOnLoad marks an object to survive scene changes.

void Awake()
{
    if (Instance != null && Instance != this)
    {
        Destroy(gameObject);
        return;
    }
    Instance = this;
    DontDestroyOnLoad(gameObject);   // this manager persists across all scenes
}

⚠️ Important: DontDestroyOnLoad only works on root GameObjects. If your manager is a child of another object, it won't persist — Unity even warns you. Keep managers at the scene root.

A Game State Machine

Games move through distinct states — a main menu, active play, a pause screen, game over — and each allows different things. Scattering bool isPaused, bool isGameOver flags everywhere quickly becomes a tangle of impossible combinations. A state machine models this cleanly with a single enum.

public enum GameState { MainMenu, Playing, Paused, GameOver }

The manager holds the current state, exposes a method to change it, and raises an event (Lesson 3.2) so UI and systems react — without the manager knowing about them:

using System;
using UnityEngine;

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    public GameState State { get; private set; } = GameState.MainMenu;
    public event Action<GameState> StateChanged;   // announce transitions

    void Awake()
    {
        if (Instance != null && Instance != this) { Destroy(gameObject); return; }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void SetState(GameState newState)
    {
        if (State == newState) return;
        State = newState;

        // Pause freezes time-based logic; WaitForSeconds & physics stop (Lesson 3.3 / 1.2).
        Time.timeScale = (newState == GameState.Paused) ? 0f : 1f;

        StateChanged?.Invoke(newState);   // let listeners react
    }
}

Scene Management

Loading levels, returning to the menu, restarting after game over — all handled by the SceneManager class in the UnityEngine.SceneManagement namespace.

using UnityEngine;
using UnityEngine.SceneManagement;   // required for SceneManager

public class SceneFlow : MonoBehaviour
{
    public void LoadLevel(string sceneName) => SceneManager.LoadScene(sceneName);

    public void Restart()
    {
        // Reload the scene that's currently active.
        SceneManager.LoadScene(SceneManager.GetActiveScene().buildIndex);
    }

    public void QuitToMenu() => SceneManager.LoadScene("MainMenu");
}

💡 Additive scenes and managers: a common architecture keeps managers in a small persistent "bootstrap" scene loaded additively, with levels swapped in and out around it. Combined with DontDestroyOnLoad, this cleanly separates "systems that live forever" from "content that comes and goes."

Singleton Pitfalls

Singletons are convenient — maybe too convenient. Because Instance is reachable from anywhere, it's tempting to route everything through it, recreating the tight coupling Lesson 3.2 warned against. Used well, singletons and events complement each other.

💡 Rule of thumb: if you find everything calling Instance, you've drifted back to tight coupling. Push notifications out with events; pull commands in sparingly.

Exercise & Quiz

using System;
using UnityEngine;
using UnityEngine.SceneManagement;

public enum GameState { MainMenu, Playing, Paused, GameOver }

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }
    public GameState State { get; private set; } = GameState.MainMenu;
    public int Score { get; private set; }

    public event Action<GameState> StateChanged;
    public event Action<int> ScoreChanged;

    void Awake()
    {
        // TODO: singleton guard + DontDestroyOnLoad.
    }

    // TODO: AddScore, SetState (with timeScale), Restart.
}

using System;
using UnityEngine;
using UnityEngine.SceneManagement;

public enum GameState { MainMenu, Playing, Paused, GameOver }

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }
    public GameState State { get; private set; } = GameState.MainMenu;
    public int Score { get; private set; }

    public event Action<GameState> StateChanged;
    public event Action<int> ScoreChanged;

    void Awake()
    {
        if (Instance != null && Instance != this) { Destroy(gameObject); return; }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    void Update()
    {
        if (Input.GetKeyDown(KeyCode.Escape))
        {
            if (State == GameState.Playing) SetState(GameState.Paused);
            else if (State == GameState.Paused) SetState(GameState.Playing);
        }
    }

    public void AddScore(int amount)
    {
        Score += amount;
        ScoreChanged?.Invoke(Score);
    }

    public void SetState(GameState newState)
    {
        if (State == newState) return;
        State = newState;
        Time.timeScale = (newState == GameState.Paused) ? 0f : 1f;
        StateChanged?.Invoke(newState);
    }

    public void Restart()
    {
        Score = 0;
        SetState(GameState.Playing);   // also restores timeScale to 1
        SceneManager.LoadScene(SceneManager.GetActiveScene().buildIndex);
    }
}

Summary

📚 Additional Resources

• Scripting Reference — DontDestroyOnLoad
• Scripting Reference — SceneManager
• Scripting Reference — Time.timeScale
• Unity — Programming patterns for game architecture

🚀 What's Next?

Your game now has a brain that tracks state and score. Next, players need to see it. Lesson 4.2, UI Scripting, connects your managers and events to on-screen UI — score labels, health bars, pause menus — with uGUI and UI Toolkit.