• Ei tuloksia

The development of Wizard Wars has been an ongoing project since 2012, and has been more or less done on the side of fulltime work, hence the long development time. It started as a project which primary purpose was to provide a testing platform for many game design and development methods and ideas, but has since evolved into a full game. In addition to designing the UI, my main goal was to see how far I could push my vector graphics skills with the character and environmental assets. The main non-art focuses of this project were the porting of a traditional strategy game concept to a tablet platform; the testing of touchscreen control schemes; and the creation and balancing of the playstyle and spells for each wizard.

Each of these processes would have been very interesting to document more thoroughly and would have made for a great thesis subject. However, in the end I opted for the UI design for the reasons that it was a process I had full control over, and it was the most relevant one for my career.

From a visual standpoint I would summarize the UI design process as starting with something way too elaborate, which was then gradually simplified into a clean and consistent visual style.

In retrospective, the visual design broke almost every principle of UI design in its earlier iterations. Poor utilization of the screen estate, no visual hierarchy or structure, too many fonts and font sizes… For this reason, the beginning of the design process was very frustrating for me, as I kept creating designs that just did not work. I genuinely thought I was following design principles, when in reality I was not.

I think the main factor holding me back was that as a game artist with no real UI design experience, I was designing full-screen images instead of UI elements. Too much thought was put into creating a theme for the whole screen instead of focusing on how the information was to be displayed in individual elements, which would then be used to build up the UI as a whole. As a summary, I kept sacrificing way too much usability in favor of an impressive design.

The biggest success of the thesis is definitely the fact that my UI design skills have evolved significantly. Nowadays I think about the design process in a completely different way, being able to deconstruct the UI into smaller elements to tackle one at a time. Adopting useful work methods, such as starting the UI design process by creating a flowchart instead of going straight for the layout sketches, has also proved to be invaluable.

During the thesis project I confirmed the notion that most of the UI design should be done together with the game designer, or whoever is in charge of the user experience and game mechanics. Questions about the control scheme, user flow and gameplay that had not been thought of during the regular game design surfaced all the time. It was surprising for me to notice how much hand in hand gameplay design and UI design go. Many gameplay improvements were thought of during the UI design process and vice versa. The whole gameplay simplification process described briefly in the beginning of Chapter 4 was a direct result of the control scheme limitations of the touchscreen.

One important fact to keep in mind is that I had much more freedom during this UI design process than I would ever have in a “real-world” project for an actual game company. As this thesis project did not have a set deadline, the only limitations for me was the requirements established by the game design and the amount of time I was able to set aside. In a “real” game project there would be many demands and restrictions set on the UI design both from inside the project in the form of time and resource limitations, and from outside in the form of the product owner’s and producers’ wishes and demands. The fact that this thesis project was not done for a client also means it is harder to measure the actual quality of the UI, as there was no product owner who could say how well the design met their expectations and needs.

Although the goals of this thesis have been met – to design the visual style and create all the art assets for the UI of Wizards Wars – the UI design is still not completed. Animations and special effects have to be designed and added to bring the polish and visual impressiveness expected of an industry-standard mobile game. As the UI elements have been designed with these animations in mind, I don’t think it will be a difficult undertaking, although it may be a time-consuming one.

Also, the current wish list for Wizard Wars is quite long, with many features that might get explored further in future versions of the game. One of the more interesting ones is the map assembly, which lets the players choose what tiles to add to their current game. This would require an extra screen after the Choose a wizard menu, as well as some new UI assets, for example a condensed tile description with just the sprite and name, and a way to show and/or regulate the balance between the three tile types (monster, item and event). Another possible feature is letting the players adjust the number of tiles in the current game, to enable both quicker and longer-lasting games. This would require the crystal guardian to have scaling stats, so it is weaker in the quicker games and stronger in the longer-lasting ones. I expect this feature would not be too hard to add as long as the guardian’s scaling is balanced properly. The last bigger feature in the wish list is to allow 2-4 players instead of just the default three in the play with friends game mode. This feature is very appealing to include for flexibility and player enjoyment reasons, but it would require considerable amounts of testing to see if it is even feasible.

