Official Scene Loading System

Hello! I saw your video announcement about UOPs and I'm excited to contribute to this game's development. I'm interested on working on the Scene Loading System, since I already dealt with this on other projects of mine.

In the case of the scene management system, it is not taken from any external Unity package or code from a third party; I came up with it myself and, since I use it on many of my own projects, I'd like to port it to this game, which would solve the issue fairly quickly. If it's not allowed, there's no problem as well, I just want to contribute to this as much as I can anyway.

So, how it works? I propose using a simple SceneSelector component which will require a scene to be selected from the build index, and expose a LoadScene() method to be called either from events, other components on the GameObject, or from other GameObjects. To avoid any typos or user error, the scenes will display on editor thanks to a custom inspector made for the component which will loop through the scene list and list all scenes by name in a dropdown so there's zero errors by virtue of typing the scene's name manually. This way it would be more comfortable for designers to load scenes, and it can be easily integrated within the boundaries of having an empty scene where many other scenes an be loaded, we just add other SceneSelector objects.

This is how I deal with scene management on my games, and I think it makes it easier to deal with scene management without much hassle.

 

This is now the official thread for the Scene Loading System (card on roadmap)

Please start with simple implementations that generally stick to what the card on the roadmap is saying. There will be time to expand the functionality.

 

Also, I don't know if you noticed by the there is already an implementation of this in the repo, on a different branch (https://github.com/UnityTechnologies/open-project-1/tree/Scene-Loading). Did you take a look at it?

 

Yup, I noticed it shortly after writing this post. I'll take a look and see where I can help. Thanks!

 

@CharlExMachina do you need help with that? I was gonna volunteer for it, but since you already have something done, we can work with that, I think

 

Hey! Sorry for the late response. Of course, feel free to contribuite. I just submitted a pull request to the Scene-Loading branch in GitHub, so feel free to check out the code!

 

Always post a link please. https://github.com/UnityTechnologies/open-project-1/pull/31

 

Looking at it initially, I dislike this approach a lot but who knows, maybe I don't know something.

1. How do you find references to a ScriptableObject event?
2. Can you modify respond to an event (adding/removing listeners) without modifying a scene?

 

I think level SO needs to contain list of SO events that would be triggered on enter/exit

 

Still doesn't answer my questions, doesn't scale well (what if you have 50 levels?) and doesn't cover all other events that don't run on enter/exit. I dislike SO events in general, tried them in my project and they were terrible. I would only use them if I had 9 designers and 1 programmer in a team.

With other approaches you can quickly see all references/listeners/raisers.


In this example wrappers can be made to let designers use them in editor (for ex. ButtonLoadMenu) and they give more context than very generic "GameEvent".

 

Can you give better example on how you used them?

 

Very similar to how current Scene Loading is implemented and how it's described on

I remember creating custom editor drawers to be able to see at least current scene references but it still wasn't enough. It's a mess in mid-bigger projects.

 

Hmm, I feel like it's not completely the right way of using ScriptableObjects. I would call this "overmodularity"
SO events and data sharing is increadibly powerful, but we need to handle it smartly, yet simply

Enemies health-bars example is an interesting one, I'll take a sit tomorrow at rethinking these approaches

 

can we do this on discord or something

 

there is already a thread for discussing this and the Unity officials are also discussing this.

 

Hi everyone

I wanted to work on this functionality, but observing the PR mentioned in this thread, it seems it has been merged already. Is there anything left to implement that I could work on here? If not, I suggest updating the card on Codecks, as I came through there.

 

The scene loading system in the main branch seems not to work. I played the main menu scene and pressed the start button, nothing came on screen but no cameras rendering. When I checked, the button was bind to disable the menuelements gameobject and a scripts function. But the next screening wasn't loading up.

 

Where should be talk about Scene related things, here or anywhere else. Because this thread is too old.

 

Hey @Amel-Unity, I just watched your Event and Loading Systems segment of Episode 2, thank you for the presentation.

I would like to ask if you could integrate Unity's Addressables system for loading?

The reason why I would like to see Addressables being used in this project is: I ran into various issues when I integrated Addressables in an existing project (missing features, weird API, bugs). I would hope that you run in such issues too, which then hopefully creates a need inside Unity Technologies to add missing functionality, iron out more bugs, etc.

 

@cirocontinisio @Amel-Unity
Now It's not clear the state and plans regarding development Scene Loading System:
- current code include possibilities to multiscene loading, but work not finish
- didn't explain clear the Scene Loading System concept - It will be continuous space (It divided into separate scene with constant loading the most closest scenes) or "fully separated scenes" with teleportation between them

