USER INTERFACE DESIGN ISSUES FOR SONY PLAYSTATION 2

There are several important issues to take into consideration when planning your first user interface for a game. The obvious ones are related to the game itself and are of course different for each game. There are a number of common variables that are important to understand when creating all PlayStation game interfaces.

Overview of Relevant Sony Requirements

One of the most important and somewhat daunting aspects of UI design for Sony PlayStation are the Sony Requirements. The Sony Requirements are a lengthy list of required behavior and messaging relating to the Sony hardware. Different regions can interpret these requirements differently so it's important to be conservative and to have a good understanding of them when beginning your design.

The Sony Controller and Key Mapping to Flash

Behind the computer and mouse, the Sony PlayStation Controller may be the most popular UI device in history. If you think about how many PlayStations there are on the planet and how many hours people spend holding the controller, it's sort of frightening because the controller is so incredibly simple. There is no keyboard and no mouse, yet you can drive such amazing experiences with it.

As a Flash designer, you constantly have to think of how to present complicated choices and decisions to a user holding the Sony controller.

For instance, what do you do when you have to spell a name? What if you have two things on the screen that are both controlled by the right and left arrows? How do you warn players who press the OK button quickly over and over in a series of alerts that doing so in certain cases will result in data loss?

Fortunately, Sony and its licensed developers have dealt with these problems. The trick for UI developers is to stretch the line between experimentation and the Sony Requirements. The Sony Requirements can be complicated and passing the test is tough. In Star Wars Starfighter™ we were dealing with a new machine that wasn't even released so we were all extra worried about these requirements.

So the Sony controller needs to be flexible, but familiar (see Figure 12.5). In some countries the OK button is the circle button. In other countries the OK button is the X button.

Figure 12.5. Sony controller with general mapping guide.

In some cases you have to break these rules. For instance in the alert that asks, "Are you sure you want to format the Memory Card?" we swapped the OK button functionality with the Cancel button functionality a user wouldn't accidentally hit OK to delete every game he has been playing.

Translating all this to Flash is pretty simple. Each key has a corresponding ASCII letter key on a normal keyboard. The Flash developer simply makes some buttons that react to the key presses. The key mapping on the first generation player is done on a developer-by-developer basis. When or if the Internet version of the Flash Player comes out, we think that the key mapping would be part of the player. One of the shortcuts we made that helped with localization was that we made movieclips out of the buttons on the screen that we always reused.

The movieclip would always make a call like

 parent.script.o_button_pressed(); 

In every screen where there was a layout of buttons, we always included this script that contained this call. So when we had to localize and swap the X button functionality for the O button functionality, we could swap out the code in the clips to change their behavior everywhere.

The Sony Memory Card

It is important to realize that dealing with memory cards is very difficult, very unglamorous, and can easily take up half your programming time. You have to deal with every thinkable issue when it comes to memory cards (see Figure 12.6).

Figure 12.6. Example flow of the memory card format functionality.

For instance, here are just a few of the issues you need to deal with:

• Is the card full?

• Is the card formatted?

• Does the card have saved data on it?

• Is it a PlayStation 2 card?

• Is the card damaged?

• Are you formatting it?

• Is it done formatting?

• Are you reading from it?

• Did you tell the user how much space is on the card?

• Did you tell the user how big the game data is?

• Is the user sure he wants to format, create a game, or save one?

• Are you telling the user that the card is being read or written to?

• Did you warn the user not to pull out the card or swap the card?

• Did the user do that anyway?

• Did the user do that to both memory cards in both memory card slots?

So you get the idea. This is just a partial list we put together. It does not go into what happens after each Yes and No answer. Don't underestimate the time it takes to do this. There are no real shortcuts except perhaps having a knowledgeable person help you through the planning process.

Memory Footprint Issues

The memory footprint of the UI needs to be small enough to fit into RAM along with the player and parts of the game code. In our project, we did not run the actual game at the same time as the Flash UI and player.

Because of the frame rate issues and some minor renderer anomalies, we used bitmaps extensively. They took up more RAM than vector art but they always looked much better. It is surprising how much you can compress images and still have them look fine in NTSC mode. In most cases on Star Wars Starfighter™, we had to "butterfly" bitmaps. Because the designs were mostly symmetrical, we were able to split the bitmaps in two and remove one side (see Figure 12.7). Then we would use a symbol instance of the bitmap, duplicate it, flip it, and bring it together to show both sides.

Figure 12.7. "Butterflying" a background image in Star Wars Starfighter™.

You can "butterfly" graphics that are symmetrical in order to save memory.

