Gamasutra - Features - "GDC 2004: Cross-Platform User Interface Development" Printer Friendly

CMP Game Group Presents:

GDC 2004: Cross-Platform User Interface Development
By Rob Caminos and Tim Stellmach
Gamasutra
March 26, 2004

URL: http://www.gamasutra.com/gdc2004/features/20040326/caminos_01.shtml

UI is always the first thing a player will see, and yet it's often the last thing a developer thinks about. Just like the opening credits for a movie, the UI can help to set the mood for the rest of the game, for better or worse. If a game has a UI that looks bland, or is difficult to use, how will that impact a player's first impressions of the rest of the game?

From PC to Console

Whether you're converting a PC game to console or developing an original console title, the PC is always going to be a major part of the production pipeline. This section will illustrate some of the major differences between consoles and computers.

The Display: What You See May Not Be What You Get

Content on the PC can look very different once it's on a console. It's important to understand the differences between the displays used for PCs and consoles.

- CRT Computer Monitors most commonly used by gamers
- Variable Resolution: Typically between 640x480 - 1280x1024
- Progressive (Every line drawn)
- 17"-19" in size (typically)
- Small Dot Pitch
- Consistent screen area(same for all models and brands)
Crisp and clear display: meant to be viewed up close

Computer Game Display

- CRT Televisions most commonly used by gamers
- Fixed Low Resolution: 640x480(typically)
- Interlaced (Every other line drawn)
- 19"-36" in size (typically)
- Large Dot Pitch
- Variable screen area (different for every model and brand)
- Fuzzy and blurry: meant to be viewed from a distance

Console Game Displays

The Tech Behind The "Tube"

TVs use electron guns to shoot tight beams of electrons onto the screen from within a vacuum tube. The screen is coated with phosphor, which glows where it gets hit by the beam.

The Tech Behind The "Tube" - Cathode Ray Tube

What Happens When TVs Behave Badly

Screen Distortion

The pictures below, from the beta test of Jedi Academy (Xbox), show one of the distortions that can occur on televisions.

Distortions

This is what happens when you have a lot of electrons in one line of resolution and fewer in another. Electrons repel one another because of their like electrical charge. The brighter the color, the more electrons are being fired at the screen, which will mean more electrons repelling one another. The opposite is true of darker colors - fewer electrons repelling one another. Together these lines create screen-distortion.

Suggestions:

Invest in a really cheap TV for distortion testing - the kind you get at a super market, not at Best Buy.

Avoid using bright and dark colors together, especially with thin and/or straight lines.

Screen Legibility

Text is such a common part of our daily lives that we rarely stop to notice just how complex it really is. Just think of how many polygons it would take to render a letter like "Q". There is a reason why you never see "Books On TV" - you would go blind trying to read that much text on a TV. Televisions were never designed for reading text on screen. A console developer must always test for legibility of the UI on a television, especially when concerning fonts.

Concerning Fonts

The larger and thicker the text, the easier it will be to read. It's better to have the player page down than to try and fit it all on one screen with a smaller font size.
If you can read this then you are straining your eyes J

Try to make all your letter characters the same size. That will make it easier to manage long text strings.

Avoid using lowercase letters as they are more difficult to read. Lowercase letters are also more difficult to manage since their sizes vary so much. Instead, try using smaller versions of uppercase letters.

Consider using an outline for the font. It may not look as clean, but it can go a long way towards making your text easier on the eyes.

Here are some good and bad examples for TV viewing:


Good	Bad


Good	Bad

HUD Readouts in Jedi Academy (Xbox)

Over-Scanning

TVs tend to over-scan their screen area, which means the picture on the screen is a little larger than the display. How much the TV over-scans varies from TV to TV. To compensate, console manufactures (e.g. Sony, Microsoft, Nintendo) require that the edges of the screen not contain any important information. That means things like a heads up display, dialog boxes and UI elements must remain within the confines of a safe region. Sony, Microsoft, and Nintendo have different requirements, but none of them have restrictions on being too cautious. Microsoft requires that an Xbox title have a safe region that uses only the middle 85% of the screen (544x408) making it the most conservative. We have yet to find a TV that this safe region won't compensate for. (Note: The safe region is different for HDTV)

Jedi Knight: Jedi Academy

The pictures above illustrate the impact the safe region (added outline) had on Jedi Academy. Note the difference it made to the HUD.

