You Are Here:

Usability In Mobile Games

Register Today

Register with Forum Nokia now and you'll enjoy the full benefits of the Forum Nokia membership.

Register Login
Community Highlights

Wiki article of the week

Zoom and Rotate Gestures in FlashLite for touch-enabled devices

Champion of the month

Jackson Feijó Jackson Feijó
Read more about Jackson on the Champions website.


Forum Nokia Events

Nokia Developer Days in South Africa
December 01, 2009
Johannesburg, South Africa

Forum Nokia Developer Conference ’09, India
December 07, 2009
Bangalore, India

LeWeb
December 09, 2009
Paris

Web Runtime Coding With Aptana WRT Plug-in
December 09, 2009
9am New York | 2pm London | 4pm Helsinki

Web Runtime Coding With Aptana WRT Plug-in
December 09, 2009
9:30am New Delhi, noon Beijing


View all

Version 1.0 / 23 March 2004

Table of contents

When you think of mobile games, you think of fun. But what does fun have to do with usability?

Fun is one of the main factors that differentiates game usability from usability in other applications. Mobile games are typically played for brief time periods, so there is no extra time to learn how to navigate inside the game. Playing should be as intuitive as possible and the challenge should be in the game play, not in the interaction with the game user interface.

Usability provides the framework and tools for playability, which is a quality every game must have in order to survive. Playability is defined as the degree to which a game is both fun to play and usable, with an emphasis on the interaction style - the quality of game play.

It has been said that an individual game lives or dies by its interface. If usability problems get in the way of intense game playing, the game probably will not be played again.

Back to top

How to turn a good idea into a great game

Navigating in the waves of a game experience When playing a game, users should experience the game world, and in order to do that the game navigation structure should support the experience. Use of high-level UI components should be avoided. Game menus should look and feel like the game. If high-level UI components are used, they should support the game experience seamlessly.

Figure 1: Three different game menu implementations

Figure 1 displays three different implementations of the same game. In the first example, both the game menu and the game are implemented with custom graphics in full-screen mode. Here, the game experience is not disturbed by phone graphics. This kind of seamless experience should be the goal when designing game navigation structure.

Should there be an interruption Mobile games are played in a context where interruptions often occur: somebody might call or send an SMS message, or the player might need to pause the game to buy a bus ticket. Therefore, the game design should support saving and pausing.

There are novice and expert users among mobile gamers. Novice users often need more help than expert users. Help should be available if needed, easy to access and quick to read. These design principles are useful:

  • Make help text brief. Concentrate on the controls in the help text (Figure 2).
  • Provide in-game help (Figure 3). Display short text on the screen to explain new items, characters, and situations in the game. Provide a setting to disable in-game help, too.

Figure 3: In-game help in Yo-Yo Fighter by Sumea is activated when user touches help icon

Almost like the real world The user has expectations of how his/her surrounding environment works. The game world should match that model. Movement and moving objects in the game world should be intuitive, and obstacles and possibilities should be easy to detect.

  • The game should function like the real world, to the degree that it's possible. For example, when characters are jumping or throwing objects, the flight path should be predictable
  • There must be no invisible barriers that the player cannot pass or holes that s/he cannot reach (Figure 4).
  • Do not kill the user/game without letting the user do something about it.
  • Match functionality and outlook. Things should do what they seem like they are supposed to do, and look appropriate to the function they perform in the game.
  • Do not force the player to learn new things if s/he can utilize his/her prior knowledge. Implement a realistic physics model.
Before applying the guideline The game has an invisible barrier to the right of the spaceship - the player cannot go right, although there is nothing visible preventing him.
After applying the guideline The new version does not contain such barriers. Note the little information circle where a player can get hints on how to play the game.

Figure 4: Invisible barriers were removed after user testing to make game world match real world (example presented in Developer Platform 1.0 for Series 40: Usability Guidelines for J2ME™ Games)

Back to top

Where do I stand?

