You are on page 1of 74

Design and User Experience Library v1.

7 > Game design

© Nokia 2009.

Game design
This section describes usability and user experience issues that are specific to game design.
• Mobile game usability
• Game experience guidelines
• Mobile game graphics
• Mobile game playability heuristics

Mobile game usability

Usability is not a one-dimensional property. It has many overlapping components; some even
contradict one another. In most cases, usability is associated with the following attributes:
Table: Usability factors
Satisfaction A subjective feeling of contentment.

Efficiency A minimal amount of time wasted.

Learnability Degree of ease when starting to use the system.

Errors Number of errors the user makes and degree of seriousness.

Memorability How well the user remembers the system when returning to

Game usability needs to be differentiated from playability, which refers to a user's overall
experience with a certain game. The most comprehensive definition of playability states: The degree to
which a game is fun to play, with an emphasis on the interaction style and plot-quality of the game; the
quality of gameplay.
Playability is affected by the quality of the storyline, responsiveness, pace, usability, customisability,
control, intensity of interaction, intricacy, and strategy, as well as the degree of realism and the quality
of the graphics and sound.
The importance of the usability factors mentioned in the table above varies. For example, in a flight-
booking system for expert use, efficiency and lack of errors are very important, but for an information
kiosk, learnability, memorability, and satisfaction are higher priorities.
Game applications are not terribly complicated when compared with word-processing applications,
for example. Mobile games are typically played for quite brief periods of time. They are played for
enjoyment or challenge, which pose different usability needs. The special nature of games, especially
mobile games with their small screens, creates special needs for their user interface.
Care must be taken to ensure that the game interface and concept are pleasing to the user. This also
means lack of distress and irritation. The key to usability is simplicity - a complex solution is itself a
problem. Efficiency is not a particularly important usability attribute for games, at least not in and of
itself. In the end, of course, efficiency produces satisfaction and it must not be ignored; however, the
user is not usually trying to leave the game as soon as possible.

The most important of all usability criteria is simple: Know the user. In order to design a product, a
designer must know the audience. Making guesses about the age or education level of the users is a
risky foundation for a business.
Even with demographic data at hand, it is not always clear what conclusions to draw. With mobile
games, it is essential to know where they are being played, for how long at a sitting, in what situations,
how they are paid for, what the function of playing is, and so on. All of these factors need to be
considered in the design.
See also;
• Usability return on investment
Usability return on investment
Jakob Nielsen, a usability pioneer and guru, states that developers should invest 10% of their project
costs in usability for maximum payoff. However, return on investment (ROI) is more difficult to assess
with usability, since costs are measured in money while usability is measured in increased use, more
efficient use, or greater user satisfaction.
Converting usability improvements to dollars is easy in e-commerce, where doubled sales have an
immediate value. For intranets, productivity gains are also fairly easy to convert into monetary
estimates: simply multiply the time saved by the hourly cost of employees.
Other types of design projects are harder to convert into an exact ROI. What is the value of increased
customer satisfaction? Of more traffic or increased use of a Web site's target features? These estimates
vary between companies, and thus the monetary value of doubled usability also varies. However, it will
be substantial in most cases.
Typically, the more people use a design, the bigger the usability ROI, since the benefits come from the
added value that ease of use brings to each user. For an application with many users the benefits are
greater than for an application with a limited user base. Typically games, especially successful ones,
have a very large and variable user base. This translates into making usability a high priority, since the
benefits are substantial.

Game user experience guidelines

Developing good games is not an easy task. Good playability and usability is often a result of hard
work in all design phases. This section contains game experience-related information, tools, and
examples to assist game developers in developing usable games.
• S60: Top ten usability guidelines for games contains one-page summarizations of the most
important game usability guidelines.
• Main menu design contains visual presentations of main menu design recommendations.
• Pre-game guidelines, Game experience guidelines, and Post-game guidelines contain detailed
design recommendations about different topics in game development.
• Case: Mobile action games, Case: One button games, and Case: Mixed reality games contain
information about the challenges and possibilities of designing different kinds of games.
In this section, the following symbols are used to highlight issues that are especially important in
certain platforms or technologies:

Java Java™ Platform, Micro Edition (Java™ ME) games

Symbian Symbian C++ games

S60: Top 10 usability guidelines for games
1. Appropriate main menu implementation
• Implement the game's Main menu with custom graphics, but only if it can be done well.
• Avoid using UI components with standard graphics in the game itself.
• Use the navigation key as a primary control. Users should be allowed to move focus with the
navigation key and select items with it.
• Use the left softkey as Select or Options menu.
• Use the right softkey for Exit/Cancel/Back.
2. Pause and save
• Single-player games: Provide save game capability (except for very short games). Provide
pause game capability.
• Two-player games: The game should go into Pause mode for both players if one of the players
is interrupted. It must be possible to continue the game. The player who was not interrupted
should receive information about why the game is being paused. For example, "Waiting for the
other player to continue."
• Games with more than two players: Design games so that the interruption of one player does
not interfere with the other players' game. The interrupted player's game can be switched to the
background without pausing the game or the player can be dropped from the game. The
preferred action depends on the game type.
3. Provide feedback
• Provide clear feedback on essential elements in the game: when a level is completed, when a
bonus level is reached, when the players succeed (score a goal or kill an enemy), etc.
• Essential elements need visual feedback so that the game is playable without sounds.
• In multiplayer games, provide clear feedback about who has won and lost. Communicate to the
user about his/her performance by using "you" instead of a name or colour symbol.
• After the user has uploaded a file (for example, a clip or a ghost) to a server, provide clear
feedback that the file has been uploaded and where the destination folder is.
• After the user has sent a challenge to a friend, provide feedback that the challenge has been sent
4. Status
• 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 player's
status in the game at all times.
5. Challenge
• Provide rewards early on to keep beginners motivated. Rewards can be new levels, abilities,
weapons, etc. Providing rewards in a random schedule maintains motivation for the longest
• Do not make the game more difficult by altering constants, such as the physics model attributes.
Instead the challenge should come from difficult tasks.
• Create as human-like AI as possible - reasonable but not completely predictable.
• When feasible in multiplayer games, provide player-ranking and player matching systems that
try to match players of equivalent skill against one another.
6. No sound abuse
• Keep the default sound volume close to the volume of the phone's regular sound - not too quiet,
but not much louder, either.
• Allow the user to adjust the sound level of both background music and tones.
• Sounds must not be too loud or too high-pitched, and users must be able to turn sounds off
• In Bluetooth multiplayer games, background music should be synchronised for all players to
avoid an auditory mess.
7. Distinctive graphics
• The objects' and characters' appearance must match their functionality/activity.
• Different items must appear clearly different and their functionalities should be distinctive as
• In multiplayer games, characters need to look different enough so that the players can identify
who is who.
• In multiplayer games, make sure that the colours of the characters appear the same for all
8. Provide in-game help
• Provide in-game help to the user. Training mode is the preferred solution.
• The in-game help feature should not stop the game. The player should be able to skip the help
should s/he so choose.
9. High-score list
• There should be a high-score list, if it fits the game idea. A high-score list motivates the player
to compete against his/her previous score or some friend's score.
• Games become more interesting when players can compare their performance with the
performance of possible community members. Give the user the possibility of updating his/her
scores to the high-score list of the game community.
• Show in the community high-score list both the scores of some of the best players and the
scores of players who performed closest to the user.
10. Easy restart
• Provide an easy way to restart single-player game. For example, in the Game Over screen,
provide a "Replay," "Play again," or "Restart" command, taking the user back to the beginning
of the game, with the same settings as before.
• In multiplayer games, provide a quick way to start a new game with same opponents.

Main menu design

A well-designed main menu delivers a visual impact, and both gives the players an impression what the
game is about, and guides them towards the game experience. The core features should be visible in the
main view, and they should be accessible with recognisable controls.
In this section:
• Game main menu - S60 Symbian C++
• Game main menu - S60 Java™ ME
• Navigation diagram - S60

Game main menu - S60, Symbian C++

There are basically three possibilities for presenting the game's main menu:
1. Create the entire menu system from scratch. This implementation is recommended for all games
and entertainment applications. However, although it provides the most flexibility and the best chance
for a good user experience, it is also the easiest way to make mistakes. Even if custom graphics are
used, interaction needs to be consistent with other S60 applications. See Navigation and user
experience in S60 games at Forum Nokia for the key S60 interaction-style issues that should be
considered when implementing the game menu with custom graphics. This main menu implementation
should only be used if it can be done well. It should work at least as well as the higher-level UI. If
standard graphics UI components are used together with custom graphics, they should be used
consistently. Use of standard graphics UI components should be limited to game main menus; they
should not be used in the game itself.

2. Customise S60 UI components. Developers can create their own custom components or modify
UI components, and implement the game's main menu with modified S60 UI components. This
implementation is suitable for games with complex navigation structures.

3. Implement the menu with the standard S60 look and feel. The game's main menu can also be
presented with standard S60 UI components. This implementation is not recommended.
• It is recommended to implement the game's main menu with custom graphics, but only if it can
be done well. The navigation key should be used as the main control. Softkeys should be
labelled, and they should be used consistently with S60 interaction style.
• Avoid using UI components with standard graphics in the game itself.
• When designing a game user interface, you should understand the user interfaces of similar
games, both on devices and other platforms. However, you should not just copy the UI. In case
of conflicts, you can refer to this documentation package.
• Use of terms in game menus needs to be consistent. For example, if the game is a Formula 1
racing game, terms that support this picture should be used, not terms from a rally game.

Game main menu - S60 Java ME

There are basically three possibilities for presenting the game's main menu:

1. Implement the entire menu system with game graphics. This is recommended for all games
and entertainment applications. Although this possibility provides the most flexibility and the best
chance for a good user experience, it is also the easiest way to make mistakes and requires the most
memory. This menu implementation should only be used if it can be done well - it should work at least
as well as the higher-level UI. Even if custom graphics are used, interaction needs to be consistent with
other S60 applications. Sometimes developers have no other option than to use high-level UI
components, for example for accessing the phone book or establishing Bluetooth connections. To
ensure a seamless user experience, the use of dialogues with standard graphics should be limited to
game menus. In the game itself, high-level components should be avoided.
2. Use only a background image and Options menu. If the application is simple enough, a pop-
up Options menu can be used as the game's main menu, which can result in a usable navigation model
for Java ME games. However, to guarantee a seamless user experience, all other menus should be
implemented with game graphics in full-screen mode.
3. Use high-level UI components in the game main menu. If the game is more complex, list
components can be used for implementing the main menu. This menu implementation is problematic in
many ways, but the main problem is that the left softkey cannot be labelled Select, because the system
automatically provides an Options menu. This implementation often leads to various usability
problems. If this implementation model is chosen despite its problems, the most important issue is that
the Options menu should never offer only the Close option, but should also present some other, more
desirable selection. It is also important to include the Close option for exiting the game in the main
menu, not just in the Options menu.
• If it can be done well, implement the game's main menu with custom graphics. However, the
interaction style must be consistent with the user interface styles for the S60 Platform.
• Avoid using standard UI components in the game itself.

Navigation diagram - S60

The following figure shows a typical navigation scheme for a S60 game. Games vary widely, of course,
and care must be taken to ensure that softkey labels are appropriate and that screen titles and menu
entries are descriptive.
Not all screens and buttons are required in every game, and each must be evaluated in context. Some
games require more versatility from the user interface than shown in the figure. In particular, Intro,
About, and Game Mode screens may not be appropriate for every game.
Note also that not every screen is depicted; for example, the screens for entering player names and the
high-score list are not shown. The high-score list after the game is identical to the screen that is
accessible through the main menu, except that the Back button takes the user to the previous screen,
not to the main menu.
1. This screen is optional but recommended.
2. In Pause mode, the screen title may be adjusted accordingly.
3. For simplicity, the navigation flowchart is not drawn to its full depth.
4. Player names are asked for after the game mode has been selected. Game difficulty level is
also implemented in this screen.
5. This screen is needed only for action-based games. Its purpose is to allow the player to adjust
to the game situation and prepare for action. The left key may be shortened if Continue does
not fit. Other options include Go, OK, Game, and Proceed.
6. The left softkey may be labelled Menu or Pause, depending on the game type and context.
Pause is recommended for action games, Menu for turn-based games. If a player selects Exit,
confirmation must be asked from the player or the game must auto-save. The left softkey may
be labelled with a symbol, such as a triangle, if a softkey text is not displayed during the game.
7. Implementing the right softkey Exit is optional.
Pre-game guidelines
Usability guidelines presented in this section are related to pre-game concepts, and contain general
usability guidelines as well as guidelines specific to Nokia platforms.
In this section:
• Loading
• Intro
• Main menu
• Navigation keys
• Pause menu
• Bluetooth connection menu
• Login menu
• List design
• Handling payments
• Help
• Save the user's time
• Text entry

Load in reasonable time. Slow response affects the user experience severely and negatively. If the game
takes too long to launch, it annoys the user, and because mobile games are played mostly while waiting
for something, the user might not find it worth the trouble.
• Make the game launch in reasonable time, the faster the better.
• Display some feedback, such as a progress bar to reduce the perceived time of waiting. Even
better, give the user something to do while the game loads in the background.
• The same goes for starting the game from the main menu.
• Symbian applications should launch in less than 5 seconds.
• Provide a short description of the game, a Web page, the name of the game and its vendor, and
so on. This data is placed into the .jad file, and can be viewed with the Details command on the
• Java™ ME applications should launch in less than 10 seconds.

Make it possible to skip the intro.
A game introduction is an important part of the game experience, but users may find it annoying when
forced to sit through the same introduction every time.
• Make it possible to skip the introduction. The preferred keys are the navigation key, number
keys, and the default select key. The End key and the task switching key should work normally.
• Provide instructions, such as "Press 5 to skip intro."
• Intro music should be stopped if the user skips the intro.
• The introductory splash screens should not be displayed for an extended time: two to three
seconds per screen is sufficient.
See also:
• Intro sounds

Intro sounds

If the game has intro music, it may annoy others if the user starts it up in a location where silence is
preferred, and thus the user may choose not to play the game.
In studies conducted for these guidelines, most users did not comment about game sound one way or
the other, and when they did, comments were usually negative. Make sure that the sounds do not annoy
the user.
• Sound settings may be asked when starting the game.
• If intro music is implemented, there must be a way to switch it off.
• Music settings should be off by default if the profile is silent. Note that the user may also
change the device profile when the game is in the background.
• Symbian applications should check the current profile, before playing the intro music. If the
profile is silent or beeping, intro music should not be played.
• In mobile information device profile 1.0 (MIDP) devices, MIDI sounds are played even if the
profile is set to silent. In those devices, intro music in MIDI format should not be used.
• In some MIDP 2.0 devices, MIDI sounds may not be played if the profile is silent, but tone
sounds are. In those devices, intro music in tone format should not be used.
See also Sounds.

Main menu
The main menu must present certain familiar commands to the user; they are listed below. The name of
the game should be used as the main menu title. Note that not all of these commands are applicable to
all games.

Commands available at the main menu should include:

• Continue game. Available only if a game is saved automatically. The user is taken to the game,
and should be allowed to get prepared before the action starts. If this option continues a
multiplayer game, it should be named accordingly, for example "Reconnect" or "Continue
Bluetooth game."
• New game. Starts a new game or, if there are multiple game modes, provides a menu to select
from among them.
• Settings. If there are no more than two settings, they can be integrated in the main menu. The
format "Sound: On" should be used instead of "Set sound off."
• High scores. Available only if there is a point in keeping track of high scores. The high-score
list is sorted from the best to the worst, best scores first.
• Help. Instructions for the game. Concentrate on the controls; be very brief about the story, if it
is mentioned at all. However, the objective of the game and the rules should be covered. The
help text should scroll more than one line at a time with a single key press.
• About. Copyright, version, and vendor information about the game. The URL of the game site
should be mentioned here. This item is optional.
• Exit. Exits the game and saves settings.
The main menu should be short; scrolling should not be necessary. All items should be visible, and a
deeper menu structure should be used if necessary to avoid scrolling. A wide hierarchy should be
preferred over a deep one.
Use more items at each menu level rather than a few items in a deeper structure. However, scrolling
should be still avoided. If there is enough space in the main menu screen, settings or different game
modes can be presented directly in the main menu.
The number of screens should be minimal. Do not provide eye candy without any real content. Every
screen (except the actual game screens) should contain information about at least one of the following:
status of the application, content of the window, or title of the application, and indications about the
actions to perform.

Navigation keys
Although game navigation should be visually different from the device UI style, it should behave
familiarly. This means that naming of the softkeys, as well as their functions, should be consistent with
the UI style.
• Device's default navigation key is used for moving focus or cursor.
• Device's default select key is used for navigating forwards.
• Device's default back key is used for safe backwards navigation.
• Softkeys should be labelled in full-screen mode, too. Labelling should be consistent with the UI
• Use Options or Select as the label for the left softkey in game menus.
• If the Options menu is used, it should always offer another option in addition to the standard
• Use Back, Quit, Exit, Cancel, or Clear as the label for the right softkey. Note that settings are
saved when the settings screen is exited with the right softkey. In game menus, the right softkey
should take the user one step backwards.

Pause menu
• The Pause menu should contain the following options: Continue, Settings, Help, Back to main
menu, Exit game.
• If the user selects "Exit game" or "Back to main menu," confirmation should not be displayed, if
the game is saved automatically.
• In the Pause menu, the default back key should take the user back to the game.
• When the user returns to the game, there should be enough time for the user to get prepared. It
is a good idea to have the game dimmed in the background so that the user can see the current
situation and prepare.

Login menu
• Do not force users to enter their login name and password every time. Offer the possibility of
saving the password in the Settings menu.
• If custom graphics are used in the Login menu, make sure that the focus is sufficiently visible,
and forms are implemented according to the UI style in all platforms.
• Users should not need to select text fields before entering text. Text fields should go to the text-
entering state automatically when the user tries to enter text.
• Access point query pop-ups should not be repeatedly opened if there are problems when
establishing a connection. A worst-case scenario is that the user panics, presses the End key, and
switches the application to the background, but the game keeps opening pop-ups every ten

Bluetooth connection menu

• Do not use technical terms like "Create server" and "Connect to server." Use "Create game" and
"Join game" instead.
• Users do not need to know the Bluetooth name of a server device. The name of the game should
be queried when a user selects "Create game" from the Bluetooth menu. Reasonable default
settings should be provided for the users, so that they only need to accept possible dialogues or
• Provide instructions for establishing the Bluetooth game. These should be available in the
Bluetooth connection menu.
See also Games Over Bluetooth: Recommendations to Game Developers at Forum Nokia.

List design
Menus must be consistent with each other and clear to the user. Users should know where they are at all
times and how to navigate around.
• The title of each screen should describe the contents of the screen. Do not use "Please select" or
"Main menu" as the title.
• Menu commands should be listed by decreasing frequency of use. However, keep items that
belong together close to each other, such as Load and Save. Also, commands should appear in a
logical order - if certain things are generally done before others, they should be listed first in the
• If there are no items in a list, do not show a blank screen; instead, show "No items" or "No high
scores," or something similar.
• No command should be listed in a menu more than once, not even under a different name.

Handling payments
• Provide a confirmation dialogue with the exact price information before any payments. Use
only the default positive key for accepting.
• Do not use game graphics in the confirmation dialogue.
• Provide feedback about success or failure of payment.
• The Confirmation dialogue can be implemented with the Alert dialogue.

Concentrate on essential issues in the help. Even though many players claim they read the help text,
most do not - until they encounter a problem. Even when they do read the text, they typically remember
only what they are looking for - most often, the controls. Some players also want to know what the goal
of the game is.
• The help text should be brief.
• Provide help on the controls first, because this is the first thing players look for.
• The game objective should be presented second, right after the controls. The objective should be
described in four sentences or less.
• The game story can be skipped altogether or mentioned only briefly. If the story is mentioned, it
should be described after the controls, with the game goal.
• Mention diagonal movement, if it is available (1, 3, 7, and 9).
• Use pictures in the help
• Help for multiplayer games
See also:
• In-game help

Save the user's time

Efficiency must be assessed from the user's point of view. If saving a game takes ten seconds but the
user can continue playing at the same time, this is better than taking five seconds to save during which
time the user must wait. The latter may be technically faster, but the user does not perceive it that way.
Time spent navigating and configuring the game should be kept to a minimum, and time spent playing
to a maximum. Users should understand what they must do in the game.
• Whenever possible, the game must provide reasonable default values for data requested from
the user. If the user has previously entered data, that value should be used as the default. If no
data has been entered, provide a reasonable value, or zeroes, for numerical data to indicate the
data format. However, defaults should not be provided if no purpose is served. For example,
there is no point in providing "First name Surname" as a default value in a player name field -
this does not save the users' time because they must erase the old text anyway. However, it does
make sense to provide a famous athlete's name in a sports game.
• The game should remember what the users have done and not force them to do it again. For
example, if the game challenge comes primarily from solving puzzles on levels, the game
should not require the user to play these levels every time if there is no additional challenge.
The user should be able to start up on the level that was last achieved, but should also be able to
restart from level 1.
• The game must preserve all the data the user has entered. This applies to the name the user has
given, the options selected before playing, and the options selected during the game.
• Passwords should not be remembered by default, but this possibility should be available for
• The player must be involved in the game quickly. It is crucial to get the players in the game and
arouse their interest. This means that there should be no complicated settings to adjust before
playing, or there should be a "quick-start" option.
• If possible, time-consuming operations should be done in the background while the user does
something else.

Text entry
Text-entry screens should follow users' expectations, asking for information that users expect, and in
the order in which they expect it. Users should always understand what is being asked, why, and in
what format data should be entered.
• Fields in forms should be grouped logically and presented in a natural sequence.
• Name entry should be requested only when needed, not before.
• Do not force the user to enter a name at all, especially a name of a certain length.
• Provide the last entered name as the default so that it can be accepted quickly.
• The application must not ask for data that it can reliably find on its own.
• Forms must be consistent with each other, the application, and the UI of the device. The terms
used, command and option names, and screen layout must be familiar to the user, based on the
user's experience with the device and the current game.
• Form fields must indicate the format of the data requested. If the number of choices is limited,
they should be presented in a drop-down menu or a similar structure that allows selection from a
limited, predefined list.
• If the user enters the data in the wrong format, the game should correct the user as much as
possible. For example, if the user enters a comma as a thousands separator but the game expects
a space, the string could be corrected automatically. However, this can be done only if it is
certain that the entered data is inappropriately formatted. It is a good idea to inform the user
about the correction.
See also Text.

Game experience guidelines

Usability guidelines presented in this section are related to the actual game experience.
In this section:
• Make the user comfortable
• Keys and game controls
• Graphics
• Backlight
• Sounds
• Match with the real world
• Feedback
• Give control to the user
• Game design
• End key
• Pause
• In-game help
• Latency in multi-layer games
• Text

Make the user comfortable

Respect the user's privacy.
Generally, users do not know if the data they enter is being sent over the network, where it is stored
(device memory or SIM), and so on. Accordingly, they hesitate to enter personal information, such as
their e-mail address. When personal information is requested, the reason should be clear to the user.
• Do not ask for (personal) information that is not required, and make sure the user knows why
sensitive data is being requested. Confidential data should be crypted, if possible.
• Store personal data in one place only. Users should be allowed to erase their data.
• Sensitive data, such as credit card numbers, should not be stored at all.
In this section:
• Do not annoy the user
• Do not for the player to restart from scratch

Do not annoy the user

Typically, games can be played in locations where it is not suitable or socially acceptable to have the
sound on.
• The user must be able to switch sound and vibration on and off independently of each other.
• In the Settings dialogue, provide a way to disable the vibra functionality, if the game uses it.
• Use check boxes in the Settings dialogue. If this is not possible, use the Sound: On format. Do
not use the "Sound On" format, since it cannot be deduced if the selection turns sounds on or

Do not force the player to restart from scratch

If the game is level-based, it should not require the user to replay levels if no additional challenge is
provided. The user should be able to continue from the previous level, but should also be able to restart
from level 1. Game challenge should arise from learning to play the game, not from challenging the
players' patience by forcing them to play repeatedly through training levels.
• As a general rule, the game should be designed for short 5-15 minute game sessions.
• Provide a way to skip levels the player has already completed, if relevant.
• Provide difficulty settings, if applicable.

Keys and game controls

Providing clear and readily understandable game controls is vital to playability. Because of the various
key layouts in devices, it could be a good idea to allow the user to modify the controls. But in general:
• The default navigation key should be used for movement; number keys should be enabled, too.
This is especially important on devices where the End key may be pressed easily by mistake.
• The default select key should be the main action button, along with button 5.
• The controls in the game should be used consistently and the number of different controls
should be relatively few. Users generally do not remember a button's purpose if there are lots of
different buttons for different game modes and different parts of the game.
• If more complicated controls are needed, they must be used consistently. For example, if two
different jumps are needed, the same key (2) can be used; the height of the jump is determined
by how long the key is pressed.
Typically users do not use number keys for movement, but they should be enabled and not used for
anything else. In some devices, the navigation key may not be optimal for fast action games.
• Simultaneous key presses
• Diagonal movement
• Key functions

Simultaneous key presses

Multiple key presses must be supported by the hardware. All S60 devices support multiple key presses.
Support for the detection of multiple key presses does not necessarily enable diagonal movements with
the navigation key.
•In Java™ ME applications in S60 2nd Edition devices, detection of simultaneous key presses is
possible with the getKeyStates() method of the GameCanvas class.
• In Java™ ME applications in S60 1st Edition devices, this can be done by using
keyPressed() and keyReleased() methods together with Boolean variables showing
the status of the keys.
• In Symbian C++ applications in S60 devices, detection of simultaneous key presses can be
enabled by calling the CAknAppUi::SetKeyBlockMode(ENoKeyBlock) function.
However, this does not apply to navigation key events. For example, it is not possible to detect
Up+Select navigation key events simultaneously, but it is possible to detect an Up+Softkey
• Note that if key blocking has been disabled by calling the function above, certain key
combinations on some devices cause the application to switch to background unintentionally.
Key mapping on S60 2nd Edition, Feature Pack 2 or newer devices should be designed so that
the player does not accidentally press the following key combinations:
• 7+8+0+*
• 9+0+#
For more information, see the Forum Nokia Wiki.

Diagonal movement
Some devices might not support true diagonal movement. The navigation key may not physically
function diagonally, or simultaneous vertical and horizontal presses of the navigation key may not be
detected. This poses problems in games that could benefit from this feature, especially because users
are typically unaware of this limitation. Informing users is unlikely to help, because not all of them
read the help information; even if they do, diagonal movement is such a natural thing that they might
try it anyway.
• For devices that do not support true diagonal movement, games should be designed in such a
way that they do not require diagonal movement.
• If diagonal movement is needed, you should help the user. For example, in level-jumping
games, a jump could be diagonal if the character faces either way, left or right. Also, if there is a
ledge in that direction, the character could jump on top of it, even though the player jumped
straight up.

Key functions
If there are several keys for one function, users may be uncertain whether or not the functionality is
included in the game. If there are several functions for a single key, the user may become confused,
since the same key does different things at different times or when operated differently.
• There should be only one function associated with each key and one key for each function.
However, if the functionalities perceived by the user are close to each other, the same key can
be used; for example, the right softkey can mean Cancel or Back, depending on the context.
Users use the default navigation key fairly well and naturally in every device, so all games should be
controllable with it. The keypad layout differs between devices, some being more suitable for playing
games than others. For this reason, it is good practice to allow players to choose if they want to use the
default navigation key or numeric keypad for controlling the game.
• Enable the default navigation keys for controlling the game.
• Also enable numeric keys for controlling the game.
• Numeric keys need not literally move the character. For example, if the character can throw
something upward, the 2 key can be used for this feature, especially if the 5 key is used for
something else.
• It is not required to be able to do everything inside a game at any time. Often it provides
additional challenge to simplify the controls. For example, instead of allowing the use of every
item with a specific key, there could be a key to switch the active item and then the action key
could be used to use each item.
If a game has animations or loading screens during which the player cannot do anything, key presses
should be disabled. If the user presses a key and the game remembers it, that key takes effect when the
game starts and most likely that game session will be ruined.
• Disable prepressed keys.

Take screen size into consideration. Note that screen resolution does not necessarily mean that the
screen is physically larger. Game graphics need to be optimised for device screen resolution, but also
for the physical size of the device screen. For example, using same font size in all devices may make
the text too small to be read.
In Java™ ME, there is no API for directly getting the screen physical size. However, screen size can be
deduced from the font sizes. Font sizes can be asked with the Font.getHeight() method.
In S60 2nd Edition, Feature Pack 3 devices, applications may be scaled by the compatibility mode.
From S60 3rd Edition onwards, legacy applications designed for the 176x208 resolution are not
supported. Applications can query the screen size using the command:
The physical screen size can be calculated in Symbian applications. Class CWsScreenDevice
provides method SizeInTwips(). One twip is equal to 1/1440 inch.
For more information on, see Scalable UI support.
In this section:
• S60 screen orientation
• Harmonious colours
• Match functionality with appearance
• Use each screen fully

S60 screen orientation