As a Variant can be use the mixed "Loading scheme":
- the simple scene (beach, forest) load full at ones
- the big scene as the Town - divided on squares and it loads at once only the most closest (which directly connect to current square of protagonist), but it will have sense only if: the scene will divided more than 9 subscenes (more than 3 x 3, because the center will demands to load all 9 subscenes) or the town will have the road around the center town and the town can't be cross directly through center.

May be good idea to create a short design doc where are shortly will described main concepts for all system and links between them.
Because now information is thrown to different places and sometime it doesn't correlate with each other, by example "SceneLoading" - 3 threads on forums, 2 (minimum) open PR.

 

I have made a demo of what I had in mind with having 2 location scenes loaded at the same time. I think it can be integrated quite seemlessly with what we have so far. Just instead of unloading the old location scene automatically after the new scene is loaded, we would have to unload it when the player passes the trigger.

The player would live in the persistant scene or gameplay scene, no need to do any spawning except when the game is started.

To the demo:
- it consists of 4 scenes, colored blue, green, yellow and red to make them easily distinguishable (which of course in the real game we will not make that obvious). I also gave the directional light in each scene a different color but it isn't as obvious in the demo as I thought it had to be (possibly our brain is trained to filter out changing light conditions).
- each scene is inside a trigger collider which is somewhat bigger than the scene. Before the player can get to the scene the player has to walk into the trigger which causes the scene to load. In the demo I load the scene in full view to show the loading. In the real game I would suggest to trigger the loading when the scene can't be seen yet.
- around the loading trigger collider is the unload trigger which is somewhat bigger than the loading collider. Theoretically I could use the loading trigger as well but I want avoid that the scene is loaded and unloaded multiple times in case the player moves back and forth on the edge off the collider.

This is how the scenes and the coliders are arranged in the demo:


- In the bottom right corner of the demo I have placed a top down camera so that you can see which scenes are currently loaded
- You might remember the discussion about giving a far away view of the town in the whiteboxing thread. For this reason I placed a 2D image of the red scene to be seen from the blue scene. Again I am unloading the 2D in full view for the demo but of cause we want avoid that in the real game.

Here is the demo:

Let me know if you would like to try it, then I will make a PR.

 

If we are considering the 2 location scenes approach, we would need to consider this in the whiteboxing in the sense that the scenes' shapes fit together. I would recommend we do this just in case, so don't need to redo the whiteboxing.

Unless you want to provide some different guidance on the shapes, @itsLevi0sa's map and the colliders I made could help with that.

This is not problem for spot light or point lights, but only for directional lights in the case we want different directional lights in different scenes (else we can place one directional light in the permanent scene, which we previously used to create the lightmaps).

With different directional lights it isn't an unsolvable problem, but it needs indeed attention. I would suggest a script that turnes the directional light and changes it's color/intensity based on the player position near the scene border. When the player approaches the scene border the old scene's light will be gradually turned to a medium rotation between the old and new scenes' lights when the player is on the scene border and further to new scene's light direction as the player walks away from the border into the new scene. If you like I can make a trigger prefab to be put on the scene border with a script attached that does it (I guess it takes 2 directional lights as input to be set when the scene is loaded and you would have to be careful not to place it 180 degrees rotated...).

I don't see a problem with the nav meshs.

• For one, even with 2 scenes loaded the ground doesn't need to overlap much to allow walking from one scene to next (actually not at all, but a visible gap due to small inaccuracies would feel weird),
  
• I wouldn't expect the critters to follow the character out of their "home scene".
  
• We can also have one Bard Hare living on the beach and one Bard Hare being in town without the player noticing it's not the same Bare Hard.

 

I want ask something about a script that is related to SceneLoading System. It's about the EditorInitialisationLoader script where i cannot seem to understand what's happening.
what is in that i and j for loop, when it is returning and when it is loading the scene.
Also on what basis is the _isEditorIninitializerMode is set to true or left as false.
And a silly C# question, but the return statement is returning from the loop or the Start method.
Any explanation will be highly appreciated.

 

With "return" you leave the method. This is indeed somewhat questionable here, as this means if one of the scenes that had to be loaded was found, we leave the method - whether we still had other scenes to load or not. It would make no difference if the array of scenes to load only contains one scene - but why do we use an array then?

 

This is a breaking kind of thing. This would not spawn the player too if it returns from the method.
Isn't there a continue keyword in C# like in python to continue the loop.

 

It still works with only one scene - but definitely we would have laid a trap for us if want to load more than one scene at a time later.

The keyword would be "break" I guess, but that would not be the solution either - on the next "i" in the "for" loop the scene path would be different and we end up loading a scene we had already loaded.

I would have had another suggestion, improving readability at the same time with some "isSceneLoaded"-variable and thought I would actually update the code - but looking at the EditorInitialisationLoader in my version it is only loading one scene (no array). And the LocationLoader doesn't have the problem either, it actually has an "IsSceneLoaded" method. I wonder where you found that code that you show above.

 

