Manager Classes in Unity: When They're Genius and When They're a Bad Idea

A manager class is likely one of the first things you have written in Unity. GameManager, AudioManager, UIManager, SaveManager, they show up in every tutorial, every asset store project, every "clean architecture" YouTube video with a thumbnail of a guy with a weird looking beard pointing confused at a whiteboard.

And look, managers work, and that's exactly the annoying part to explain - but I'm going to try anyway. Managers work well enough, for long enough, and then you don't even notice the problem until your GameManager is 2,400 lines long and touches literally everything in your project. At that point it's not a manager anymore. It's a god object wearing a manager costume.

Let's talk about when managers are genuinely good architecture, when they quietly rot, and how to tell the difference before your Inspector starts looking like a control room of a spaceship.

 

What Defines a "Manager Class" in Unity?

A manager is just a class that owns and coordinates a specific system. Nothing fancy conceptually, it's the "system" version of a noun. There's only one in existence in your project.

• AudioManager, usually plays sounds, manages music, handles volume settings
• GameManager, usually tracks game state, score, win/lose conditions
• UIManager, usually shows/hides menus, updates HUD elements
• SaveManager, usually serializes and loads player data

And so on. In Unity specifically, managers tend to be implemented as singletons (GameManager.Instance.DoThing()) because Unity's component-based architecture doesn't naturally give you a "one central brain", everything is scattered across GameObjects in a scene. Managers are the duct tape that holds the scattered bits together.

That duct tape metaphor is doing a lot of work here. Keep it in mind for later.

 

Why Managers Are Genuinely Good (at times)

Before we tear apart managers, let's give credit where it's due. There are real, defensible reasons developers reach for them constantly.

1. They centralize logic that actually needs centralizing

Some things in your game genuinely are global. There's only one audio mixer. There's only one save file. There's only one "is the game paused" state. Wrapping these in a manager isn't over-engineering, it's just naming reality correctly.

2. They give you a single, predictable entry point

AudioManager.Instance.PlaySFX("explosion") is readable. Anyone on your team, including future-you at 2 AM before a submission deadline, knows exactly where to look. Compare that to hunting down which of your 40 GameObjects is responsible for the boom sound due to a trigger event. Managers win on discoverability, easily.

3. They survive scene loads (when set up right)

DontDestroyOnLoad plus a singleton manager means your music doesn't restart every time you load a new level. This alone is why AudioManager is basically mandatory in most projects. Nobody wants the "record scratch" effect every scene transition.

4. They're easy to explain to junior devs (or yourself, six months later)

Managers map cleanly onto how people already think about systems: "the thing in charge of audio," "the thing in charge of saving." That mental model is valuable, especially on small teams or solo projects where onboarding overhead needs to stay near zero.

So yes, managers DO solve real problems. The trouble starts when they solve every problem, because you never said no to them.

 

The God Object Problem: How a Manager Rots

Here's the pattern. It's almost always the same story arch, and if you've shipped more than one Unity project, you've probably lived it.

Week 1: GameManager tracks score and game state. Clean, simple, feels great.

Week 3: GameManager also handles pause menu logic, because... well it was already there, and adding an if statement felt faster than making a new class.

Week 6: GameManager now spawns enemies, tracks player health, manages the audio mixer reference (why not, it's already a singleton), and has a public static field for basically EVERYTHING!

Week 10: You open GameManager.cs, scroll for eleven seconds straight, and quietly close your laptop.

This is called scope creep, but architectural scope creep is sneakier than feature scope creep because it doesn't show up in your game, it shows up in your codebase, where nobody except your team (and future contractors, God help them) will ever see it.

The telltale signs your manager has gone rogue:

• It has more than 5-6 unrelated responsibilities
• Other scripts reference it constantly, but it references almost nothing back (one-way dependency hell)
• You're scared to refactor it because "everything touches it"
• It has methods like HandleEverything() or a 200-line Update()

A god object isn't defined by line count alone, it's defined by unrelated responsibility count. A 1,000-line AudioManager that only does audio things is fine, if verbose. A 400-line GameManager doing scoring, UI, spawning, and save logic is a god object even though it's shorter.

 

So When Does a Manager Become a God Object, Exactly?

Here's the rule of thumb I actually use: if you can't describe what the class does in one sentence without using the word "and" more than once, it's drifting.

"GameManager tracks score and game state", fine (even though I'd make a ScoreManager). "GameManager tracks score, handles pause menus, and manages enemy spawning, and also does save data", run.

Another gut check: could you delete the class and rebuild it from scratch in under 20 minutes, using only its public interface as a guide? If the answer is "no, because seventeen other scripts reach directly into its guts," you've built yourself a god object. 

 

The Fix Isn't "No Managers", It's "Smaller Managers, Doing Less"

A lot of well-meaning advice online swings hard the other direction: "never use singletons," "always use dependency injection," "managers are an anti-pattern, full stop." That's overcorrecting, and honestly it's not realistic advice for solo devs or small teams shipping a game jam project in 48 hours.

The actual fix is scope discipline, not manager abolition.

Split by responsibility, not by convenience. Instead of one GameManager doing everything, break it into GameStateManager, ScoreManager, and SpawnManager. Yes, that's more files. It's also more sanity.

Use events instead of direct references where you can. Instead of UIManager.Instance.UpdateHealthBar(health) being called from inside PlayerHealth, fire an event: OnHealthChanged?.Invoke(health), and let UIManager subscribe to it. Now PlayerHealth doesn't need to know UIManager exists at all. This one change alone kills a huge chunk of god-object coupling.

Consider ScriptableObjects as data channels. Unity devs increasingly use ScriptableObject-based event systems (a "GameEvent" SO that multiple scripts can raise and listen to) specifically to avoid the singleton-spaghetti problem. It's a bit more setup up front, but it decouples systems beautifully. AudioManager doesn't need a direct reference to the player, it just listens for an "OnPlayerJumped" event asset.

Ask "does this NEED to be global?" before making something a manager at all. Not everything does. A pickup item doesn't need ItemManager.Instance if it can just handle its own logic and fire an event when collected. Managers should be reserved for things that are actually singular and actually global, audio, save state, overall game state. Everything else can probably live somewhere more local.

 

A Quick Gut-Check Table

Situation	Manager?
One audio mixer, needs to persist across scenes	Yes, totally reasonable
Tracking win/lose state for the whole game	Yes
Handling one specific enemy's attack pattern	No, that's the enemy's own script's job
Coordinating "is UI visible right now"	Yes, but keep it UI-only
Storing player inventory and handling combat and saving and dialogue	Please, for the love of your future self, split this up

 

Wrapping Up

Managers aren't bad architecture. They're a tool, and like every tool in Unity they get dangerous when you reach for them out of habit instead of intention. The line between "clean, centralized system" and "god object that everyone's afraid to touch" isn't about how many managers you have, it's about how disciplined you are with what each one is allowed to do.

Next time you're about to add "just one more thing" to GameManager, ask yourself if it actually belongs there, or if you're just avoiding the five extra minutes it'd take to make a new class. Your six-months-from-now self is watching, and they will remember.

 

~happy Coding!