2 years since Unity UI is here, and yet there is nothing to handle multiple UI screens.
Every single “tutorial” that talks about UnityUI I can find is about making a crap 2D game with a menu screen and then a scene to play the game.
Yes it’s very simple and it works.
Now can we all talk about the fact that real games have different UI screens, running in the same scene, and there is NOTHING to handle that at all in Unity ?
Multiple Camera: Very shitty solution and complicates everything
Multiple Canvas: Stacking on each other and complicates even more
Multiple Panel: Panel is not a UI screen, it’s just a UI element, so it’s not made for that
So we’re left off with 0 solutions included in the engine. Good job…
This is very annoying that none of this has been done yet, instead of doing useless platform support (who the fuck play games on Samsung TV or Windows Store anyway ?), maybe it would be great to actually have normal features in the engine. I don’t see good games making their way into Unity if they can’t have such a simple feature…
If I’m understanding your definition of UI screens correctly, you can use the Canvas Group component to separate UI “windows”. You can set their interactibility and alpha which stops all the child UI elements on it and underneath it from being interacted with.
I have been using the same solution for a while now and I don’t seem to have any issues of having too many objects in the same scene. I use only one canvas group, no reason to use more than one.
Inside that canvas group I have my windows named “Pause Menu”, “End Screen” etc. and to enable or disable each window I use a simple script called “GenericWindow.cs”. This script enables and disables window by using a simple render(bool answer) function. render(false) will disable a window and render(true) will enable it. All scripts that are children of the UI window will be disabled as well as their scripts running in the background. It’s a simple solution that I’ve been using for a while now without any complaints or issues.
using UnityEngine;
using UnityEngine.UI;
using System.Collections;
public class GenericWindow : MonoBehaviour {
public bool renderOnStart = false;
[HideInInspector]
public bool rendering = false;
// Use this for initialization
void Start(){
render(renderOnStart);
}
// Update is called once per frame
void Update(){
}
public void render(bool ans){
rendering = ans;
foreach(Transform child in transform){
child.gameObject.SetActive(ans);
}
}
}
So if you look closely at the hierarchy portion of the editor, you’ll see that each window is divided up nicely, followed by a “content” child, followed by the window’s contents itself. Each window has a “GenericWindow.cs” component attached to it which controls whether the window is active or not. The component also holds a “Render On Start” variable that if enabled will keep this window opened on startup.
The last variable “Rendering” is enabled automatically and should be hidden from the hierarchy so don’t worry about this one. This Variable can be used to find out if a window is open or not.
I hope this solution answers your question, and it’s a shame that nobody has a clear explanation either on how to setup UI properly. I’d say this is a fantastic way to do so.
This is why I have a content child. The purpose of iterating is to eliminate the possibility of error. if we just disable the first object, we will still have the other objects active. For whatever reason, if you don’t decide to use content as the parent child of a window object, you wont have the issue since it iterates through all children by default. there is a reasoning for this madness hehe.
Also the object containing the component does not get disabled on purpose. The reason behind this, is just in case you would like to have a script running on the window behind the scenes.
This layout and method has been designed over many projects and just seems to work best this way. Like I said, I never had any issues with this way.
Another reason why you would disable and enable objects, instead of destroying and instantiating. destroying and instantiating generates garbage. using “new” uses memory, instantiating uses memory. what’s the point on destroying and instantiating objects if you can just reuse them. I’m not sure If I living in the past here like when simple bullet holes in goldeneye were reused, same as mines, but it just makes sense not to destroy something if you can reuse it.
