I’m trying to simplify the architecture of my project as much as possible. Ideally, I would like to have scenes that can run without the need of persisting inter-scene MBs.
I currently use a singleton MB (on a “don’t destroy on load” game object) that holds the services of the app (scene/files/audio/ads management etc), but I want to remove this “inter-scene” object and turn it into a lazy singleton c# class.
What stops me is that I can’t think how I would handle the app lifecycle events (app paused, app resumed etc) without a persisting MB. Any insights on this?
PS: I don’t want to use an events system, as it brings logic coupling and complexity in the debug process.
Just make it so that a first-access to its instance adds a permanent MB to your game, every subsequent access uses that instance. That’s the standard unity pattern. There’s even a bunch of wikia-type code out there for UnitySingleton type class, each with its own quirks and/or limitations.
You can also make “scene singletons,” basically that behave like singletons but go away at the end of each scene. An example would be a level manager that comes into being and handles your wave progression, then gets destroyed and created afresh the next level, with that level’s parameters.
@Kurt-Dekker
Thanks for the answer. I’ve already implemented this exact pattern with a singleton MB that persists.
However, this “App object” has nothing to do with graphics, so I wondered if I could turn this into a c# class and remove the MB. This would allow me to run whatever scene as first in the editor, without starting the project from App scene.
What remains to be handled in this scenario is how to handle app pause/resume etc from a central class. These app lifecycle events cannot be handled without an MB, so I’m asking whether the whole community eventually keeps at least 1 singleton in their projects to handle such events.
It is by far the simplest solution under Unity, especially when you need a reliably per-frame Update() heartbeat.
Looking at the commercial-scale project I am working on right now there are 23 separate managers running in the DontDestroyOnLoad part of the scene. Some of these come from third party software plugins, some of them are from our own code, like a ScreenOrientationManager, UserNotificationManager, etc.
1 Like