CONSTRAINTS OF THE GAME PLATFORM

When building Flash games for the desktop, we are pretty spoiled. There is plenty of everything: processor power, RAM, powerful video accelerators, and big screens. When you look at the box of a regular game for sale, you will usually see minimal and recommended specifications. When developing a game for the web, either you or your client defines minimal requirements, such as target machine. That target machine, however, is often much slower than the one you do the actual developing on. Still it is often considered acceptable even if the game doesn't run perfectly smooth on the target machine as long as it is playable, because features required to be in the game are not necessarily compatible with the minimal system. Most users are expected to actually have a faster machine.

This does not translate to the Pocket PC. With the introduction of Pocket PC 2002, all devices equipped with it are currently based on the same processor, the Intel strongARM processor running at 206MHz. In the future, there may be differences in speed between devices and processors, but currently there is one common platform. That makes testing easier for you if it runs well on your testing device, it will run well on all devices. If it doesn't, it won't work well for anyone else either.

Processor Speed

Pocket PCs are slower than desktop PCs. Although the CPU clock speed does not determine the actual speed of a device, it is an important indicator. Desktop CPUs are now way beyond 1GHz. The CPU currently used in a Pocket PC 2002 runs at 206MHz. The performance of a device is a compromise of size, speed, and power consumption.

What does this mean for Flash games on the Pocket PC? You will meet the limits of processor power much more quickly than on a desktop. A great deal of movement on the screen and intense ActionScript are not your Pocket PC's best friends. Optimization for good performance on the device will accompany most projects. You will find that it's often hard to port a game developed for the desktop to the Pocket PC platform because of processor constraints.

The more actions you try to execute per frame, the more the processor has to work. Loops, and especially nested loops, are not very processor friendly. Recursion is similarly intense the more levels deep you go the more intense. Some actions take more processing time than others. String operations are generally among the most intense ones, so try to avoid them if you can. Looping through an XML object tree is a combination of looping and string operations; handle with care on devices.

Flash renders graphics in a way that relies mostly on the processor. This is true for devices such as a Pocket PC, where most computing is handled by one single processor. Certain graphical operations are more intense than other ones. The most intense ones are alpha effects, gradients, especially radial gradients, and masks. The more vector lines Flash has to draw, the harder it makes the processor work. Text usually consists of complex lines, so animating text is a bad thing to do on the Pocket PC. Flash tries to reduce the amount of calculation by not redrawing the entire stage every frame, but only the rectangular area within which change occurs. If you have something changing constantly in two opposite corners of the screen, you force Flash to do a full stage redraw every frame, even if not much else is changing.

Alpha effects add even more to that because Flash has to redraw the area that an alpha effect is applied to, even if only a small part of it is actually affected by change. All these effects add up to use more processor power when used together or when used multiple times.

The frame rate of a movie also has an effect on the processor use. The frame rate you set is the maximum rate the movie can run. If Flash can't keep up with it, it tries to catch up using as much processor power as it can. I recommend 10 frames per second for Pocket PC games. At this rate you still see change as movement. If you set the frame rate higher, your game will probably not run faster anyway on the Pocket PC.

Developing games from the beginning with low processor use in mind will save you a lot of pain. If a game runs fine on the Pocket PC, it will run perfectly smooth on your desktop computer.

Don't Count on Connectivity

Out of the box, the only connections a Pocket PC has are the sync cable to the desktop and the infrared connection. Although most Pocket PCs can be expanded to have an Internet connection of their own you cannot expect it to be there. With Pocket PC 2002, you can now get to the Internet through the sync cable. That is nice for testing, but is not the typical game-playing situation on a device.

You generally want to play on the Pocket PC when you are away from your desk, when you have only the device with you. If you had a broadband wireless connection, you could just browse to your favorite game site and play. That is not reality yet. Most wireless connections are slow (really slow; such as between 1.0 and 1.5KB per second), and you pay for airtime. And most Pocket PC owners do not have one. Downloading a few hundred KB to play a casual game on the road is not really an option for most users.

So for games, as for most applications, it is best to package them so that they can be downloaded onto the desktop and then synched with the Pocket PC.

For some games, then, it might make sense to load small amounts of game data from a server while on the road. Still you should try to design your game so that it can run without a connection.

Saving Game States

The Flash Player for the Pocket PC does not provide you with any kind of file input/output (I/O). Thus you can't save and receive a game state directly.

You can use loadVariables (and with the Flash 5 Player, the XML object) to send and receive game states to a server. This, however, requires the device to have an Internet connection.

