optimizing the code

One of the major issues we faced during testing our content on the device was memory runouts. There was one instance in the game where we had three enemies and one hero, and for all all of them, we had to check for collisions with the wall, with obstacles, with each other, and with collectable items on every Enterframe loop. Every time we ran the game on the device, the "Problem with content 1" error message occurred, which refers to memory loss. We then reworked the code in such a way that when the characters were moving vertically upwards, only the objects in their path upwards would be calculated for collisions and not all the objects currently on the Stage. This reduced the calculations by more than half, and helped us get rid of the error message.

Optimizing your ActionScript is very important if you want your game to run smoothly. The following tips will help you build great games that also perform well:

• The Flash 4 tellTarget action works a lot better than the dot syntax. Your code runs a lot faster because a step-by-step path is defined for locating the movie clips or variables. However, while using a dot, the referring object starts looking from the main Timeline, which results in a performance hit. Luckily, Flash Lite 1.1 is based on the Flash 4 engine.
• Try reusing your variables as much as you can, especially if they exist on the root, because these variables will continue to be present in the device memory as long as the movie is playing. And if they are redundant, they just eat into the resources unnecessarily. For every new declaration made, the file size will increase by 12-15 bytes depending upon the variable type.
• Avoid using variables of the float type, especially while moving your movie clip symbols through scripting. This is because Flash Lite does not round off your floating point numbers, so you will not only end up with a higher file size, but your movie clip will also not function as expected.
• Avoid using very long variable names and keep them as short as possible for better game speed. Imagine if you were asked to say iwishthenamecouldbeshorter = 1 compared to gVar = 1. Which one would you be able to say faster? Likewise, processors appreciate shorter expressions.
• Avoid using nested conditions, especially in loop structures, as it will completely stop all movements on the screen during the calculations. This gives the impression of your game being hung, and the player may not enjoy the experience very much.
• Always have a reference variable for Object properties, especially in loop structures, as shown in the following snippet. If this is not done, the processor wastes resources while computing the property value on every iteration.

str = "12345";
cnt = str.length;
for(x=0; x<=cnt (instead of str.length); x++) {
   .......
}

These are just a few of the important pointers we jotted down during our coding process. You can also check the following great resource for more tips: ActionScript Optimization Tutorial.

dressing up your game

Always ensure that the graphic designer and the programmer know exactly what they are currently working on. If you doing both jobs, it's even better, because you will understand the capabilities of the Flash Lite technology and develop the content accordingly.

The graphics for games on mobile devices are generally quite small in size for the players to really notice minute details. Moreover, the color support is also limited to no more than 65,000 colors. As a result, a lack of graphic detail is less of an issue on these small screens.

The performance of a game on mobile devices largely depends on the graphics. If your graphics are optimized, it reflects not just in your file size but also in the performance of your game. Consider the following tips when designing games:

• Keep the number of nodes at a minimum when creating vector shapes. This will also improve the performance of Flash Player, which calculates every curve in a shape before rendering it on a frame loop. Optimizing the graphics not only helps keep final file sizes small, but also boosts the performance of complex games. Figure 6 shows the optimized and unoptimized versions of a character's face from Cryptic Capers. The optimized version of this character, shown on the left, has a smaller footprint and is rendered faster than its unoptimized, sluggish cousin. Note also that to the naked eye, the difference in appearance is negligible when the character is reduced in size to approximate its appearance on the small screen of a mobile device.

Figure 6. The optimized (left) and unoptimized
(right) version of a Crytpic Capers character

• Create a color palette with minimum colors and maintain and repeat the same palette throughout the game. Every additional color created using the color palette, apart from those already present in the default palette, adds up to 20-30 bytes for every symbol that uses that color in the file. Figure 7 shows two color patches; the final patches look the same when minimized. However, Patch A uses more colors and results in a larger files size than Patch B.

Figure 7. Both color patches look the same when minimized,
but Patch A uses more colors and results in a larger file size

• Remember that not every color that you use in your Flash file will look the same on all devices. This is because your desktop system can render millions of colors. By contrast, a mobile device has only around 65,000 colors. So always compare your content and see the colors that work best for you.
• Avoid grouping shapes. If your graphics require duplication, convert them to a movie clip symbol or a graphic symbol instead of leaving your graphics in groups. Symbols are easier to calculate by the processor, even with multiple instances present on the Stage. However, each instance of a group will be calculated separately. Thus symbols help boost the performance of your game.
• Avoid using gradients and alpha transparencies, especially when your game has animations. Try working with flat colors for better performance.
• Keep the use of raster images to a minimum. Raster images run a lot faster than vector graphics; however, they can also create memory issues, if they are not able to decompress correctly while running on a device. Moreover, raster images contribute to larger file sizes. Optimize raster images in an application like Macromedia Fireworks before using them in your Flash Lite file. Also, don't let raster images dominate your Flash application, otherwise you forgo the strengths of Flash as a great scalable environment.
• Avoid unnecessary blank keyframes unless they are absolutely necessary. Blank keyframes add to the final size of the game file.
• Minimize the number of off-screen objects, especially if they are animated. Even when they are not visible to the player, they are using device resources, thus slowing the performance of the game.
• Avoid using outlines on vector graphics, because they slow down the game performance. However, if you really need to use an outline, you can emulate it by using a surrounding fill.

