Posts Tagged ‘Heuristics’



12
Oct

iPhone games should not be interrupted by calls.

Part of a series on iPhone Game Design Issues. For an introduction see here, or use the categories on the right.

The most obvious thing that can be said about iPhone gaming, and yet a factor developers commonly miss,  is that it appears on a phone. There are many ramifications from this, such as where a player is likely to be playing (the bathroom?). The focus today though is on the important factor that a phone is likely to receive calls.

 

Receiving a call

Receiving a call

Text messages are handled by the iPhone OS, and appear as a pop up box that can be dismissed, with minimal interruption of the game (and hence needs no input from a developer). However receiving a call will shut down the game and run the phone program regardless whether the call is answered. This is where good design is required to avoid a usability disaster.

 From a technical perspective receiving a call is essentially the same exit process as if the ‘home’ button (the only button on the main page) is pressed. However from a usability perspective, the important difference is that the user has no control over whether they receive calls or not, and so the software has to accommodate this. If the app just ‘drops’ you, without saving the state of play, and then starts the app from fresh when the call is finished/rejected, this is going to negatively effect the user’s experience. They will be unlikely to want to play again, since they will be redoing aspects of the game they thought had been completed earlier. Furthermore the fear that they will receive more calls, and thus lose progress, is going to be a lasting factor, and prevent the user from investing time to continue.

 It is therefore important for iPhone game designers to consider that the medium is going to lead to unexpected interruptions to game play, and provide a solution which will accommodate this.

Who does this right?

Scoops

Scoops

Scoops, the casual ice cream tower building game, successfully implemented this in a later version of their game.

In the initial release a call (or ending the game) would cause the game to restart from the beginning (without saving the high score). Despite being a short game (a typical session would probably be under ten minutes), the game’s only measure of progress is a high score table, and so losing progress like this can easily anger players. This was recognised, and fixed in later versions so that now the game will resume from where it left off after returning from a call. Further to this, the game will start paused so that players returning from a phone call can adequately prepare to resume their gaming session. The designer, Ian Marsh, has ensured that interruptions to game play will not hinder player’s progress in the game.

 

Who does this wrong?

Alive4ever, the zombie survival game ‘inspired’ by Left4Dead, has recently added a ‘horde’ mode, where users must survive waves of enemies of increasing difficulty in order to unlock additional bonuses.

Unlike Alive4ever’s other modes, where games would be in <5 minute intervals, successfully unlocking all the weapons in the new mode would require playing for over an hour without interruption. If the user intentionally exits the game, or receives a call, their progress in this mode is lost, and the user has to start the hour long session from the beginning. The implications of this are that the user will be unlikely to retry this, and the real enemy becomes not the zombies on screen, but the challenge of not receiving calls for an hour!

Alive 4 Ever. Not Left 4 Dead.

Alive 4 Ever. Not Left 4 Dead.

 

As a little bonus to finish on, here is a gem of an app review, for Scoops.

User: FredsYourUncle 
Score: 1/5
Subject: Fool
Review:  “ Tomatos arnt vegetables “

8
Oct

iPhone Game Design Heuristics

Within the field of usability, heuristics are ‘shortcuts’ to overcoming major usability issues, and are often used to supplement user testing. They can quickly identify large usability issues, early in the development process, and prevent the need for major redesigns further down the software development process. If many of these issues didn’t become addressed until play testing, typically one of the last steps of development, the amount of re-working needed would increase exponentially.

Their use is particularly important with the ‘home-grown’ scene of iPhone game design, due to the small size of most development teams. Because a development kit costs only $99, and publishing a game requires no budget (except marketing), the iPhone development scene is a lot more small scale than other mobile platforms, and so often teams (or individuals) cannot afford to employ the most thorough methods of evaluating usability, such as expert review.

It would be useful then to have a series of guidelines that developers can follow to identify good and bad iPhone usability game design issues, which is what I’m attempting to achieve in this series of blog posts. Within each topic, I will aim to cover why it’s important, and provide examples of a correct, and an incorrect implementation. Hopefully this will prove to be a useful resource for iPhone game developers. 

For further reading about mobile phone usability issues, Nokia’s study can be accessed here: Nokia Heuristics Study . It was produced before the development of the iPhone, and hence lacks an up to date perspective, particularly with iPhone specific aspects of usability.