Usability Heuristics in Troll Tower Defence

As I approach the end of the school year, it is once again crunch time for me, which means working on a million different projects all due roughly around the same time (just joking about having one million things due; I’ve got 15 things on my to-do list at time of writing, all of which are worth marks). But enough about that, this week, seeing as we had a guest lecture where we had a sneak peek at the project he was working on as well as discussed UI design issues with the game, I will also do the same.

For those that remember, back at the beginning of the year, I mentioned I was working on a poker game as well as did some testing on it to see how usable the interface was based off of what we are learning in HCI class. Unfortunately, due to other school work creeping up, that project has been put on hold for a while now and there are no new updates.

On the other hand, I have been working on another project. This project started out as a side project that I would only work on in my spare time, but, seeing as I needed a few more portfolio pieces for my demo reel, I had decided to use the game as a portfolio piece, which is why there has been a lot of progress on it (in terms of gameplay).

First, let me start by talking about the game. The game, titled “Troll Tower Defence”, is an iOS game that I am planning to release on the app store once it is complete. I am sure most of you know what tower defence type games are, and, for those that don’t, basically wave after wave of enemies approach along a path, and as the player, you must build towers at strategic points on the map and upgrade them in order to kill the monsters along the path before they reach their goal. If too many enemies slip by, then the player loses the game.

Here is a screenshot of the game in action:

May not be the most exciting thing in the world, but I am a fan of tower defence games and figured hey, why not make one where troll faces are invading?

Okay, I’ll admit here that I haven’t done too much research in this area here and so this next part will talk about the Nielsen usability that I have already violated (Nielsen, 1995):

Visibility of System Status: Maybe my game doesn’t violate this heuristic… yet. In the screenshot above, you can see that vital information is shown at the top of the screen: the player’s lives, the number of gold they have, as well as the current wave. I will need to find a different font as well as increase the font size as I am sure most of you have realized that it is really small and hard to see.

User Control and Freedom: This is a biggie. In the game’s current state, players are able to build the tower and place it wherever they wish; however, there are no clearly marked “emergency exits”. Once a building has been placed, it is there until the end of the game. Also, there is no way to pause the game if something important comes up in the player’s real world and they need to stop focusing on the game for a minute. The fix here will be to support a remove option so that players can sell their tower back for money as well as to implement a pause state.

Flexibility and Efficiency of Use: One of the main tasks, and a core component of the game is building towers. As this is done very often, it would make sense if I allow the player to tap the button for the tower they wish to purchase, and then continue tapping the map to continuously purchase the same tower. Currently, the user must tap the button for the tower they wish to buy, then tap on the map for where they wish to place it. This process is repeated each time the player wishes to place a new tower.

Help Users Recognize, Diagnose, and Recover from Errors: I do have a lot of debug statements that print out the status of my game when it is in debug mode, although this will not be of any use to the player. At the moment, if the game encounters and error and fails, then it fails and the user is not given any notice. It will most likely be beneficial to have a pop-up of some sort appear whenever there is an error and explain it to the player in plain English.

Help and Documentation: This here is another one that I have violated, primarily because I haven’t gotten to code this section of the game yet. Looking at the current main menu screen, you can see that players don’t really have an option except to figure out how to play the game on their own. I’ve tested the game with a few people so far and all of them have pointed out that the lack of instructions have made it hard for them to figure out how they are to perform the tasks that they need to in the game. Sometime in the next couple of weeks I will be adding a help / instruction section to the game so that players are able to read this and learn how to play the game.

I haven’t violated these heuristics yet, but at the rate I am going now I probably will very soon as there is not much time left and a lot of work to do.

• Match between system and real world
• Consistency and standards
• Error prevention
• Recognition rather than recall
• Aesthetic and minimalist design

As a gameplay programmer, I think being able to satisfy all 10 heuristics is a very big issue. Violating any one of them can easily lead to potential usability issues in the end product. Therefore, I think it is of utmost importance that all 10 heuristics are met; otherwise, you can have the most impressive game out there with all the bells-and-whistles, but, at the end of the day, players are going to say your game sucks because they’re not sure how to play it or what it is they are supposed to do in your game.

References

Nielsen, J. (1995, January 01). 10 usability heuristics for user interface design. Retrieved from http://www.nngroup.com/articles/ten-usability-heuristics/