Learning NGUI for Unity

NGUI is available in three different licenses:

Now that we know the different licenses, let's make a quick comparison between NGUI and Unity's default UI system.

With Unity's GUI, you must create the entire UI in code by adding lines that display labels, textures, or any other UI element on the screen. These lines have to be written inside a special function called every frame: OnGUI().This is no longer necessary—with NGUI, UI elements are simple GameObjects!

You can create widgets—this is what NGUI calls labels, sprites, input fields, and so on—move them, rotate them, and change their dimensions using handles or the Inspector. Copy, paste, create prefabs, and every other useful feature of Unity's workflow are available.

These widgets are viewed by a camera and rendered on a layer you can specify. Most of the parameters are accessible through Unity's Inspector, and you can see what your UI looks like directly in the game window, without having to hit Unity's play button.

Sprites and fonts are all contained in a large texture called atlas. With only a few clicks, you can easily create and edit your atlases. If you don't have any images to create your own UI assets, simple default atlases come with the plugin.

Using this system ensures that, for a complex UI window composed of different textures and fonts, the same material and texture will be used when rendering.

This results in only one draw call for the entire window. That, along with other optimizations, makes NGUI the perfect tool for working on mobile platforms.

There also is an easy-to-use event framework written in C#. The plugin comes with a large number of additional components you can attach to any GameObject. These components can perform advanced tasks depending on which events are triggered: hover, click, input, and so on. Therefore, you might enhance your UI experience while keeping it simple to configure. Code less, get more.

NGUI comes with its own localization system, enabling you to easily set up and change your UI's language with the push of a button. All your strings are located in a.txt file.

Lighting, normal mapping, and refraction shaders are supported, which can give you beautiful results. Clipping is also a shader-controlled feature with NGUI, used for showing or hiding specific areas of your UI.

We've now covered what NGUI's main features are; let's see what we'll create using this book.

After buying the product from the Asset Store, download and import it by performing the following steps:

Ok. Once the Importing package pop-up window appears, skip the following section (reserved for users who already have the NGUI package on disk) and move on to the Package Importing section of the book.

If you already have NGUI's Unity package on your disk, follow these steps:

When the Importing package window is displayed, continue to the next section.

You have opted to import NGUI's package for Unity, and the Importing package window should be displayed. Follow these steps to finalize the importation:

We have now successfully imported the plugin into our project. Let's create our first UI!

In order to create a label, navigate to NGUI | Create | Label, as shown in the following screenshot:

Look at your Hierarchy view; you'll see a new GameObject called Label, as shown in the following screenshot:

Great, we have a label in the scene. But nothing is displayed. Why? Because we have to choose with which font we want to render the text. Let's do that!

Select this new Label GameObject. Now, in your Inspector view, you'll see that it has a UILabel component attached to it as shown in the following screenshot:

Currently, the Font field is set to None (UIFont). This means that no font is selected for this label. That's why most of its parameters are grayed out.

In order to select a font, click on the Font button (1) as shown in the preceding screenshot. By doing so, a new pop-up window appears, letting you choose a font by clicking on the Select button (1) in the next screenshot. For now, select the Arimo20 font, as shown in the following screenshot:

Once the font is selected, switch to the Game scene. You should see text like this:

It's great that we have our first NGUI text label. Now, we'll see how we can configure it.

The UILabel component attached to our new Label GameObject has some parameters. Let's see what they are and what they affect. The parameters are shown in the following screenshot:

We've reviewed the label's parameters. Let's configure them so they look good!

Before we study more parameters, let's configure this label correctly for later! Please set its parameters as shown in the following screenshot (changes are highlighted in the screenshot):

Ok, our label is configured. Below these parameters, you might have noticed more Widget parameters. We are now ready to see what they are.

Make sure you have nothing selected, and navigate to NGUI | Create | Sprite, as follows:

Now, take a look at the following Hierarchy view; you'll see a new GameObject called Sprite:

