What's a good tutorial for using multiple scenes?

Getting Started
1

I’m new to Unity, but I do have some programming experience.

What I’d like to do as a learning project is a 3d turn-based strategy game (very simple at first…). It’ll have a main menu, settings, load/save, and different environments (e.g. towns, indoors, maps, etc.) I can create objects in Blender and add them to a scene, and I’ve experimented with programmatically creating game objects and associating them with C# objects/containers/code.

What is the best way to use the scenes in the Unity editor? I’d like to pick an approach that will scale well so that I don’t have to recreate/rewrite the scene management stuff later. Will this work:

  • Create a mostly-empty “root” scene which is the default scene. Then add other scenes as needed programmatically.
  • Create a separate scene in the editor for each major aspect of gameplay. e.g. one for walking in a town, one for battle, one for shopping, one for settings…

Any thoughts or advice? Links?

Here, under Known Issues

“Cross-scene references are not supported but also not prevented.”

Does this mean scripts attached to objects in one scene should not directly access another scene’s objects/scripts? If so, how do I make them communicate indirectly?

2

Hi there

There is no “best” way to use scene in unity, you can use scenes in many diffirent ways and people tend to do it diffirently depending on the sort of prject you 're doing. If you’re just starting you just put everything into one scene and make a system for loading in a level from another scene later on, or just stick with one scene for everything- its easier to prototype that way.

If you want to make cross scene referances to things, you need to “connect the objects” when scenes are loaded.

/K

1 Like
3

One thing to understand quickly in game design, is that there is no best way. The ability is all in manage things as you see best fit, for that specific case.

Unity load one scene at time; unless you load dynamically, which is not something that you want to do in your first game. As general case; you have a starting scene, which has a main menu, and such; from there you may want to load another scene.

Start with one; create prefabs and load them in the scene. There is no way to design a game just on paper, since it is an iterative process…you may find that what you want isn’t working, only when you actually run the prototype.

Regarding cross-scene; usually you never access objects in different scenes, because that object once the old scene is destroyed, won’texist anymore. Same for a scene that is not loaded yet…you get an exception because you try to access something that hasn’t been instantiated again. You may carry objects using singleton; but it is confusing when you have a complex game.

Seems an oxymoron, but if you make 3 simple games (pacman, marble madness, pong), and then try to make something more complex; it will take you less time, compared to start directly with the more complex project :slight_smile:

1 Like
4

Thanks for the responses! This first project is for experimentation and familiarizing myself with Unity. If something gets too complicated, I’ll just pick a simpler approach to get it working and move on to the next task. I do know C# and have watched/followed a number of tutorials. In this thread, I just want to pick an approach to dealing with multiple scenes so I don’t have to completely rewrite/redesign this code in the future.

I had already begun laying out my GUI elements in various scenes; at this point, trying to fit all the different windows/menus/toolbars/hud-elements into one scene in the editor would be a huge headache - very confusing, and just not enough space. Individually the windows are very simple; there’s just a lot of them. And I’ve been stuffing (obvious) placeholders in most fields so that I can focus on only the most basic functionality of each part of the program, not try to do everything at once.

Guess what I was looking for were examples about how to make full use of the scenes’ loading/unloading of assets and the modularity of having things stored in separate scenes. That way I don’t have to worry about name conflicts, and each scene can be created for a specific purpose and be largely self-contained. Distributed complexity usually means less headache, as long as the design is sound.

For the design, I’m thinking I could create an object called SceneManager in the root scene, which will be the single connection between the root scene and its sub-scenes. It will contain methods for loading/unloading sub-scenes, communicate with the WindowManager to track which windows are open/showing/have focus, and communicate with the InputManager to determine e.g. which sets of hotkeys to use.

And each scene will have a SceneImplementation object that implements some common methods and serves as a single connection between its objects and the root scene’s Scene Manager.

So if the user decides to open the settings window, the SceneManager would do basically the following:

  • Tell the WindowManager/InputManager to save their current state.

  • Load the Settings scene, if not already loaded.

  • Tell the WindowManager/InputManager to display the settings scene’s windows and route input there.

  • Call the Settings scene’s SceneImplementation.OnDisplay() method.

  • Wait until the Settings scene has received an appropriate input event.

  • The Settings scene will call a method in the root scene’s SceneManager to notify it of results/changes.

  • Apply changes if needed.

  • Reverse what was done in steps 3-1.

I’ll keep all the sub-scenes as simple as possible - probably just one setting/value for example - just want to confirm that the design is sound and will work as expected later when I write the “real” settings GUI. Basically my approach is to create a tiny proof-of-concept (or IOW the barest possible implementation) for each major portion of the program, leaving myself stubs and notes for later expansion.

