In this chapter, we looked at many aspects of UIs in the first part, whereas we got handy with it in the second part, by implementing a UI within our game. However, before going on to the next chapter, I invite you to take a look at these exercises to improve your UI designing/programming skills. They are divided, for your convenience, into two parts: the first to improve your designing skills, and the second to improve your programming skills.
Improving UI designing skills:
- A great exercise: A great exercise is to find around three examples of games that you like, which are all different. For example, choose a strategy, adventure, and puzzle game. Next, for each of them, write down, or draw and annotate, each of the UI elements, what their function is, and what happens when a user interacts with it. For example, if the user presses the next button, what happens? Do they go to a new screen, or does a pop-up appear? You don't have to do this for the entire game, but enough to get a feel for how the UI works, and to understand how the placement of icons impact the user's experience. Next, try to experiment with changing the way that the UI is positioned and even the types of UI element. For example, if there is a health bar on the left, move it to the right or substitute the bar with text and see how it changes the feel. The main purpose of this exercise is to keep experimenting with different approaches to the UI. This is especially useful when you may have too many elements on screen, and as a result you need to remove some. In this way, you will have begun to develop different ideas and approaches to modifying the UI to achieve different types of interaction. Finally, document what you have done, and feel gratified by what you have accomplished and learned.
- A frame interface (part I): Take the map provided in the package of this book (or the one you are currently using). Now imagine that, instead of having only a bar at the top for the UI, you have also a right lateral bar. Furthermore, imagine to have more than 20 kinds of cupcakes tower, two kinds of sugar that the player can collect, brown and white, and that for each tower the player can decide two different upgrades other than selling. In this scenario, design an interface that easily display to the player all what he or she needs. In particular, ensure that the interface is intuitive, and could be used even without an explanation. At the end, ask to your friends to take a look at the paper prototype of your interface and check if it really achieves what you had in mind. Little tip: it's impossible to fit 20 kinds of tower all at once in the interface; therefore, you may want to divide them into categories, or have a scrollable area with all the towers.
- A frame interface (part II): Once you have designed the interface of the previous exercise, look carefully at the colors of the map provided into our package (or the one you are currently using). Now, choose the color palette carefully for your UI so that there is enough contrast to be able to read the interface without much effort, but at the same time it is pleasant to look at, since it is in harmony with the colors of the map.
- A frame interface (part III): Now it's time to create all the graphics necessary for the design you have created in the last two exercise. You can create the graphics from scratch, or take part of the graphics from the package of this book. Once created, import them into Unity, including slicing, dividing into Sprites, and so on.
Improving your UI programming skills:
- An evil button: We have seen that the event on the button is triggered only when the pointer is released and still within the button. In fact, if the player moves the pointer out the component, the event won't be triggered. In the case of an evil button, once the player has clicked it, it's done, the action will be executed. However, in the case of the button, the action is not executed when the player clicks, but when released. Implement an evil button so that even if the player moves the pointer away from the button and release, the button will still trigger the action.
- The selected toggle: Unfortunately, at the moment, Unity doesn't have any functions to retrieve the toggle that is selected from a toggle group. If by the time you are reading this book, a new version of Unity releases this function, you can still improve your skills by doing this exercise and ignoring the new pre-made function of Unity. In fact, having the ability to retrieve the active toggle is really handy in many situations and in many of your games. As such, implement a script that given a toggle group with an arbitrary number of toggles is able to retrieve and return the selected one (if any; in fact, there might be none).
- Runtime dropdown (part I): Read the official documentation of the drop-down component carefully, and implement one that can change the number of options at runtime. In particular, place a toggle group that allows the player to pick a set. Every set contains different options for the drop-down menu. Once the player choses a set, the options of the set are loaded into the drop-down menu (there should be only one drop-down menu in the scene, and you need to dynamically load the new options). Little tip: since the number of options in each set is variable, the easiest way to do this is to clear all the previous options of the drop-down menu and load the new ones.
- Runtime dropdown (part II): If you want to go further, take the previous exercise and through a Input Field and a button allow the player to add an option to the current selected set.
- Runtime dropdown (part III): If you felt confident doing the previous exercise, keep going by implementing the possibility to remove an option from the set.
- The lighting pointer: If you have read the UI effect component section, you will know about the existence of a special component that creates shadows. Place a text in the middle of your scene and apply the shadow component. Play a little bit with its values to understand how they work, and how to simulate the light coming from different directions. Now, implement a script that, based on the pointer positions, changes the shadow component so that it seems that the pointer has a kind of light on the text. Therefore, if the pointer is above the text, the shadow will be below, whereas if the pointer is on the left, the shadow will be on the right. By the way, I warn you that a possible consequence of doing this exercise is to create something that you will spend a fairly large amount of time to play with, because playing with it can become addictive!
- Again Prefabs: We faced prefabs in the previous section, in game development they are always really useful, particularly when you have multiple scenes and we don't want to implement the whole UI again for each level. Since we are going to create different levels in the last chapter, it's a good idea and good practice to create a prefab for each of the main UI functionalities. As such, create a prefab for the health bar, one for the sugar meter, one for the buy section of the UI and another one for the upgrade/selling section of the UI. Furthermore, create one last prefab containing all the UI (basically the canvas along with all its children). In this way, we can just place this last prefab in the scene in the next levels. However, remember to then add an Event System manually in the new scene.
- A frame interface (part IV): If you have done at least the part 1 of this exercise, you have designed an interface. Scale the map so that you can create the frame described in part 1. Then, implement the interface. Afterwards, test the interface again with your friends to check if it feels right now that it is digital. Eventually, modify it based on the suggestions of your friends, and don't forget to share your work, also with me if you want. If you also quote the book, I'd be pleased.
- A negative damage: When we created our health bar script, we wrote a function to apply damage, and it checks if the health has reached zero. However, what about a negative damage? In that case, the health of the player increases, and it shouldn't. Therefore, add a control to avoid a negative damage, such as setting the damage to zero if it's below zero.
- Healing the player: If you have done the previous exercise, it's not because we are sadistic against the player, but because that function should only apply damage. To heal the player instead, create another function that takes as a parameter an amount to cure the player, and checks if the health is no more than the maximum amount. If so, it just caps the health to the maximum.
- Warning the player I: When the health goes below 30% means that the sweet-tooth pandas are devouring the cake, and the player should be warned. Warn the player by showing a pop-up that appears on the screen only once, when the health is below 30%.
- Warning the Player II: In the same vein as the previous exercise, a pop up menu could disturb the gameplay. Therefore, warn the player in this way: change the color of the health bar to yellow when the health is between 20% and 40%, and to red when it is below 20%. Of course, restore the green color once the health is above 40%.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.