This one: https://github.com/UnityTechnologie...SceneManagement/EditorInitialisationLoader.cs
This prefab has the script: https://github.com/UnityTechnologie...ayEssentials/LocationEditorInitializer.prefab
The scene ready broadcaster:
https://github.com/UnityTechnologie...ipts/SceneManagement/SceneReadyBroadcaster.cs

 

No it has two scene to load, persistence and gameplay.

 

I still don't think we should load multiple scenes. Yes, the downsides are all addressable, but it's extra work that I don't think we can support. You are basically talking about making it an "open world" game.

We can definitely give the impression that there is something beyond the currently loaded scene, by using a skybox for far details, or mega-Prefabs of compositions of natural objects (rocks, ground pieces, vegetation) for close scenery.

In my head, these mega-Prefabs would also appear in the other scene, and they would act as a "wall" to surround the currently loaded scene and force the player to exit from some specific entry/exit points.

But yes, definitely I don't think we have the capacity to load multiple scenes if we want to finish this game by March

 

Another little argument against loading multiple scenes at a time: in the current whiteboxed map, there are 800 objects. I set the Static flag on all of them, and it took something like 10 seconds on my machine, which is pretty good.

Now, 800 objects are nothing compared to the amount we might have if we decorate the island the way it should be. We could get to 100.000. Technically that's not an issue, one might say, since we load and unload scenes, but there will be instances when we want to have them loaded at the same time. For instance, when baking skyboxes or baking lightmaps.
This might easily get out of hand and make it impossible for some members of the community to work on the project in that sense.

 

There is no doubt that the high number of objects sucks on performance more than polygons (Take it from someone who tried to build cathedrals stone by stone). Therefore I have made myself a script that joins meshes, but it is quite easy in to join objects in Blender as well (at least if they share a texture). We should try to merge the static geometry whereever we can.

 

So if you want to load all scenes at a time how does this speak against loading 2 at a time?
BTW, don't we possibly already have loaded 2 scenes at a time sometimes anyway, if we unload the old scene async? At least if we load and unload scenes at different times, those two processes will not compete with each other for CPU/IO/memory bandwidth.

 

It's not that simple. Joining meshes means they have to use the same shader, or that the tool needs to assign the correct materials to each submesh. Even then, some shaders rely on object position for... reasons (did you ever watch this episode, with the position-based random colour shader?)
In fact to solve that, we decided not to batch as static vegetation, but to use Instancing on the shaders.

Are you talking about Location scenes? We do load async and additively, but only a new location and unload the old location. It was never the plan to load more than one location at once*.

* the function still takes an array to support the loading of the persistent scenes needed, but again, never intended to load multiple Location scenes.

In any case my comment was referring to "have them loaded at the same time" in the editor, not during gameplay.

 

I watched the episode, I used it on the bushes in the jungle. I tried to use it on the trees as well but as the trees are not baked so far but the trees are a prefab with consists of trunk and leaves, it didn't work.

 

One word of caution with this, baking meshes, etc.: some vegetation objects currently don't have the Wind shader on because not all of them have painted green channel on the vertex colour (which is the one driving the motion in the wind), it's something I always wanted to fix but I never got to it!

 

I'm curious about how to approach building an open-world game.
If we were to make it an open world, what need to be load and unload on the fly?
Besides lightmap and navmesh, are there other things that we need to handle?

 

We're definitely not making it an open world.

Other things to handle? Plenty. One example: sounds, if you have an AudioSource that references a sound then it is loaded into the RAM. So we'd have to carefully manage memory and make sure to unload any object that is no longer needed.
Skyboxes: we'd need some kind of blending, or a system of layers? Not sure. Or no geometry baked in the skybox, just sky.
There's a lot of considerations, many of which would be very connected to the design of our game!

 

Unrelated to the above:
As I'm working on refactoring the level loading to include Addressables, I'm in a bit of an annoying situation for what concerns the "hack" which we have in our locations, to allow pressing play at any time from any scene.
Before the refactor what it did was to load the additional needed scenes (PersistentManager and Gameplay in a Location, PersistentManager in a menu) by iterating over all open scenes and checking whether those scenes were already opened. Very hacky and now harder to do due to some restructuring.

So: since we have the Scene loading tool @canchen_unity and @dotsquid made, can't we do one thing: if you click on a scene which is a location, we also open additively the appropriate scenes to make it run (PersistentManager and Gameplay) so that when you press Play the scene runs - not because of a hack - but because the appropriate scenes ARE actually loaded.

Is this good, is it bad? Any drawback you can foresee?

 

I finally managed to merge my Addressable-related changes into main. In the effort of keeping the ability for anyone to just press Play in any Location scene in the editor, I had to rework the system a couple of times. In the end, I changed less code than I expected.

