Developers need the ability to create Game/Application scope objects and code not tied to a particular scene file. There are a few ways of almost getting there, but none of them fill the gap. Right now, everything has to be in a scene. DontDestroyOnLoad, RuntimeInitializeOnLoadMethodAttribute and static constructors don’t cut it.
The way I imagine it working is that I can define a GameObject (or multiple GameObjects), add components to it, and this game object will be created and initialized on startup, before any scene is loaded. It should be defined outside of any Scene. It’s an application-scope GameObject. It doesn’t necessarily have to be a GameObject, but that seems like it would follow “The Unity Way” and be the most intuitive.
It should be easy enough to implement. It would essentially work like a Startup Scene that is always defined and always loaded first on startup. All objects in the scene will automatically be marked DontDestroyOnLoad, then the “real” first scene will be loaded. In the editor, all scenes need to be able to access GameObject instances (and component instances) in this global startup scene, as if they existed in the current scene.
It would have the following benefits over the typical StartupScene+DontDestroyOnLoad:
You can start testing from any scene in the editor.
You don’t need to worry about accidental changes and differences between scenes [if you add the object in every scene to get around #1]
No duplicate objects between scene that you need to kill [if you add the object in every scene to get around #1]
You can reference components/objects in the global object. For example, add a button “OnClick” to a global “GoToMainMenu()” function.
There will be that one well defined main application entry point that everyone is always looking for.
But maybe it’s more complicated than I realize. Is there any reason why this wouldn’t work? Is there something I’m missing?
If you want something that just exists runtime, and doesn’t require Update/FixedUpdate calls, you can just use a good old static class. Nothing Unity-specific about it. That’s your “global object”. That’s usefull for things like functions that pause the game and save the game and goes to the main menu or whatever - if it doesn’t contain any variables and there will only exist one of it, it’s a static class.
If you need the MonoBehaviour callbacks, or need to reference it like a GameObject (or Object) for other reasons, use the singleton pattern.
We’ve got a script that needs to be on every level anyways (named “Level”, conveniently), so we’ve hooked up creating all the prefabs that are needed to test from any scene there. It also spawns the player and the camera and everything that’s only created once in the first scene that’s loaded (with a static flag). Even if you don’t need that, having a little hook script that does all of those things that you attach to the main camera or the sun or whatever on every scene won’t be too difficult.
Don’t get caught up on “global object”. I meant that as “A GameObject which always exists in all scenes”. Not the same thing as a Singleton. The “Singleton” solution is what I already described and gave 5 reasons why a “global object” is better.
In all other application and game development environments, there’s a point of application entry that you can hook into to initialize services, load configurations and whatever else is important to be done first. A dev needs to have control over when and what order things are initialized. I’ve seen this issue come up several times before. I’m hoping we can forget about the bandaids and hacks, so that we can have a well thought out approach to application initialization integrated into Unity.
So, I’m wondering if the devs at Unity have thought about this at all. Is it a “we’ll try implement this or a better solution at some point”, or is it a “this is the way we like it and we’re sticking with it”.