Great, we have a sprite in the scene. Let's see its Inspector parameters.

Let's define some terms as we review UISprite's parameters:

Right now, nothing is displayed because we haven't chosen which atlas and sprite we want to use.

We have reviewed the parameters of UISprite. Let's configure it to display something.

Selecting an atlas

We must select an atlas. We'll use an example atlas that comes with NGUI.

Select our Sprite GameObject, and click on the Atlas (1) button showed in the previous screenshot. The following window appears:

Select Fantasy Atlas (2). If the atlas is not listed, click on the Show All (3) button of the atlas selection window, and it will appear along with other example atlases.

Selecting a sprite

Now that we have selected an atlas, we can select which sprite to render, as shown in the following screenshot:

Perform the following steps:

1. Click on the Sprite (1) button to open the sprite selection window. Within this new window, select the Dark sprite by double-clicking on it.

2. Change the sprite Type (2) to Sliced.

3. Click on Color Tint (3) and set: {R: 255, G: 180, B: 0, A: 255}.

Your Game view should now look like this:

Ok. We now have a square sprite. But we have a problem: it's rendered over our text label. That's because the sprite's Depth value is higher than the label's.

Note

The new sprite's Depth value is higher than the label's because NGUI automatically sets a new widget's Depth to the highest to make sure it is displayed over previous ones.

Set the following widget parameters for our new sprite in order to have this result, as follows:

1. Depth: The label's depth is at 0. Set this one to -1 so that it displays behind.

2. Size: Set it to 400 x 80 to create a box around our Main Menu label.

Great, our first sprite is correctly configured! Before we move on, we can try out the different sprite types.

With NGUI, we have four basic types of sprites:

Now that we have a sprite onscreen, let's try them and see their parameters.

Sliced

Let's start with the Sliced type of sprites, since our sprite is already configured like that.

Select our UI Root | Sprite GameObject in the Hierarchy view. Look at the Preview window at the bottom of Inspector:

You can see that the Dark sprite's size is only 17 x 17 pixels. We have stretched it up to 400 x 80, and it still looks good—no pixelation or stretched corners!

That's because it is a nine-slice sprite: the four dotted lines in the preceding screenshot represent the slicing lines. Corners always remain at the same size, while other parts of the sprite stretch to cover the demanded area. Sliced sprites are thus very useful to create windows, borders, title bars, and more.

Simple

A Simple sprite is used to display an icon or a specific image that does not require slicing. In order to avoid pixelation, you shouldn't resize it too much over its original file size.

If you switch our sprite's Type from Sliced to Simple, slicing parameters are ignored, and our 17 x 17 sprite is stretched and looks terrible, as shown in the following screenshot:

Ok. We can now move on to tiled sprites.

Tiled

A Tiled sprite is a pattern that can be repeated indefinitely. In order to illustrate it effectively, select our Sprite GameObject and follow these steps:

1. Change its Atlas to the Wooden Atlas.

2. Set the Type parameter of UISprite to Tiled.

3. Change its Sprite to the Stripes 1 sprite.

Within the Game view, you might notice that our background is now diagonal orange stripes. The pattern is repeated and it looks good compared to a simple stretched sprite.

Here's a comparison:

In the preceding image, the same sprite is used. On the left-hand side, the sprite Type is set to Simple: the sprite is simply stretched and pixelated. On the right, the sprite Type is set to Tiled: the pattern is repeated and not stretched.

Now that we've seen how tiled sprites work, let's talk about filled sprites.

Filled

A Filled sprite is displayed partially depending on a FillAmount value between 0 and 1. Set the Type parameter of our UISprite to Filled. Ok. Now, we can review the three new parameters, as follows:

The following parameters are specific to filled sprites:

