User interfaces are a significant part of anyone's game development journey, no matter what kind of game you're working on.

You're probably, at some point in time, also developing a user interface for your users to, well, interface with.

There are a ton of different approaches to UI tooling, both within engines and available from a number of different

third-party providers. If you're watching this video, you're probably using Unity, and if you're like me, you probably also

have a love-hate relationship with Unity's default UI system. I think you'll agree that while it's a fairly robust

set of tools, Unity UI definitely comes with a lot of drawbacks. There's a somewhat arcane familiarity required in

understanding how all of the components work with one another in order to achieve a result that looks good, and it

seems that Unity have also understood the limitations involved because, over the past couple of years, they've been

working on an alternative. And while I've been keeping my eye on it, it hadn't really been something that I was excited

to talk about or even use; many of the features were pretty bare bones, and it just seemed easier to go with what I

knew. So I was hanging out in Unity land for the time being. However, as of this talk at Unite in 2023, showcasing a

number of different improvements added to the latest version of the package, things changed, and I'm now well and

truly on board the train to UI Toolkit town! Hi there, I'm Matt, and welcome to Game Dev Guide. In this episode, we're

going to take a look at some of the key things you might need to know in order to get started working with Unity's UI

Toolkit at runtime. We're going to take a look at how we can build out a simple main menu in the UI Builder and how to

animate between different states of our interface. We'll look at how to build a custom component in C# and how we can

expose properties and behaviors to be usable inside the UI Builder window. We'll then look at how to use the

painter tools to draw our own radial progress bar component from scratch. And finally, we'll look at how we can bind

game data to our components so that they update themselves to represent the data automatically. Now, I know I mentioned it

in the intro, and some of you may be new here, so you may be thinking, "Wait a minute, there's a fully functional

runtime UI solution in Unity already." And yes, there is. In fact, I have multiple videos here on the channel that navigate

around some of the many, many drawbacks of Unity's older UI system. There's also the even older IMGUI, which I've also

touched briefly on in the past, but that mostly just became useful for editor tooling rather than runtime. And in

modern Unity versions, the majority of the editor code has now been replaced and is rendering inside of UI Toolkit.

Now, anyway, so I won't be diving into that here. The point is, for the past couple of years, there have been two main

solutions in place: Unity UI or the new UI Toolkit framework. And frankly, up until Unity 2023.2, 

[Music] Toolkit seems like the future for Unity. However, it's still in development, which, if you're a Unity veteran, you're all too

familiar with. Like most things in game development, a lot of this is going to require nuance for you to decide whether

moving to UI Toolkit is a valuable decision for you in your project. So hopefully, this video can act as a case

study and help you make that decision. There are pros and cons to both UI tool sets; there are a lot of things I like

about UI toolkits, especially some of the affordances they offer when it comes to animation, styling, and reusability, but

it's also a very different way of working, and the entire thing is closer to a web development workflow, which

depending on your disposition, is either a pro or a con. For me, I think this is actually one of its biggest strengths

because one of the industry's largest third-party solutions, Coherent UI, uses virtually the same web-based design

philosophy. Coherent has been in many, many well-known indie and AAA titles, so there's a robust history of proven

products there. Taking that idea but integrating its concepts further into your engine and relying on the power of

C rather than JavaScript hooks makes a lot of sense to me, and I can see why they opted to go this route. Not only

does it become an accessible solution for UI and UX artists in the industry who are more familiar with web-based UI

design, opening up the pool of developers you can hire, but as an aside, you're also allowing users to harness the wealth of

knowledge that exists online for that type of interface design, and there is a lot of it. That said, for a lot of people,

the web design approach is horrible, and the amount of boilerplate you need to write to get anything up and running

sucks, so your mileage may vary. What I'm saying is, I get it. As many regular viewers of this channel would know, I'm

very, very familiar with Unity's UI system. At this point, design and workflow philosophies aside, though, the biggest

drawback from a feature standpoint for UI Toolkit is the lack of custom shaders and world-space support. So if those are

two things you desperately need in your game, you'll need to figure out some workarounds or hold off until Unity adds

Support for them. I fully recommend checking out the UI roadmap on Unity's website, as this will give you a bit more

of an overview of what features exist and what they're looking to work on next. I'll post a link in the description down

below. So, with all that said and out of the way, let's jump in and get started working with UI Toolkit for

runtime. I have a small scene here where the player can drive around a little road network. Right now, if I hit play, I

go straight into the game, but I'd prefer if we had a little main menu for the player to be greeted by before they

start playing the game. Nothing too complex, just a simple play button, maybe an options button, and an exit button

should suffice, I think. So let's take a look at how we can build something like that inside of UI

Toolkit. Let's open up the UI Builder by going to Window > UI Toolkit > UI Builder. This is a visual editor Unity

have created for us to more easily build out UI Toolkit interfaces. You see, unlike Unity UI where we have components that

