I’m an experienced dev playing around with Unity, and I have been struck by how difficult it is to manage scenes programmatically. I do not want to stock scenes with assets as they will be dynamically determined and I will need to populate nearly everything in them at runtime. I’ve found that you can create new scenes programmatically, but I’m running into the following issues.
Scenes require initialization logic. Unity does not seem to support scripts for scenes, so if I want to create some sort of initialization or management logic for my scene, I have to create some blank object and attach a script to it (or attach it to the camera, which I think I like even less).
I need to create scenes that can act upon input parameters - for example, I want to create a new level that generates terrain based on some input. It appears that you cannot pass input parameters in scenes in any way. The two solutions I’ve seen are to create an invisible object that does not get deleted with properties you want attached and to find that object in your new scene, or to create a static class that manages global variables. Both of these are paths to hell, the second moreso than the first.
Essentially, I’m looking to do something analogous to what you can do in ActionScript by instantiating a new MovieClip - but scenes in Unity are far different than MovieClips.
Is there a solution to my problems above that isn’t so hack-y, or is it really this hard? Am I misunderstanding some fundamental design pattern that would make my proposed design unnecessary?
Tell me, why would you want to create a scene, if you’re going to populate stuff in it?
A scene is ONLY a container of GameObject. You can load them or unload them, and you can load them on top of each other.
In the end, what you’re saying is, you only need a single empty scene and nothing else, since you’re going to create stuff in it anyway.
In that case you don’t need to, and in fact shouldn’t, be using scenes at all. Well, except just the one, of course. That’s what I do frequently.
That seemed weird to me at first, but now it seems almost nonsensical not to do it that way. Like the scripts almost have some kind of physical connection to the “space” they are controlling. I find I visualize the logic more easily that way.
Frankly, I still think the way Unity handle the scene exposure to the managed side to be very lacking and a terribly flawed design. Just look at the dirty hack they did to make AssetBundle streamed scene. Build a scene by string? What the…
In most engine I’ve worked on, a Scene (or map, or level) can also have “Scene Components” on its own that define parameters and behaviour unique to the scene itself. Let’s say you load a scene that has some specific wind, fog, skybox, etc. setting in it. (Or being underwater, in outter space) Logically, that parameters should be part of the scene definition itself, not part of a GameObject. However, right now, if you want a loaded scene to behave differently, you got to find the GameObject handling that. (And not to say the possibility of having multiple MonoBehaviour colliding)
Just to be clear, I’m not saying stuff cannot be done that way, just that it’s not very clean as design.
I generally have a master presenter or a scene manager that is in charge of initializing all the main systems in the scene. And yes, it’s an invisible GameObject that sits in the scene. Anything that needs to be initialized in a certain way eventually gets initialized through this master object’s Awake and Start functions.
EDIT: You talk about having a script create scenes. My scene master script can set up the scene at runtime. I can see the benefit of being able to create scenes through code, mainly we could pre-calculate scenes instead of having a script build it at runtime. (I guess we can pre-generate prefabs to instantiate at runtime.) But the scene’s master script will have to do for now, unless someone knows how else to generate scenes via code.
Unity is definitely lacking when it comes to initial scene input parameters. Unity scenes are meant to be built in the editor, and then loaded in that same state every time. So if you want to load a scene in a different state, the only way to do that is to have unity load it incorrectly first, then quickly fix all the problems in Awake(). It would be very nice if there was a single entry point into each scene, but frankly that doesn’t exist.
Thanks, this may be how I ultimately have to do it - forego using additional scenes altogether.
I had liked the idea of using scenes because there are still portions of the game that will share common functionality that I would like to expose via the editor. For example, all levels in my game will share the same GUI, the same control scheme, the same weather effects, but the rest of the content will be dynamically generated. In this case, it makes sense to have a “Level” scene that constructs the dynamically generated portion based on the input parameters. All objects can be disposed by disposing the scene (at least I would assume this is possible), whereas now it seems like I’ll need some sort of global resource manager that can handle this.
Do you use some other hierarchical organization if you forego using additional scenes, such as placing the entirety of a level in a GameClip or something similar? How do you handle disposing and managing all the objects you create?
So just put everything you need on a single GameObject and save it in your “empty” scene.
Keep a list of everything you create at runtime so you can destroy it or rebuild it. Most likely, that list would be held by a script on that “unique” GameObject.
As others say, just create a blank Game scene that holds all your runtime code, and populate it at startup with your dynamic content. You can put content into this scene for testing as you craft the game experience, and then just remove it and switch to dynamic content.