Are there best practices for "Singletons" (persistent GameObjects) in Unity?

Question

I'm rather new to Unity, and C# too as a matter of fact!

What I am doing right now is:

• I have a "Singleton" (it's not really a Singleton but that's not the point) GameObject called GameManager, to which is attached my GameManager.cs script containing most of the game info (which tutorial text has been already displayed, functions to load localized text, last scene loaded...)
• As children of this GameManager object, I have different kinds of GameObjects I do not want to destroy on load either, such as PostProcessing Profiles, Global Lights, Audio Manager, UI Canvasses (canvi?) and other things...

There are plenty of great tutorials on Unity, and it's an awesome community, but I could not really find any info on Unity's "best practice" regarding GameObjects management.

Is this a correct way to proceed? Will I have issues in the future with this method? Should I make a generic class that implements Unity's DontDestroyOnLoad() and have the Object I want to keep inherit from that class? Is there a better way?

It works fine for now, but I want to be sure I am not doing this the wrong way and potentially messing up with my game's performance or stability.

Many thanks in advance.

Answer 1

There are two best-practices here.

1. Build lots of singletons, and replace Unity's built-in initialization system

2. Build very few singletons, and work within Unity's initialization system, and make heavy use of the new Multi-Scene Editing system.

Option 1 is very popular with game-studios and professional gamedevs, who are skilled at doign this and have done it many times before. The main problem is that once you start down this route you are comitting to maintaining your own parallel init system. The main advantage is that your system is probably better, definitely more powerful, and usually faster (!) than Unity's internal one.

Option 2 is more popular with people new to game programming, who want to lean on as much of Unity's built-in features as possible.

---

That said, there are some strange things in your question.

For instance ... Canvas? Why on earth would you be trying to make Canvas into a singleton? This suggests you're misusing Canvas in a big way (and probably some of the other classes).

The standard approach (and the only one that Unity supports) is for every Scene to have its own unique Canvas. To do something different ... is very odd.

I suspect you've misunderstood what "DontDestoryOnLoad" does. It does not prevent things being destroyed on load!

Instead, it prevents being destroyed when a NEW scene is being loaded, and they only lived in the OLD scene. A much better name would have been: "DontDestroyWhenLoadingANewScene"

There are a lot of bugs (going back many years) in Unity with DontDestroyOnLoad, so in general its best to avoid it as much as possible. For simple cases it works fine, but if you use it too much you run into complex edge cases and interactions with Unity's own internal classes.

Answer 2

Obligatory utopic programmer answer: Try to avoid using singletons as much as possible.

That being said, feel free to use my singleton implementation, been using it for years in production and it works fine.

https://gist.github.com/ronrejwan/7a4f0037effec3c9e8943542cf9cfbc9