Refer to Andreas Heim's article, Best Practices for Porting Flash Animation to Mobile Phones with Flash Lite, for more great tips on graphics and animation for Flash Lite on mobile devices.

Sound and music are as important in your game as any other element since they help keep the player's interest. In the case of Cryptic Capers, the sound was even more important, because the game had such a rich look and feel; without sound it would have looked incomplete.

However, incorporating sound in games for mobile devices isn't as easy as incorporating sound for browser-based desktop games. In the case of Cryptic Capers, our greatest obstacle was keeping track of the inflating file size of the game and memory consumption on the device when adding sound. We wanted to keep our file size between 180-200K. However, after including sound, the file size was more than 230K. Moreover, on screens where we had more calculations, the game always crashed with a memory error. The challenge was, where do we go from here?

We first used five MIDI sounds in the entire game—four event sounds and a background score. MIDI gave us a small file size as most of the sounds were 1-2K in size. However, we discovered that different devices played the MIDI sounds differently. On some devices the sound was fine, while on others it cracked and got higher in pitch. A little scraping through the device's functionality had us realize that different mobile devices had different tone generators. These tone generators did not always have support for all instrumental tracks present in a MIDI file. Thus the sound, although the same, seemed different on different phones. Since we wanted to achieve cross-platform compatibility, we also thought of trying out the WAV or MP3 formats.

The WAV format resulted in too large a size for the final SWF file. We had to optimize the sound in order to avoid memory errors. We resampled the WAV sounds by getting them down to under 22 KHz, restricting the number of channels in the sound to 1 (mono) and the sample bit rate to 8. Although the sound quality was not that great, we had managed to accommodate 5 sounds in our game, which played back well on all Nokia Series 60 devices.

With the sound added to our game, we noticed that every time the sound played on the device, the game paused for a few milliseconds before continuing. This was because the sounds were inside the movie clips and were set to event sounds. Every time the Timeline reached a sound frame inside a character movie clip, the sound would first load at the same time as the change in character graphic and then play, hence the pause and delay in playing the sound. To patch over this delay, we made sure that we loaded the sound first and then the change in character so that the halt in the game would be less obvious. Although the pause continued after this, it was not as noticeable, because it was masked by a change in animation immediately after it.

Using sound in Flash Lite requires some finesse and trial and error to see what works best for your content. If you want to learn more about sound formatting and optimization for your Flash Lite content, you can refer to Frank Gelat's tutorial "The killersound Technique — Optimizing Digital Audio in Flash Lite" or Nader Nejat's article "Using Sounds in Flash Lite 1.1." You can also visit the Nokia forum to learn more about audio capabilities on Symbian OS-based devices.

where's that bug?

In theory, game development should be simple—finish one part of it before moving on to the next—be it story, level, characters, obstacles, compatibility, or sound. Keep testing your content at every stage of development so you can catch and fix bugs immediately.

The fact that the Flash authoring environment has a debugging tool is a boon for any developer. You cannot just keep track of variables but also use it to spot movie clip hierarchies and remove any unused movie clips. My personal favorite debugging method is the trace function:

trace ("Am I stuck at this point");

I find it very convenient to insert it within code loops, tellTarget methods, and call references when my code throws errors.

As a game developer you must have definitely experienced writing long scripts and declaring variables at various points and then forgetting about it. Believe me, it happens to everyone. However, when you know how to debug your code, your job gets a lot easier.

Conduct your testing in the standard Flash Player or Flash authoring environment, and the device. In the Flash authoring environment, you can spot the ActionScript errors and warnings. This ensures that your code is clean and free of infinite loops that could otherwise hang your game. However, this is not enough. There are a number of errors that your emulated environment will not trap, but the device will. These errors include memory leaks, corrupted bitmaps, bad sound data, and other similar issues. It will also help you test the functioning of your new FSCommand2 functions, which would otherwise not run in the IDE.

Our focus was to make sure that our content ran collectively on all platforms and devices. We started our testing on the Series 60 devices, and after we had finished testing the game, we adapted the same build of the game by testing it on the UIQ phones and the Pocket PCs, which use a stylus. We then checked to see if the game would work on the web, and made the necessary alterations. Just in case you're wondering — we also had an optimized version for the Japanese devices. We finally had a game that ran perfectly well on all target devices. The catch phrase of "author once, run everywhere" proved very true in our case with Flash Lite.

In this article, I've shared with you our experience of building Cryptic Capers. Although it was developed during our "Flash Lite research" phase, it has proven to be one of our best games due to its addictive gameplay and stunning graphics. We look forward to seeing it played on mobile devices worldwide.

In the meantime, we hope our practice and knowledge will be helpful in your own efforts to develop games for Flash Lite 1.1. Naturally, you first have to enjoy playing games before you can actually build a game that is fun to play. You can search the web for sites that provide simple games like Memory, Tic Tac Toe, and so on to start with. You can then take the next step and take on games like Space Invaders, Simon Says, Slider Puzzles, before graduating to more difficult games like Pac Man, Tetris, and Basketball and others.

If you have ever created Flash PC games, the experience of creating Flash mobile games will not only be different but also exciting. The process of creating the game remains the same. What changes is the size and platform for delivery. And the best part is, all you need is Flash MX Professional 2004, the Flash Lite 1.1 CDK, a Flash-enabled device, and great enthusiasm to get going. So what are you waiting for? Get started already.