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: Satisfaction Efficiency Learnability Errors Table: Usability factors A subjective feeling of contentment. A minimal amount of time wasted. Degree of ease when starting to use the system. Number of errors the user makes and degree of seriousness.

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 flightbooking 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. 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. 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 successfully. 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. 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 time. 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

2. Pause and save
• •

3. Provide feedback
• • • • •

4. Status

5. Challenge

• • •

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 easily. In Bluetooth multiplayer games, background music should be synchronised for all players to avoid an auditory mess. The objects' and characters' appearance must match their functionality/activity. Different items must appear clearly different and their functionalities should be distinctive as well. 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 players. 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. 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. 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.

7. Distinctive graphics
• • • •

8. Provide in-game help
• •

9. High-score list
• •

10. Easy restart

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 popup 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. 2. 3. 4.

This screen is optional but recommended. In Pause mode, the screen title may be adjusted accordingly. For simplicity, the navigation flowchart is not drawn to its full depth. 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

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 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 device. Java™ ME applications should launch in less than 10 seconds.

Symbian

Java

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. Intro sounds

See also:

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.

Symbian

Java
• •

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 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 textentering 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.

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 queries. 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 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. The Confirmation dialogue can be implemented with the Alert dialogue.

Java

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

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 users. 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.

Java

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 off.

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. Java 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. Symbian

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 event. • 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. 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

S60 screen orientation
Java Information about changed modes can be obtained with the Displayable.isShown() method.

Navigation key directions work normally in all modes. Symbian 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 KEikDynamicLayoutVariantSwitch. 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 control):

Application UIs can override HandleResourceChangeL() to detect the KEikDynamicLayoutVariantSwitch message and re-layout of their main controls from this. Controls can override HandleResourceChange() to detect the KEikDynamicLayoutVariantSwitch message and re-layout themselves and their components.

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 colourful.

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. 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.

Java

Symbian

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

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 player.

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.

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. 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.

Java

• • •

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. Realism No invisible barriers Bonus and special features

In this section:
• • •

Getting killed

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.

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, differentlooking 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.

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.

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.

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. 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. Disable sounds and music To pause or not to pause Pause in multiplayer games Actions in pause menu and resuming the game

Java
• •

In this section:
• • • •

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 type. 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 interruption.

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 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.

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.

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. No foul language or offensive terms Make text easy to read

In this section:
• •

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

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

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 results screen is interesting and useful.

Only abstract points are displayed. It is not clear 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 result from the just finished game is highlighted.

The user has been forced to enter a name every time he or she has finished a game. As a result, the highscore 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 instantly.
• • •

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 session.

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 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.

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 usability?
• • • •

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 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).
• •

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 www.gamasutra.com, 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 gamers. 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 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.

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 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.

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 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.

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 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!

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

Contrast
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 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.

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 experience. • 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 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

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 example,Gameplay.

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. GU1 GU2 GU3 GU4 GU5 GU6 GU7 GU8 GU9 Game usability heuristics Audio-visual representation supports the game Screen layout is efficient and visually pleasing Device UI and game UI are used for their own purposes Indicators are visible The player understands the terminology Navigation is consistent, logical, and minimalist Control keys are consistent and follow standard conventions Game controls are convenient and flexible 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 gameplay
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 colours. 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 pleasing
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 fullscreen 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 minimalist
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 capabilities.

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 actions
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 errors
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.

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. 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

MO1. The game and play sessions can be started quickly
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 surroundings
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
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. GP1 GP2 Gameplay heuristics The game provides clear goals or supports player-created goals The player sees the progress in the game and can compare the results The players are rewarded and rewards are meaningful The player is in control Challenge, strategy, and pace are in balance The first-time experience is encouraging The game story supports the gameplay and is meaningful There are no repetitive or boring tasks The players can express themselves

GP3 GP4 GP5 GP6 GP7 GP8 GP9

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 recommended.

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 balance
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 firsttime 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 stories. 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 styles
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 differentiation
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 possessions
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 considered.

Adding new modules: Multiplayer game heuristics
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 games. Similarly, new modules can be added for pervasive games, public-screen games, or other new game formats. 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 instances 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 multiplayer 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 communities
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 gameplay.

MP6. The game design hides the effects of the network
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 games
No. GP6. GP9. GP2. Game heuristics First-time experience is encouraging The players can express themselves in the game The player sees the progress in the game and can compare the results GU5. The player understands the terminology

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 game
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 think.

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 multiplayer 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 styles
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 abbreviation Expert evaluation Heuristic evaluation Meaning See Heuristic evaluation.

Heuristic evaluation is a widely used method for evaluating usability of software 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. 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. Non-player character Testing the game with real players. The testing can be done in a laboratory, when direct observation methods can be used, or as field testing, when methods like interviews or questionnaire surveys are usually more applicable.

MMORPGs

NPC Playability testing

Mobile game playability heuristics reference sheets
No. GU1 GU2 GU3 GU4 GU5 GU6 GU7 GU8 GU9 Game usability heuristics Audio-visual representation supports the game Screen layout is efficient and visually pleasing Device UI and game UI are distinguishable Indicators are visible The player understands the terminology Navigation is consistent, logical, and minimalist Control keys are consistent and follow standard conventions Game controls are convenient and flexible 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. GP1 GP2

Gameplay heuristics The game provides clear goals or supports player-created goals The player sees the progress in the game and can compare the results The players are rewarded and rewards are meaningful The player is in control Challenge, strategy, and pace are in balance The first-time experience is encouraging The game story supports the gameplay and is meaningful There are no repetitive or boring tasks The players can express themselves

GP3 GP4 GP5 GP6 GP7 GP8 GP9

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 instances

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 applications. 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 items. 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

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. Guideline Softkey usage and navigation style are consistent with the UI style. True False Platform specific [] [] []

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 specific []

Application keeps its state and saves any entered data automatically in case [ ] of technical or social interruptions. User can resume using the application easily. 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 developers. []

[]

[]

[]

[]

[]

[]

[]

[] [] []

[] [] []

Application runs successfully in low-memory condition or displays a clear [ ] and informative error message. Default navigation key is used consistently to move focus and navigate forward. If application is not extremely simple, detailed and up-to-date contextsensitive help or user guide is provided. []

[]

Symbian

[]

Symbian

[]

[]

Symbian

© Nokia 2009.

Sign up to vote on this title
UsefulNot useful