SceneMode.Additive : Is it just too much of a pain to use?

Hi All,

I'd not really used SceneMode.Additive before in anger: is it just me or is it just too much pain to be worthwhile especially when combined with Singletons? Or am I just probably not doing it right? Sorry I know that's hard to answer without code but it's more of a generic question than anything.. eg My thought process for a real simple game is...
A Main Menu Scene with a Play button.
Play Button Loads a "Game" Scene then Additive Loads "LevelX" Scene.

It works but it's seem it's a massive PITA in many ways.

I wanted it because I wanted to do modular levels (eg easily load levels while keeping all the real game mechanics in place), eg on a simplistic level keep eg 'GameManager' and 'SoundManager' singletons running etc between level loads. Are there better ways forward? better patterns? Better to look at ScriptableObjects?

Or best to just stick with something like used in the 2D Kit example.. eg Have a template Level with all the game mechanics in that you build upon for each separate level. I come from a background of modular reuse and that just doesn't sit right.. feels more like the old 'CGI includes' from back in the early www days rather than modern modular way forward.

Any advice / pointers to decent examples very much appreciated Thanks

Cheers - Mark

 

Scenes by their very nature assume whats inside them is going to remain, for the most part, static and unchanging after the game is built. The only real benefit of using scenes for modular levels I can see is bake lighting for visual fidelity. Additive scenes is advertised as allowing a big team to split the game into parts for each specialized person to work on what they need to. Even then the split depends on the team. You can split by area and have each level designer go crazy in their own designated space. You can split by job, like there's someone working on terrain, someone working on lighting, someone working on props, each in their own scene which comes together to make the game whole.

The way you have described your design feels like you want splitting by area, but maybe you intend to reuse the objects in the scene in a different position? You never really explained what problems you are facing so lack of scripts aside, proper advice will require more critical information. Like, are the objects in the scene not where you want or expect them to be? Are you annoyed by the huge amount of scenes? etc etc.

 

I'm not sure what you're having difficulty with but all my games are done with additive scene loading.

My typical scene for play mode might have:

- a loading scene (canvas set to render on top of all else)
- the UI scene (score, HUD, etc.)
- the PlayerController scene
- the "content" scenes: the actual level stuff, which might be further broken down:
- the static level data
- the enemy spawning overlay (matches the level precisely)
- the lighting and/or weather scene

Those are all loaded additively and know about each other through loose coupling (usually using my Datasacks package) or else just a GameManager type thing. Once everybody reports that they're loaded and ready, the loading screen is destroyed and off you go.

The other great thing is that with larger teams, breaking your scenes up keeps everybody out of each other's hair a little bit better.

 

What issues did you have? Why do you mention Singletons specifically as being a problem?

Yes, keeping content and functionality split from one another is a great idea, and splitting them across scenes can be a neat way to do this. I wouldn't set out make a non-trivial game without planning to do this.

Before you start making content in earnest, make sure you understand the architecture of your game. What will the key classes and objects be? How will they communicate? How will they get hooked up to one another? What scenes will each bit be in? What will be persistent and what needs to be (un)loaded at runtime?

 

Truer words have never been spoken. You nailed it @angrypenguin

 

Having multiple scenes open and singletons are two independent features that have nothing directly to do with each other, so whether they work well or badly in conjunction depends on exactly what you are doing with them.

 

Additive Scenes are a bit of a pain, but all-in-all are worth it. For Managers and singletons, the old way is DontDestroyOnLoad. That works, and people have explained it lots. But having all-level Managers in a base scene, with the second scene as logic and stuff for that exact level, is better. Various issues:

o You have to train yourself to stop double-clicking a scene to switch to it. You probably have a base scene loaded, with the real scene added. You have to remember to "RemoveScene" on the active one (not Unload Scene -- that keeps it but hides everything in it). The right-click OpenSceneAdditive on the new one. But that becomes a habit after a few days.

o New objects are added to the first scene. Even if you have the second scene selected. You'll have to either manually move them (which isn't too bad since you were probably going to move them anyway). Or, I haven't done this, drag the real scene up above the base scene.

o The lighting can be mysteriously weird. It usually fixes itself, or not.

o Instantiated objects are added to the base scene. The means they won't auto-vanish when you unload that scene. You'll have to Destroy them yourself. Making the new scene into the active one (SceneManager.SetActiveScene) fixes it, but it breaks the lighting again! This may have been fixed.

o Your code needs to use a coroutine or some other delay to unload the old add-on scene asynch, then load the new add-on scene asynch. This is more complicated than just loading a scene. Reloading the current scene is a different problem. But it's not too bad, and once it's written it's no problem at all.

 

I strongly recommend writing custom Editor functionality for this kind of stuff.

My scenes have an Editor-only "prerequisites" object in them. When loaded, if their prerequisites aren't present then the appropriate other scenes which provide them get loaded. Anyone in the team can just double-click any scene to load it, and it'll set itself up ready to go.

It's the "Active" scene that stuff is added to by default. Right-clicking and selecting "Set Active Scene" on the relevant scene's header changes this. However, as you say later, this can have side effects.

This is just... I really can't understand why it is like it is! If someone in my team left something like this I'd tell them that to finish it.

In our project we often get errors about lighting being different in the various loaded scenes, and as far as I'm aware there's no built-in way to fix that, you just need to copy settings from scene to scene until they're all the same. Even then, there's not a convenient way to switch between lighting settings for different scenes, since the Lighting panel (IIRC) only shows settings for the Active scene... so you need to switch scenes and copy settings one at a time.

Thankfully, someone wrote and shared an Editor script to solve most of that, too. I'm pretty sure I've been using the one by @Peter77 in this thread., which looks like it's been updated with better multi-scene support since I grabbed it. Thanks, @Peter77!

 

Some extremely useful feedback and information, thank you ever so much to you all for replying. This sort of info is golddust to anyone not familiar with Additive Scene workflow. I'll get back in the next few days on some of the comments and will answer couple of questions

@KurtDekker... you have a new fan.... datasacks is pretty awesome, but more importantly your games are.

@angrypenguin Great input.. thank you. Although I don't have issues with lighting/additive scenes in the latest project I've certainly got gaps my knowledge I'd like to fill.. especially around lightmap swapping on the fly so thank you for those links. + RE: the advice: "make sure you understand the architecture of your game"... of course.... 100% Hence the thread infact.. although I've been developing for a very long time I continuously want to learn more and be better, hence the thread

 

Yeah, I agree: it's hard to generically capture all the awesomeness that is possible in Unity3D workflow. I still discover new and amazing ways of saving time, making things more reliable, etc. I struggled early on when I was getting started about "Come on people, give me a clue about how to make this easier!" and it slowly comes. Just be patient and you will get more and more comfy and have more of that good gold dust caked right in your brain case to use in just the right moment when you're working in Unity. Unity is just AMAZING that way.

Hey, thanks! I'm likewise a huge fan of seeing your above-stated phrase "I continuously want to learn more and be better..." that is the best way to be! Welcome!