A Note on Technical Requirements
Games that do not meet manufacturers' technical requirements (such as conforming to the safe region) are not allowed to be published. Manufacturers do grant exceptions, but generally not for any really significant violations.

From Mouse to Controller

"The keyboard and mouse give you near instant response and near exact control. The controller is a far less precise, far more...well...leisurely input device."
- Warren Spector

With PC games, the player uses a mouse pointer to precisely select the item they want. With a console, however, the player has to use the D-pad or thumbstick to seek the item they want by cycling through the entire menu. It is therefore very important to make the UI menus as efficient as possible. Below are some guidelines to consider:

Make sure that anything you put in the UI is absolutely necessary.


With a mouse this menu is no problem but a real pain for a console controller.	By consolidating non-essential menu items, the player has less to seek through.

Avoid placing menus that require scrolling to see all its contents.


This design means the player has to evaluate each choice and reject it until, they find the one they want.	With all the information visible, the player may see their choice and seek to it.

Absolutely make sure that menu navigation is fast.

And when I say fast, I mean instant. Screen transition animations are one thing, but having to wait a second between each menu item is incredibly frustrating and totally unnecessary.

The Design of Everyday User Interface

Technical requirements vary from platform to platform, however the underlying principles behind them largely don't. Donald Norman's The Design of Everyday Things is an excellent source to learn about these principles. The book is a must read for anyone that develops user interfaces. It points out things in our everyday lives that are poorly designed and don't need to be, such as doors that you push that actually have to be pulled. Citing examples from The Design of Everyday Things, we hope to teach you a little design aikido that will satisfy technical requirements of all the major platforms.

Get a Clue!

"The human mind is exquisitely tailored to make sense of the world. Give it the slightest clue and off it goes, providing explanation, rationalization, understanding."
- Donald Norman

Here is a UI problem that just about every gamer has faced once or twice: a menu with only two items and no clear explanation of which item is currently selected. Let's break down the rationalizations a player might have when faced with a screen like this:

If the player is not familiar with console games, they may have no idea which button to press on the controller.
Since the two menu items are different colors, one of the items is selected and the other is not.
The yellow body text is different from the menu text, so no clues there.
The menu items are on top of one another, so the player can assume that the Directional Pad or thumbstick is pushed up and down rather than left and right.
When the player pushes up and down on the D-Pad, the colors of the menu items are swapped.
One of the words is in white so that could imply that it's lit up. The other item is blue which could mean that it is off. But the reverse is just as likely.

So the player is left with two options: scan the manual for more clues or press any button on the controller and hope for the best.

The player presses the D-pad up, which makes "Yes" appear blue, and presses a button. The player ends up at the screen they were at previously. There was no feedback communicating that they moved back in the UI stack (for example a unique sound effect), but the player knows it's the previous screen because they remember what it looked like. With these clues they are able to deduce that white text is the selected item and blue is not. Now that the player understands the selection system, they get through the UI with greater ease and start playing the game.

In reality, this only took a few seconds to figure out, but it's still irritating. It wouldn't have taken all that much effort on the part of the UI designer to correct this kind of confusion.

Provide Instructions

"One of the most important principles of design is visibility. The correct parts must be visible, and they must convey the correct message."
- Donald Norman

For starters, it would help to give the player some instruction on how to make a choice. Insert a callout that consists of a brief text string that explains its mapped function, and an icon of the button to which the function is mapped. The icon should represent the button in color and shape. For some consoles, this is a requirement.

Provide Feedback

"Feedback: sending back to the user information about what action has actually been done. Imagine trying to draw a picture with a pencil that leaves no mark: there would be no feedback."
- Donald Norman

A cursor is an effect or collection of effects that are applied to the selected item that provides visual feedback to the player's actions. In the original example of this UI screen, the cursor's only effect was a color swap of the text. This may work in menus of three or more items, but is ineffective in a menu with only two. A more refined cursor object, such as a glow effect and a shape that encompasses the text, is necessary.

Sound effects are also excellent for providing additional feedback for the player's actions. In addition don't underestimate the power that good sound effects can have on the player's enjoyment.

Seven Principles for Transforming Difficult Tasks into Simple Ones

Any cross platform UI is going to stumble on some challenging screens. These seven principles can be used as guidelines that will contribute to a better design.

