2
\$\begingroup\$

I always hand a bunch of public static manager classes in my game:

  • GameManager (singleton) for reading and writing persistent data and gamestate across scenes
  • SceneManager for holding scene data (coins picked up, score, are we in a cutscene)
  • UIManager for dealing with HUD stuff
  • SfxManager for sound effects
  • PfxManager for particle effects

On the gameobject that holds these manager classes, there are also subordinate classes (e.g. HUDManager, a smaller class that managers tasks specific to HUD, and then delegate those tasks into other smaller scripts) in order to avoid monolithic manager classes.

Is this method frowned upon in Unity game development and if so, what are some better solutions than this approach?

Improve this question
\$\endgroup\$
4
  • \$\begingroup\$ You may want to consider the "manager of managers"/"Service Locator" strategy, described here for example \$\endgroup\$
    – DMGregory ♦
    Sep 3 '20 at 14:18
  • \$\begingroup\$ @DMGregory Thanks for the link! That'll solve the multiple singleton issue. So, aside from that, is it generally considered a bad practice to have public static XManagers and to reference them using "XManager xmanager = XManager.instance", because it'll be difficult to follow the flow of logic and to debug, or is this quite common and an accepted practice in game development to doing so, because games are chaotic and very different from normal software? Thanks Gregory! \$\endgroup\$
    – SirMt
    Sep 3 '20 at 14:29
  • 2
    \$\begingroup\$ In general, I'd recommend not worrying about what other devs might or might not "frown upon" - look for concrete problems/benefits or other outcomes. Is this approach serving your needs? Have you experienced any specific pain points or measured issues with this that we can help you solve? If not, then it's entirely possible it's Good Enough™, and you can focus on something else until/unless it becomes a problem. \$\endgroup\$
    – DMGregory ♦
    Sep 3 '20 at 14:33
  • \$\begingroup\$ Thanks for the comment and thoughts DMGregory :) \$\endgroup\$
    – SirMt
    Sep 3 '20 at 14:37
2
\$\begingroup\$

My usual approach is to minimize managers by creating smarter gameObjects which have their own controllers.

  • "coins picked up" and "score" are properties of the player, so they should be on the player game object.
  • Instead of an UI Manager, I create controllers for individual UI elements. When they show information about a gameObject (like player.score), they reference a gameObject in the scene.
  • Instead of an Sfx Manager, I use objects with audio sources which might or might not have controllers which control that one audio source.

But if the manager-pattern feels natural to you, then you might feel right at home with the new DOTS architecture, where all the game logic is in managers (called "Systems").

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .