USER INTERFACE LOGIC FOR FLASH IN A GAME TITLE DEVELOPMENT ENVIRONMENT

By itself, Flash does not have the capability to handle all the duties required to interact with the PlayStation hardware and game code. In this section we'll discuss some of these requirements and look briefly into the custom protocols and logic needed for the project.

Communication Protocol between Flash and the PlayStation 2 Hardware

For the Flash interface to act and react it obviously needs to communicate to the PlayStation 2 game and PlayStation 2 hardware. For this communication to occur there will have to be some type of middleware that the user interface can talk to in its own language.

Middleware between the PlayStation 2 and Flash can be thought of as a type of interpreter between the actual C++ game code that controls the game and the Flash user interface and Flash. It can be as simple as some script functions in a text file.

There is a strong tendency to overlook the length of time it takes to build out the middleware layer for Flash. It is important that whoever takes on this task is highly skilled and has full knowledge and understanding of the underlying game code.

Who Drives, Flash or the Game Code?

There has been a lot of discussion with similar applications whether to create a "state machine" in C++ that basically drives Flash completely. A state machine is an application whose only job is to keep track of the state of the game and the user's actions. In this case, Flash would simply tell the state machine what buttons were pressed and the state machine would tell Flash which frame to go to or what info to display, and so on. There would be no logic inside Flash at all in this scenario. Because of various resource issues we decided that creating a state machine would be more time-consuming and be harder for us to test and debug.

So it seemed smarter for us to handle all questions and drive the UI on the Flash and ActionScript side. In other words, Flash asked all the questions. The middleware would never tell Flash what to do unless asked. When Flash got to a specific screen, we would ask the middleware layer from Flash what the state of things were and display based on the answer we got. For instance, we could ask the middleware layer if the user had unlocked certain missions in the game or what the current controller analog stick sensitivity setting was (see Figure 12.3). The middleware would simply respond to the current stick sensitivity query with something like "30". We would take that number and tell the display graphic to display the result (in this case a progress bar).

Figure 12.3. Controller settings from Star Wars Starfighter™.

Alternatively, if the user wanted to change the controller vibration setting, we would show them the settings as they pressed the arrow keys. In this case we would increase or decrease the progress bar using tell target commands. Once the user stopped and pressed the OK button, only then would we send back the corresponding number to the middleware layer that set the controller sensitivity setting.

Flash Commanding the PlayStation 2

In the Secret Level port of the Flash 5 Player, the procedure is to call a middleware function via the getURL Flash command in the format:

 "callback://function." 

For instance, to set the Sony PlayStation 2 to play in stereo sound mode, we would tell the middleware:

 getURL ("callback://SetStereoStatus 2"); 

This calls the function in the middleware layer called SetStereoStatus and sets it to stereo (2). If we wanted to set the mode to mono, we would set this number to 1. This choice of digits is arbitrary and decided in the middleware layer. The middleware needs to actually be set up this way to communicate the information to the Sony PlayStation 2.

PlayStation 2 Code Commanding Flash

Of course, we have to ask questions of the middleware layer to get information about the Sony PlayStation 2 hardware settings or game settings.

For instance when we get to the sound screen, before displaying anything, we want to ask the middleware layer what the stereoStatus is.

 getURL ("callback://GetStereoStatus stereoStatus"); 

One interesting thing here is that we set up the middleware to let Flash set the name of the return variable. So Flash is saying "tell me what the stereoStatus is and put that value into the variable named stereoStatus ".

We built the UI and middleware as we went along and found that we needed to change variable names sometimes to keep them from sounding like they belonged to something else. For instance, the variable name memorycardMessages became memoryCardAlerts when we added alerts to the memory card screen.

So, getting back to the check for the StereoStatus value, the Sony PlayStation 2 would give us a value of 1 or 2 and then we would tell a movieclip to do something with it. Usually, we would go to a frame on a movieclip that would display Stereo or Mono.

The interesting thing is that when we query the middleware, we have to let the Flash movie go to another frame to actually receive the data, so all routines are at least two frames long. Now we will have the second part of the routine on the next frame:

 play();  if (stereoStatus == 1) {       // tell the stereo indicator movie clip to display mono       mc_stereoStatus.gotoAndStop("mono");  } else if (stereoStatus == 2) {       // tell the stereo indicator movie clip to display stereo       mc_stereoStatus.gotoAndStop("stereo");  }  stop(); 

This two-frame routine can complicate things. Sometimes you are checking something on the PlayStation and then you can be "pulled" from that check mid-frame by a user action. The result is usually that you get stuck in a frame. Sounds weird and it is. You have to be ready for people to hit keys over and over again rapidly. Having a play() action at the beginning of the second frame seems to resolve these interruptions.

Other than these few issues, ActionScript behaves as expected on the Sony PlayStation 2 platform. We find no behavior differences between ActionScript in the web player and the Sony Playstation 2 player. There are only a few obvious things missing such as FSCommands and other external data calls such as loadVariables. In some ways it is easier than developing for the Internet in that file loading is not an issue and you don't need to account for latency to server-side applications.

Figure 12.4. Sound screen from Star Wars Jedi Starfighter™.