In Star Wars Jedi Starfighter™ we had the luxury of using the loadMovie command so we had much more flexibility when it came to memory issues. However, in both projects, we had to compress bitmaps extensively to fit.

Compressing bitmaps to save RAM memory is very different than compressing for the normal Flash web player. In RAM we are concerned with the "unpacked" size of an image. So compressing a big bitmap down to 30% using Flash export settings will not help much. The bitmap will still expand to close to its original size once it is used. Therefore, we needed to compress the image outside of Flash and then import it to save the optimal memory.

We used JPEG compression in both versions of Star Wars Starfighter™. Remember that you need to test on NTSC while compressing images. What looks bad on your monitor can be perfect on NTSC.

For more information on creating content for output on television, see Chapter 11, " Flash Content for Television."

Frame Rate Issues

The frame rate of the first generation player was frankly slow. Game developers shoot for 60 frames per second. On the web we are often satisfied to approach 24. By using more bitmaps and animating smaller areas of the screen, we were able to achieve something close to 24 frames per second. However, when using the Flash 4 version of the player, toward the end of the project, when everything was looking really nice, we begin to notice the poor quality of the fonts. The only way around this issue was the playback quality setting on the player. Basically, we set the player to "high" quality mode which anti-aliased the fonts, but brought performance down to a crawl.

So in the end, we threw out all our animation and transitions. It was a painful experience that we wouldn't want to repeat. Fortunately, there was some time at the end of the project to put in some new animations that were subtle and small enough to perform and give the UI some life. We used bitmaps when we could and minimized our use of alpha channels.

On the LucasArts Star Wars Jedi Starfighter™ project using the Strobe version of the Flash 5 Player, we ran into frame-rate issues when displaying large amounts of text. To get around this issue, Secret Level and LucasArts created a system to display the fonts as bitmaps rather than as triangles. We had to set all text fields as dynamic text the player would read these and replace them with bitmapped system fonts. This was very effective but made the display of double-byte characters more difficult as you will read in the next section. To display double-byte characters, the only real solution is to use outlines laid out on a timeline.

The performance lessons learned here can be applied to all Flash players coming out on devices. Use small areas of the screen and don't use alpha or if necessary, only use it sparingly. The horsepower and screen drawing speed may not be there but there is only so much you can do despite it.

Localization Considerations

One of the ways that we saved money and time in the Star Wars Starfighter™ project was when we decided to localize into other languages. Imagine the labor involved in localization using traditional console UI design. In the Flash user interface for Star Wars Starfighter™, we created versions for French, German, Italian, and Spanish in just one week (see Figure 12.8).

Figure 12.8. Localizing Star Wars Jedi Starfighter™ into Italian.

Text Length Issues

Our recommendation is to take all the text in your file and create an Excel doc with every word of text in it. Then, get a German translation early and apply the German text to your interface design before it is "locked in." (Of all the languages we were localizing to, German words usually take up the most space.) Place the new translated text into the Flash file early to be sure that your design is viable and flexible enough.

Double-Byte Character Support

If you will support Japanese or other languages that require double-byte characters, test early to make sure your C++ code and/or Flash Player is double-byte compatible. Make sure that dynamic fields display the characters correctly. In the current version of the Flash Player we use, dynamic text fields will not support double-byte text. Therefore, we needed to make sure that all the displayed text is made into outlines and laid out on a timeline.

Work with a native speaker if possible. It's too easy for English-speaking designers to mix things up if they don't understand the characters. It's a luxury to have someone right there with you.

Keep Everything Flexible

Keep ActionScript issues in mind, such as button functionality changes and text editing, as you build the project. Use text that can be edited in Flash whenever possible. Be sure to leave room around the edges of your text for unplanned changes. Even when you prepare, sometimes word lengths in other languages will surprise you.

Use an Experienced Designer

You need to have a Flash designer place all the text for every language. The Flash designer has to have a grasp of the structure of the file and where all the hidden alert movieclips are and so on. Also, the designer will have to make adjustments to the design; for instance, you want the balance of the buttons on the screen to be clean so you will have to adjust their locations to adapt to different button label lengths.

On LucasArt's Star Wars Starfighter™, we attempted to create a translation page in the Flash file so that a translator with no Flash experience would be able to simply paste the translated text into this page and the code would then display it throughout the file (see Figure 12.9). Technically, this is not difficult, but the end effect was visually inadequate. Because of the different word lengths in each language, we had a great number of alignment and word wrapping issues that could not be adjusted to work across all languages. Also, this method will not work for double-byte characters as we described earlier.

Figure 12.9. Star Wars Jedi Starfighter™. main menu screen development cycle.