Why I chose UI Toolkit over IMGUI to make my first Unity tool with
Unity is a great game engine. It has many features I love like utilizing the power of C#, providing a handy editor, letting you make anything you want, being extremely general purpose, etc. But there’s one special thing about it I love the most: Extendability.
The fact that anyone can extend Unity’s features by developing tools, assets, and packages is one of the things which makes it a powerful engine. Tool development was always one of the things I wanted to try. As for what to make a tool for, I first had to find something to improve in the workflow. As I worked with Unity for a little while in a more professional manner, I finally found the reason.
What was the problem?
Most developers separate their assets based on their type, then separate them based on their purpose. something like this:
Assets
|
|_ Scripts
| |_ UI
| |_ Enemies
| |_ Environment
| ...
|_ Prefabs
| |_ UI
| |_ Enemies
| |_ Environment
| ...
|...It’s very organized and intuitive. It makes sense. But, there is a problem. When you need to design a level and place the prefabs in their places, you need to move between different folders, which is frustrating. It’s much more ideal to gather all the frequently used prefabs in one place and just drag them into the scene when we need them.
So I made the Prefab Palette. A tool where you can bring your prefabs to one place and easily drag them into the scene without navigating from one folder to another. You can even save your palette to use later. It’s available on my Github and you can add it to your project using unity’s package manager.
I decided to make my first tool using the new UI Toolkit instead of IMGUI, and trust me, you will use it too when I tell you why I did this.
What is UI Toolkit?
According to Unity documentation, UI Toolkit is a set of tools, features, and resources helping developers make custom UI and extensions for the Unity Editor, runtime debugging tools, and runtime UI for games. It’s inspired by standard web technologies and if you know how to design a website and also somewhat of Unity, you’ll have a good time developing UI using this tool.
It divides your UI into 3 files: UXML, USS, and C#:
- UXML: It’s the equivalent of an HTML file in web development. It describes the structure, element, and hierarchy of your UI. It is written in XML format using
UnityEditorandUnityEnginenamespaces. - USS: It’s similar to a CSS file in web development. It lets you determine the style of each element and class.
- C#: It does the same job as the javascript file in web development. It contains the logic of the UI you’re making. You have access to the Unity libraries.
Although Unity highly recommends using this new way to develop UI in new projects, it’s still in development. You can see a comparison between UI Toolkit, IMGUI, and uGUI here.
Why is it better than IMGUI?
There are many reasons to choose UI Toolkit over IMGUI for your new tool. It provides better encapsulation, event handling, readability, and debugging.
Note: Since I used UI Toolkit to develop an editor window and not a runtime UI, all comparisons are between IMGUI and UI Toolkit.
Better encapsulation
Dividing a UI panel into three files of UXML, USS, and C# makes it possible to separate the logic and the looks of it in a much more intuitive way. This leads to more scalability and readability. It also makes it easier to debug and improve them.
Better event handling
Handling an event in an editor UI Element that is not supported by default is done in the OnGUI() method by capturing all the events, checking their type, doing some geometry magic to see if it happened within the boundaries of the desired element, and then acting accordingly. It’s because the developer doesn’t have access to the element in the code. They are drawn when you call the respective function and then it’s over.
But in UI Toolkit, you can access each element anytime you want using names and class names and register callbacks for any event you want. There is no limitation for event types you can handle for an element. You can register any event callback to any element of any type.
Not only does this make developing tools easier and more convenient, but also it’s more aligned with OOP principles since the one responsible for handling the events is the UI element itself, not the whole window.
Easier debugging
When developing a UI using UI Toolkit, the developer can use a tool called “UI Toolkit Debugger”. Using this tool, the developer can access every element in the UI and check their style attributes, the hierarchy, and some other things. Just like what “Inspect Element” does in the web browsers. The developer can even change the values and see how it affects the UI.
This tool is not provided in IMGUI, even for IMGUI elements used inside a UI made with UI Toolkit.
Better performance
When a UI is developed in IMGUI, it is rendered to the screen every frame. That’s why you should add your UI elements in the OnGUI() function which is called every frame. This approach consumes a lot of resources unnecessarily and is processor intensive.
The better approach is to repaint the UI only when needed, e.g. when an event has happened that changes the state of an element, or the window have resized, etc. This is the approach UI Toolkit uses. It repaints the UI only when it’s necessary.
Easier & better styling
Using the power of USS and inline styling, developers can make tools with unique better looks in an easy way. Its CSS-like format makes it easy to learn, especially if you are familiar with web development.
In conclusion, UI Toolkit makes your tools easier to develop, boosts their performance, and makes them easier to debug. It made developing this tool a lot easier for me.
What do you think? Do you think UI Toolkit is the better way to develop UI in Unity? or are you going to stick to IMGUI? Tell me your opinion in the comments.