It is possible to store a game state using cookies. Although FSCommand is not supported by PIE (Pocket Internet Explorer), you can use JavaScript, pseudo URLs in >getURL actions to store data from Flash. However, due to the temporary nature of cookies, you cannot guarantee that the cookie will still exist the next time the user opens the game and wants to continue with the saved game.

Death of a cookie can be caused by its expiration date, or when the user decides to clear his or her temporary Internet files. The browser may also drop cookies if it runs out of allowed space for temporary files. With the limited amount of internal storage space, this can happen much faster than on a desktop. And on top of that, the user may have chosen to only allow session cookies or to not to allow cookies at all. Any other approach to saving game data requires the installation of other software. This can be done by installing or creating a web server on the Pocket PC (see Chapter 9, "Standalone Application Development Using Flash and Java").

If you don't want to rely on cookies, you don't have a real option to save a game state when you use Flash by itself. If you want to be on the safe side, develop games that don't need to save a game state to be playable.

File Size for Games

Pocket PCs have a limited amount of internal storage space ranging from 32MB to 64MB RAM for Pocket PC 2002 devices. This memory is used for storage and to run programs, usually split in half. The storage space can be expanded with memory cards and micro drives, but you can't assume that your user will have extra memory available.

The Flash Player was originally created with small file sizes in mind. Yet it is still capable of handling files that are several megabytes on desktop systems. On the Pocket PC you shouldn't rely on the same capabilities, simply because there is much less overall memory available.

If you try to play back a 2MB SWF on the Pocket PC, Flash will not only have to keep those 2MB in memory while running as an ActiveX control within PIE, but PIE will also store a copy in the temporary Internet files. The Small Web Format (SWF) is a compressed format and during playback it gets uncompressed. This is especially the case when using bitmap graphics and playing back sound. If your device is equipped with 32MB of storage, of which 16 are reserved to run programs, you can easily run low on memory with larger files, especially when you also have other programs open.

You can help Flash with its memory management by splitting your files into smaller pieces and loading and unloading them as needed.

As you share a limited amount of available space with everything else the user has on his Pocket PC, it is a good idea to carefully watch out for the file size of your game.

Game Sound

Sound is an important part of the gaming experience. There are some limitations to the device, however, that you will have to keep in mind when creating games for the Pocket PC.

The built-in speaker has a naturally limited quality. The headphone outlet provides a decent audio quality. It is likely that the user, at some point, will be in an environment where audio from the device is unwanted. So any game using audio should have a quick option to mute the sound.

On the Compaq iPaq, the speaker is on the joystick. This means that your game audio could be muffled if the joystick is being used.

On the technical side, Flash can export raw, uncompressed sound as well as ADPCM and MP3 compressed audio. The Flash 4 Player that was released for the Pocket PC could only handle raw audio and ADPCM compression. The Flash 5 Player for the iPaq also can play MP3 sounds. Versions for other platforms might or might not be able to handle MP3 sound.

Raw audio means uncompressed sound. This leads quickly to huge files, so you don't want to use it in most cases. Although MP3 offers better compression and better sound quality than ADPCM, it is more processor-intense to play back and is thus competing for resources with the screen redraw and ActionScript. For some games this can make the difference between playing smoothly or not. At this point I recommend mainly ADPCM compressed audio for Pocket PC games.

This might change as more versions of the Flash Player support MP3 and the devices become more powerful. The backdrop is that ADPCM audio adds significantly to the file size compared to MP3 audio, so use it wisely and re-use event sounds where possible and use short loops where needed.

Display Size for Games

All Pocket PCs have the same display size of 240x320, a vertical format. The maximum area that can be used by Flash within Pocket Internet Explorer is 240x260. This area can be reduced if the user has the browser's address bar open.

To use Flash's entire screen real estate as described here, the margin widths need to be set to "0" in the embedding HTML document:

 <BODY marginheight="0" marginwidth="0" leftmargin="0" topmargin=0 rightmargin="0"  bottommargin="0" > 

This means you have only that amount of screen real estate and not one pixel more. For game design, this means you have to be sure you have enough space for the game area itself, while reserving space for necessary status displays during the game. Additional framing artwork should be kept to a minimum.

Game Controls

The user interacts differently with the Pocket PC than with a desktop PC. There is no mouse, but rather a stylus and a touchscreen. Sometimes fingertips are used to play instead of the stylus. So depending on the game, it might make sense to have buttons and hit areas large enough so that they can be used with a fingertip.

With the stylus as pointing device, the "mouse" movement doesn't get tracked until you press on the screen. For Flash development, this means buttons do not receive rollover and rollout events.

The Pocket PC doesn't come equipped with a physical keyboard, thus you can't build complex game controls using the keyboard. The directional pad of the Pocket PC, however, functions in Flash as the arrow keys.