5

This is why you create prefab for your elements, and load them at runtime.
Usually the first layout is what the player see on screen 99% of the time; any other feature or functionality, that require you to open a different panel/view/item, will be loaded at runtime.

I did tackle the main menu in a very simple way: one canvas for each screen that I want to display; then you hide/show the canvas with the alpha property in the canvas group.
Another way that I did use, is labels that you overwrite with new content; so you have one canvas, a set amount of labels and you change text at runtime; based on which option you want to show. You can wire at runtime the onClick event for each button, so it is a breeze to dynamically set the UI.

This is partially true; 2000 functions in 100 objects are as much as a headache, compared to 500 functions in 5 objects. It all depends from your design, and the complexity of the interactions. Which means that it apply on a “per case basis”.
Once your product grow, and you will feel the need to print a UML of your objects to figure out interactions, you will see that distribute complexity to bring sanity, is just a dream that we all had at one point :slight_smile:

Good start; make it a singleton, doNotDestroyOnLoad and be sure of what you put in it; I would suggest to implement a MVC pattern, although with Unity as is, you will have to jump through some hoops.
Keep in mind that more scene you have, more memory your app require; more time you spend loading, less time you spend doing something; you want to strike a balance. Some people would just cringe, hearing of “one scene per panel” approach, but you are experimenting, so the best way to learn is to do things and see pros and cons of a solution.

You want a GameManager BTW, to save states; keep things separated…each manager does one thing only: scene manager deal with scene, UI manager deal with what you push on screen, game manager deal with load and save of states.

Give it a try, see what happens; once you tried few solutions; you will start to see on your own what goes well and what is not; and your questions will become more and more focused :slight_smile:

6

Hey, you know i thought a lot about this as well, and i totally agree that it’s just like your code, which should probably be as ‘readable’ (or in this case, easy to comprehend the flow of, build upon, and edit, etc) as it can be while being as performance friendly as it needs to be.

that being said, i’ll offer my own way of doing it at this point:

for any kind of game that is primarily in one perspective/mode of action/mechanics style such as a simple game, rpg, or one big map game like sotn, super metroid, or terraria, i would use one single scene for everything, then you would just have things like the title screen or credits etc each with parent objects turned into prefabs that can be loaded up with loadasset just by having a string stored. create parent objects for each segment of the map in big games including as much area as you can handle having loaded while also being able to load up the prefab parent of any other area the player could possibly be about to enter into, which can be done in the background as they approach a way to enter into that area, move it into position and setactive it (keeping track of all the active ones in an array or something). unless the player is walking into a portal or teleporting into another physical coordinate, or something, you don’t have to interfere with the player’s movements at all, they just walk right through. if they are walking through a door and you want the outside/inside world to disappear as the other appears, you just deactivate it and activate the other, which probably won’t cause a hiccup, and of course leave that area loaded until they can no longer just walk back through into it before you reload it. if the inside/outside world coordinates don’t match up or if the player is walking through a portal into another area, moving them into the necessary position can of course still be done without a hiccup. i have exits fade into black for example in a 2d game, and there is an object hanging out into the black in each area that has a script attached that just ontriggerenter activates one area and deactivates the other in the blink of an eye. of course there’s nothing stopping you from using a transition if you want. aside from this i would only use a separate scene for complex mini games or periods of play with totally different mechanics or perspective like the motorcycle/sub battles in FF7 or fishing in breath of fire 3 for example, because in those cases you aren’t going to be using almost all the same stuff minus change in only terrain or npcs etc. if the map is so huge that you’re concerned about storing a massive string array, they could also be loaded up in sections of adjacent groups of areas, if that makes sense.

now for a crazy scinematic game like dragons lair or phoenix write or a game with totally disconnected levels like goldeneye or katamari, to me at least, it makes more sense to imagine and separate them into difference scenes (which could also be broken down as described above if necessary), because they are actually different scenes with quite possibly more varied content between them, and more easily visualizable as a series of chronological scenes like a movie.

hope this helps anyone, feel free to ask any questions about making these things happen lol

7

There is a Live Training video that steps you through creating a scene selection menu though it predates the Scene APIs.

https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/creating-a-scene-menu

There is a blog entry with a video but it’s only a few minutes long.

https://blogs.unity3d.com/2014/08/04/multi-scene-editing/

Outside of those and other videos on sources like YouTube I’d just sit down and start experimenting. It’s the approach I started taking once I realized that the bulk of tutorials are aimed at beginner topics and not the subjects I was interested in once I stepped beyond the basics.