1. FillDir: Select one of the following five fill directions:

   • Horizontal: The sprite is filled horizontally. This is usually used for progress bars and life gauges.

   • Vertical: The sprite is filled vertically.

   • Radial90: The sprite is filled around a 90-degree angle.

   • Radial180: The sprite is filled around a 180-degree angle, resulting in a car windshield wiper effect.

   • Radial360: The sprite is filled around a 360-degree angle, resulting in a clock or timer effect.

2. FillAmount: This floats between 0 and 1 and defines how much of the sprite is visible. The mask's shape depends on the selected FillDir (1).

3. InvertFill: Check it to invert the sprite's fill direction.

You can visualize the fill effect by modifying the value of Fill Amount(2). If Fill Dir is set to Radial360 with Fill Amount around 0.55, the output will look like this:

You can try out the different fill directions before we explain how UICamera and UIPanel work.

Before we continue to the next section, please set back our sprite's Type parameter to Sliced, with the Dark sprite from Fantasy Atlas.

The UIRoot component scales widgets down to keep them at a manageable size inside the scene view. It also handles the different scaling styles.

Your Game view's aspect ratio might be set to Free Aspect or another value. For us to have the same results during the explanations to come, set it to 16:9, like this:

Select the 16:9 (2) aspect ratio. Ok. Now that we have a 16:9 aspect ratio for our Game view, we can continue.

Scaling styles

Select our UI Root GameObject in the Hierarchy view. The first parameter of its attached UIRoot component is Scaling Style. It defines how your UI reacts when the screen resolution is changed. There are three different scaling styles available:

1. Flexible: The UI is in pixels and remains pixel-perfect. A 300 x 300-pixel image always takes 300 x 300 pixels onscreen regardless of the resolution. No stretching or scaling occurs.

2. Constrained: The UI is not pixel-perfect. An image taking 30 percent of the screen will always take 30 percent of the screen, regardless of the resolution. The UI is scaled up or down to fit the screen's height, width, or both, depending on the parameters you choose.

3. ConstrainedOnMobiles: This is the Flexible mode on the desktop and Constrained mode everywhere else.

The UIRoot component has different parameters depending on the selected Scaling Style. Let's start with the default Flexible scaling style.

Flexible

This mode ensures that your UI elements remain at the same size in pixels (pixel-perfect) regardless of the resolution or Dots Per Inch (DPI). Here's an illustration of that:

The 320 x 240 widget shown in the preceding figure (W1) appears small on a 1920 x 1080 screen (S1) and large on a 640 x 480 screen (S2) because it's in Flexible (pixel-perfect) mode.

With the preceding illustration, if your screen is smaller than 320 x 240, your widget is not entirely visible. That's where the other parameters shown in the following screenshot come in:

The parameters are as follows:

1. Minimum Height: This is an important parameter to keep our UI from being cropped on small screens. When the screen's height is below this value, your UI is scaled down to fit. It will then be as if Scaling Style was set to Constrained with Content Height set to the screen's height.

2. Maximum Height: This is similar to Minimum Height, but for the screen's maximum height. When the screen's height is above this value, your UI is scaled up to fit.

3. Shrink Portrait UI: If your game or app can change orientation (landscape or portrait), check this option—the UI will be scaled down to fit the screen.

4. Adjust by DPI: Enabling this option will make your pixel-perfect UI take the screen's DPI into account. In practice, NGUI will believe that these two screen configurations are identical:

   • Resolution: 1280 x 720—200 DPI

   • Resolution: 1920 x 1080—400 DPI

Here's a practical example to illustrate the pixel-perfect Flexible behavior:

1. Select our Sprite GameObject.

   • Change its Size to 425 x 240

2. Select our UI Root GameObject.

   • Set the attached Minimum Height parameter of UIRoot to 240

Now, resize your Game view window to a larger screen: when it's more than 240 pixels high, the sprite's always displayed at 320 x 240 pixels. It's pixel-perfect and crisp.

Resize the Game view to a small size: when it's less than 240 pixels high, the UI is scaled down to avoid it being cropped. That's the purpose of the Minimum Height parameter.

The same principle applies to MaximumHeight.