1. Use knowledge in the world and the head.
People don't like to feel stupid, so a good user interface can compensate for this by providing instructions. Knowledge in the world refers to the visible instructions that are provided by the design. A door labeled "PUSH" is knowledge in the world that tells someone not only that they have to push the door open but also that they don't pull the door and look stupid.

Knowledge in the head is about referring to previously established standards. A door that has a vertical bar on one side of it communicates to the user that the door must be pulled because all doors that have this feature work the same way (and if they don't, then it's bad design).

2. Simplify the structure of tasks.
Tasks should be simple, minimizing the amount of planning on the part of the user. Short term memory can only retain about five unrelated items. A good user interface will accommodate for this constraint. If a UI screen is too complicated, then the user has to waste time trying to understand the design of the screen, delaying play time, and lowering the player's enjoyment.

3. Make things visible.
Making things visible is about providing feedback to the player. It's not just the visual clues about audible ones as well. A good user interface will provide feedback on the execution side of an action so that players know what actions are possible and how they are executed. It will also provide feedback on the evaluation side so that players can tell the effects of their actions.

4. Get the mappings right.
Don't use a callout that has a blue "A" button, when the button is green on the controller.

5. Exploit the power of constraints.
Constraints can be used to make the player feel as though there is only one possible action - the right one. Constraints are similar to the simplification step.

6. Design for errors.
Allow players to recover from errors, and make them reversible. (More on this later)

7. Standardize.
Either create or adhere to standards so that the player will have some idea of what actions to take. (More on this later)

Now let's look at some examples of some tricky UI screens that utilize these seven principles.

The Soft Keyboard

Since no major console comes with a keyboard and some don't even support them, console games rely on a software solution for text input. Console developers have taken many different approaches toward soft keyboard design. Microsoft Same Studios usability labs have done extensive testing on the subject. Their results showed that players overwhelmingly preferred a horizontal, alphabetic layout over other virtual keyboard designs.

Soft Keyboard

The figure above shows a soft keyboard design for an Xbox title that has a number of advantages:

Knowledge in the world is used by illustrating the mapping of common functions such as Space, Backspace, Caps Lock, to available buttons on the controller. It also uses knowledge in the head because it resembles the look of an actual keyboard; people will instantly understand its purpose.
Arranging the letters alphabetically simplifies the design and is faster since any literate gamer will know the order of the letters. (QWERTY is based on motor memory, not visual)
By splitting off the alphabet, symbols, and accents (for European languages) into three different keyboards, the user isn't bombarded with a large number of choices to make. Having fewer keys also minimizes cursor travel.
The cursor is the same color and shape as the "A" button thus providing visual feedback. Cap Lock is communicated with a text string as well as tinting the keys to the same color as the blue "X" button.
Assigning Space and Backspace to the left and right shoulder buttons creates a natural mapping (Space moves to the right, and backspace moves to the left). They are also easy to use simultaneously with the "A" button and thumbstick/D-pad.
Constraints are used by limiting the movement of the cursor. The keyboard is navigated one key at a time, rather than holding down the d-pad to continuously travel, and likely miss their target.

Controller Settings

It's important to keep the UI stack short, but it's just as important not to bombard the player with information. Trying to fit too much information on one screen can give a player mental indigestion.

A common example of this problem is the controller mapping screen. Numerous games have functions mapped to every available button and try to fit it all on one screen.


Button Settings	Thumbstick Settings

The figures above show a controller setting screen for a first person shooter Xbox game that is broken down into two separate screens.

Knowledge in the world is used by placing callouts and offering explanations for the various functions.
Screens are simplified by separating buttons from movement controls. This reduces information overload and eliminates potential confusion with the thumbstick buttons and their movement functions (PS2 and Xbox controllers).
Button Icons are placed next to the function they are mapped to and point to a controller image to establish mappings.
Plenty of text breathing room for localization.
3D arrows on the thumbstick icons offer a better explanation of the sticks function.

Design for Errors

"If an error is possible, someone will make it. Errors should be easy to detect, they should have minimal consequences, and, if possible, their effects should be reversible."
- Donald Norman

All major console manufacturers require that any destructive action, such as overwriting a game save, have a confirmation dialog to allow the player to back out of a potential mistake. However, there are other kinds of irreversible actions that can still hinder a player's experience even if they are not as costly as losing a save game.

Potential Error