The user must always understand his/her current status and the status of other players. Critical information about the game character's health, weaponry, money, etc., must be conveyed to the user clearly, without risk of misinterpretation.

  • Determine the most important information for players and display it clearly on the screen, making sure there is not too much information - one or two status indicators are plenty for most games. If this is not sufficient, the design may need to be refined to allow a simpler interface.
  • In multiplayer games, players must be able to identify both their own and the other players’ status at all times. For example, in racing games the player should be able to follow where others are on a map, and in puzzle games the player should be able to see the scores of the other players. Players can’t imagine a good action game if they can’t at least select the opponent and view his/her status. An even better solution is to show the status on the small screen all the time.

Go easy on the sounds Mobile games are often played in public places with other people around. Music and sounds might be a good addition to the game experience, but a great disturbance for others. Therefore:

  • Provide a silent start-up, rather than one with music.
  • Provide a sound menu in the game to make sure the player can deactivate or activate sounds.

Back to top

Design and evaluate every step of the way

Usability guidelines are handy and useful design tools. In order to guarantee good usability, evaluation should be a fundamental part of the development process. Even though mobile game development processes are very short, there are techniques and methods, such as expert evaluation and group testing, which have proven to be useful for mobile game developers. Usability is not the only factor that produces good games and gaming experiences, but without it no games could ever be played.

Related More games guidelines can be found in the Usability pages of Forum Nokia. Those useful guidelines focus on game play. New mobile game usability guidelines focusing on multiplayer games will be available within the next few days. In multiplayer games, other players provide the main challenge. There are numerous ways that a game design can support that scenario.

Game User Experience Library

Copyright © 2004 Nokia Corporation. All rights reserved.

Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other product and company names mentioned herein may be trademarks or trade names of their respective owners.

Disclaimer The information in this document is provided "as is," with no warranties whatsoever, including any warranty of merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed substantially prior to final release. This document is provided for informational purposes only.

Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to implementation of information presented in this document. Nokia Corporation does not warrant or represent that such use will not infringe such rights.

Nokia Corporation retains the right to make changes to this specification at any time, without notice.

License A license is hereby granted to download and print a copy of this specification for personal use only. No other license to any other intellectual property rights is granted herein.

Back to top

Print the document

Rate This

Bookmark this page: DeliciousDiggFacebookGoogleYahooStumbleUponRedditDiigoTechnocratiTwitter  Share this page Share this page Print this Page Print this page Invite a friend Invite a friend
RDF Facets: qdcZidentifierQSxhttpE3aE2fE2fwwwE2eforumE2enokiaE2ecomE2fmainE2fhtmlE5freadersE2fusabilityE5fandE5ffunE2ehtmlX qfnZupdatedQDx2008E2d10E2d16X qdcZtypeQUqfnZE45E78cludedFromGeneralE4CistingsQ qdcZtypeQUqwebZE52esourceQ qdcZtypeQUqwebZInformationE52esourceQ qdcZtypeQUqwebZPageQ qdcZtypeQUqfnTypeZE52esourceQ qdcZtypeQUqfnTypeZWebpageQ qdcZtypeQUqmarsZManagedE52esourceQ qdcZtypeQUqrdfsZE52esourceQ qfnZdistributionQUxhttpE3AE2FE2FforumE2EnokiaE2EcomE2FX qfnZtypeQUqfnTypeZE52esourceQ qfnZtypeQUqfnTypeZWebpageQ qmarsZlanguageQUxhttpE3AE2FE2FswE2EnokiaE2EcomE2FlanguageE2D1E2FenX qrdfZtypeQUqwebZInformationE52esourceQ qrdfZtypeQUqwebZE52esourceQ qrdfZtypeQUqwebZPageQ qrdfZtypeQUqfnTypeZE52esourceQ qrdfZtypeQUqmarsZManagedE52esourceQ qrdfZtypeQUqfnTypeZWebpageQ qrdfZtypeQUqrdfsZE52esourceQ qrdfZtypeQUqfnZE45E78cludedFromGeneralE4CistingsQ