After I finish the animations and special effects for the UI elements, my work on Wizard Wars is done, at least for now. The first version of the game is ready to be launched on iPad except for some programming for the in-game view, and a more extensive testing round to fine tune the balancing of the wizards and tiles, and to polish the gaming experience in general. From there on out the future of the game is mostly decided by if it will get any traction or not. Any potential updates should not be too demanding art-wise, so I expect to be able to continue contributing to the project on the side of my other commitments.

REFERENCES

Books and published works:

Cao, J., Zieba, K., Stryjewski, K. & Ellis, M. (2015). Consistency in UI Design: Creativity Without Confusion. UXPin Inc.

Cooper, A., Reimann, R. & Cronin, D. (2007). About Face 3: The Essentials of Interaction Design. Indianapolis, IN, USA: Wiley Publishing Inc.

Fox, B. (2004). Game Interface Design. Boston, MA, USA: Course Technology/Cengage Learning.

Galitz, W. O. (2007). The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques, Third Edition. Indianapolis, IN, USA: Wiley Publishing Inc.

Lidwell, W., Holden, K. & Butler, J. (2010). Universal principles of design. Beverly, MA, USA: Rockport Publishers Inc.

Novak, J. (2012). Game Development Essentials: An Introduction, Third Edition. Clifton Park, NY, USA: Delmar, Cengage Learning.

Saunders, K. & Novak, J. (2013). Game development essentials: Game interface design, Second Edition. Clifton Park, NY, USA: Delmar, Cengage Learning.

Sears, A. & Jacko, J. A. (2002). The Human-Computer Interaction Handbook. In Pagulayan, R. J., Keeker, K. & Wixon, D. & Romero, R. L. & Fuller, T. (Eds.), User-Centered Design in Games (pp. 883-906). Hillsdale, NJ, USA: L. Erlbaum Associates Inc.

Web articles and blogs:

Carmichael, S. (2012). Mobile games winning the war for your attention.

venturebeat.com/2012/11/07/console-vs-mobile-gamers/ (Read 15.3.2014) Glinert, E. (2009). Upping Your Game’s Usability.

gamasutra.com/view/feature/132499/upping_your_games_usability.php (Read 16.3.2014) Laitinen, S. (2005). Better Games Through Usability Evaluation and Testing.

gamasutra.com/view/feature/2333/better_games_through_usability_.php (Read 15.3.2014) Llanos, S. C. & Jørgensen, K. (2011). Do Players Prefer Integrated User Interfaces? A Qualitative Study of Game UI Design Issues.

digra.org/wp-content/uploads/digital-library/11313.34398.pdf (Read 9.3.2014) Morrison, B. (2013). Using Psychological Principles for Great User Interfaces.

gamedev.net/page/resources/_/creative/game-design/using-psychological-principles-for-great-user-interfaces-r3397 (Read 17.3.2014)

Quintans, D. (2013). Game UI by Example: A Crash Course in the Good and the Bad.

gamedev.tutsplus.com/tutorials/aesthetics/game-ui-by-example-a-crash-course-in-the-good-and-bad/ (Read 14.4.2014)

Russell, D. (2011). Video game user interface design: Diegesis theory.

devmag.org.za/2011/02/02/video-game-user-interface-design-diegesis-theory/

(Read 16.3.2014)

Stonehouse, A. (2010). User interface design in video games.

thewanderlust.net/blog/2010/03/29/user-interface-design-in-video-games/ (Read 11.2.2014) Williams, S. (n.d). What’s the Difference Between a Hue, Tint, Shade and Tone?

color-wheel-artist.com/hue.html (Read 10.08.2015)

Wilson, G. (2006). Off With Their HUDs!: Rethinking the Heads-Up Display in Console Game Design.

gamasutra.com/view/feature/2538/off_with_their_huds_rethinking_.php (Read 17.5.2014) Zammitto, V. (2008). Visualization Techniques in Video Games.

bcs.org/upload/pdf/ewic_eva08_paper30.pdf (Read 14.4.2014)

Image sources:

Figure 5. Screenshots from

Final Fantasy finalfantasy.wikia.com/wiki/Menu_(Final_Fantasy) Final Fantasy XIII gametremor.com/2010/12/12/final-fantasy-xiii

Figure 24. Modified from http://www.1001fonts.com/sf-comic-script-font.html#gallery