Constrained

The Constrained scaling style is the opposite of pixel-perfect: you set Content Width and Content Height for the virtual screen, and your UI will rescale itself up or down to fit.

In practice, it means that a widget taking 100 percent of the screen will always take 100 percent of the screen regardless of the resolution. Let's try it now. The following screenshot shows the Constrained scaling style:

Select our UI Root GameObject in the Hierarchy view. For its attached UIRoot:

1. Set Scaling Style (1) to Constrained.

2. Change Content Width (2) to 320.

3. Set CContent Height (3) to 240.

4. Check the Fit option for Content Height.

Our screen is now always considered as having a height of 240, which is our sprite's height; it is now taking all the screen.

Resize the Game view to a large view. You'll see that, at all screen sizes and resolutions, our sprite always takes 100 percent of the screen's height (and width, if it's a 16:9 resolution). That's the Constrained mode: the UI is scaled proportionally to the screen's height based on the referenced Content Height.

ConstrainedOnMobiles

By setting your scaling style to ConstrainedOnMobiles, your UI will be Flexible (pixel-perfect) on desktop and Constrained everywhere else.

Select our UI Root GameObject. Below the UIRoot component, you'll find UIPanel.

UIPanel acts like a widget container—it creates the geometry. All child widgets will be rendered by this panel in one single draw call, if they all use the same atlas.

You might have more than one panel if you want to separate your UI, but keep in mind that a new panel equals a supplementary draw call.

The UIPanel component has three basic parameters:

These parameters are as follows:

You can set the Clipping to None and leave default values. We'll talk about the advanced parameters when we need them. Now, let's talk about the camera.

Select our UI Root |Camera GameObject. You can see that it has both a Unity orthographic Camera and a UICamera component.

Orthographic Camera

The orthographic (2D) Camera is used to view our widgets and render them over the Main Camera (3D) used to render the actual scene.

This is achieved by setting the rendering depth of Main Camera to -1, while the camera used to render NGUI widgets has a depth of 0 with the Clear Flags parameter set to Depth Only.

All these steps were executed automatically on the creation of a new 2D UI. Hence, we can see the widgets we created, rendered over Main Camera.

Note

Here, we're talking about camera rendering depth, not NGUI widget Depth value. The camera's depth defines its rendering order. The camera with the highest depth will be rendered over the others.

The culling mask of the orthographic camera must be set to only display our 2D UI layer. Let's create one right now.

Click on the button to change our GameObject's Layer (1), and select Add Layer... (2). This is shown in the following screenshot:

The Inspector view now displays the Layer menu. Next to User Layer 8, type in our new layer's name: 2DUI.

Now, reselect our UI Root GameObject in the Hierarchy view. In the Inspector view, you can notice that our UIRoot component and all its children are on the 2DUI layer, and the Culling Mask parameter of Camera is set to 2DUI only.

Now that we have our separate layer to hold our 2DUI, let's see what UICamera is.

UICamera

We'll now explain the purpose of UICamera, review its parameters, and configure it.

Purpose

This component sends out messages concerning events triggered on UI elements viewed by the camera it's attached to. For example, events such as OnClick()and OnHover()can be triggered on a button when the player clicks or hovers it.

You might have multiple cameras if needed. Here's an example with three different cameras:

1. 3D perspective main camera that renders the game. Layer: Default.

2. Orthographic camera for in-game 2D UI elements. Layer: 2DUI.

3. Separate 3D perspective camera used for 3D menus. Layer: 3DUI.

The afore mentioned cameras used for UI (cameras 2 and 3) need the UICamera component to interact with UI elements. The component can be added to the game's main camera (camera 1) if you want your 3D in-game objects to receive NGUI events too—they must have a Collider component attached to them.

Note

The in-game objects you wish to also receive NGUI events require Collider because these events are triggered by raycasts. Therefore, if the object has no Collider attached to it, the raycast will simply go through it.

Ok, now that we know the purpose of UICamera, we can review its parameters.

Parameters

These are the 11 parameters of UICamera:

Let's see what the above parameters correspond to:

1. Event Type: Select which event type this camera will send. Types that concern the UI sort events depending on their Depth value, whereas in World types events are sorted depending on their distance from the Camera component:

   • 3D World: This is used to interact with 3D-world GameObjects. Select it if this is your 3D game's main camera.

   • 3D UI: Option used for interaction with 3D user interfaces.

   • 2D World: Select this option if this is your 2D game's main camera.

   • 2DUI: This is used for interacting with the 2D UI.

2. Event Mask: Select the layer on which the event raycast is triggered. For example, setting it to Everything will result in all objects with Colliders receiving these events.

3. Events go to…: Here, you can select whether the objects you wish to receive events require either Colliders or Rigidbodies.

4. Debug: This enables or disables debug mode. This option is useful when you have unwanted behavior. When enabled, the currently hovered object is displayed in the top-left corner of the screen.

5. Allow Multi Touch: This enables or disables simultaneous touches. This is mandatory if you want to use pinch-to-zoom or other such gestures on mobile platforms.

6. Sticky Tooltip: This enables or disables the sticky tooltip option:

   • Enabled: The tooltip disappears when the mouse moves out of the widget's collider

   • Disabled: The tooltip disappears as soon as the mouse moves

7. Tooltip Delay: This defines the required stationary time in seconds before the widget's tooltip is displayed.

8. Raycast Range: A raycast is an invisible ray that is cast from one point towards a specific direction and is stopped if it encounters another object. The UICamera uses raycasts from the mouse or touch position towards the forward direction of Camera to detect collisions and handle events. You might set the range of this raycast if you need to limit the interaction to a certain range. The default -1 value implies that the raycast's range will be as far as Camera can see, defined by its Far Clipping Plane parameter.

9. Event Sources: You can specify which events this camera listens to:

   • Mouse: This is used for mouse movements: left/right/middle click, and scroll wheel

   • Touch: This is used for touch-enabled devices

   • Keyboard: This enables keyboard input. It uses the OnKey() event

   • Controller: This enables support for joysticks or game controllers

10. Thresholds: These values come in handy when you want to specify the minimum values before a particular event is triggered:

    • Mouse Drag: When a mouse button is pressed (the OnPress()event is triggered), this value determines how far in pixels the mouse must move before it is considered a drag, and sends OnDrag()events to the dragged object

    • Mouse Click: When a mouse button is pressed (the OnPress()event is triggered), this value determines how far in pixels the mouse can travel before the button release has no effect (the OnClick()event is not triggered)

    • Touch Drag: This is the same as Mouse Drag, but for touch-based devices

    • Touch Tap: This is the same as Mouse Click, but for touch-based devices

11. Axes and Keys: These parameters let you assign Unity input axes and keys to NGUI's input system.

    • Horizontal: This is the input axis for horizontal movement (the left and right key events)

    • Vertical: This is the input axis for vertical movement (the up and down key events)

    • Scroll: This is the input axis for scrolling

    • Submit 1: This is the primary keycode for validation

    • Submit 2: This is the secondary keycode for validation

    • Cancel 1: This is the primary keycode for cancel

    • Cancel 2: This is the secondary keycode for cancel

    Note

    You can edit Unity input axes at any time by navigating to Edit | Project Settings | Input.

Now that we have reviewed the parameters of UICamera, we can configure it for our project.

Configuration

We will now configure our UICamera component for this specific camera so that it suits our project and our future UI. Select our UI Root | Camera GameObject, and then:

1. Set the Event Type parameter to 3DUI because this camera will be used for both 2D and 3D UI interactions.

2. Set the Event Mask to the 2DUI layer only since our UI will reside on it.

3. Set Events go to... to the Colliders value because our widgets will have Colliders attached to them.

Good. We are now ready to create more interactive user interface elements.