Some feedback on MSE

The new MSE stuff in 5.3 is really awesome and it's good to see that unity is caring more about streamed games. I worked on Ori and the blind Forest where we had rolled our own solution for level streaming and multi scene editing - it would be incredible if noone has to go through that pain again

However I do have some feedback on the current system. This is taken from some tweets I send (slightly tweaked for forum format).

1. There needs to be an EditorSceneManager.LoadInPlayMode(Async) or OpenSceneAsync. The old LoadInPlayMode API's seem deprecated with no replacement. Ideally the "must be in build settings" constraint would just gone entirely in play mode.
Right now, streaming scenes in the editor is horrendously slow (it's just synchronous). I understand that given how asset compression does it's thing it'll always be slower in editor, but making it 100% synchronous is really unfortunate. It just means that playing any type of streamed game in the editor is a terrible experience.

2. SceneAsset class should be public - finally allows for (a sane way to) custom inspectors & importers, yay!

3. Need some method to store metadata with the scene like the bounds & other params used for streaming (and be able read this at runtime). There were some similar request on the forum already. It's needed for a wide variety of use cases. Heck, in a way unity already does this with it's scene based lighting settings etc. Now it needs to be opened up to the user.

4 Ori had an explicit SceneRoot GO.It's a great place to put manager scripts, and do "scene wide" stuff. The current MSE system has a root sort of kind of, it'd be great to have an actual GO (-like) as the root. Metadata could also be attached to this root. Right now selecting the scene root just shows nothing - which is a shame. If the metadata system as above is implemented it could perhaps all those settings here.

6. MSE gets unity closer to scene == prefab. Biggest thing missing is loading a scene at a certain offset. This is again where an explicit scene root would help.

7. Similairly to prefab nesting - "parenting" scenes in some way would be really useful, both for structural reasons (splitting scenes in geom /lights/ ...), and for including common objects (managers, player, ...)

8. I feel like the scene root should always be shown in the hierarchy. It would help with discoverabilty of MSE in the first place, and just generally be more consistent. Also as mentioned this root should be used to at least show relevant metadata.


I know it's beta 3 already but hope some of these thoughts are helpful nonetheless

 

Hi Steen, Appreciate the reply!


1. Fair enough about the adding scenes, it wouldn't bother me but might catch someone off guard.
However, biggest point here was that right now there is no sane way to play streamed games in the editor - which is a major flaw if unity is serious about supporting streamed games. Right now there is no way load to async load stuff in the editor. Will that be addressed at some point?
Additionally, again about adding scenes to the build settings - how about editor only API to load scenes that aren't in build settings async? For people who know what they're doing this could be of help. In Ori we almost never made full game builds, at least not locally. Problem is that if you don't have all the scenes in your build settings you couldn't actually play the game in the editor. To solve that we had some script that ran on entering playmode finding all scenes and adding them to the build settings etc. I'm sure more people have this problem and for advanced users it really would be of a lot of help to have _some_ way to just load scenes without coupling that to what's going to be built. Playing in the editor and building really should be seperate.


2&3: Awesome

4&8: Which is why I'm saying there should be! I understand that the scene header is just a simple GUI thing atm, but I feel like it would make sense to make it an actual root. See 4&8, and really 2&3&6&7 too - all of these would be greatly simplified if the "header" thing would be an actual root like you'd expect instead of just a GUI thing.

6: Yeah I imagine that's ways out before it's fully integrated. I think it's pretty close to a point where people could experiment with this though. If point 6 is adressed I could see myself using this for some of the stuff that is in ginormous prefabs right now (think: "InGameGUI.prefab", "PauseMenu.prefab" that kinda thing). It'd be a shame to exclude all those already potential helpful use cases because of a relatively minor road block.

7: See above, but yes that one is much trickier One day, one day...

Thanks again!

 

"It is actually to ensure that the game you are testing in playmode in the editor also works when you build a player. If we allowed you to load any scene during playmode you could be testing and thinking "this works great". Then you build a player which can take quite some time only to find that you forgot to include the scenes and your player does not work."

I suppose you've never worked with Asset Bundles then, because this is exactly what you have to contend with if you want to simulate asset bundles in the editor. Go look at Unity's own example AssetBundleManager, which simulates loading levels in the editor via EditorApplication.LoadLevelAdditiveInPlayMode.

If all scenes have to be in the build settings, then basically MSE doesn't work with Asset Bundles, as they will get included with the build defeating the whole reason for using asset bundles in the first place. If MSE doesn't work with Asset Bundles, then it's basically a useless feature for any project we're ever going to work on, useless for any webGL game which needs to have a very small app size to be viable, etc.

 

I just want to chime in and say that having a scene root object should be heavily considered. Even if it is a hidden game object that is injected into scene files starting in 5.3, I would highly recommend it. I know that is not how the scene files worked previously, but the editor and the game not being able to determine which scene the object came from is a headache that I feel should be handled by the editor. The big UX issue for designers is that there isn't any way for you to notify users that they are dragging an editor reference from one scene object to another scene is just a recipe for designer disaster. I hope you consider it if not for 5.3, for 5.4.

Thanks!