Design your GUI with UI Builder! [Unity Essentials]

Learn Content
, , , ,
1

Whenever it comes down to creating GUI, Unity provides you with three abbreviated options:

  1. IMGUI (Immediate Mode GUI)
  2. UGUI (Unity UI / GameObject-based GUI)
  3. UITK (UI Toolkit; full featured since 2021.3)

Be it runtime or editor GUI, for beginners I strongly recommend to use UI Toolkit!

UITK enables you to visually design the GUI and its styling with a CSS like syntax (USS) in a WYSIWYG editor:

image
image1326Ă—799 124 KB

This, in and of itself, will save you countless of hours of work! Trust me. I had to deal with UGUI for the longest time and kicked it down the drain the moment UI Toolkit was usable at runtime.

If you want to dig down into details and get technical, check the GUI comparison page to see what each system’s strong suits, caveats and the target audiences are.

UGUI has been with us for the longest times and some of its major quirks revolve around layouting, adapting to varying screen resolutions, the clickediclickediclickiness of working your way through a deeply nested hierarchy of objects and countless of other things, not the least bit its RektTransform (pun intended).

UI Toolkit Usage Examples

When it comes to actually scripting UI Toolkit, it’s definitely, absolutely not more effort nor more complicated than UGUI!

Drop a UI Document component and your own GUI script onto a GameObject. Assign the VisualTree asset (your designed GUI), and in your script query any object by name. For menu GUI I prefer to do it a little less efficient (queries repeatedly) but more convenient to set up like this:

private Button JoinDirectButton => m_Root.Q<Button>("JoinDirectButton");
private TextField AddressField => m_Root.Q<TextField>("AddressField");

Then I hook up some events as needed:

JoinDirectButton.clicked += OnJoinDirectButtonClicked;
AddressField.RegisterValueChangedCallback(OnAddressFieldChanged);
...

And quite easily you can do neat features like highlighting an invalid entry, here any malformed IP address makes the IP Address field’s text get highlighted in red while typing:

private void OnAddressFieldChanged(ChangeEvent<String> evt)
{
    var textColor = Color.black;
    if (!IPAddress.TryParse(evt.newValue, out var _))
        textColor = Color.red;

    AddressField.style.color = textColor;
}

This is only to show that one needn’t be afraid of UI Toolkit requiring way, way more code than UGUI. It’s not!

And compared to IMGUI … don’t even get me started! If I see developers still writing editor GUI code with IMGUI (and struggling, of course) it’s just sad. I mean … if you only know a little bit about IMGUI, you can imagine what kind of mess it requires to design even a primitive developer-centric GUI like this merely because it contains a plethora of elements:

AssetInspectorScreenshot
AssetInspectorScreenshot548Ă—1201 74.8 KB

Of course I designed this GUI with UI Toolkit and the script to make this GUI functional is just 322 lines (counting empty lines too).

2 Likes
2

Do you know if there’s a big performance difference between UGUI and UITK? I use UGUI currently and I’ve noticed that I lose about 10% of my framerate to the UI. I’ve managed that a bit by disabling certain elements when transparent but it’s still a huge hit.

Also how hard is it to migrate from UGUI to UITK?

3

We can’t really compare the UI frameworks. Each has some strong arguments and pain points, and each has specific performance considerations.

For instance with UGUI it’s highly recommended not to put your entire game UI in a single canvas. This would cause all of the UI to update for every change made to the UI. Instead, aim for one canvas per each decoupled thing. Say the ingame popup menu is a canvas, the inventory and character screens have separate canvases, the tooltip overlay with all the RPG item stats is on its own canvas and so on.

You mean porting an existing UI? It’s going to be a lot of work since the paradigms are quite different and it depends on how coupled the code is to the specific GUI.

If you mean from a conceptual point of view, eg learning it and letting go of old habits, I’d say it’s no different than say switching from BiRP to URP. Overall you’ll see it’s quite easy to get a grip on things but then you want to do something specific but it’s just not in the place you expect or may even work quite differently.

The best thing about UITK is that you can open UI Builder and start hacking a simple UI together quickly. Perhaps try to recreate one of your existing GUIs just to see what needs to be done to get to the same layout. Once you have the layout all figured out, it’s just a matter of adding the code hooks and for most UI that means reacting to simple click events, perhaps the occassional style change, and that’s about 98% of the use cases. :wink:

1 Like
4

I had no idea! (Shows how much I know about the UI I’m using). Damn I was hoping i could just pack it up and resolve not to change anything but now I suppose I should start breaking my existing UI apart at some point…

5

In case there are more unknowns you should go over this page. It has the “split canvas” thing at the very top because it’s so essential. :wink:

6

ugui is the best part of Unity, no other package comes even close to how complete ugui is. I can create an entire facebook app just using ugui, it’s amazing once you get a hold of it.

instead of creating a nice syntax that translates to ugui (I could create a transpiler probably in 2 weeks, but I’m not in my 20s anymore so not a good opportunity cost – I applied to Unity multiple times in the past 5-6 years, but no response, perhaps I could’ve helped with this), they simply reinvented the wheel, as they’re doing with their networking packages (but there it’s justified)

since many years ago I never felt ugui is missing anything, and believe me, I did complex runtime game editors with many components, nesting, runtime inspectors etc.

you can be unstoppable with ugui