Professional Documents
Culture Documents
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
Memorability How well the user remembers the system when returning to
it.
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.
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.
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.
Loading
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
• Symbian applications should launch in less than 5 seconds.
Java
• 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
device.
• Java™ ME applications should launch in less than 10 seconds.
Intro
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
• 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.
Java
• 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.
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
style.
• 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
Close.
• 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
seconds.
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
menu.
• 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.
Java
• The Confirmation dialogue can be implemented with the Alert dialogue.
Help
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
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.
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.
Java
• Disable prepressed keys.
Graphics
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.
Java
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.
Symbian
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:
CEikAppUI::ApplicationRect().
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
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.
Backlight
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.
Java
• In some mobile information device profile 2.0 (MIDP) devices there is no way for applications
to control the status of the backlight.
Symbian
• 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.
Sounds
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
sounds.
• 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
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
player.
Profiles
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.
Symbian
• Game sound level should be adjusted according to the currently active profile. The
CSettingInfo interface can be used to determine the active profile.
Java
• 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.
Realism
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
accessible.
• 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.
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.
Feedback
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
successfully.
See also Display status clearly and Give control to the user.
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.
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.
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
transmission.
• 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
background.
Java
• The hideNotify() method can be used to determine if the application is switched to the
background.
• 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
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
example.
• 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.
Text
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
language.
• 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
Post-game guidelines
Usability guidelines presented in this section are related to post-game concepts.
In this section:
• Restart
• High-score list
Restart
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
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.
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.
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.
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
session.
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
toolbox.
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
playing.
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
example.
• 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 www.gamasutra.com (Berbank Green, 2005).
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
Gamevil, www.gamevil.com)
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
Jadestone, www.jadestone.se)
Figure: Freerun has a nice, flowing experience when jumping from roof to roof. (Courtesy of
Creativenorth, www.creativenorth.co.uk)
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
games.
Figure: Pacmanhattan player receives running direction from a game operator via mobile phone. See
www.pacmanhattan.com 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.
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
accordingly.
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
devices.
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
players.
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.
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
Guideline.
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!
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)
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.
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
should:
• 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.
Figure: The different layers that a player needs to pass in order to access the core gameplay of the
game.
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
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.
GU3 Device UI and game UI are used for their own purposes
Mobility
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.
GP2 The player sees the progress in the game and can compare the
results
MP3 The game helps the player to find other players and game
instances
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
evaluations.
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
sheets
No. Game usability heuristics
GP2 The player sees the progress in the game and can compare the
results
MP3 The game helps the player to find other players and game
No. Multi-player heuristics
instances
Design and User Experience Library v1.7 > Guidelines and checklists > User experience
checklists
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.
Error notes are informative and clear; they do not contain terminology that [ ] []
is too technical.
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.
Application has been tested with actual end-users, not just in-house [] []
developers.
Default navigation key is used consistently to move focus and navigate [] [] Symbian
forward.
© Nokia 2009.