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

MadCat Tutorials

간단한 게임 시나리오 소개 및 UI 필요성 설명

5분 분량의 간단한 게임 시나리오 소개: 플레이어가 큐브의 색상이나 회전을 변경하는 게임

큐브와 상호 작용하기 위한 사용자 인터페이스(UI) 필요성 강조

기존 방식(Canvas 사용)의 문제점 언급: UI 요소가 게임 오브젝트에 종속적이고, 게임 공간과 UI 공간이 혼합됨

기존 방식의 비효율성 지적: 대부분의 경우 불필요하고 도움이 되지 않음

UI 툴킷을 사용하여 UI 문제 해결

UI 빌더(UI 편집기)를 열어 UI 툴킷 작업 시작

UI 툴킷의 세 가지 구성 요소(레이아웃, 스타일, 기능) 설명 시작

레이아웃(UXML 파일) 생성 및 설정: 컨테이너와 버튼 배치, 속성 설정 (인스펙터에서 설정, UXML 파일에 저장)

UI 툴킷의 스타일링 (USS 파일) 및 기능 구현

스타일링(USS 파일): 스타일 시트를 사용하여 버튼 스타일 재사용

버튼 클래스 생성 및 속성 설정: 코드 반복 방지

버튼에 텍스트 추가, 레이아웃 완료

UI 문서 및 C# 스크립트를 이용한 UI와 게임 연결

UI 문서(UI Document): 레이아웃 파일 연결하여 UI 표시

기능(C# 스크립트): UI 툴킷 구성 요소와 상호 작용

UI 요소 참조 및 버튼 이벤트 처리

UI 기능 구현 및 프로젝트 관리 효율성 강조

스크립트 연결 및 큐브 컨트롤러 인스턴스 가져오기

대규모 프로젝트에서의 효율성 및 디자이너와의 협업 강조