The previous figure shows an example of a training dialog that is meant to teach the player about a particular aspect of a game. The down arrow and page counter under the paragraph illustrate that there is a second page of information that the player can view by pressing down on the D-pad or thumbstick. Should the player press the "A" button, they will close the dialog box and miss the information on the second page. This design gives the player the ability to make this mistake. Below is an alternate approach to the same dialog that resolves this problem.

Remove Error

By binding the "A" button to move to the next page, in addition to the D-pad "down" button, it forces the player to see all the information, instead of closing the dialog and missing it.

Reversible

Once the player has seen all the screens, the "A" button will now close the dialog and return to the game. Pushing up and pressing the "B" button allows the player to return to the previous page if necessary.

Standardize

Most games map the same buttons for moving forward and back in the UI stack and some consoles require it. Therefore it's conceivable that in the player's mind, these buttons are for "positive" and "negative" actions.


Used for: · Select · Accept · Yes	Used for: · Back · Cancel · No

UI designers can take advantage of these associations, as seen in the following:

Boolean Benefits

Rather than making the player press the D-pad to move a cursor to select their choice and then press a button, they just press a single button.

Tools of the Trade

UI Flowchart. The following is a Microsoft Excel spreadsheet that we used to map out the flow for the UI in Crash Nitro Kart. CNK shipped on Game Cube, PS2 and Xbox so the flowchart was a tremendous asset in tracking any cross platform issues. This flowchart was created before any UI is put into the game so that we could adjust for scope and plan for any cross platform issues.

Notice that some of the cells are actually hyperlinks. These are linked to MS Word documents that go into excessive detail about an individual UI screen. The flowchart is meant to provide answers to engineers, artists and designers. The documents outline any code support that may be needed, mockups for artists to refer to for visual design, and usability functionality for designers.

UI Flowchart

Text Dictionary
A text dictionary is a must in any game development, especially in any cross platform project. The figure below shows samples from the text dictionaries we used in Crash Nitro Kart. It's simply a .csv file (formatted here for better presentation) that assigns text strings to tags that are used in the game. So when changes need to be made, it's done in a single file rather than going into source material. The dictionary makes localization for different languages, and different platforms significantly easier.

Text Dictionary

UI Menu System

When development for Crash Nitro Kart began we decided to develop a scripting language specifically for UI development. Assets would be generated in other applications and layout and functionality would be done in script. This method would allow us to make a single user interface that would work on multiple platforms. We affectionately named our menu system G.U.I.D.O. which stood for Graphical User Interface Design Outline (yes it is a stretch).

Rather than get into the specifics of using GUIDO, I recommend some goals based on what we learned:

Goals for a UI Menu System

Lightweight: It shouldn't require a lot of memory or CPU, and it should use both efficiently
Clean: A big hacked mess is going to make life difficult for everyone involved. A menu system should be thought of as long term investment. Take the time to make clean and efficient code.
Extensible: A menu system must have the ability to add new features without hacking up the design. Designers and artists are always going to dream up new features and effects for every project.
Reusable: One of the primary goals of a menu system is to make it reusable from project to project, regardless of the platform the project is for. If you stop to think about it, UI's haven't changed all that much since, even the 8 bit era (at least not when compared to the differences in game play).
- Minimize dependencies on other libraries
- Good separation between generic menu system and title-specific stuff will facilitate reuse.
Easy to Use: enough for a non-programmer to use (with some learning).
Powerful and Flexible: enough that menu designers will be asking programmers how to do things, rather than designers asking programmers if they can implement a new feature to allow them to do things.

Final Thoughts

Keep It Simple Stupid

While it's true that a good looking user interface is important, it should hardly be the focus of your technology. A UI is not an effective tech demo. A minimalist approach toward UI design allows the player to focus on the function, without getting distracted by the form.

Make It FUN!!!

Think of the opening credits for a movie. They tell the audience who did what in the movie, but filmmakers learned that it's also an opportunity to entertain the audience and set the mood for the rest of the film. If the player has fun with the user interface, it will only enhance their overall enjoyment when playing the game.

Source Material

Crash Nitro Kart
Publisher: Universal Interactive
Developer: Vicarious Visions

Jedi Knight: Jedi Academy (PC, Xbox)
Publisher: Activision
Developer: Raven, Vicarious Visions

The Design of Everyday Things
Author: Donald Norman

Special Thanks

Jonathan Herman, Jonathan Mintz, Brian Osman and Mike Scavezze.

Opinions expressed here do not necessarily reflect those of Vicarious Visions.