Okay, dumb question: Why scenes?

This has been nagging at me for a while and I've got to ask: why do people use multiple scenes?

Like, I get using a blank scene to prototype. But why do games reload everything all over when they could just as well load up the objects as needed?

What's the benifit of doing a wipe on everything and reloading large swaths of them?

Is is a memory thing?

 

Easier to manage? From a design standpoint and also memory. If you just use one scene you'll basically still be writing your own version of a scenes manager. You'd need some kind of a structure to serialize the levels you design and so on, which would then be basically your own custom scene format. I'm not talking about procedurally generated games of course.

 

I prefer to use my own system so I can control what parts are unloaded when, so I can let the user know what's going on and maybe even let them continue to play in a small area while new things load in. It's also the only way to do procedural games.

Design your scene as you would if you were going to use the built in scene manager...
Parent everything in your scene to a 'root' empty...
Make that empty a prefab...

That's the most basic way to go about it. When you instantiate a level, store the reference somewhere so you can destroy it & instantiate new levels later. The way I go about it for slightly larger games is to have multiple references for pieces of the game. Arrays for enemies, level geometry, interactable items, etc. I've even created a simple 2D game that iterates through a list of things it needs to spawn, instantiates just a couple, then returns and continues on the next iteration. This lets the use continue to play while the world is built ahead of them.

This works very well for UNet multiplayer as well.

Because when they designed this system to make game dev easier, unloading and reloading everything is the easiest option to use that is acceptable for the widest variety of games And there's also that "don't destroy" function you can put on the few things you want to keep in your scene... but then you'd have to track it and destroy it yourself if it's not supposed to be in a later scene.

 

Every map/level/scene we have is dynamically constructed, so we only use a single scene with our core game code attached.

I use multi scenes a lot to test variations of assets/content on device. Also many scenes in our content projects. So, we use them a lot, just not in the game.

 

I usually open a new project, write a module, export said module as a unity asset package into my 'modules' folder, and then delete the temporary project. When I'm writing something new I don't like having my asset folder cluttered Though I suppose I would do the same as you if I was testing something that had to interact with a lot of assets from the main game.

 

All scenes do is load initial resources, so you don't have to load them "blindly" by script. If you were doing it oldschool and load all resources via script, you'd still have different sets of loading commands for different parts of the game, one way or another you'd still have "scenes". Unity just cuts to the chase.

 

If you are building a simple game with a level concept, then scenes are ideal. There is little from my menu scene that needs to persist into my gameplay scene. What's the point if writing a ton of custom loading and unloading code?

The main benefit to scenes is development time and stability. Not everyone has a team of engineers in the back room like @zombiegorilla.

 

I actually think a lot of developers do indeed use one scene and load/unload as they need it. That's what I do in my game as well. As others have said though, for a gamey game that has levels, using separate scenes and putting don't destroy on load for your manager GameObjects would be a really nice clean way of doing it.

 

And here I was all this time thinking I was the odd one out and doing something "wrong". I use one master scene that loads or removes things as needed. Works for me.

 

With multi scene editing due in 5.3 (but could be pushed later) enables Unity developers to better manage scenes especially for open world games where you might want to stream things in, or perhaps you just find it easier putting all your ui elements in one scene and loading those in and out on demand and so on...

It's just organisation.

 

So... unity is getting partials / includes?

 

You'll have to see.

 

For the record, we let our engineers sit with the rest of us, and make great efforts to treat them like normal people.

But the reality isn't so much about resources, more one of design. Our games are all builders/dynamic, so there isn't much practical use for scenes in that sense.

 

Sounds like someone wants me to speculate. That's dangerous.

 

I sort of mentioned that one

 

Wow! I'm really glad I asked about this. Thanks everyone, I guess I had some major misconceptions about how most games handle loading.

@superpig - Thank you for the links. I've read over most of the manual and script API, but I think that when I went over those sections they initially went over my head. I will give them a second reading.

EDIT: Okay, I just re-read through it and I do recall this stuff. I just haven't gotten a chance to apply it.

 

If you code in raw OpenGL or DirectX, the point of reference is Camera.

So, a scene is a collection of memory objects that are loaded in memory that made visible or invisible to the camera. In Unity, they make it all easy by making a scene for you without coding.

> why do people use multiple scenes?

It's easier that way. You don't need to code custom loader and unload code for each scene.

If you are writing a large game, you'd want to write a custom loader
- it is hard to share a nested prefab across 20 scenes,
- you want consistency across scenes instead of using prefabs.
- you want to do run-time culling and loading of models.

 

Pretty much this. It's not always useful to group objects together into scenes, but when it is I figure I may as well use what's there.