Why Singletons Break Your Game & The Right Way to Fix It in Unity.

I'm very sorry, but the voice makes me wanna turn sound off and look at subtitles

Too deep for me to use but still helpful for future reference.
Thank you very much for explaining everything in a comprehensive manner with an analogy, I appreciate it!

Good tip, drop the weird voice at the start. you don't need it.

It is one way of doing things. If you dig a big more you will end up in the MVC architecture. I seem to find difficulties with this architecture specially because we don’t have control on the order of how the subscribers will be called to an event. You should try Single Entry Point with a sync calls, ir is another strategy if you like.

Something's odd. A proper Singleton class object should self-initialize if not initialized. I'd expect to hear that having singleton-based game systems it was impossible to properly swap between different instances of the same system, like having two different UIManagers for aiming and dialog, but if you had problems with initialization and null-point refs, this means the main Singleton class was poorly implemented.

Not a fan of UnityEvent exposed, where you input the function in editor. Makes it hard to look who call your function (can't get the reference through VS) and it break if you rename the function. Err.

I call bs. Singletons are not a problem if you are able to use them only for a common logic that you can pack in additive scene that is ALWAYS loaded.

Another problem that I am having with Singletons in Unity is that, when testing in the editor, it seems that the static variables retain their values even after stopping and playing again.

Thanks for sharing this, I've been using singletons for a long time and always had this issue, never used unity events before, so you are a live saver.

I don't think this is the answer to singletons. Scriptable objects can be a nightmare to handle in large quantities and can really make it painful when you get a few continual nullrefexception after something gets unassigned. For those using singletons, they should only be created inside of a boot scene. Once booted this would then load the remaining scenes. I much prefer a DI container alongside a Service Locator as they're easier to test and much easier to swap out. Scriptable Objects are much better for modular design when necessary, but are not the answer to singletons.

Highly recommend git-amends video on event channles if you like this pattern. He goes into much more depth and detail on this system.

Im a beginner in game dev / programming, but I dont think this is good advice. Only important and unique classes like controllers/managers should be singletons, like a GameManager/SoundManager/UIManager etc...The problem in your example, in my view (a begginer view) is that you shoudnt be
activating and deactivating your singleton classes like this...Controllers and Managers should be inicialize once in the game run (at the start) and must not be destroyed or deactivated

It looks to me that you make a wrong decision in terms of game architeture and are blaming singletons for the problems that u are having with it

The point is, when you overuse singletons everywhere, your code becomes tightly coupled. Imagine if your game has many systems and they are dependent on each other, and in some scenes, you don’t need certain systems. It becomes a nightmare to go through every script and make changes. You can use this approach with singletons to make your life easier. Singletons are still very useful, but do not overuse them.