Could Unity use a Root Scene?

In most programming languages there is a root function or/class e.g. main().

One of the issues with Unity is that it is the root of your game, which is great as Unity does a lot for you but without a scriptable root we end up having to do weird hacky things (DontDestoryOnLoad(), PlayerPrefs) to keep the core game mechanics and data , players state and even UI/controllers between scenes.

It's one of the first 'hacky' problems you hit developing with Unity.

So could Unity use a Root Scene?

Note ECS has a default world. Is that like a root scene, can the base world be kept between scenes?

 

No. Do it yourself.

 

I Do every time I write a multi-scene game and it's clunky and inelegant.

Could an optional Root Scene make multi-scene game development simpler and more elegant?

 

No.

 

You can already do a root scene. Just make it the first scene you start, and only use additive scene loading for other scenes. I think DontDestroyOnLoad is generally better though, because you're only keeping around the objects you actually need to keep around. It is only 1 line of code, so I've never considered it a weird hacky thing.

 

I actually prefer this approach. I find DontDestroyOnLoad to be about as subtle as a sledgehammer. I want this thing to hang around through a couple of scene loads, so I am going to make it immortal. No one shall ever destroy it! Muh, hah, hah, hah. Seriously, its such an evil villain scenario.

With additive loading one can apply more subtlety. DestoyOnGameExit, DestroyOnPlayerChange, DestroyOnGameSessionEnd, DestroyOnLevelEnd, DestroyOnLeavingArea. Or so on based on the needs of your specific game design.

 

Indeed, make a 'preload' scene, do all your init and singleton stuff, then additive load every other scene. Be sure to assign the new scene as the main scene when you do.

There's also this.

 

@Arowx

The scene is the root scene.

You know what multi scene is all about in Unity, I assume? Unity and everyone is trying to make things less dependant on a root scene. Because the concept of a root scene is the same as having main.cpp - it's invasive to have to go through it. You can make it like this if you want.

The rest of us are asking Unity to go the opposite way, make things less dependant on scenes so we can stream stuff and so on. Current issue is the lighting setup - it's locked to scene. Probes are locked to a master scene etc... very limiting.

So no, I don't want an even more root than root scene.

I currently have a master scene where things are pooled and the lighting is baked with, and a bunch of other scenes which are loaded in and out using multi scene to manage editor perf, authoring and so forth.

 

I also did it with one ''preload' scene containing the singelton things. The other scenes i am loading additive.
Im am far away from a unity pro (started this year) but i am a good programmer. Actually i found it hard to implement/work out my solution and read many tutorials.
For my needs a root scene would have been very helpful!
I think unity has a lot of intuitive features but in my opinion scene loading ist sadly not one of them... perhaps i only think so becauce i just suck at unity ;-)

 

Slightly of topic, but have you had any success using occlusion culling with this approach? I'm currently trying to get this to work.

 

I haven't actually noticed any problems with that but I bake occlusion with everything visible so that's probably why...

 

So you activate all your scenes together on the inspector and bake it?

 

My toolchain bakes it, from the menu. It loads up all scenes which have geometry and calculates a lot of things from probes to navmeshes to lighting and occlusion.

I haven't got around to this part being a bottleneck yet so I've not investigated too deeply (sort of new ish to multi scene myself).

 

I don't know about scene but your initial point makes sense. I could see it being interesting being able to override or extend the program entrypoint (main) in some manner.

 

People talk additive scene loading or dontdestory. we use a third option, RuntimeInitializeOnLoadMethod and scriptable objects.

Code (CSharp):

1.       [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
2.       static void CreateManagers()
3.       {
4.             Steam = Object.Instantiate(Resources.Load<SteamManager>("SteamManager"));
5.             Settings = Object.Instantiate(Resources.Load<SettingsManager>("SettingsManager"));
6.       }

 

Stupid question, using the "RuntimeInitializeLoadType.BeforeSceneLoad" parameter, what can be accessed from the method ? I mean, the scene is not loaded yet, so can the class access something in the (not loaded) scene hierarchy ?

 

You can add stuff to the scene only. Which I dont only load stuff that should live during the entire game session. (ie its perfectly fine doing new GameObject("my objects"); it will be added to the loading scene)

 

Thank You.

As you can see nearly everyone has a different approach or take on this idea, that's because it's the solution we find to make our own version of the Unity 'root' problem.

An optional root scene or script or class or world, gives a hook where the developer can choose to place global game data, code and scene elements.

Imagine if there were a root component you could just drop on an object and it would be guaranteed to be the first thing to exist and run in your game and to live through as many scene loads as you choose...

 

Everyone has posted different solutions that fit their own specific needs.

 

We already have that...

 

Yeah, that exists now. It's just not forced on people.

 

My point is it could be made simpler and easier...

Look at the Unity UI it lets you quickly build up a level and with a few lines of code and/or standard assets you can have camera movement and player interaction.

Now think about how you had to work out how to keep things going between scenes, something as simple as a post game score screen becomes a head scratcher as the score was in your game object and UI which vanishes when you move between scenes.

Should every Unity developer have to search for and find the DontDestroyOnLoad Method or could a simple in UI root component or tick box make it easier?

 

I'm pretty sure it will be part of the upcoming visual scripting madness, so you can click your application together, including dontdestroyonload if you choose to do so.

 

It is not complex enough for people who work at that level (the only people who would see any benefit from the concept of a root scene) that it makes sense to make it a full, official paradigm.

 

I have to avoid the Unity UI because it offers no real benefit and has low performance. I'm still struggling at the rationale behind a lot of it if I'm honest. Shifted to just using textmesh pro with my own suitable textured objects. Works better and is simpler for me.

You are advocating one way of working but that might not be suited to a lot of scenarios, since it is one way of working.

 

I don't think he's referring to the Unity UI. I believe he's referring to the Unity editor interface.

 

Ah so he is. but I don't understand any of what is asked for. A scene is exactly that. Using multi scene you can if you choose, use it like building blocks. Or the nested prefabs (which are technically scenes as far as I know).

 

You treat it as if it's a problem with Unity, but it's not. It's a design decision that every piece of software has to make based on its own requirements.

If you're using Unity then it's going to have an impact on the specifics of those requirements. Unity not addressing your specific project design preferences is not a "problem" with Unity.

 

At some point you have to accept the engine is designed for professionals, not for beginners. Its nice to have a beginner friendly engine. But that's not really the point.

 

But is already this simple. I'm not seeing how it could be made easier without forcing every other project to be harder.