By the way, all that I explained related to Addressables in the 8th episode of the Journey still applies. (in fact it's a good primer to the text below, if you haven't watched it)

For anyone interested in code, here's what changed: you will notice a few changes, specifically in the scripts

SceneLoader.cs

(the one who loads scenes, located in the PersistentManagers scene),

EditorInitialization.cs

(now called

EditorColdStartup.cs

) and in the

InitializationLoader.cs

, which is the very first script that kicks off in the game, in the scene called Initialization.


-- Normal flow



Like I said in the live, Initialization is the first scene to be launched and also the only one now contained within the BuildSettings. This means that it is packed with the build itself (contrary to all other scenes which are now in bundles).
This scene contains a script which essentially does this:
- Loads the scene PersistentManagers
- Requests

SceneLoader.cs

in PersistentManagers to load the main menu
- Unloads itself


-- "Cold Startup" (aka press Play from any scene)



This behaviour is very much what I ended up putting in

EditorColdStartup.cs

, so now if you press Play from any Location scene you get that

EditorColdStartup.cs

:
- Checks if PersistentManagers is already loaded. If yes, it means we're "following the flow". If not:
- Loads PersistentManagers
- Requests its own loading (this has to be provided specifically by providing the right GameSceneSO in each scene)
- Immediately unload itself
- PersistentManagers will load the requested scene and, since it's not present, also Gameplay


--

Maybe there is a better way with less code / less setup, if you have ideas please feel free to suggest them. Just keep in mind the requirements: scene loading/unloading with the PersistentManager always present, activating the right scene once loaded, being able to press play from any scene, the SceneSelector tool needs to keep working, and all of this needs to work with Addressables

 

@cirocontinisio As I said before, I would like to update my whiteboxing to work with the Addressables scene loading system (Which became much more urgent as the whiteboxing was broken with the recent changes. What's the point of whiteboxing if nobody can play it?). Before starting I have two questions:

• Are you or is someone else working on the same thing? Should I better keep my hands off?

• I case I go for it, I guess have to create an alternative initialization scene which goes into the build settings. This will then load an alternative main menu scene (set up as Addressable) which after pressing start takes the player into the whiteboxing beach scene (set up as Addressable). In the beach scene I would then place colliders which "onTriggerEnter" take the player to glade etc. Would you agree?

 

@cirocontinisio Contrary to what you said in the livestream I think it would not be good to have all the location scenes in one asset bundle. Wouldn't it use the same amount of memory as if all scenes were open at once?
In the lifestream you were mentioning that if e.g. a rock is used in several scenes, it will be loaded several times. So I guess it might make sense to have an additional asset bundle containing the common prefabs like trees and rocks (maybe the shaders too), whereas the scene specific prefabs, like e.g. the boat and the shells on the beach would stay with the scenes like this:

I would expect the common prefabs will be loaded after the player presses start and never unloaded. I guess we need to load them explicitly and keep a reference to them. Else - I would expect - the common prefabs will be "referenced only in the beach scene" and unloaded if we unload the beach scene before we load the glade scene. If the common prefabs would be loaded and unloaded each time the common prefabs asset bundle would not help to reduce the loading time.

"border prefabs" I named arrangements of commons prefabs that serve to partially block the view between adjacent scenes near the scene borders (behind the border prefabs there would be a 2D image or skybox). I think it would be more efficient to have the same prefab in adjacent scenes if they are only loaded once and even more important they would be guaranteed to be consistent between neighboring scenes.

Since "border prefabs" preferably use only common prefabs they would not have a lot of textures and mesh data but I guess they would have/could have lighting data. Since they are used by exactly 2 scenes we can decide based on the size whether we want to keep them all in one bundle or split them - maybe we keep them common at first as we would need additional logic to load and unload them.

 

Yes, totally. I thought I had mentioned it in the livestream: the current bundle configuration is just for the sake of simplicity, but it will make sense to separate the scenes into different AssetBundles.

In any case, they can stay in the same Addressable Group but can't use the trick with the folder containing them to be marked as Addressable (which we use now). They will need to be included in the group one by one - and for now it doesn't make sense since we haven't created the set of final scenes yet.

So yes, consider the current asset organisation in Addressables temporary!

 

Small update to say that I've pushed some changes to

main

so that now, when randomly pressing Play from a Location scene in the editor, we don't reload said scene but we just load managers on top.

This fixes an annoying behaviour we have had for a month that required you to save the scene before pressing Play, something really not optimal for quick tests. Thanks a lot @TJHeuvel-net for pointing it out!

As part of this, I've removed the code around loading an array of scenes, which was unnecessary. Now every loading behaviour only includes one scene reference.