Let's imagine we have the following scenario: We have a tiny little game, appropriate for a five-minute video. In this game, we have a cube which the player can rotate or change its color, and that's basically it.

Obviously, in order to interact with the cube, we need to provide some user interface to the player, and that is the actual topic of this video.

Because there's an old way to do this and a new way. For the old way, we would have to go into a hierarchy, start adding some UI elements to the canvas, reposition them, and do stuff like that.

Now, while that works and was used by thousands of Unity developers over the last years, we might ask some questions here. For example: Why is the UI living in the same space as our cube? Or, why are all of our UI elements attached to particular game objects? Are those things really necessary or helpful for most use cases? The answer is no.

Fortunately for us, there is now a new way to solve the same problem: Introducing UI Toolkit!

So let's remove our canvas and see what else we can do. To start working with UI Toolkit, all we have to do is open the new UI editor, which is called UI Builder.

UI Toolkit provides a nice separation of concerns into three parts. The first part is our layout, which we save as UXML files. Let's call this one "Cube Game UI". We can now arrange our basic layout for a simple HUD (although HUD is a pretty big name here for something pretty simple).

We need one container for the whole screen and one for our actual buttons at the bottom. We are setting all those properties in the inspector, but they are all saved into the UXML file which we created before. Notice how we are not touching our actual game scene at all; the UI work is detached entirely from our game logic, and we could reuse this.

In any game, we'd like to—for our game, we need three buttons. This brings us to the second component

of the UI toolkit, which is styling. Now, obviously, we could set all the properties we want for each button in

the inspector, but one rule in programming is: don't repeat yourself.  The UI toolkit allows us to isolate and reuse our styling with style sheets,

which are saved as .uss files. What this allows us to do is create a class for our button, but set the

properties on the class, not a particular button. Then, all that's left to do is add the

class to the other buttons, and they all look the same. Finally, let's give them appropriate text, and we are done with our layout.

So far, our game and our UI are entirely isolated and don't know about each other. What we now need is one small piece to

actually connect them. This is a component called a UI Document. In here, we just choose our layout file, and our UI is visible.

The third and final component of the UI toolkit is functionality or behavior, and this is done in C# scripts, just as

all of our other coding. So let's create one here and call it 'UI'. Jump into the script. We want to use the UI element's

namespace in order to interact with our UI toolkit components. We then need access to a Cube Controller, which is

surprisingly allowing us to control the cube. Now, in `OnEnable`, we need a reference to the root element of our UI

because from it we have access to all the other elements. That way, we can now get references to our three buttons,

but that only works if we gave them the appropriate names. And finally, let's now do what we're

actually here for: give the buttons some functionality. For that, we can access the `clicked` event on the buttons and hook up the

Appropriate function from the Cube Controller. Let's go back to Unity, attach the script, get an instance of the Cube Controller.

and our UI is fully functional. Notice again how our work on the UI and the game were entirely separated, and

notice how most of the UI work was done without touching any code. Particularly on large projects, this workflow can help a lot in keeping the

project clean and have smooth cooperation with your designers. This was UI Toolkit in 5 minutes. Thank

Unity UI Toolkit in 5 Minutes

Scripts