Currently our loading screen is part of the website. To ease cross platform development the
screen will be ported and part of unity-renderer.
Website enables or disables the Loading Screen through some flags in the
global state: show = state.showLoadingScreen || state.waitingTutorial.
These flags are set from multiple places within kernel. We can differentiate three different flows working with the Loading Scene.
In a normal signin process, the showLoadingScreen flag is modified in this order:
1) renderer\sagas initializeRenderer.setLoadingScreenVisible => true
2) dcl.ts teleportObservable.setLoadingScreenVisible => true
3) dcl.ts renderStateObservable.setLoadingScreenVisible => false
4) loading\sagas initialSceneLoading.finish => false
In the SignUp process, the showLoadingScreen flag is modified in this order.
1) renderer\sagas initializeRenderer.setLoadingScreenVisible => true
2) dcl.ts teleportObservable.setLoadingScreenVisible => true
3) session\sagas showAvatarEditor.setLoadingScreenVisible => true
4) dcl.ts renderStateObservable.setLoadingScreenVisible => false
5) session\sagas showAvatarEditor.setLoadingScreenVisible => false
6) dcl.ts renderStateObservable.setLoadingScreenVisible => false
7) session\sagas signUp => true
8) loading\sagas initialSceneLoading.finish => false
9) website.ts loadWebsiteSystems.userAuthentified.ensureRendererEnabled => false
*The waitingTutorial is modified in this flow as well. It handles the
edge case: User finishes the signup process but the world has not been loaded yet.
When teleporting, the showLoadingScreen flag is modified in this order:
1) dcl.ts teleportObservable.setLoadingScreenVisible => true
2) dcl.ts renderStateObservable.setLoadingScreenVisible => false
Notice how most of the time the flag is changed reduntantly. In any case I haven't found any conflict in the way they are modified.
The Loading Screen will be ported to Unity as a HUD.
kernel will maintain the ownership of the visibility of the screen. Now, instead of
changing the showLoadingScreen flag, kernel will send a message to
Unity with the relevant information (LoadingScreen: on|off, IsTeleporting: on|off, Stage: ESTABLISHING_COMMS | COMMS_ESTABLISHED
| EXPERIENCE_STARTED...)
The website Loading Screen shouldn't be needed anymore. Currently we are
dispatching some events listened by the website about the renderer being loaded.
Although website is reacting properly to this, it's a never reached state since we
don't show the player the Play or Enter as guest buttons until the
renderer is ready.
Therefore the whole Loading Screen can be removed from website.
The need of a preloading stage (while loading Unity) is out of this ADR scope. It
would maintain the current implementation of a spinner hiding the
Play/Enter as guest buttons.
The implementation in Unity is pretty straight-forward. A HUD reacting to the kernel message to show the screen while maintaining all the features of our current implementation (cycling tips, animated progress bar...) should suffice.
Cross platform development can reuse this new loading screen flow almost entirely.
A first step into decoupling the experience lifecycle from kernel to end up moving parts
of our current loading/sagas responsibilities into Unity.