Information about changed modes can be obtained with the Displayable.isShown() method.
Navigation key directions work normally in all modes.
On S60 3rd Edition devices, games may be run on different screen resolutions and orientations.
Symbian games can detect the current screen orientation, for example, with
CWsScreenDevice::GetDefaultScreenSizeAndRotation(), and it is also possible to
detect orientation changes on-the-fly by implementing a
CCoeControl::HandleResourceChange() and check for events of type
Layout-aware applications, that is, any application that is not a legacy application, will have to be able
to respond to changes in screen size and layout. They can detect changes in layout with the following
methods (note that applications should try to ensure that layout events are processed only once for each
• Application UIs can override HandleResourceChangeL() to detect the
KEikDynamicLayoutVariantSwitch message and re-layout of their main controls from
• Controls can override HandleResourceChange() to detect the
KEikDynamicLayoutVariantSwitch message and re-layout themselves and their
For more information, see the SDK Help on Layout-Aware Applications at Forum Nokia.

Harmonious colours
Although a colour screen can be very informative, it should not be overused. Colours that have a
special meaning, such as a colour highlight for a selected item, must be easily recognisable.
• The colouring scheme within the game and the navigational structure should be consistent.
• The selected item should stand out clearly.
See also Feedback.

Match functionality with appearance

Graphics need to be distinguishable from one another. For example, opponents should not get mixed
with each other or with some other objects.
• The appearance of the objects and characters must match their functionality/activity. It should
be possible to make a reasonable guess about a character's purpose based on appearance. For
example, enemies should intuitively stand out from rewards.
• Different items must appear clearly different, and their functionalities should be distinctive as
well. Items and animations should be sufficiently unique. In particular, different enemy
characters must be unique.
• In multiplayer games, characters need to look different enough that the players can identify who
is who. For example, do not use colours that are too similar.
• In multiplayer games, make sure that the colours of the characters appear the same for all
players. Users should be able to identify themselves as a particular colour and have everybody
see them as that same colour.
See also Match with the real world.

Use each screen fully

Ideally developers should use the full screen, without leaving blank areas. If blank areas exist, images
can be centred in the screen.
• Balance graphics and blank areas evenly on the screen.
• The background must not look bland or too busy.
• The background image of the game must not be confused with the game objects and characters.
The background is not there just to be pretty - advanced players can use it to time or align
actions and events.
• The background should be different from the foreground; make its objects less detailed and less

Many devices turn the light off after 15 seconds of idle time to save battery. This is a relatively short
time in some games. If the backlight goes off during a game, it is difficult for the player to see what to
do. If the user presses a key to get the light back, the application will react to it just like any other key
press, and it might affect the game. In Series 40 3rd Edition and S60 3rd Edition devices, it is possible
to control the backlight with the Backlight API.
• In the help, tell which button is safe to push if the backlight goes off during the game. When
communicated as one of the controls, this information takes the least space and text. For
example, 4=left, 6=right, #=backlight.
• In some mobile information device profile 2.0 (MIDP) devices there is no way for applications
to control the status of the backlight.
• The game should keep the backlight on by calling the User::ResetInactivityTime();
method every ten seconds. To save battery power, approximately a minute should go by before
the application allows the device to turn the lights off.

Most players think that sound in mobile games is nice but not necessary. In user testing conducted for
creating this guidelines document, users rarely commented on a game's sound, and when they did, the
comments were almost always negative. It is important not to annoy users with too many or loud
• Keep the sound volume close to the volume of the device's regular sound - not too quiet, but not
much louder, either.
• Sounds must not be too loud or too high-pitched, and users must be able to turn sounds off
easily. The game must be playable without sound and there must be a visual signal for each
event that the sounds symbolise.
• In Bluetooth multiplayer games, background music should be synchronised for all players to
avoid an auditory mess.
Allow the user to adjust the sound level of both background music and tones in those devices
where it is possible. Allow setting the volume close to silent. On some devices this has to be
done by setting the volume of sound files lower, or mixing the sound yourself, instead of just
relying on the audio APIs.
In this section:
• Use unique sounds
• Relay information
• Do not rely solely on sounds
• Profiles
• Alternative uses for mobile game audio

Use unique sounds

The sounds of a game must be different from the sounds of the device, as well as distinctive from each
other. The user must be able to differentiate among the sounds, even without seeing the screen.
• The sounds should be unique - they must not be confused with one another.
• Sounds should be consistent with what happens in the game - sad events should produce sad
sounds and happy events should produce happy sounds.
• The sounds must not sound like ring tones, SMS tones, and so on.

Relay information
The auditory channel is an excellent way to relay information about things that are outside the user's
attention. The user should be aware of what goes on in the game, which translates into using sound as a
way of communicating with the user. Also it is noteworthy that in Bluetooth multiplayer games, sounds
from one player's device relay information to other players as well, because players are close to each
other. Sad sounds from the opponent's game may be happy sounds for the winning user.
Sounds should convey information, and can be used as an additional channel to relay information to the

Do not rely solely on sounds

Very often mobile games are played in situations where sounds must be turned off. The game cannot
assume that the user has the sounds on.
• Make the game playable and understandable without sounds.
• See also Feedback.

If the users set their device to silent, they expect the game sounds to be silent, too. The user would be
surprised to hear background music or tones when the device is silent - especially if the game is being
played in a public place, such as in a church or a school.
• Provide a sound menu in the game to make sure the player can deactivate sounds.
• Game sound level should be adjusted according to the currently active profile. The
CSettingInfo interface can be used to determine the active profile.
• In mobile information device profile 2.0 (MIDP), MIDI sounds follow the device profile, but
tones played by games are audible, even when the device profile has been set to silent. Notice
that this is opposite from MIDP 1.0. The user will certainly be surprised to hear tones when the
device is silent - especially if the game is being played in a public place, such as in a church or a
school. It should also be noted that some S60 devices might not play the game tones and
background music at the same time.
• If the game has tones, they should be off by default.
• Inform the users in the help or alongside sound settings that if they have put the device in the
silent mode and still hear tones in the game, they need to turn them off in the game settings.
• Inform the users in the help or alongside sound settings that if they cannot hear background
music even if they have turned it on in the game settings, they need to change the device profile
from silent to another profile.

Alternative uses of mobile game audio

Alternative uses of sounds include audio games, games that are based purely on audio. Some current
audio-based games and resources are available at the Audiogames web site. These games are mainly
designed for the blind, but they offer many interesting insights for mobile game developers too.
Another direction are games that are affected by the music. The basic idea is that a music file, such as
an MP3 file or a ring tone, is analyzed, and the game events and characteristics are affected by the
selected background music.
Even a trivial game can be made interesting if the player can affect the game experience by changing
the background music to their favorite song.

Match with the real world

The game must be playable without the user having prior knowledge of how it works. In theory, this
means that a game could be solved and a high score reached in the first play session; in practice, this
should not be the case or the game will lack challenge. Game success must not depend on knowledge
of things about to happen in a game, such as where a treasure is located. Of course there can be secrets
and surprises within a game, but developers should not annoy users, for example, by killing them when
there is nothing they can do about it. For example, users should not be forced to take a 50/50 chance in
which the wrong selection kills them, or required to know what will happen next in order to make it
possible to clear that area of a game.
• Game challenge must not come from knowledge that a player must possess prior to playing.
In this section:
• Realism
• No invisible barriers
• Bonus and special features
• Getting killed

The rules of everyday physics are understood intuitively. For example, although people often make
mistakes in assessing the trajectories of objects, they are fairly good at estimating whether or not the
movement of an object is believable. This implicit knowledge should be exploited, not violated.
Applying realism to a game makes it feel more familiar and predictable.
• Do not force the players to learn new things when they can use prior knowledge. A realistic
physics model should be implemented in relevant games (racing games, for example).
• Do not expect that objects that are dangerous to a player in real life will be desirable in a game.
For example, in racing games the players might intuitively avoid hitting dangerous-looking
objects even if they are designed to give more speed.

No invisible barriers
If there are sections of the game area or level that the players should not access, they must be prevented
from going there. Areas that are inaccessible must look different from areas that are normally
• There should be no invisible walls or invisible barriers. If something is inaccessible, it should
not appear to be accessible, otherwise users will get frustrated.

Bonus and special features

Games should be variable to keep players interested. Special levels are features that bring more variety
to the play. They also increase the replayability of the game. However, if the game rules for these levels
are different, players must understand this.
• Provide variety in the game through bonus levels, changing game settings, or providing
different styles of game play. A natural reward and motivator is to reach the next, different-
looking setting, gain new abilities, or meet new opponents.
• Bonus and special levels must look distinctively different from normal levels; this can be
accomplished by using in-game help text, a different background, different sounds, and so on.
• The objective of the bonus level or special game play needs to be clearly stated if it differs from
the normal levels.
• If players can reach special levels by their own actions, the special level should start right after
the action (for example, finding a treasure or achieving a certain score). There must be a clear
connection between what the user does and what happens as a result.

Getting killed
If it is possible to die in a game, and particularly if the death comes as a surprise to the user, there must
be a short period of immunity where the user cannot die again and has time to recover.
• The player should be invulnerable for a moment after dying. This can be accomplished by
taking the user back to a safe place, shielding the user to prevent a hit, or taking the user back to
the beginning of the level.
In multiplayer games it is essential to know the status of the other players.
• If the user cannot see the other players, inform the user when somebody dies. Use the other
players' names and colour symbols so that the user can easily identify who has died.


Players need to know how they are doing and what they have accomplished. Fun is derived when
players know how they are succeeding and what they need to improve. In multiplayer games, the
challenge depends on other players. Therefore, the player needs to get feedback from other players'
actions, too. Players need feedback to understand the game situation, plan their own actions, and
evaluate how everybody is succeeding.
• Provide clear feedback on essential elements in the game: when a level is completed, when a
bonus level is reached, when the players succeed, or why they have failed (score a goal or kill
an enemy), and so on.
• Essential elements need visual feedback so that the game is playable without sounds. Some
ways of presenting feedback are more easily perceived than others. For example, a progress bar
or tally mark communicates amount (for example, player health or amount of strikes) better
than Arabic numerals.
• In multiplayer games, provide clear feedback about who has won and lost. Communicate to the
users about their performance by using "you" instead of a name or colour symbol.
When users are connected to a game server, they need to know what has happened and is happening in
order to know what to do next. If there is no feedback about interactions on the server, the user will
think the actions have failed.
• After the user has uploaded a file (for example, a clip or a ghost) to a server, provide clear
feedback that the file has been uploaded and where the destination folder is.
• After the user has sent a challenge to a friend, provide feedback that the challenge has been sent
See also Display status clearly and Give control to the user.

Display status clearly

The users must always understand their own current status and the status of other players. In particular,
critical information concerning topics such as a game character's health, weaponry, or money must be
conveyed to the user clearly and without the 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 in the game at all times. For example, in racing games the player should be able to follow
where others are on a map, in puzzle games the player should be able to see the scores of the
others, and in action games the player should at least be able to select the opponents and view
their status if it is not possible to show the status on the small screen all the time.

Give control to the user

The user needs to feel in control of the situation. The application must adapt to the user's way of doing
things, not vice versa.
• Give the users feedback on their actions. Click sounds and effects should begin within 50 ms of
the action. If the action takes between 0.5 to 2 seconds, provide an indication that something is
happening. If the expected pause is longer than two seconds, the users need to know how much
longer they must wait and, if possible, be able to switch to something else while waiting, or
cancel the current action.
• The user should not be forced to perform a specific procedure in a certain order. This applies to
the settings as well as to the game itself. Well-designed games allow the players to reach their
goal in many different ways.
• Users should not be left in a situation where they cannot affect their destiny in any real way. It is
frustrating to fail and not be able to do anything about it.
• Let the users get prepared, not in such a way that it ruins the game or provides no challenge, but
so that they can survive. In particular, this applies to game startup and continuing from a pause,
but also within the game itself.

Game design
Always aim for simplicity in the overall design.
• Make your game a minute to learn, a lifetime to master.
• Often additional rules make games more complicated but not better.
• It is often complicated to make things simple.
• Do not use too many different characters in a game - make sure each one is unique.
• Provide different game modes only if they are truly different and provide value.
See also Challenge.

In addition to being easy to use, games must be challenging enough for advanced users, but easy
enough for beginners to stay motivated.
• The challenge level needs to be near optimum. Too difficult means frustration, too easy means
boredom. Since players have different abilities, the game should either adjust difficulty
automatically or provide a setting to do so.
• Provide rewards early on to keep beginners motivated. Rewards can be new levels, abilities,
weapons, and so on. Providing rewards in a random schedule maintains motivation for the
longest time.
• Do not make the game more difficult by altering constants, such as the physics model attributes.
Instead, the challenge should come from making tasks and objectives more difficult. By altering
the constants, developers force players to learn a new set of rules, and once they have learned
them, the game is likely to be just as easy or hard as before; all that has been gained is an
extended learning curve.
• The AI of the games must meet several challenges. First, it must be reasonable and act pretty
much as a human would. It must be challenging for experienced players and there should not be
one single strategy that always wins.
In multiplayer games, the challenge depends on other players. When feasible, provide player-ranking
and player-matching systems that try to match players of equivalent skill against one another.

End key
According to the S60 UI Style Guide at Forum Nokia, the device should return to the idle state when
the user presses the End key within an application. The application should not be terminated. This is
logical and clear behaviour in single- and two-player games where the game can be paused. However,
in games with more than two players, the pause is not convenient. From S60 2nd Edition, Feature Pack
3 onwards, pressing the End key closes the application.
• In single- and two-player games, if the user presses the End key, pause the game and switch it to
the background. The player(s) should be able to continue the game.
• In games with more than two players, if the users press the End key, they are dropped from the
game or the game can be switched to the background without the game being paused. The other
players should be able to keep on playing. The preferred action depends on the game type. See
Overview of Multiplayer Mobile Game Design at Forum Nokia for more information.
• From S60 2nd Edition, Feature Pack 3 onwards, pressing the End key closes the application.
This can cause inconvenience to players on some devices.
• In Symbian games, it is possible to catch and ignore a
KAknUidValueEndKeyCloseEvent window server event in AppUI's
HandleWsEventL(). This sends the application in the background instead of closing
it. It should be possible to implement a save-and-exit behavior by catching that event,
saving the game state and then calling the base class implementation of
HandleWsEventL()with KAknUidValueEndKeyCloseEvent.
• In Java™ ME games the game can save the situation before closing. This is possible
with the destroyApp() method.
See also Pause.


Since mobile games are often played in restless contexts and on a communication device, games are
often interrupted. This means that there must be Pause and Save game features to make it possible to
continue an interrupted game later.
There are two recommended ways for implementing the pause feature. The first is having a separate
pause menu. This is recommended for more complex games. The other is combining the game main
menu and pause menu to a single menu. This is recommended for very simple games.
Tip: To quickly evaluate a mobile game's quality, take a look at its pause menu.
• Enable saved games. The current game should be saved automatically if the user exits before
the game is over, as in Snake. Other possibilities are to save at a certain location or save at the
end of a level.
• When in Pause mode, the game should go into its main menu or Pause menu where the first
command is "Continue game."
• The game should go into Pause mode for any of the following: an incoming call, a clock alarm,
a timer alarm, a calendar alarm, an incoming message, or an incoming infrared or Bluetooth
• If the game has been switched to the background, it should be checked if the user has changed
the profile to silent.
• If the game is switched to the background, the game should be paused. Music and vibra should
be off when the game is in the background.
• If the player exits the game with the End key, the game should not close, but stay open in the
• The hideNotify() method can be used to determine if the application is switched to the
• An application should not change focus from one screen to another within the hideNotify()
method (for example, Display.setCurrent(Displayable d)). In the S60 platform,
this causes focus to be regained by the game application. From the user's point of view, it looks
like pressing the End key or the Application key leads to the menu, which is not a desirable
effect. It is recommended to use the Shownotify() method for regaining focus when
changing display.
In this section:
• Disable sounds and music
• To pause or not to pause
• Pause in multiplayer games
• Actions in pause menu and resuming the game

Disable sounds and music

A game is often paused when something happens in the player's surroundings. Pressing the pause
button should automatically stop all the sounds, music, vibrations, and other animations.
• On platforms that support multitasking, it is essential that the game does not consume resources
while it is open in the background.
• Some games have even played sounds when in the background, and novice users might not
know how to close the application, except by powering off the whole device.
• Minimize the use of system resources when paused.
To pause or not to pause?
Some games might not seem to need a pause menu at all. There does not seem to be any point for a
pause menu in strategy games that do not contain real-time action. However, users still need a pause
feature - the ability to interrupt the game quickly and continue it later.
In Series 40 devices, the quickest way to quit a game is by pressing the End key. This should save the
current situation and quit the game. When the player later opens the game again, the first option should
be "continue game." So, even strategy games need a pause feature, but it can be implemented as
automatic saving and loading.
S60 games are similar but a bit more complex because of the platform's multitasking features. The user
can press the Application key (or also the End key prior to S60 2nd Edition, Feature Pack 3) to quickly
exit the game. The game should then be paused, and also saved.
The implementation of multitasking in S60 works well with interruptions, even so that users often do
not even notice it. Unfortunately, it cannot be relied on as an "automatic save game feature"; users
could power off the device, and thus lose the game.
Tip: Advanced S60 users may know that a game can be paused by opening the Power key menu and
selecting keypad lock. If this feature could be useful for pausing your game, it should be mentioned in
the game instructions. This feature could be useful for always-on games, which still need to be
physically paused, even if the game is not paused.
See also End key.

Pause in multiplayer games

Usually if one of the players is interrupted in a two-player game, the other player does not keep
playing. It should be possible to continue the game after the interruption, because short interruptions
are frequent in mobile contexts.
• The game should go into Pause mode for both players if one of the players is interrupted in any
of the ways mentioned in Pause and save game, above. It must be possible to continue the game.
• When in Pause mode, the game should go into its main menu or Pause menu where the first
command is "Continue 2-player game." It must be possible to quit the game during the pause,
because the interruption may take a long time.
• The player who was not interrupted should receive information about why the game is being
paused. For example, "Waiting for other player to continue."
In games with more than two players, other players may want to continue when one player is
interrupted; therefore, pausing everybody's game is not a convenient solution.
• Design games so that the interruption of one player does not interfere with the other players'
game. The interrupted player's game can be switched to the background without pausing the
game or the player can be dropped from the game. The preferred action depends on the game
• If the player is dropped, determine how to handle the drop and how to keep going in the game.
For example, players should be able to avoid dropping from the game by skipping the
For more information, see Overview of Multiplayer Mobile Game Design at Forum Nokia.
Actions in pause menu and resuming the game
The default action in a pause menu is, of course, resuming the game. The player should be able to
resume the game with the same key with which the game was paused. Using different keys for pause
and resume is not recommended and not very intuitive for the player. This is usually conveniently
implemented by having "Resume game" as the first option in the pause menu.
In addition to just pausing and resuming, provide options that might be useful for the player. In some
games, it might be a good idea to add options for other frequently needed actions, such as quickly
restarting the level or exiting the game.
Players should also be able to read Help topics without leaving the game. It is a good idea to add Help
topics to the pause menu. This way, players don't need to memorize all the instructions before trying
the game. This is an especially useful feature in complex games.
In action games, using the pause menu might get a player's character killed; typically, when the user
continues the action, the user might get surprised, or might not yet be prepared for the action. Some
common solutions for this include displaying the game situation in the background of the pause menu,
or not having the game action start instantly after the "resume" key press.

In-game help
Users do not typically remember help text. It is much better to provide information to users when they
need it. If it is relevant to their situation, it is more likely they will remember it.
• Provide in-game help to the user. The most common in-game help is to provide a separate
training mode or have the first level serve as a training level. The training mode can have
instructions, animations, and so on, to teach the game logic.
• In-game help can be provided in the form of "information items." When the player walks over
these items, text appears. If the text is very short, it can be displayed in full, such as "Thieves,
look out." For longer text, use text that tells the user how to access the longer text, for example,
"Press 8 to read note."
• It is important to keep in mind that help text must not interfere with the experienced players'
game. This can be accomplished by having a separate training mode or level or providing a
setting to switch in-game help off. Information items could also be designed so that they are not
picked accidentally. When using the training mode, the real game should not be instructed.
• There might not need to be a special visible item for help, although it is recommended. Short
text can appear automatically when the player encounters the first enemy of a certain kind, for
• Text should also appear when players encounter new items or new controls that they haven't
used before. Examples of in-game help include "Press 3 to jump," "Press 8 to dive," or "Take
the treasure."
• The in-game help system can also impart some of the game's story by, for example, telling the
player what must be done next. However, if this is necessary, it is possible that the story is
obscure and not immediately understandable by the player. It may be preferable to simplify the
game story.
• In-game help can also be provided for movement, especially if it is not evident that the player
can move. The first time the character is visible, show arrows around him and corresponding
controls beside the arrows.
• The in-game help feature should not stop the game. The players should be able to skip the help
should they so choose. Help text that pauses the game is annoying to advanced players.
• Controls should appear near the object they are controlling. For example, arrows with 4 and 6
could appear beside the player's character, not at the top or the bottom of the screen.
See also Help.

Latency in multiplayer games

In UDP and TCP connections, latency is likely to be in the one-to-three-second range. For many
multiplayer game categories, delays of several seconds are simply intolerable.
In real-time games, alter game design to address latency issues. For more information, see Overview of
Multiplayer Mobile Game Design at Forum Nokia.

Use the users' language and terminology. The user must understand what the game is trying to say. Use
natural language, not techno-babble. When feasible, the game should be localized to the user's native
• The game should employ the user's native language. Using the user's native language has a great
effect on the user experience: Users perceive labels faster, and nuances in meaning (for
example, comedy and wordplay) are better understood.
• Do not use difficult terminology, abbreviations (for example, pl. for player or l. for level), or
strange acronyms (for example, FPS, MMOG).
• Use consistent terminology and the same names throughout the game. Be consistent with the
device UI terminology, too.
• The game should employ the user's native language, ideally via the device's language settings. If
there are separate versions with different language strings, it is more difficult to keep them
updated and more complicated for the player. If the .jar size permits it, developers should
include all the relevant localization strings in the original package.
In this section:
• No foul language or offensive terms
• Make text easy to read

No foul language or offensive terms

Users may be offended by foul language, or its meaning may be wrongly conveyed to the user.
• Swearing or foul language should not be used.
• Use neutral, not offensive words.
• Users should be treated with respect. They should not be blamed for errors; rather, they should
be helped to recover from them.

Make text easy to read

• In devices with small screens, the amount of text in games should be minimal; users should not
be forced to read long passages of text on small screens.
• Scrolling text should be reasonably fast and smooth.
• Text should not be in ALL CAPS, because it is more difficult to read and understand. Capitalize
only the first letter.
• Text must be grammatically correct.
• Images should not substitute for essential text. Images and icons are typically more difficult to
perceive and interpret than single words. However, simple and generalized icons like arrows
may be superior to text.

Post-game guidelines
Usability guidelines presented in this section are related to post-game concepts.
In this section:
• Restart
• High-score list


If the users enjoy the game, they will probably want to play again as soon as possible. If the game has
settings such as player names or game modes, it is frustrating to set them again, even if the game helps
the user.
• Provide an easy way to restart the game. For example, in the Game Over screen, provide a
"Replay," "Play again," or "Restart" command, taking the user back to the beginning of the
game, with the same settings as before.
• In multiplayer games, provide a quick way to start a new game with the same opponent. Make it
easy to start a game with the same or different settings.
• Avoid long loading times or complicated dialogues when restarting the game.

High-score list
Keeping players motivated and providing a positive user experience are vital components for the
success of any mobile game. High-score lists are used to motivate players in almost every game.
While most games implement a high-score list, it frequently consists of nothing more than names and
scores. The essential question to bear in mind is this: What is the value of a high-score list to a player?
If the high-score list does not contribute anything positive to the player's experience, then it might be
perceived as an additional, useless step. The high-score list should feel like a reward, not a punishment!
In this section:
• Select appropriate, interesting scoring units
• High score list in single-player games
• High-score list in multiplayer games
• Only good scorers may enter their name

Select appropriate, interesting scoring units

Instead of simply counting "points," use a more concrete, game-relevant measure for success. For
example, completion time, distance achieved, or number of enemies killed/hostages freed are much
more interesting reflections of the game. Additionally, this kind of scoring creates a sense of continuity
between games and makes it easier to recall the feeling of achievement from previous games or
anticipate success in future games. Hence, the scoring system should be based on the type and context
of the game.

Prefer Avoid

Scoring units are related to the game world. The Only abstract points are displayed. It is not clear
results screen is interesting and useful. how well the player has succeeded.

High-score list in single-player games

When a player reaches the high-score list, a notification should be given. However, not all players care
about this. Therefore, the player should be asked what to do.
• There should be a high-score list if it fits the game idea. A high-score list motivates the player to
compete against the previous score or some friend's score.
• If the score is good enough to reach the high-score list, the game should say so, for example,
"Congratulations! You've reached 2nd place in the high-score list."
• Do not require the user to enter a name. Players should be able to skip the name entry with the
default back key.
• No more than ten high scores should be listed.
• Provide some predetermined values for the high-score list. This way the users receive feedback
on how good they really are - it adds to the reward value of the high-score list. Entering a name
for a bad score feels like a punishment, not like a reward.
• A name of certain length should not be required.
• The last entered name should be the default value for the name entry.
• Use of the predictive text entry for name entry should be avoided. Users do not expect it, and it
does not work well for names.
• Standard input method should be used for text entry, because they are already known to users. If
text entry has been implemented with game UI components, make sure that it works in devices
with a QWERTY keyboard too.

High-score list in multiplayer games

High-score lists are social in nature. Great score results are not just for a player's private enjoyment -
they are shared with others. This is a core feature of high-score lists: Players compare their
performances and brag about them with others! High scores and scoring systems also allow players to
compete with each other, or establish their own personal goals.
Games become more interesting when players can compare their performance with the performance of
possible community members.
• Give the users the possibility of updating their scores to the high-score list of the game
community despite the level of the scores.
• Show the user both the scores of some of the best players and the scores of players who
performed closest to the user.
• The last entered name in any text entry should be remembered and suggested as the default.
• Consider using the community high-score list in selecting opponents of equal strength for
multiplayer games.
A good scoring system also allows players to form a meta-game on top of the actual game. For
example, good games allow players to define their own goals, such as finishing a level with all bonus
points collected or all secrets found. Another example is letting players compete with each other by
comparing scores even in a single-player game.
Good online high-score lists are a bit more complicated to design. Players do not want to see just the
top 10 results; rather, they want something to which they can compare themselves. In multiplayer
games, players are often ranked so that they can compare themselves to others, view their rank, and
find equally skilled players for matches. In single-player games, temporary high-score lists can be used.
For example, a list of "Today's top players" provides everyone with a chance to get on the list, at least
for a few minutes. After all, high-score lists are all about feeling good about oneself; telling a player he
or she scored lowest among thousands of players is not very supportive.

Only good scorers may enter their name

Many games provide high-score lists with pre-filled results. Often character names from the game
world or from game development teams are used. This helps players measure their success, and
provides them with goals to achieve. This is a very good practice in mobile games, because it reduces
the amount of text entry and navigation. Forcing a player to go through the high-score list each time the
game ends may be frustrating, especially with a low score.

Prefer Avoid

The high-score list is pre-filled with results. The user has been forced to enter a name every time
The result from the just finished game is he or she has finished a game. As a result, the high-
highlighted. score list is full of blank names.

Case: Mobile action games

This section discusses the challenges and possibilities of designing action games for mobile devices.
Many of the issues presented relate to overall game design and game mechanics that aim to improve
the user experience, rather than details of technical implementation.
The action-game genre is a classic - there have been shooting, reaction-based concepts, and
platform-jumping games from the first days of the computer game industry. Their long-time presence
hasn't made them any less popular, however, action games still attract a lot of game players, and their
popularity is reflected in continuing success on the sales charts. Popularity also brings competition, and
today's successful action games really need to provide a quality game-playing experience that stands
out from the crowd. In a best-case scenario, a new game throws something completely fresh and unique
into the mix!
Why do action games remain so popular? It could be that they offer a simple, easy-to-understand
experience that provides instant gratification. Ideally, players should be able to pick up an action
game and simply start a new session; the basic rules of the game should be easy to learn and remember,
with easily grasped controls. Concurrently, the game world is highly visual, and the continuous flow of
action creates a captivating feeling of immersion in the game.
Action games fit the mobile use context perfectly. In the mobile world, players can reach for their
device in a bus or on a train and start a quick, convenient game-playing session. Within that mobile
world, goals should be accomplished quickly, and it's usually best if the game kicks into high gear
• Mobile considerations
• Keeping the player motivated and interested
• Speed and movement

Mobile considerations
When developing action games for the mobile environment, there are special considerations that result
from hardware issues. Keypad controls and display properties set certain limitations, as do processing
power and memory. The mobile-use context - that is, players are on the move, often with limited time
to invest - also imposes issues that should be considered in the game design.

Limited controls and keypad latency

The mobile device keypad is quite small and can be challenging to handle quickly. However, the
joystick-like navigation key is a natural choice for control, and very easy for players to learn. Game
designers should try to use the navigation key button for the primary action key. For secondary action
keys, use * and # .
Alternative navigation controls can be provided with the numeric keys (2 for up, 8 for down, 4 for left,
and 6 for right). Alternative controls are useful on devices where the keypad layout makes players
prone to press the End key by mistake. Avoid any situation where the player needs to press several
buttons at the same time or where control keys are located right next to each other.
Latency (time between key press and actual action) differs among different device models. Game
designers should make sure that the latency is acceptable for their target devices.

Display limitations
Mobile displays have limited space, resolution, and colour capacities. Typically, action games feature a
lot of objects appearing simultaneously on the game area. In the mobile context, the different game
objects (enemies, friendly characters, neutral objects) must be instantly recognisable by the player from
their colour or shape, while still retaining their small size. Also, the colour contrast between active
objects and the game background must be sufficient - remember that mobile devices are often used
outdoors, which can significantly reduce the legibility of the display.
However, making objects harder to recognise and tweaking the contrast between the object and the
background can be one element used to increase the level of difficulty in the game.

Device capabilities
A graphic-intensive game quickly uses up the limited resources of a mobile device. Problems with
memory capacity and processing power have a direct impact on the user experience of an action game.
If a special effect looks great but noticeably slows down the game playing, consider an alternative
solution. The key is early optimisation and testing on actual target devices.
All objects do not need to move at blazing-fast speeds, even in a fast-paced game. While it is essential
that the player control feels responsive, it's not necessary for every little background detail to be
animated smoothly or scroll quickly.

User errors
In the mobile-use context, users are prone to making errors due to interruptions while playing. The
game should always tolerate a few user errors. For example, the player character should endure a small
number of hits before getting killed, instead of experiencing an instant death.
Also, provide quick access to a "pause" game option. The pause option should be readily available, for
example, via the right softkey. Indicate the pause mode clearly on the display. Even when the game is
manually quit, players should have the option to continue where they left off when starting a next

Keeping the player motivated and interested

A game should keep the player motivated and interested during several sessions and over a long period
of time. Also, the game should provide enough content in the form of a variety of challenges and
rewards. If a player is able to play through the entire game quickly, then there is usually something
wrong with the game design or difficulty level. Conversely, a classic problem in action games is when
the player is made to repeat the same thing over and over because the level of difficulty is too great.
Combining repetition with little variety and a steep difficulty curve adds up to a bad user experience.
The game should have enough content (scenes, opponents, or levels) to last for several game sessions.
Increasing the difficulty level (for example, by speeding up the game and making enemies tougher) is
common between levels, as the player becomes more familiar with the game controls. The player
should also be allowed to skip the basic levels that have been completed in previous game sessions.
When a player has completed the game, he or she is eager to continue playing. A classic way to achieve
this is to loop and restart the game with an increased level of difficulty. Another way to create variety
and motivation is to allow the player to start the game over with different characters or ships with
different skills or qualities. For example, one character may be tough but move slowly, another may be
agile but possess less powerful weapons, and so on. Making different characters available as the game
progresses and as the player completes levels can also be a motivational factor.
Providing different power-ups that are available for a limited time can add depth and variety to game
playing. For example, in Alpha Wing II, the protective shield can be used for only a limited time before
it needs to reload, so the player must think strategically about when to use it. The player must carefully
plan when to be vulnerable and when to use the shield for protection.

Figure: Protective shield in Alpha Wing II prevents players from getting stuck. (Images courtesy of
Glu Mobile)
Speed and movement
Player immersion is a measure of how deeply the player is engaged with the game world and
experience. If the level of immersion is good, then the player is totally focused on the game.
Achieving this degree of involvement relies on a skillful combination of interaction and movement on
the screen, sound design, intuitive control, and content that keeps the player engaged. In action games,
the key is response and movement. Quiet moments or gaps in the action can serve to emphasize key
points in game playing.
Selecting the perspective and direction for movement can also be important. Perspective can have a
dramatic impact on the illusion of speed and action the game creates.

Figure: The scrolling direction limits the maximum game speed. The player's reaction speed limits the
game speed in horizontal and vertical directions; in an isometric game this is not a problem.
Action games need to be reactive, but do not always need to be fast. Game designers can also create
tension in environments that are slow moving. In some cases, the "slow motion" sense of impending
trouble can be more dramatic than a fast and frantic play that leaves no room for the player to take in
his or her position. The ability of the player to have an instant "elastic" response to any input is
important. Inertia, anticipation, suspense, and surprise are all tools in the action-game designer's
Sound design should support the action taking place on the screen, and game events should provide for
a sound effect . The user should be able to switch the sound on/off and control the volume.
As an action-game designer tool, the set of APIs that controls vibration or lights in the mobile device
has perhaps been underused. These controls have now reached a level of stability and support that
allows them to be used to highlight the player's experience. Battery drain and the slight delay that
occurs when initiating a motor response (such as the vibra effect) are trade-offs that designers should
take into consideration, but these tools can be highly effective if used at the right moment in game

Case: One button games

It has been said that the easiest game to use would consist of a single button labelled Push. When you
pushed it, the display would say, YOU WIN. The irony of this example is that while such a game
would have few, if any, usability issues, it clearly would not be much fun.
A small keypad and limited game controls are often considered major limitations in developing mobile
games. A typical mobile device keypad does not compare to a dedicated game control of a game
console: the mobile device keypad is optimised for navigating in menus, entering numbers and text
symbols, and general good looks, not for accurate manoeuvring in frantic action games. So how do
developers ensure rewarding gameplay experiences with only one button — and without compromising
• Turn input limitations into strengths
• Simplifying controls
• One button games
• Game design
Turn input limitations into strengths
Limitations in game controls can be seen as challenges to overcome. In Game Developer magazine,
Noah Falstain presents the Judo Rule:
“Turn your limitations into strengths.” “When you find yourself constrained by a difficult circumstance
or combination of limitations in design, look for a solution that turns those very limitations into a fun
solution. Try to make the limitations work in your favor, not against you.”
Noah Falstain in Game Developer. March 2006
Keypad limitation needs to be accepted in game design, and design should occur around this limitation.
Having ten keys for each game action is not a requirement for a fun game. The mobile device keypad is
not a limitation to the game experience itself — it is possible to design fun and challenging mobile
games with simple controls, too.

Simplifying controls
Pretty much everything can be done with one button only. The following list contains strategies and
examples for simplifying controls:
• Automatic action: Run forward automatically, for example.
• Combine several actions into one: Jump and shoot simultaneously, for example.
• Change action of button: Jump when facing an obstacle, but shoot when facing a monster, for
• Use different kind of button presses: Keep button pressed down to stop running; press once to
shoot; press twice to jump, for example.
These techniques can also be used to simplify game controls in “regular” mobile games. Many of these
solutions can be experimented with using Flash animations from the online article “One Button
Games” at (Berbank Green, 2005).

One button games

According to Kyu C. Lee, president of Gamevil, there are number of factors that make one-button
games popular and successful, especially on mobile handsets ("GDC: Success Factors of One-Button
Casual Mobile Games" at, 2006). These include the following:
• Better fit for small screens: One-button games are usually simple and don’t require much
effort from the user. One-button games can be enjoyed by the user even during mobility.
• Ease of play: One-button games are easy to play and can be targeted at and played by a wider
number of users, from a four-year-old child to his grandmother, and from casual to hardcore
• Addictive: One-button games are more engaging due to their simple nature.
• Shorter development cycle: One-button games are much easier to develop, and the time
required to develop them is considerably shorter compared to other types of games.

Game design
Some examples of one-button mobile games are presented below.
Figure: Skipping Stone sports surprising graphics and bonus events. Simple one-button gameplay
requires a sense of rhythm and accurate timing, which results in addictive gameplay. (Courtesy of

Figure: Kodo is a one-button multiplayer puzzle game. The game is played in one handset; each player
has one button for moving his Kodo. The direction of movement rotates automatically. (Courtesy of

Figure: Freerun has a nice, flowing experience when jumping from roof to roof. (Courtesy of
These games and a few others were evaluated for this document by game-experience specialists. The
following observations were made about the nature of one-button games.
One-button games are different from “regular” mobile games. The player does not need to focus his
attention on the controls or the keypad. He can fully focus on the gameplay and graphics. This means
that a one-button game should feel very responsive; animations need to be smooth and game actions
need to be immediate. Use animations, effects, and bonus graphics.
Timing and rhythm are essential for a positive experience. In one-button games, the game challenge
does not come from the skilled controlling of game characters, but rather from precise timing, fast
reactions, and the rhythm of actions. Achieving a good rhythm or completing a series of difficult
actions precisely on time is a key element in a good one-button game experience.
A lag between user key press and application response varies between different devices. Especially on
some older devices and Java™ Platform, Micro Edition (Java™ ME), formerly known as Java™ 2
Platform, Micro Edition (J2ME™) games, the keypad lag may affect the game experience. A game may
not run as smoothly as intended on all supported devices. Developers need to take this device-specific
lag into account when testing their game. To achieve the best results, timing and calculation of keypad
lag may need to be optimized for each supported device.
Due to the limitations of a one-button game, it should have many stages or levels so that the player has
a chance to rest his thumb.
To summarize:
• A mobile device keypad is not a limitation to the game experience.
• Animations need to be smooth and the game needs to feel responsive. Graphics should vary to
keep the player interested.
• Interaction should emphasize rhythm, timing, and skilled chains of actions.
• Techniques from one-button games can be used to simplify game controls in “normal” mobile

Case: Mixed reality games

This section takes a closer look at games that blur the line between the virtual and the real world:
mixed reality games. We examine some key qualities of the genre, offer a brief technology overview,
and provide several real-life examples. This particular game genre is still developing and is open to
new innovations and concepts.
Mixed reality games (or pervasive games) make the real-life world part of the game experience.
When a player's real-life attributes, such as geographical location or physical actions, have a direct
impact on the game, the game-playing experience becomes stronger and more personal. Pervasive
games are not necessarily tied to a certain time or medium. A game can surround the player all the
time, 24 hours a day. And the real world can be mixed with the game world in any number of different
game types - for example, a quick-and-simple sports game with innovative game controls or a highly
involved private detective game with an extensive background story woven into it.
The mobile platform works well for pervasive games because a mobile device goes wherever the player
goes, thus the means of interacting with the game is always present. Mobile phones and smart devices
enable connection to the network and an exchange of data from remote locations - whenever the player
wants it or the game mechanics demand it.

Figure: Pacmanhattan player receives running direction from a game operator via mobile phone. See for more information. (Image by Cristopher Hall)
An important aspect of pervasive game mechanics can be the social element, whether players are
playing against real opponents or working together as a team to meet the goals of the game. The mobile
platform provides plenty of options for supporting social interaction between individual players or
groups of players: traditional messaging, instant messaging, e-mail, Web, and conventional phone calls,
for example.
Mixed reality games have the distinction of being uniquely suited to mobile platforms. Game
designers should be aware that there are a number of possibilities for providing interaction with the real
world; this is only a broad overview of several game design options that are not often considered.
• Combine technologies to create innovation
• Alternative input methods
• Location-based possibilities
Combine technologies to create innovation
A number of exciting mobile technologies support innovative pervasive game design. Some of the
technologies are already in everyday use, while others will emerge in the near future. Note that design
and development should never be entirely driven by technology and features. Technology should
support and enable brilliant game concepts, not the other way around.
The key to creating innovative concepts lies in combining technologies. For example, a common digital
camera combined with the possibility of instant communication with others and the ability to upload
location-aware content to the Internet opens up a realm of completely new possibilities. The result is
much more than the sum of its parts.
Consider the possibilities of combining some of the following technologies:
• Camera: Offers the ability to display and capture images and utilise them instantly, also over a
network connection. A camera can be also used to generate in-game objects, such as game
levels, characters, and objects.
• Microphone: Offers the possibility of speech input and voice controls.
• Locationing (Cell ID and GPS): Offers the ability to use players' real-world location or
movement as a game mechanic.
• Touchscreen: Offers new input possibilities where the UI can be used more freely. Devices
supporting touch input will be introduced in the near future.
• Internet services: Web access, RSS feeds, discussion boards, blogs, and Wikis provide instant
possibilities for sharing and producing content globally between communities.
• RFID and Near Field Communication (NFC): While still far from common, these
technologies enable actually touching real-life objects with a mobile device.
• Bluetooth: Can be used to detect proximity of other devices and players.
• Acceleration sensors: Already on some devices; they enable real physical interaction, not
limited to button pushing.

Alternative input methods

In devices such as the Nintendo Wii and Nintendo DS, the innovative use of input and control methods
has given a completely new twist to older game genres. Being able to touch the device screen and
manipulate the UI by hand allows players more freedom than simply using the keypad for input.

Figure: The Groove Labyrinth game in the Nokia 5500 Sport uses a motion sensor that allows the
player to control a marble by physically tilting the device. Other designs have used a camera to achieve
a similar effect.
Designers should not overlook the more obvious input methods, such as using the microphone on a
mobile device. Voice commands can be used in fun, creative ways - to make the player sing a tune, for
example. Consider bending the traditional rules for non-intrusive use of the device and break them
However, innovative input methods should not be used simply to put on a show of technology - they
should provide real, added value to the game. Refine the methods so that the resulting control is both
intuitive and responsive.

Location-based possibilities
Mobile device locations can be tracked in the cellular network with Cell ID information (the device is
always connected to a certain cell in the network) and with satellite GPS tracking. Some Nokia devices
feature a built-in GPS receiver, and external GPS devices can be used to connect with many Nokia
For example, in the game The Journey 2, the player takes the role of a private investigator. While
playing the game, the player moves in his or her surroundings and interacts with different locations.
The game is implemented by using the Cell ID in the mobile network, which enables the game to
distinguish the player's different locations. GPS adds more accuracy to location-based applications.
Utilising the wireless connection, it is possible to share location information between players. The
game RealReplay allows players to record and share virtual race tracks and compete against other
One popular way to use GPS is geocaching: hiding some item on a specific location and providing this
information to a community as GPS coordinates. Consider a massive multiplayer treasure hunt game,
where individual players or different teams try to find all clues from various locations before their
opponents do.
Note that there are limitations to location technologies. GPS may not work indoors or in large urban
cities with very tall buildings. When considering the use of Cell ID, remember that network cell sizes
may be large in some areas, so having the player walk to the neighbouring cell might be quite an
exercise. Privacy issues are another important consideration when using location-based solutions -
players should know how the location data is being used.

Mobile game graphics

• Graphics appeal
• Device restrictions
• Overcoming the display challenge

Graphics appeal
Great graphics provide great experiences! With games, graphic attractiveness is a key element in
creating an enjoyable user experience. In fact, the first impression and the entire mood of a game
session are created in the first few seconds after the user has launched a game. Providing a WOW!
effect right at the start sets a positive tone for the whole session.
Figure: Ancient Empires II is a good example of using transition animations and text to create a feeling
of interactivity. (Images courtesy of Glu mobile)
Designing graphics for mobile games is very different from designing for PC games. This section
presents some best practices and visual examples of graphic design for mobile games. It also focuses
on overcoming some of the main usability and user experience limitations: the small screen size (with
portrait and landscape modes) and the mobile context.
For more general information on S60 graphics, see S60 Platform: Visualization and Graphic Design

Device restrictions
The main restrictions a mobile device imposes on graphics and artistic freedom are the following:
• Available memory size
• The processor capacity
• Limited display size and resolution
If a game runs slowly or a device freezes, this is not a good gaming experience. Additionally, a game
application should not use up other system resources, such as battery power. The overall user
experience is not good if, for example, the battery dies shortly after an intense gaming session while the
user is traveling on a train.
Performance issues can be addressed with good design, proper planning, and testing. Use only graphics
that are meaningful, limit the use of large graphics, and consider carefully which animations are really
needed. Check to see if there are alternatives; for example, find out if some animations (such as
sparkling stars) can be implemented with a few lines of simple code.
Finding a balance between good graphics and device limitations is an iterative process - test early, and
test often!

Overcoming the display challenge

The display of the mobile device sets the primary limitations for game graphics. The most critical
display limitations are screen contrast and small size.
• Contrast
• Use clear and meaningful graphics
• Limited display space
• Landscape mode
Mobile games are often played in situations where viewing the screen is challenging when different
game objects need to be clearly differentiated from the game background. For example, bright sunlight
requires very good contrast to make objects on the screen easily visible. Playing a game on a moving
vehicle, such as a bus or a train, makes it harder to perceive movement on the screen.

Figure: Contrast affects the gameplay. (Images courtesy of Glu Mobile)

On the other hand, decreasing contrast between the background and the game objects and adding more
action on the screen can be a good game mechanism for increasing the level of difficulty (for example,
in a shoot-'em-up action game). Remember to implement this kind of effect gradually, and only in the
later stages of the game when the user has mastered all the game controls.

Figure: Alpha Wing II uses contrast to increase game difficulty in later levels. It is difficult to notice
enemy ships from fast-moving 3D background with similar colours. (Images Courtesy of Glu Mobile)

Use clear and meaningful graphics

Mobile display size is limited, so make sure that every graphic element has a purpose. Inefficient use of
graphics in mobile games creates clutter and visual noise on the small screen, increases the file size of
the game, slows the game, and impairs the playability and user experience. Every graphic element
(whether a game character, an animation, or a background object) should always have a justification for
its existence and guide the player toward achieving the required goals.
Although the mobile screen is small, graphics must be clear and sufficiently large. A mobile player may
get distracted and lose focus during a game - the graphics should allow him or her to quickly and easily
return to the game and resume play. Small items on the screen can be easily missed.
A clear distinction between different objects is important. For example, differentiate clearly between
friendly and opposing game characters, dangers, obstacles, bonuses, and especially the player's
character. The player should be able to easily identify enemies within a reasonable period of time.
Different shapes, appearances, colours, sizes, and actions can help the player recognise various objects
in the game. In multiplayer games, the friendly characters must be clearly differentiated so that players
can identify who is who.
Figure: In Ancient Empires II, consistent colour coding is used through the game to separate
friends from foes. (Images courtesy of Glue mobile)For more information, see Full-screen usage
in S60 at Forum Nokia.

Limited display space

Apply the judo rule: Turn your weaknesses into your strengths. If you cannot escape the limitations of
the small screen, use them to your advantage. Think of ways to turn the screen size into an integral part
of gameplay - part of the game's challenge that the player must learn to overcome. Make the small
screen a cognitive challenge, not just a visual limitation.
One design strategy is to emphasize the importance of what is not displayed on the screen. This means
that the game area should be bigger than the screen area. Knowing, remembering, anticipating, and
guessing what is outside the field of vision can be an essential part of the game experience!
Some example scenarios include platform jumping games or first person shooters, where the screen
only displays what is in front of the player character. When the player cannot see what is behind or
around him or her, the player must be careful of a possible enemy hiding around the corner.

Figure: Lock'n Load 2 is a good example of a 3D game that expands the game world outside the screen
limits. (Images courtesy of Blaze)

Landscape mode
When using a mobile device in landscape (that is, using a widescreen orientation), there are a few
issues you have to consider. The landscape mode (for example, Gallery application in the latest S60 3rd
Edition devices) can be very useful for some game types, such as platform games, where scrolling from
left-to-right (or right-to-left) is needed. Some devices can also be ergonomically better for longer game
sessions in the landscape mode.
Figure: Games should handle screen orientation change correctly.
In many cases changing the display orientation for an existing application will require a lot of re-work,
if this requirement was not considered already at the design phase or if the whole game was designed
for a certain orientation. The latest S60 devices include both devices with fixed landscape screens, and
also devices where the screen orientation can be changed by the user (either physically by turning the
screen or with software by executing the rotate application). In general the application should adapt to
the orientation the user has chosen. Unless considered early in the game design, the requirement to
handle the orientation change "on the fly" may be difficult even if graphics and layout could scale.
Locking to a certain orientation is not recommended, unless it is a crucial aspect of that gameplay
There are a some usability considerations you should remember:
• Using the keypad and controls can be more difficult if the device screen is held horizontally.
The user is likely to make more mistakes in fast-paced games. Design the controls accordingly.
• Use softkeys correctly also in horizontal orientation:
• When the keypad is to the right of the display, the upper softkey corresponds to the right
softkey functionality (Exit, Back, Cancel) and the lower softkey corresponds with the
left softkey functionality.
• When the keypad is to the left of the display, the upper softkey corresponds to the left
softkey functionality (Accept, Options) and the lower softkey corresponds with the right
softkey (Exit, Back, Cancel).
The most important issue to remember is that many Nokia devices are capable of using (and changing
between) both portrait and landscape screen orientation. It is important for the developer to consider
this, and at least inform the user if the game is unable to support both orientations. Leaving the user
with a blank screen or application that ignores the change is the worst outcome.

Selling the game experience

This section gives guidance to game developers and distributors on how to sell and deliver positive
game experiences. A game experience research team analyzed top selling games and some of their sales
portals on three continents: Asia, Europe, and North America. Two or three portals from each continent
and altogether 30 games were informally evaluated and analyzed, but no user testing was conducted
this time. Names or game titles are not mentioned to protect the reputation of developers.
Instead of focusing on reporting research results, this section concentrates on giving insights to game
developers, publishers, distributors, and intellectual property owners for building a mobile game
market with a lasting value.
This is what we learned: There are some fantastic games, but there are also games with substandard
quality, offering poor game experience. However, the marketing material, concept, or branding of the
top selling games have some interesting properties that game developers concentrating on high quality
games should take into account.
In this section:
• Developers dilemma
• Distributing in style
• Quality in possession
Developers' dilemma
Unlike computer games, mobile games are often spontaneous, not very well thought-out purchases.
Mobile games, ring tones, and logos are massively advertised in many magazines, Web sites and WAP
portals, and even in television, but rarely reviewed. Typically the advertisement is crammed with games
— there is something for everyone.
Mobile games are bought with very little information about the game itself. Sometimes only the game
name is shown, with a screenshot and a few descriptive sentences. Actual reviews are usually seen only
in dedicated media for hardcore game players.
Given this, it is no wonder that consumers seem to go for the familiar-looking games based on licensed
intellectual property or familiar game types. A game experience is not just about the game. The player's
current experience is affected by his past. Previous experiences, knowledge, and opinions all have an
effect on how he feels about playing the game. When browsing a game list, a familiar-looking movie
title or game type might just be the thing that gets the user’s attention.
There is only so much that can be communicated with just a few words, or in a single picture, but still
all the necessary elements should be present. The key is to keep the game titles informative. You need
to grab users’ attention with something that they can relate to their previous experiences. According to
our sample, at least the following strategies can be used to attract the attention of potential players:
• Licensing, for example movie titles, other games, comics, athletes, or celebrities.
• Familiar game type, for example, by using familiar words like "Strategy," "Tycoon," "Action,"
"Shoot," "Adventure," "Puzzle," or "Racer."
• Familiar mood and genre, by using words and images like "Mafia," "Tank," "Food," "Soccer,"
"Fighting," "Puppy," "Boyfriend," "Kittens," or "Bad."
• Referring to a specific local or global cultural heritage, by utilising concepts like "Dragon,"
"Baseball," or "Pub."
The same idea goes for the detailed game descriptions and pictures — they should communicate
something about the game. Using screenshots from the actual game is a good practice because it is hard
to be more descriptive than that.
The game visuals, name, and brand should communicate the game concept and idea. They should have
"mental hooks" that can be easily connected to previous experiences and things people like. Also
understanding the local nature of mobile content is important.
You do not have to please everyone — it is far better to catch the full attention of those who might be
interested in your game. The mobile content business is inherently local — see, for example, the ring
tone and background image advertisements in a newspaper. The following figure is an example of the
dragon game marketing material. The screenshots and game description communicate effectively the
genre and type of game. Note also that this game is more localised to Western markets, where
"Dragons" are associated with less positive attributes than in Eastern cultures.
Example marketing material

Figure: Marketing images

Be a fire-breathing dragon! Burn down villages, hunt flocks of cattle, gather treasures, and fight against
human armies. Use the power of your wings and fire to destroy as many helpless humans as you can.
Game missions include burning down all buildings, attacking heavily armed fortresses, and duelling
with knights, as well as keeping the energy level above the critical level by eating cattle.

Distributing in style
Providing low-quality games that sell well because of good titles is not only short-sighted but it also
hurts the mobile game markets. The whole industry needs to work together to ensure the quality of
mobile content. There are lots of excellent games offering positive user experiences. The problem is
that they might not be promoted to users. From the game distributor point of view this means that they
• Focus on quality games. Do not just promote games with familiar names from the latest
blockbuster movies. Good titles may sell games on short term, but on the longer term only
quality games and a positive overall user experience make customers come back.
• Provide enough information about the mobile games. This makes it easier for users to find the
quality games they like. Use several pictures and include actual screenshots. It would be even
better to offer animations or downloadable game demos.
• Ensure the positive user experience in game sales channels, including the downloading and
payment process.
• Determine the right metrics for success. Focusing on the numbers of short-term sales may
distort the picture towards games with good titles, regardless of the content quality. Develop
metrics for measuring the game experience and customer satisfaction for a long-lasting value.
Because digital “shelf space” is a major issue in selling mobile games, it should be used wisely. Good
visibility can sell any game well, but it can sell an excellent game even better.

Quality in possession
Developing mobile games is challenging, but it is not rocket science. Intellectual property owners
should focus on and demand a high quality implementation of their property.
The right developers are able to produce a high-quality game experience. Methods, tools, and services
to ensure game experience quality have been available for several years.
There are lots of excellent games offering positive user experiences, and the whole mobile industry
needs to work together to ensure that they are delivered to users.

Mobile game playability heuristics

This section describes how mobile game heuristics can be used for evaluating mobile games. The
heuristics are described in detail and an example of how to expand the model to apply to new kinds of
games is given.
The intended audience includes the following:
• Usability experts who evaluate the playability of mobile games and are familiar with the expert
evaluation method.
• Game designers who work in game development projects. They can use heuristics as a check
list to avoid the most common playability problems in games.
Expert evaluation is a widely used method for evaluating the usability of utility software. In those
evaluations usability experts evaluate software against general usability heuristics. An example of such
a list is Jacob Nielsen's Ten Usability Heuristics.
Usability of utility software is often understood as effectiveness, efficiency, and satisfaction.
Additionally, users usually have certain tasks that they try to accomplish with the application. Usability
heuristics are designed for evaluating these things.
Games differ from utility software in some key characteristics.
• In games, the purpose is to have fun and enjoy playing the game.
• Learning to play the game, solving problems, or discovering new things is part of the
• In a game, the players do not know what to expect in advance.
• Game designers have created the game content and defined goals that the players must achieve.
The heuristics are a result of game design literature review, playability evaluations of mobile games,
and consultation of game design experts.
Our heuristic model for mobile games is modular and consists of three core modules:
• Game usability
• Mobility
• Gameplay
These modules form the core and they are common for all mobile games. However, there are specific
mobile game types, for instance, multi-player games or pervasive games that have characteristics that
are not covered in these modules. Therefore, new modules need to be added to the model. All the
feedback on using the model is more than welcome and can be submitted through the Forum Nokia
Resource Evaluation form.

Figure: Modules in the core playability model

Gameplay is the "heart of the game." When the structure of our model is presented as layers, it is
evident that the outer levels need to work properly before the player can access the core gameplay.
Typically problems occurring in the two outer layers are out of the scope of the evaluation, but with
some new mobile game styles, such as public-screen games, the evaluators need to consider these
aspects as well. Once platform and software are stable, evaluators can start evaluating game usability,
mobility, and gameplay issues. It should be noted that it does not have to be done in this order.

Figure: The different layers that a player needs to pass in order to access the core gameplay of the
In this section:
• Using the heuristics in expert evaluations
• Mobile gameplay heuristics
• Adding new modules: Multiplayer game heuristics
• Terms and abbreviations
• Mobile game playability heuristics reference sheet

Using the heuristics in expert evaluations

These heuristics are especially designed for evaluating mobile games. However, most of the heuristics
can be applied to other games as well. For instance, the heuristic for allowing interruptions is closely
tied with the mobility of the game, but the heuristic that recommends providing clear goals for the
players is relevant in any game.
The heuristics are designed to be used in evaluating game playability in expert evaluations or
playability testing, but it is also possible to use them as a design tool. The heuristic model provides
guidelines for good playability in mobile games. However, for well-grounded design reasons,
breaking a heuristic is perfectly alright. Some heuristics can conflict with each other in some
situations, but with good design and right balancing designers can overcome these conflicts. For
instance, allowing players to express themselves and preventing deviant behaviour in the game may
require compromises.
In this section:
• Expert evaluations and heuristics in practise
• Expert evaluations support playability testing

Expert evaluations and heuristics in practice

Expert evaluations are used for evaluating the playability of mobile games. In an expert evaluation, the
evaluated game is tested by game design and usability experts against the playability heuristics. The
evaluators can evaluate the game as whole, or take only one part (for example, battle or trading) and
evaluate it against the heuristics. The game can be also evaluated against a certain module at a time, for
The expert evaluation needs to be done with the target group in mind. When the experts find problems
in the game, they map them to the heuristics and categorize the seriousness of the problem (a three-step
scale from major to medium to minimum). An evaluation form can be used to ease remembering the
heuristics and documenting the problems (see Mobile game playability heuristics reference sheet).
The team that evaluates the game is usually not the same as the one that designs it. As in other kind of
software testing, the team that designs or implements the application often becomes blind to its own
errors. The sooner expert evaluations are used in a game project, the better. It is possible and
recommended to evaluate a game already when there is a simple prototype that demonstrates a certain
aspect, for example, moving in the game world.
For each evaluation, the game developer needs to deliver the game prototype or document, that will be
evaluated, and a release note. The release note describes which functionalities are supposed to be
already in place and which ones are missing.

Expert evaluations support playability testing

In playability testing, real players play the game either in a laboratory or in their normal environment
(field testing). The data is gathered with direct observation, interviews, play diaries, questionnaires, or
a mixture of these methods. Other user-centred design methods, such as focus group discussions, can
be used early in the project.

Figure: Evaluation methods in different phases of the game project

It is recommended to do an expert evaluation for the fully working game before starting the playability
testing with real players. When this is done well in time, it helps to catch and fix the obvious problems
with the usability and game interface. If the problems that are reported after expert evaluation are not
fixed, they will typically be rediscovered in playability testing. The expert evaluation also helps
planning the test and focusing on the right issues in playability testing.
The purpose of playability testing is not to catch software bugs - even if software bugs tend to turn up
in playability testing of very early prototypes - but to discover playability problems with real players.
Mobile gameplay heuristics
Mobile gameplay heuristics are divided into three categories:
• Game usability
• Mobility
• Gameplay
Game usability heuristics contain also mobile game-specific issues that are highlighted in the text.

Game usability
The game usability heuristics cover the game controls and interface through which the player interacts
with the game. As a general rule, the game interface should allow the player to control the game
fluently and display all the necessary information about the game status and possible actions. The game
interface is usually the first thing that a player encounters when starting to play a new game. Good
game usability ensures that the player will have another enjoyable play session.

No. Game usability heuristics

GU1 Audio-visual representation supports the game

GU2 Screen layout is efficient and visually pleasing

GU3 Device UI and game UI are used for their own purposes

GU4 Indicators are visible

GU5 The player understands the terminology

GU6 Navigation is consistent, logical, and minimalist

GU7 Control keys are consistent and follow standard conventions

GU8 Game controls are convenient and flexible

GU9 The game gives feedback on the player's actions

GU10 The player cannot make irreversible errors

GU11 The player does not have to memorize things unnecessarily

GU12 The game contains help

GU1. Audio-visual representation supports the
Due to the rapid development of graphic cards, games look visually appealing and the players expect
that, too. However, the game graphics should support gameplay and story and be informative for the
player. In addition, the graphical look and feel should be consistent throughout the game.
Audio can be used to evoke emotions and increase immersion. A good sound environment in the game
supports a positive gaming experience. Normally, there are two types of audio present in the game:
music and sound effects. Both of these have their own roles in creating the sound environment and they
should work together seamlessly and not create cacophony.
The graphics or audio should not prevent the player from performing actions or make them
unnecessarily difficult. For instance, using a nice 3D camera effect may look cool, but may make the
game unnecessarily difficult to play.

Mobile game-specific issues:

Mobile games are played both outdoors and indoors. The game should be playable in different
lightning conditions. In addition, the display usually shakes and moves because it is integrated with
input devices. For these reasons, our experience shows that it is preferable to use high contrast with
Mobile games can also be played in situations where non-players need to be taken into account. It
should always be possible to control the volume level of the game or mute the game (see also GU3:
The game accommodates with the surroundings). The game should never use audio as the only
resource of providing feedback because players might be playing the game muted and are not able to
hear sounds.

GU2. Screen layouts are efficient and visually

Designing a good layout is not always easy. The layout should present all necessary information for the
player, but on the other hand, if the screen is filled with all kinds of information, it starts to look
crowded. Also, games should follow the general principles of good screen layout design. It is important
that the player finds the navigation controls and that they are not mixed with the information that needs
to be visible on the screen.

Mobile game-specific issues:

In general, this heuristic is specifically important for mobile games due to limited screen space.
Designing the layout for a mobile-phone screen can be challenging, but a good rule of thumb is that
information that is frequently needed should be visible to the player all the time.
GU3. Device UI and the game UI are used for
their own purposes
It should always be noticeable whether the player is dealing with the game user interface or device
functions. The game interface should not use the device's user interface widgets in the game interface,
because it breaks the immersion. The most impressive immersion is achieved when the game uses full-
screen mode hiding other features.

Mobile game-specific issues:

In mobile games, some features of the device, for example the network connection, should be visible in
the game interface. However, the game should present this information using user interface widgets
that are consistent with other elements in the game.

GU4. Indicators are visible

The player should see the information that is required for being able to play the game. An example of
this kind of information could be the status of a game character. Information that is frequently needed
should be visible for the player all the time, if possible. The player should always know the current
state of the game, for example, whose turn it is to make the next move. Indicators for critical gameplay
information should be presented to the player clearly enough. For instance, the player will feel very
frustrated if the game character dies suddenly of starvation, when here was no indicator that it was
starving. However, the "less is more" principle is also important: information that is not critical or used
frequently should not be visible all the time.

Mobile game-specific issues:

In mobile devices, there are different indicators for device functions that need to be visible during the
mobile game. These can be, for instance, the typing modality of the keypad (such as number,
alphabetical, or T9) or the connection indicators (such as Bluetooth). In addition, the player might want
to know the battery level and time during a game session.

GU5. The player understands the terminology

The terminology that is used in the game should be understandable and not misleading or unfamiliar for
the players. A similar rule also appears in Jacob Nielsen's original usability heuristics. Technical jargon
should be avoided. For example, terminology that is related to the game concept, or features that the
game needs from the device, should be translated into more understandable language. In network
games, the player usually needs to connect to a game server before the play session can start. The
command for doing this could be "Connect to the server." However, from the player's point of view, it
is not interesting to connect to the server, but rather to join the game. In this case, a more
understandable command name would be "Join the game."
GU6. Navigation is consistent, logical, and
The player navigates in the game menu (which usually consists of settings and selections for the
desired game session) and in the game world, if the game has one.
In the game UI, different functions should be organized logically, and possibly on different screens.
Long navigation paths in the game menu should be avoided - short navigation paths provide more
clarity and are easier to remember. In the main game menu, the player should be able to start a game
and have access to other important game features.
In the game world, navigation should be intuitive and natural. The game world can be either a 3D
world with forests and mountains, or a table of cards or another simplified representation in 2D.
Regardless of the complexity of the game world, players should be able to navigate there smoothly.
With a proper set of control keys, navigation can be very intuitive and almost invisible.

Mobile game-specific issues:

The navigation on a mobile device is not easy because of the small screen and limited input devices.
Mobile devices have two kinds of navigation controls: permanent and temporary navigation keys.
Permanent navigation keys should be used primarily for navigation. Temporary navigation keys are
often related to applications or to a specific user interface style. Since the games do not necessarily
need to follow the device's user interface style, the use of these keys can be more flexible.

GU7. Control keys are consistent and follow

standard conventions
Using common conventions reduces the time that is needed to learn to use any software application.
The same applies to games: using standard control keys reduces the time that is required for learning to
play the game since the player can use his or her knowledge from other games. Game devices usually
have specific keys for certain actions and every game should follow them.

Mobile game-specific issues:

The mobile device is a relatively new kind of device for playing games, but a few conventions already
exist. For example, number five on the mobile device's keypad is usually the selection key. Game user
experience guidelines specify control keys for mobile games.
One interesting thing about mobile devices is the design driver of the device. If the device is meant to
be operated one-handed, the game should be playable with one hand. Correspondingly, the device's
standard input methods should be used for controlling the game.

GU8. Game controls are flexible and convenient

Novice players usually need only a subset of the controls when they start playing the game, while
veteran players often need shortcuts and more advanced commands. It should then be possible to
customise the game controls or use shortcuts or macros. However, using shortcuts should not provide a
major edge in a competitive player vs. player game.
The configurability and amount of controls needed to play the game should be kept at the minimum,
but they need to be sufficient. Additionally, the controls should be designed according to the device's

Mobile game-specific issues:

Currently, mobile devices may not be as flexible as most of the other game devices and the possibilities
to customise game controls are often limited. In mobile phones, some functions are specifically
assigned to certain keys and they should be accessible even though the device is used for playing
games. This reduces the number of available keys for controlling the game.
The mobile device is primarily used for communication. The player should be able to manage incoming
calls during a game session. Two keys are assigned for call handling and they should never be used for
controlling the game:
• The Send key (usually identified with a green symbol) is for answering calls. This will also
move the game to the background because in-call functions are activated.
• The End key (usually identified with a red symbol) is for rejecting incoming calls.
Additionally, some keys are defined dynamically. Following the conventions of using such keys is not
always straightforward.

GU9. The game gives feedback on the player's

A good user interface has a low response time on the player's actions. An action can be either a single
key press or a more complicated input sequence. The player should notice immediately that the game
has recognised the action by providing feedback. The most common way of providing feedback is to
present it graphically. Other alternatives are to use audio or tactile feedback. Providing only auditory
feedback is not acceptable since a player may be playing the game without sounds.
Although the game needs to respond immediately to the player's actions, the consequences of the action
can be shown to the player later. If an action cannot be performed immediately, the game should notify
the player that it takes time.

Mobile game-specific issues:

In mobile devices, the network connection is usually considerably slower than in other game platforms
and it can create latency in the response time, making the game unplayable. Usually the players try to
repeat the command because it may seem that the input was not received. Mobile devices also lack
processing power compared to other game platforms, but this gap decreases constantly.
GU10. The player cannot make irreversible
The game should confirm actions that can cause serious and irreversible damage. Also, when mistakes
happen, it is helpful to enable recovery. In games, making errors is often part of the gameplay.
However, this heuristic deals with errors that are related to the bad usability of the game user interface.
Errors often happen when the player deletes game objects, such as avatars or items. Sometimes,
however, the errors can be related to positive things that must be done, but the time is just not right.

GU11. The player does not have to memorize

things unnecessarily
Jacob Nielsen has stated that a software application should not stress the user's memory unnecessarily.
This applies to game user interface design as well. Sometimes, however, the challenge in the game can
be memorizing.

GU12. The game contains help

The game teaches the player what he or she needs to know to start playing the game. The players do not
often read manuals, and a mobile game does not usually even have a paper manual. Even though a
tutorial mode at the beginning of the game is usually helpful, having a complete tutorial is not well
suited for a mobile game. The players do not necessarily encounter or need everything during the first
play sessions.
If tutorials are used, they should be entertaining and rewarding, and part of the actual game. A mobile
game should entertain the player even if he or she would only have a couple of minutes available to
play it. The player should be able to accomplish something in the game within the first five minutes.
The tutorial should be divided into chapters that teach a couple of things that the player needs during
the first play sessions. Ideally, the tutorial could be embedded completely in the game so that help
would be provided every time when it is really needed.
Help is also often needed in error situations. If the game provides useful error messages, the player can
understand better what caused the problem.

The mobility heuristics concern issues that affect the mobility of the game. Because mobile devices are
flexible with when and where games are played, the game design should assimilate this freedom into
the game experience as well.

No. Mobility heuristics

MO1 The game and play sessions can be started
MO2 The game accommodates with the surroundings
MO3 Interruptions are handled reasonably
MO1. The game and play sessions can be started
The players should be able to start game sessions quickly and easily, preferably in less than five
seconds. A play session of a mobile game is usually shorter than a play session of a computer or
console game. Browsing in a game menu consumes precious game-playing time and actions that need
to be done frequently in the game should not be hidden behind a long navigation path either.
Introduction sections or other startup screens are very common in computer and console games. These
are used for transferring the player into the game world or advertising the game developer or the
publisher. In mobile games, long intros are not recommended since they take too much time. There can
be an introduction but the player should have the possibility to skip it.
Games usually contain multiple settings for customising the game user interface or giving information
about the player or input devices. If these default settings are good for most of the players, they will be
able to access the game faster. In addition, the game should store any changes that the player makes to
the settings.

MO2. The game accommodates with

Computer and console games are usually played indoors where disturbance is minimal. However,
mobile devices have changed this pattern and mobile games are played everywhere. This sets new
demands for graphics and audio.
Mobile games may sometimes disturb non-players who are in the same environment. Noise is the most
typical way of disturbing other persons in the vicinity. A game should provide means for conveniently
adjusting the volume level or muting the game. If the volume level settings are not easily accessible,
the mobile game could also ask at the beginning if the player wants to disable the audio features of the
game (see Sounds). The game should also respect the device settings, which indicate in which mode the
player wishes the device to be, for instance, in silent mode.

MO3. Interruptions are handled reasonably

Since the mobile devices are usually multi-purpose devices, interruptions when playing the game are
inevitable. Sometimes the game must be interrupted because the player needs to do something else or
he or she moves out of network coverage and is disconnected from the game without a warning.
External interruptions during the play session are also probable. Incoming calls and messages are the
most typical interruptions in that category. Incoming phone calls are usually handled immediately, but
messages can often wait and they are handled after the play session. The surroundings may require the
player's immediate attention.
In case of a single-player game, there should be a possibility to pause the game at any time and
continue playing later. In multiplayer games, this is not that straightforward, since other players are
involved. However, the need for interrupting the play sessions exists also in multi-player games, and
the player may need to stop playing the game for a short period of time.
Gameplay is the most critical part of defining a successful player experience. Gameplay is dynamic and
it occurs when the player interacts with the game mechanics and other players. Game mechanics
consist of rules that define the operation of the game world and make up the core mechanics, the
foundations on gameplay.
Gameplay heuristics are valid for any kind of game regardless of the platform on which the game is
played. When evaluating gameplay, it is highly recommended that evaluators have at least some game
design expertise. The evaluators should also understand the design goals and know the target group of
the game. If the evaluators do not belong to the target group themselves, it is useful to get more
familiar with the potential users, for example, with focus groups.

No. Gameplay heuristics

GP1 The game provides clear goals or supports player-created goals

GP2 The player sees the progress in the game and can compare the

GP3 The players are rewarded and rewards are meaningful

GP4 The player is in control

GP5 Challenge, strategy, and pace are in balance

GP6 The first-time experience is encouraging

GP7 The game story supports the gameplay and is meaningful

GP8 There are no repetitive or boring tasks

GP9 The players can express themselves

GP10 The game supports different playing styles

GP11 The game does not stagnate

GP12 The game is consistent

GP13 The game uses orthogonal unit differentiation

No. Gameplay heuristics

GP14 The player does not lose any hard-won possessions

GP1. The game provides clear goals or supports

player-created goals
The players should be able to understand the goals that exist in the game. According to the Flow theory,
having a clear goal in mind is the core of an enjoyable experience. The goals can be either set by the
game or the players themselves. Some games encourage player-created goals, and some allow the
players to choose their goals from a set of pre-defined goals. An example of supporting player-created
goals could be providing the player information that makes him or her curious enough to want to do
something, for instance, seeing a distant island and figuring out that there must be a way to get there
somehow (even if it would not be necessary to do so in order to proceed in the game).
In case of a complex and long game, the game should contain both short-term and long-term goals.
Especially clear short-term goals are important and the player should perceive that it is possible to
achieve these goals. Short-term goals provide repeated opportunities for reinforcement and keep
players motivated to play the game. An example of a short term goal can be finding a specific item in
the game world. Long-term goals are usually more difficult to achieve and they can consist of several
short term goals. An example of a long them goal could be developing one's game character to be as
good as possible. The distinction between short-term goals and long-term goals should be clear. The
players should see the progress towards the goal (see GP2), be rewarded when they reach a goal (see
GP3), and be able to compare the achievements (see GP2).

GP2. The player sees progress in the game and

can compare the results
The players should have enough information so that they can see their progress towards the goals in the
game. The progress can be shown to the player in two ways:
1. Explicitly, for instance, with numbers.
2. Implicitly, for instance by changing the behaviour of non-player characters (NPC) in the game.
The players feel more motivated if they can compare themselves with the other players or the previous
achievements. Without feedback, the performance can be unimportant and uninvolving. Traditionally,
this has been done with high-score lists, rankings, character levels, or different titles. (See also the
heuristics that deal with the user interface side of this heuristic; GU9: The game gives feedback on the
player's actions and GU4: Indicators are visible).
GP3. The player is rewarded and the rewards
are meaningful
The players should be rewarded as they progress in the game. The most important rewards should be
meaningful for the player. A good example of a less meaningful reward could be to be able to perform a
certain action 20 percent better than earlier. An example of a more meaningful reward in the same game
could be being able to perform a completely new kind of action. The reward should be adjusted to the
challenge that the player had to face in order to get the reward. If the player expects a bigger reward
based on previous experience, and if he or she gets a smaller one, he or she will be disappointed.
A well-balanced varying reward schedule makes the players to try to get the next reward even harder
than if the reward would be just given to the player every time. The rewards should be frequent enough,
but still unpredictable, because that keeps the motivation up for the player. However, using a varying
reward schedule for reaching the major milestones (for example, a level in a game) is not

GP4. The player is in control

The game should provide at least an illusion that the player is in control of what is happening in the
game world. The players should be able to decide on actions they want to take and these actions should
have an influence to the game world.
In gambling games, the illusion of control is very important. For instance, in lottery games, the players
often like to choose certain numbers, even if the probability of winning would be the same with a
random set of numbers. The game should not include random uncontrollable events or tedious or
difficult input sequences.

GP5. The challenge, strategy, and pace are in

The game should be designed so that the players do not feel frustrated or bored with the game.
According to the Flow theory, if the challenge in the game is too high when compared to the player's
current skills, the game is frustrating. Correspondingly, if the player has more skills than required to
achieve the goal, the game feels boring. In single-player games, the player can often choose the
difficulty level and thus affect the challenge.
A variable outcome is also related to challenge. If the result of the game is evident from the start, there
is challenge and no reason for competitive play. T.W. Malone describes in his heuristics ways to
increase variable outcome: randomness, having multiple levels of goals (even if the outcome of one
goal would be certain, the long-term outcome may still be uncertain), hidden information, and adjusting
difficulty level. The balance between variable outcome and skill depends on the game style; casual
games often, however not always, tend to favor variable outcome.
The players learn new strategies as they play the game. There should not be dominating strategies for
any part of the game because it reduces the number of strategies that are used in the game. According to
Andrew Rollins and Ernest Adams in On Game Design (2003), "a dominant strategy is one that
surpasses all others by being the best one to choose under any circumstances."
The pace should be adjusted to the game style. If the player needs to think about the next moves in the
game, there should be time provided for doing that. On the other hand, an intensive game should not
allow the player to analyze different options too long because it slows down the game. However, the
game should allow the player to take a deep breath once in a while during the play sessions.

GP6. First-time experience is encouraging

The first five minutes in the game create the first impression of the game, which is very difficult to
change. The players should feel that they have accomplished something and be rewarded. If the first-
time experience is discouraging, the player may never play the game again. The first play session
should make the player desire for the next play session.
This heuristic has also to do with the learnability of the game. If the game is very difficult to play at the
beginning and learning new things is hard in the game, the first-time playing experience may be
frustrating (see also GU12: The game contains help).

GP7. The game story supports the gameplay and

is meaningful
Even though the story plays an important role in many games, it should not dominate the gameplay.
Some games do not even have or need a game story, but gameplay itself creates a "story" of victory and
loss. A good example of such a game is Chess. The game should allow the players to make their own
decisions and the story should follow the players' choices. A more complex game, such as a massively
multiplayer online game (MMOG), should support the players to create their own stories. Sometimes it
can be useful to provide just a background story for the game, on which the players can base their own
It is important that the story fits to other elements in the game and sounds plausible to the player. The
dialogue with non-player characters (NPC) should be meaningful and interesting for the player. The
player needs to have a reason to care about the game characters and the goals in the game (see Pause in
Game User Experience Guidelines).

GP8. There are no repetitive or boring tasks

The game should not require repetition of tasks without changing any conditions. Repeating the same
tasks over and over again is often called tread milling or grinding, and it is usually a guaranteed way of
killing the fun in the game. One example could be killing the same monsters over and over again and
knowing exactly how they will behave. Often, this repetition happens when the player needs to reach a
certain goal before the game becomes interesting or challenging.
However, it should be noted that the training phase is not grinding because the player needs to practice
basic actions, for instance, how the character is controlled in the game. During the training phase, it is
useful to repeat certain tasks so that the player learns them.

GP9. The players can express themselves

The players should be able express themselves by, for instance, customising their characters, acting in a
certain way in the game world, or modifying the game world. Allowing the player to change the game
world increases the feeling of ownership. Some games allow the players to change the textures or game
logic, and this is often called "modding."
The players need something that they can identify with in order to feel attachment to a game. Allowing
the players to customise and personalise their characters makes it more probable that they can identify
with their character. The simplest way of doing this is to give a name for a character. If it is not possible
to modify the character (and the game has one), the character design becomes even more important.

GP10. The game supports different playing

The players of a game can vary a lot in terms of both experience and preferred play styles. There are
also different playing styles that should be supported at least in the more complex games. In very
simple games, this heuristic may not be relevant.
The most commonly used model for categorizing players in massively multi-player online role-playing
games (MMORPG) is Bartle's player types. The player types are defined based on how the players
prefer to interact with the game world or with the other players, and if they prefer to collaborate ("act
with") or dominate ("act upon"). Bartle's player types are:
• Achievers, who like to compete with the game mechanics.
• Explorers, who wish to explore different aspects of the game.
• Socializers, who prefer to socialize with other players.
• Killers, who enjoy dominating other players.
There are also other definitions for player types in other kinds of games, but Bartle's categorization
serves as a good example, since it is pretty well known and also widely used.

GP11. The game does not stagnate

The players should always feel that it is possible to reach the goals. The player must have a feeling that
the game progresses. Correspondingly, the game should recognise immediately when the game is over
and inform the players. Ending of the play session should be clearly indicated and the game should
provide a possibility to start the game again.

GP12. The game is consistent

The game world should be consistent. If something works in the beginning of the game, the player
assumes that it also works later on. If the game world resembles the real world, the player assumes that
the same principles also work in the game world.
The actions should work in a consistent and logical way. For example, if the player can jump over a
gap, it should be possible to jump over a small fence or a bush as well. The game should not contain
invisible walls.
GP13. The game design uses orthogonal unit
The different game objects should have different kinds of purposes. Harvey Smith has introduced the
term Orthogonal Unit Differentiation. This means that the units - for example character classes - in the
game should be designed so that they are functionally different.
A simple example of orthogonally different items would be arrows that do normal damage and poison
damage. Orthogonally similar items would be arrows that do 1-3 points of damage or 2-4 points of
damage. Orthogonal unit design can encourage strategic play and expands the game's possibility space.

GP14. The player does not lose any hard-won

This heuristic is derived directly from Noah Falstein's four hundred project design rules. The players
will feel very frustrated if they have first earned something by hard work and then it is taken away. For
instance, most players will feel very frustrated if they have worked on developing a game character for
several weeks, and after making a single mistake, the character is permanently gone. Some game
designs may break this rule on purpose in order to provide a more exiting game experience by
providing very high risks. Nevertheless, the consequences of breaking this heuristic should be carefully

Adding new modules: Multiplayer game

The playability heuristics for the game interface, mobility, and core gameplay were presented in Mobile
gameplay heuristics. This core model can be used in evaluating any game.
However, there are game styles, which have their own characteristics that need to be taken into account
during the evaluation. An example of this are multi-player games. Multi-player features are not covered
in the core model, and new heuristics are needed. This chapter describes multiplayer heuristics and how
they can be used with the core model.
Also, some of the heuristics in the core model may need additions because of the new module.
Supplementary multiplayer heuristics are described in Supplements to core heuristics with multiplayer
Similarly, new modules can be added for pervasive games, public-screen games, or other new game
Many of the multi-player heuristics are closely related to issues that are being discussed Overview of
Multiplayer Game Design at Forum Nokia. Unlike the core model, this module has not gone through
extensive testing yet.
In this section:
• Mobile multiplayer game heuristics
• Supplements to core heuristics with multiplayer games
Mobile multiplayer game heuristics
There are a few kinds of multiplayer games for mobile devices: online games, proximity multiplayer
games, and "hot-seat" games (the device circulates among players). Some games support many players
per one device simultaneously, but those games are not very common. Multiplayer games can also be
asynchronous or real-time. Interpretation of the heuristic will depend on what kind of multiplayer game
is evaluated.

No. Multiplayer heuristics

MP1 The game supports communication

MP2 There are reasons to communicate

MP3 The game helps the player to find other players and game

MP4 The game supports groups and communities

MP5 The design minimises deviant behaviour

MP6 The design hides the effects of network

MP1. The game supports communication

The basis of a multi-player game is that the players are aware of and can communicate with the other
players. This can happen either directly by talking or indirectly by acting. When the players
communicate, they are more likely to form communities and make friends. In more complex multi-
player games, for instance massive multi-player online role-playing games (MMORPG), the friends in
the game is usually a major reason for the players to keep playing the game.
Depending on the game, communication channels for different purposes need to be supported. There
can be two kinds of communications in a game: synchronous and asynchronous. Asynchronous
communication is often very useful in games that last longer than one play session. The players should
also be able to choose with whom they like to communicate and ignore other players if necessary.
Mobile devices provide two means of communications: voice and text. Even if mobile phones are
designed for communicating with other people, typing text with a small keypad and viewing
information on a small screen during a play session can be cumbersome. Voice communication would
be an ideal solution and it is also faster than writing. Voice is used for in-game communication for
example in the 'Pathway to Glory' mobile game.
MP2. There are reasons to communicate
A game should provide meaningful issues for the players to discuss. In a very simple game this can be
talking about the game tactics. More complex games can provide events, difficult boss monsters that
require collaboration, interesting game objects, or puzzles to give the players more reasons to
communicate with each other. Common interests make it often more enjoyable to discuss with other
people. When playing a game, the game is a common interest.

MP3. The game helps the player to find other

players and game instances
Multiplayer games are usually played with other players and the player should sense that there are other
players in the game. In online multiplayer games, the player should be able to find friends and see if
they are online. If the player does not know all players in advance, the game should also provide means
for meeting players in the game world. One method of doing this is a search feature, which allows the
player to use character properties or titles for searching players.
If the player needs to join new game sessions often, it should be also easy to find and join new game
instances. It can be useful to allow the non-players to be spectators before joining the game.

MP4. The game supports groups and

A multi-player game should support groups and communities. The players who feel that they belong to
a community are more likely to keep playing the game. The game should enable forming a community,
organizing (for example, ranks and roles), and provide an enclosed communication channel for
community members. The players should be able to collaborate with each other and form groups. In
groups, it is usually good to show the current status of all members.

MP5. The design minimises deviant behaviour

Multiplayer games, especially online games, often facilitate bad behaviour. When players are in close
proximity or know each other well (that is, the level of anonymity is very low or zero), the probability
for bad behaviour is smaller. Examples of deviant behaviour in multi-player games are cheating,
exploiting, hacking, and grief play.
Cheating can be defined as an action by a player that violates the rules of the game 'as written' or
commonly understood. An exploit can be understood as a technique for cheating in the game. Hacking,
in this context, means an act of creating an exploit. Grief play can be defined as play styles that disrupt
another player's gaming experience.
Often, preventing grief play requires restricting player-to-player interaction, for example, player killing.
Note that player killing is not defined as grief play. However, play styles that are related with player
killing, for instance "rez killing," which means killing a player character again right after bringing him
back to life, can be considered as grief play. The balance between player-to-player interaction and
preventing grief play should be carefully considered. Setting too strict restrictions may end up in dull
MP6. The game design hides the effects of the
This heuristic is applicable only to online games. There are three major issues that need to be taken into
account: latency, disconnections, and pricing of data traffic. The latency can disrupt the gameplay and
cause delays to interaction. Mobile games can be designed so that they hide the latency. If the player
gets disconnected from the game, it needs to be handled gracefully. The amount of data to be
transferred between server and mobile devices can become a barrier for playing the game. Currently
mobile network connections are still slower than in other platforms and players need to pay for every
kilobyte that is transferred.

Supplements to core heuristics with multiplayer

No. Game heuristics
GU5. The player understands the terminology
GP6. First-time experience is encouraging
GP9. The players can express themselves in the game
GP2. The player sees the progress in the game and can compare the
GP10. The game supports different playing styles

GU5. The player understands the terminology

Online games often use terminology that is related to setting up a network or proximity play session.
This terminology can be hard to understand because it requires understanding of technical elements,
that is, game servers. The game setup should be explained so that the players can understand it.

GP6. First-time experience is encouraging

In multiplayer games, the first play session can be spoiled by the other players. This is especially
problematic in games in which the gameplay is based on player vs. player (PvP) conflict, a good
example being so-called "newbie killing". Some games provide specific areas for the novice players to
practice their skills and get familiar with the game before they enter more advanced areas.

GP9. The players can express themselves in the

Expressing oneself becomes even more important in multiplayer games because there is an audience.
The players enjoy customising their characters and showing by doing who they are and what they
GP2. The player sees the progress in the game
and can compare the results
In multiplayer games, it is very important that the players can compare their success to other players.
The audience makes the success or loss in the game even more sweet or bitter. Almost every multi-
player game provides some means of comparing player success, for example, score, level, or a player
title. Game objects can also be trophies that show that the player has managed to achieve something in
the game.

GP10. The game supports different playing

At least the more complex multi-player games should also be playable when the player does not have
any other players or friends around. Although multiplayer games are meant to be played with other
players, many players want to play at least sometimes alone. There might be simple reasons for that,
like shyness or insufficient language skills in an international community. Also, it is not always easy to
find other players who would like to collaborate on tasks that require team work. Sometimes players
may also want to try if it is possible to accomplish something without other players' help. The game
should allow this and provide reasonable content for the players who prefer to play "solo" as well.

Terms and abbreviations

Term or Meaning

Expert See Heuristic evaluation.


Heuristic Heuristic evaluation is a widely used method for evaluating usability of software
evaluation products. In heuristic evaluation, experts evaluate the product against a list of
heuristics. In the evaluation of games, the heuristic evaluations are also called expert

MMORPGs Massively multi-player online role-playing games. Persistent large-scale online

games that typically enable more than one thousand simultaneous players playing in
the same game world.

NPC Non-player character

Playability Testing the game with real players. The testing can be done in a laboratory, when
testing direct observation methods can be used, or as field testing, when methods like
interviews or questionnaire surveys are usually more applicable.
Mobile game playability heuristics reference
No. Game usability heuristics

GU1 Audio-visual representation supports the game

GU2 Screen layout is efficient and visually pleasing

GU3 Device UI and game UI are distinguishable

GU4 Indicators are visible

GU5 The player understands the terminology

GU6 Navigation is consistent, logical, and minimalist

GU7 Control keys are consistent and follow standard conventions

GU8 Game controls are convenient and flexible

GU9 The game gives feedback on the player's actions

GU10 The player cannot make irreversible errors

GU11 The player does not have to memorize things unnecessarily

GU12 The game contains help

No. Mobility heuristics

MO1 The game and play sessions can be started quickly

MO2 The game accommodates with the surroundings

MO3 Interruptions are handled reasonably

No. Gameplay heuristics

GP1 The game provides clear goals or supports player-created goals

GP2 The player sees the progress in the game and can compare the

GP3 The players are rewarded and rewards are meaningful

GP4 The player is in control

GP5 Challenge, strategy, and pace are in balance

GP6 The first-time experience is encouraging

GP7 The game story supports the gameplay and is meaningful

GP8 There are no repetitive or boring tasks

GP9 The players can express themselves

GP10 The game supports different playing styles

GP11 The game does not stagnate

GP12 The game is consistent

GP13 The game uses orthogonal unit differentiation

GP 14 The player does not lose any hard-won possessions

No. Multi-player heuristics

MP1 The game supports communication

MP2 There are reasons to communicate

MP3 The game helps the player to find other players and game
No. Multi-player heuristics


MP4 The game supports groups and communities

MP5 The design minimises deviant behaviour

MP6 The design hides the effects of network

Top 10 usability guidelines for S60 applications

1. Provide a clear navigation model. Core features of the application should be available from
the main view. Navigation model should be focused on the main tasks. Advanced functionality
should be hidden from novice users.
2. Use familiar language. Terminology familiar to target users should be used instead of technical
terminology. Terminology should be consistent with the S60 UI style. Target users' native
language should be used.
3. Hide the complexity of connectivity. Short network coverage problems should not cause loss
of users' work or stop them from working. Connection status should be displayed clearly.
Synchronization should be automatic but under user control.
4. Provide useful feedback. Let the user know if an action was successful or not. If processing
takes more than 0.5 seconds, indicate that something is happening.
5. Be consistent with controls. Minimize errors and the need for learning by using softkeys
according to the S60 UI style. Build shortcuts for advanced users, use shortcuts similar to other
6. Provide a simple Options menu. Navigation key default action(s) should also be available in
an Options menu. Sort items in the Options menu according to the S60 UI Style Guide. Main
actions should be available without scrolling.
7. Use tabs wisely. The most essential functionality should be provided in the first tab. Underlying
tabs can be used to hide advanced functionality. If more than five tabs are needed, use a list for
accessing the tabs (see the Settings application). Text is preferable to icons in tab titles.
8. Make information entry easy. Instead of text entry, prefer alternative forms of information
entry, such as selecting from a list or capturing images. Offer reasonable default values.
9. Display information clearly. Display the most relevant information first. Essential information
should not be displayed with icons only. Use colours and symbols for highlighting and grouping
10.Provide help. Context-sensitive help should be provided in the application. More detailed help
should be provided on a Web site or in the user guide.

Design and User Experience Library v1.7 > Guidelines and checklists > User experience

Quick checklist
This checklist contains items for checking the most common and the most serious usability problems -
those which may cause the application to fail in certification tests.

Guideline True False Platform

Softkey usage and navigation style are consistent with the UI style. [] []

Error notes are informative and clear; they do not contain terminology that [ ] []
is too technical.

The application contains a Help and/or an About screen. Help contains a [] []

brief description of the application's purpose and controls. The provided
information should contain the application's name and version, the vendor's
name, and support contact. Version numbering and naming is up to date.

User can cancel actions easily as specified by the UI style, especially [] []

actions related to connectivity.

Errors are handled correctly, especially those related to connectivity. The [] []

user gets information on how to recover from errors, and critical errors are
prevented completely.

Application remembers user settings and saves them on exit. [] []

Application closes network connections and Bluetooth connections on exit. [ ] []

Application handles multitasking correctly in accordance with the UI style. [ ] []

On Series 40 devices, application saves and exits on End key press. On
S60 devices, the application can be switched to background with
Application key and closed with End key (except audio applications, which
are always switched to background).

Application handles interruptions correctly in accordance with the UI style. [ ] []

The user is able to answer phone calls at any time. Incoming messages,
battery warnings, and other notifications are indicated properly.

Application starts in less than 5 (Symbian) / 10 (Java) seconds. A clear [] []

progress bar or animation is displayed quickly after the launch.
Guideline True False Platform
Application keeps its state and saves any entered data automatically in case [ ] []
of technical or social interruptions. User can resume using the application

Sounds work correctly after an interruption. For example, any muted [] []

sounds resume playing.

Application menus contain each command only once. There are no [] []

multiple instances or different wordings for the same selection.

Every selectable item in menu has a related action, in accordance with the [] []
UI style. Items that cannot be currently selected are hidden, or do not
appear as selectable.

Terminology is not technical, but familiar to target users. Truncations, [] []

abbreviations, and foul language are not used.

Application handles repeated keypresses and touch interactions correctly. [] []

Application has been tested on actual devices, not just simulated. [] []

Application has been tested with actual end-users, not just in-house [] []

Application runs successfully in low-memory condition or displays a clear [ ] [] Symbian

and informative error message.

Default navigation key is used consistently to move focus and navigate [] [] Symbian

If application is not extremely simple, detailed and up-to-date context- [] [] Symbian

sensitive help or user guide is provided.

© Nokia 2009.