control the look and layout of our visual interfaces, UI Toolkit uses two or three independent script components and separates the visual data and functional

layouts from the actual styling of the interface itself in the form of a UXML file for the layout, a USS file for the

styling, and a C# file for the functionality. We'll explore some of the affordances of this further in the video,

but for now, all you need to know is that the UI Builder essentially composes the UXML file and the USS file for you under

the hood while you're using it. You don't need to use the UI Builder to create runtime UI. If you want to go full hog

and code all of the UXML and USS files yourself, you absolutely can. I just find the UI Builder useful, and it's how I

Like to work in order to preview this properly, let's go into our hierarchy here and choose Match Game View.

Then let's save our XML file here and let's also create a new USS file and save that.

[Music] The base canvas settings here just act as a way to preview our UI on something but don't actually get stored

as part of the UI. As you can see, I've just set it to be the scene camera so I

can get a good preview for how it will look. I want a full-screen panel here, so let's create a root visual element and

set our style. We'll add a new USS selector called 'panel' to this element and then select that selector up

here and choose some base properties for this selector. One of the things I really like about this new workflow and the more CSS-

like approach is how you can build modular behaviors with stylings. Stylings sort of become component-like; for

instance, we could add a hidden selector here that, when added, simply changes the visibility of the component. This can be super useful for

making changes to your UI at runtime, as you can simply use C# code to add and remove classes from elements and

drastically change how it behaves. Next, I'll add a visual element to contain our logo and our

buttons. I want it to be in the center, so I'll actually set the flex properties on the 'panel' selector to align to the

center of the panel. A lot of this behavior carries over from CSS and is way out of scope for me to explain to

you in this video, so if you're unfamiliar with how things work in web dev, I'll leave some good resources for

learning CSS below. All right, with that set up, let's start adding some buttons. Unity has a number of built-in components here that

We can use similar buttons to the ones that existed in Unity 2D. So let's grab three

of these button components. But then let's add the class selectors into our own USS, and then let's override the visuals of these

buttons a bit until we get something we [Music] like. Finally, I'd like to get this logo

here on the menu. And so let's add a visual element on the edge here and name this [Music]

logo. In our logo selector, we'll select our image and set the scale value to "Scale to Fit." And I'm pretty happy with how this

is looking. Obviously, it's kind of basic, but it'll do the job. If we take a look in preview mode,

we'll notice that our buttons don't really react to any hover events, and they should. So let's fix that.

Much like normal CSS, we can use special selector events to change the style of our visual elements depending on certain

input states, such as hover or focus. Let's add a new hover selector for our buttons and then simply change the

background color. As you can see, the state now changes when we hover over the element. The cool thing about this selector

approach—that would have been much more difficult to support in Unity's previous UI system—is that, as you can see, we can

adjust any of these other values here and update how our button looks easily. Not only that, but we can also

transition between these two states dynamically through the use of the animation properties down here. No extra code or tweening libraries are needed.

It's just built straight into the UI Toolkit. So, for instance, let's say I want to transition the scale of my buttons

here. Down here in the animation section, we'll just add a property for scale, set the duration to around 0.25 seconds, and

Just like that, we now have a state transition between our buttons. I honestly think this is a really cool feature and is one of UI2 Kit's biggest selling points for me. Okay, so our initial menu here is just about ready to go. What we need to do now is get it working in-game by adding a UI document object and assigning our XML file. It looks a little larger than I'd like, though, so we need to go into the panel settings and change a couple of things.

These settings are essentially the same set of configurations as the old canvas renderer and related components. So here, let's switch from constant size to scale with screen size and set our target resolution to 1080p.

There we go! Now it looks like we designed it. If we hit play and mouse over our buttons, they animate as expected. So now we've got to get it functional, and unfortunately, this is a little bit more code-focused than Unity UI in the old system. Each element was a game object, so we could just expose a reference in code and set it in the inspector.

But these UXML files are just text assets, so instead we have to do a bunch of lookups as part of our coding process. UI components rely on names and classes, so essentially we have to do the equivalent of the old `transform.Find` method on everything in our UI to be able to add interactivity. I'm not super fond of this workflow because it relies so heavily on string references, and as you all know, names change all the time, so it's easy to break things.

But it is what it is for now. We can only hope that Unity improves this in the future. Let's go ahead and add a new class here, which we'll call `MainMenuController`. In our `Awake` function, we'll get the UI document and grab a reference...

to the root visual element. Then let's get our three buttons by name using this query method. This is

just the element name we set in the UI Builder for each of the buttons. We'll subscribe to the clicked event and build

out corresponding methods to handle it. Okay, so that's the basics of working with UI Builder and the runtime UI toolkit.

Now let's look at some more advanced use cases you might run into on a larger project and how you might want to

navigate them. Let's suppose I'm deciding to localize my game into other languages. I'm using Unity's localization package,

Building Runtime UI with UI Toolkit In Unity

Building Runtime UI with UI Toolkit In Unity

Scripts