Designing UIs in Unity: What you should know

Imagine a watch without a watch face to indicate the time. An interface provides important information to us, such as time, so that we can make informed decisions. For example, whether we have enough time to get ice cream before the movie starts. When it comes to games, the User Interface (UI) plays a vital role in how information is conveyed to a player during gameplay.

The implementation of a UI is one of the main ways to exchange information with the player about moment-to-moment interactions and their consequences (for example, taking damage). However, UIs are not just about the exchange of information, they are also about how information is provided to a player and when. This can range from the subtle glow of a health bar as it depletes, to dirt covering the screen as you drive a high-speed vehicle through the desert. There are four main ways that UIs are provided to players within a game, which we will discuss shortly.

The purpose of this article is to prime you with the fundamentals of UIs so that you not only know how to implement them within Unity but also how they relate to a player's experience. Toward the end, we will see how Unity handles UIs, and we will implement a UI for our first game. In fact, we will insert a scoring system as well as a Game Over Screen. There will be some additional considerations that you can experiment with in terms of adding additional UI elements that you can try implementing on your own.

This article is a part of the book titled "Unity 2017 2D Game Development Projects" written by Lauren S. Ferro & Francesco Sapio.

Designing the user interface

Think about reading a book, is the text or images in the center of the page, where is the page number located, and are the pages numbered consecutively? Typically, such things are pretty straightforward and follow conventions. Therefore, to some extent, we begin to expect things to be the same, especially if they are located in the same place, such as page numbers or even the next button.

In the context of games, players also expect the same kinds of interactions, not only with gameplay but also with other on-screen elements, such as the UI. For example, if most games show health in a rectangular bar or with hearts, then that's something that players will be looking for when they want to know whether or not they are in danger.

The design of a UI needs to consider a number of things. For example, the limitations of the platform that you are designing for, such as screen size, and the types of interaction that it can afford (does it use touch input or a mouse pointer?). Physiological reactions that the interface might give to the player need to be considered since they will be the final consumer. In fact, another thing to keep in mind is that some people read from right to left in their native languages, and the UI should reflect this as well.

Players or users of applications are used to certain conventions and formats. For example, a house icon usually indicates home or the main screen, an email icon usually indicates contact, and an arrow pointing to the right usually indicates that it will continue to the next item in the list or the next question, and so on. Therefore, to improve ease of use and navigation, it is ideal to stick to these or to at least to keep these in mind during the design process.

In addition to this, how the user navigates through the application is important. If there is only one way to get from the home screen to an option, and it's via a lot of screens, the whole experience is going to be tiresome. Therefore, make sure that you create navigation maps early on to determine the route for each part of the experience. If a user has to navigate through six screens before they can reach a certain page, then they won't be doing it for very long!

In saying all of this, don't let the design overtake the practicality of the user's experience. For example, you may have a beautiful UI but if it makes it really hard to play the game or it causes too much confusion, then it is pretty much useless. Particularly during fast-paced gameplay, you don't want the player to have to sift through 20 different on-screen elements to find what they are looking for.

You want the level mastery to be focused on the gameplay rather than understanding the UI. Another way to limit the number of UI elements presented to the player (at any one time) is to have sliding windows or pop-up windows that have other UI elements present. For example, if your player has the option to unlock many different types of ability but can only use one or two of them at any single moment during gameplay, there is no point in displaying them all.

Therefore, having a UI element for them to click that then displays all of the other abilities, which they can swap for the existing ones, is one way to minimize the UI design. Of course, you don't want to have multiple pop-up windows, otherwise, it becomes a quest in itself to change in-game settings.

Programming the user interface

As we have seen in the previous section, designing the UI can be tough and requires experience to get into, especially if you take into consideration all the elements you should, such as the psychology of your audience. However, this is just halfway through. In fact, designing is one thing; making it work is another. Usually, in large teams, there are artists who design the UI and programmers who implement it, based on the artists' graphics.

Is UI programming that different? Well, the answer is no, programming is still programming; however, it's quite an interesting branch of the field of programming. If you are building your game engine from scratch, implementing an entire system that handles input is not something you can create with just a couple of hours of work. Catching all the events that the player performs in the game and in the UI is not easy to implement, and requires a lot of practice.

Luckily, in the context of Unity, most of this backend for UIs is already done. Unity also provides a solid framework on the frontend for UIs. This framework includes different components that can be easily used without knowing anything about programming. But if we are really interested in unlocking the potential of the Unity framework for UIs, we need to both understand and program within it.

Even with a solid framework, such as the one in Unity, UI programming still needs to take into consideration many factors, enough to have a specific role for this in large teams. Achieving exactly what designers have in mind, and is possible without impacting the performance of the game too much, is most of the job of a UI programmer (at least using Unity).

Four types of UI

Before, moving on, I just want to point out a technical term about UIs, since it also appears in the official documentation of Unity. Some UIs are not fixed on the screen, but actually, have a physical space within the game environment. In saying this, the four types of interfaces are diegetic, non-diegetic, meta, and spatial.

Each of these has its own specific use and effect when it comes to the player's experience and some are implicit (for example, static graphics) while others are explicit (blood and dirt on the screen). However, these types can be intermixed to create some interesting interfaces and player experiences. For Angel Cakes, we will implement a simple non-diegetic UI, which will show all of the information the player needs to play the game.

Diegetic

Diegetic UIs differ from to non-diegetic UIs because they exist in the game world instead of being on top of it and/or completely removed from the game's fiction. Diegetic UIs within the game world can be seen and heard by other players. Some examples of diegetic UI include the screens on computers, ticking clocks, remaining ammunition, and countdowns. To illustrate this, if you have a look at the following image from the Tribes Ascend game, you can see the amount of ammunition remaining:

designing-ui-in-unity-what-you-should-know-img-0

Non-diegetic

Non-diegetic interfaces are ones that are rendered outside of the game world and are only visible to the player. They are your typical game UIs that overlay on top of the game. They are completely removed from the game's fiction. Some common uses of non-diegetic UIs can represent health and mana via a colored bar. Non-diegetic UIs are normally represented in 2D, like in the following screenshot of Star Trek Online:

designing-ui-in-unity-what-you-should-know-img-1

Spatial

Spatial UI elements are physically presented in the game's space. These types of UIs may or not may be visible to the other players within the game space. This is something that is particularly featured in Virtual Reality (VR) experiences. Spatial UIs are effective when you want to guide players through a level or to indicate points of interest. The following example is from Army of Two. On the ground, you can see arrows directing the player where to go next. You can find out more about implementing Spatial UIs, like the one in the following screenshot, in Unity by visiting the link to the official documentation at: