How are GameManagers created in Unity?

Question

I know the basics of C#(Syntax, 4 pillars, SOLID, Designs Patterns, etc...) and Unity. I can do basic stuff like Flappy bird or Fruit Ninja without any help. But problems arises when I want to create more advanced projects, I don't know how to structure projects and I can't find any guides on how you are supposed to do it. Like where are things supposed to go.

I know that you are supposed to create different Managers that handle the flow of your game like a "Game Manager" or a "Sound Manager" or a "Spawn Manager" or a "Score Managers" but I never know what logic I am supposed to put into it. I don't even know what managers you are supposed to create for easy games like flappy bird. Should you create a Score Managers that controls the score? What about a Game Manager, what should it control? What states should it have? Maybe "isRunning" and "gameOver", maybe.

But what about more complex games where you have an inventory, currency systems, etc... Lets say you have a "fish game where you can walk or hunt fish with a submarine and sell it to upgrade your submarine to dive deeper into the depths of the ocean." what states should the game manager than have? Should its responsibilities only be if the player is dead or not? What about dialogs, UI's, etc...

What about a 2D Platformer where your goal is to go from point A to point B with the help of the "Past you"

I have 20+ Unity games I would like to create, but I never learned how to use the knowledge I have to create things.

Answer 1

There's no rule that says that you have to have a bunch of component classes named "SomethingManager". It's common for projects to have a bunch of Manager components, but that's often because naming things is hard and people get lazy. Having many Manager components can even be a sign of poor architecture, especially if all of these managers are large and complex classes that put too much responsibility in one place.

Putting it another way, if you're thinking "a game has to have a Game Manager, so I need to figure out what to put in my Game Manager" then you're approaching your architecture from the wrong direction. Write the code that your game needs in a way that's suited to your game. Don't try to shoehorn your code into a particular design philosophy just because you think that's what everyone else does.

Using a "Spawn Manager" as an example; I never create a single SpawnManager for my games. Instead, I create different spawners for different types of objects using a reusable object pooling system, and reference those spawners where needed. So instead of doing something like this...

public class Bomb : MonoBehavior {
    // [...]

    public void Explode() {
        SpawnManager.Instance.SpawnBombExplosion(transform.position);
    }
}

...there will be something more like this:

public class Bomb : MonoBehavior {
    [SerializeField] private ExplosionSpawnPool explosionSpawnPool;
    // [...]

    public void Explode() {
        explosionSpawnPool.SpawnAt(transform.position);
    }
}

There's even a good reason to avoid the WhateverManager approach to naming: as can be seen in your question, a name like "GameManager" is not very useful because it doesn't really help you understand what the component does. A component name like "DeckShuffler" or "PlayerSpawner" gives you a very good idea of what the component does and when it should be used. "GameManager" tells you practically nothing about what specific functionality is implemented in the component. Some would argue that if you can't come up with a good simple-and-descriptive name for a class, that means that the class is too complicated.

---

There are so many kinds of games, and so many ways you can design and build even a particular type of game, that it's hard to find general wisdom about how to structure a project that is applicable to many projects. It's sometimes helpful to read general guides on software architecture, but some principles that make a lot of sense in other types of software don't fit well in a video game. Experience goes a long way here; the more projects that you develop, the more you'll understand what does and doesn't work and have better ideas about how to approach your architecture.

Don't settle into a standard pattern and use it over and over even if it isn't the right fit for a particular game. I'm always thinking about lessons I've learned from what I've built, and how I might improve the architecture for both the current project I'm working on and for future projects.