When creating a project with multiple scenes, how do you guys go about using singleton managers?
Do you create one singleton object, and attach all relevant scripts to that one?
Or do you create several singleton objects with only 1 script attached to it, so that you have one called “ResourceManager” and one called “PlayerManager” and so on?
I’m unsure if one thing is better than the other in terms of performance, or if it’s purely a matter of cosmetic preference in the Hierarchy overview?
If multiple objects are logically connected with each other, you can wrap them up in one singleton with references to all its related components - for example, most or all of the UI elements are likely to be under one UI singleton, which then has references to all its components.
Putting everything in one “singleton manager” is nonsensical, though. It ties your entire codebase together in a way that makes it painful to decouple, and it puts instance references in an unpredictable place, as opposed to within the class to which they are inextricably tied.
Performance-wise it’s indistinguishable, but in terms of coding practice, singleton references should be within the class that they reference, unless there is a clear reason for one class to “own” the other one.
I’m glad to hear that
That is how I’ve been going on about it, but reading about gameManagers and such I wondered if it would be more effective to store all that kind of data in one file.
Is there a way to organize singletons (like a folder or such) in your Hierarchy, or do I just have to accept that they’re always visible?
If a singleton exists and isn’t tied to an existing object (such as the UI or Player.main, for example), then I usually group them under an empty GO in the hierarchy.
Most if not all of my projects have used additive scene loading, having for example the UI and controls in the initial scene, and then additively loading the levels or whatever. The recent addition of multi-scene editing to the Unity editor makes this much easier, too.
