Introduction
Let’s face it, creating a User Interface for your game is no easy task. While working on our title Coco Blast, I came across a lot of challenges behind creating a UI that would work universally between multiple displays. In this post, I hope to describe tips and techniques behind creating dynamic User Interfaces for games.
Getting Started
When considering a UI, it is theorized that you should only have immediate vital information presented to the player. Try to reduce the need to populate the screen with random statistics and information that is seldom used.
Build your interface accordingly
The Core UI, as I like to call it, should have as few elements as possible. Great things to include would be Health, Mana, a Timer (if your game is time based), Booster Counts, etc…
The reason why these objects should be available is because they are core elements to gameplay. They directly relate immediate information that is helpful to the player.
The Secondary UI, can be considered any form of interface that contains information that doesn’t need to be presented to the player at all times. These elements could be: statistics, leaderboards, upgrade menus, etc…
Keep your UI as clutterless as possible.
Things you must know:
Draw Calls
Draw Calls consist of the objects that get drawn by the camera or screen. When a graphical object gets instantiated, the CPU must run calculations along with the GPU. All this processing increases your draw call count. For better performance, keep draw calls to a minimum.
You can read more about Draw Calls here.
Know your platform
While trying to design a user interface for your game, you need to know what platform you are developing for. For example, if you are creating a Web only game that will be shown on Kongregate, Addictive Games or Armor Games, the display size will never change. This simplifies your UI design process immensely because now there are no dynamics to your design. Everything is in a static position on the screen.
Now let’s say you are designing a game for Web and iOS. All of a sudden, we can’t use static positioning anymore. Now we need to support display sizes ranging from iPod Touch to iPad. As well, you now have retina displays which support an even greater pixel ratio. At this point, not only are we concerned about positioning, but also the pixel density (PPI or DPI) of the graphics we are using.
Theory of coding UI placement
When starting out, try to get skeletal designs of your UI. Complete with size, placement and potential animation movements.
The Breakdown
Believe it or not, there are several ways to achieve dynamic User Interfaces. The back-end design may change depending on your style of game. Here I will be showing you a technique that works for me.
Generally it is a good idea to break the UI into thirds, both vertically and horizontally. The idea behind this is as the screen scales, you have a grid of reference points.
Top-Left, Center-Left, Bottom-Left
Top-Center, Center-Center, Bottom-Center
Top-Right, Center-Right, Bottom-Right
To access these reference points, you need to be aware of the UI Coordinate System.
0,0 xy is Top-Left of the screen.
1,1 xy is Bottom-Right of the screen.
If you want to place your objects at the coordinates on the screen, all you need is the screens Width and Height.
Top-Left
<pre class="snippet-code">Vector2 topLeft = new Vector2(0,0);
Center-Left
<pre class="snippet-code">Vector2 centerLeft = new Vector2(0, Screen.height/2);
Bottom-Left
<pre class="snippet-code">Vector2 bottomLeft = new Vector2(0, Screen.height);
For the rest, you get the idea…
Using Unity’s GUI
With this in mind, here is a small code sample – C#
<pre class="snippet-code">
void OnGUI()
{
float buttonWidth = 50;
float buttonHeight = 50;
float borderPadding = 10;
Vector2 positionOfBoostButton = new Vector2(Screen.width - buttonWidth - borderPadding, Screen.height - buttonHeight - borderPadding);
Vector2 pos = new Vector2(50,50);
Vector2 wH = new Vector2(50,50);
if (GUI.Button(new Rect(positionOfBoostButton.x, positionOfBoostButton.y, buttonWidth, buttonHeight), "Boost"))
{
// Do Boost
}
}
We want to snap our Boost Button to the bottom right of the screen. So if we know the width and height of our screen, we can calculate the position of the UI element regardless of the screen size. For effect, I added a border padding.
Don’t forget that every GUI element creates 1 draw call, unless it is a GUILayout element which draws 2 calls.
Platform specific GUI
Now that we know how to place objects on the screen, we need to know how to manipulate code for different platforms.
Platform Dependent Compilation
Depending on your development, you may wish to simultaneously build your game for multiple platforms. If this is the case then ‘Platform Dependent Compilation‘ is for you.
The idea is simple. By using a bit of code, Unity can determine what code to use for what platform. This is effective for integrating multiple code platforms into one game project.
Let’s say you want to have a button for the iOS Platform that is aligned at the Top-Left of the screen. However, for your web build you want that same graphic repositioned and scaled for whatever reason.
The code is simple…
<pre class="snippet-code">
#if UNITY_IPHONE
// Change the global position of the object here
// Change the scale here
#endif
#if UNITY_WEBPLAYER
// Change the global position of the object to something else
// Change the scale to something else
#endif
Now, with this code you can build for multiple platforms without adding additional scripts or creating multiple code projects.
Third Party Tools
Unity’s Asset Store has a number of third party tools that can be useful for GUI management. Take for example TK2D. This system was not only built for UI elements but also in game 2D sprites. The idea here being we are using geometry quads to place sprites in 3D space.
This method presents its own challenges but depending on the game; this may be the way to go.
One of the biggest advantages of creating a UI out of sprites on 2D planes is Atlasing. Atlasing is a method that combines multiple sprites into one texture. Thus creating a single draw call from any one texture in that Atlas. For games that use a lot of UI elements, this obviously has its advantages.
One of the biggest disadvantages to this system is you have to create your own interaction callback scripts for Buttons and other touchable/clickable objects. For in-experienced programmers, this can be a lot of extra code management.
Wrap Up
Here I’ve presented you with a high level overview of getting dynamic GUIs created for multiple platforms. Hopefully this helps you get started on a GUI system for your own games.
If you have any questions or comments, please leave them below.
0 comments