Modified
14 January 2007
Requirements  
Prerequisite Knowledge Required products
Experience with developing Flash Lite games or apps for mobile devices.
Additional requirements  
Adobe Device Central  
Mobile Device Profile Update #4  
Flash Lite 2.1 enabled mobile device  
User Level  
Beginning  

 

Mobile games are a big business with many talented developers creating compelling device content. Although most developers can write effective code, create interesting graphics, and test their games successfully, it is always helpful to review the best practices to follow—especially considering the wide variety of handsets on the market.
 
In this article I'll provide tips to make your game design and development experience better and easier. My intention is not to provide an analysis of how to improve the game development process, but to share some tips that I picked up while developing Flash Lite games.
 
 
Tip #1: Start with a base build, then port your game
Today's handsets come with varied screen sizes and resolutions from different manufacturers. To be make things easier for you, always start with a pre-determined screen size for your base build, commonly 176x208 or even 240x320 pixels considering the range of available smartphones.
 
Base build is a term that refers to a standard platform or specification that is followed by the industry when launching a product. Following the base build allows you to cover a larger handset domain and will make the process of porting your game to different devices with a range of screen sizes easier—based on your client and project requirements.
 
Porting refers to the process of adapting your game to a specification or platform that differs from the one targeted when the game was originally designed. Historically, there have been many debates regarding the requirement to port Flash Lite games to accommodate playback on different handsets, because vector graphics have the ability to scale. However, porting is necessary for several reasons:
 
  • Pixel fonts begin to blur and look distorted when scaled.
  • Bitmap images can look pixilated when scaled beyond their original size (see Figure 1).
  • When the device screen size is not proportionate to the game screen size, users may see the area outside the Stage while playing the game. For example, 176x208 is not in proportion to 240x320 when the content is scaled.
  • Optimized vector images can become less detailed when scaled automatically for a bigger screen with a higher resolution than the game's intended resolution.

 

Pixelation occurs when bitmaps are scaled larger than their intended dimensions.
Figure 1. Pixelation occurs when bitmaps are scaled larger than their intended dimensions.
 
For best results, select a base build for your initial game development and then port the final content for different screen sizes.
 
 
Tip #2: Design with intuitive navigation for gameplay
Mobile games are all about the user interaction. When users press a key on a mobile device, it allows them to jump to a different screen or causes a character to perform an action. Users expect the standard pattern of key presses and joystick manipulation to work uniformly across all the games they play. Unusual user interaction or a change in the navigation experience can actually cause a player to dislike a game.
 
For example, a user may routinely play games using the joystick or the number keypad when controlling a character's movement on screen. Developing a game that makes a character move forward when the user presses the number 9 key is non-intuitive, because the user expects the number 2 key to move forward. Standard convention for navigation would make a character turn to the right when the user presses the right joystick control or the number 6 on the keypad.
 
Become familiar with common mobile device navigation conventions before developing your games, to ensure that users are not frustrated during gameplay (see Figure 2).
 
Use this diagram of the number keypad and joystick as a reference for common device navigation.
Figure 2. Use this diagram of the number keypad and joystick as a reference for common device navigation.
 
It is also a best practice to bind the joystick controller and the number keypad with each corresponding event.
 
As you develop mobile games, it is imperative that you build intuitive controls. Ideally the game should be playable using the four-way joypad, without requiring key presses.
 
 
Tip #3: Use variables and logic to keep your code flexible
ActionScript lends itself to working with objects and their properties, which frees you of the bad practice of hard-coding (or embedding) input values or data directly into your source code. When developing for different mobile screen resolutions, hard-coded values become difficult to manage.
 
For example, suppose your game displays three objects horizontally on-screen at an equal distance. To keep the game looking consistent across all handsets, you want the objects to maintain expanded but equal spacing when the screen size is larger.
 
In this scenario, it can be tempting to fall into the bad habit of using pre-populated values for the initial development screen size, and then altering the source code when porting the game for another handset's screen size.
 
In the code example below, the _y property of the duplicated movie clip is extracting hard-coded values from an array. In contrast, the _x property is determined programmatically, by first calculating the width of the stage, and then placing the duplicate movie clips based on the resulting values of the calculation.
 
var clipNum = 3 var xLocate = Stage.width/ (clipNum+1); var yArray = new Array (30,40,50); for(x=1; x<=clipNum; x++){ var tempMc = attachMovie("block", "block"+x, x); with (tempMc) { _x = xLocate*x; _y = yArray[x-1]; } }
This is a very simple example of code practices to follow, to ensure that your game displays correctly in all circumstances.
 
 
Tip #4: Use ActionScript functions to determine when objects intersect
Working with object collisions is required for action or adventure-based games, because the ability to detect collisions makes the content more interactive. Flash has many built-in functions to ease your code-writing for collision, including the popular hitTest method.
 
Although the hitTest method is very easy and convenient, it is not something you should use for every kind of collision. On some occasions you may want the coordinates of your movie clips to align in order to perform an activity, such as a character climbing a ladder or walking across a platform. Moreover, in some situations the colliding objects are not always perfectly rectangular or circular in shape. In these cases, you can update your gaming logic to use other strategies for performing collision detection.
 
One method that is very convenient, easy on the mobile processor and precise for object collision is the old-school collision detection method. This involves using the object's  properties of its x and y locations, in conjunction with the object's width and height.
 
The following snippet demonstrates how this is accomplished:
 
var obj = new Object (x1, y1, w1, h1, x2, y2, w2, h2); if((obj.x1 >= obj.x2) && (obj.x1+obj.w1 <= obj.x2+obj.w2) && (obj.y1 >= obj.y2) && (obj.y1+obj.h1 <= obj.y2+obj.h2)){ collision = true; }else{ collision = false; }
Considering that the Cartesian Coordinate system in Flash starts at point [0,0] on the top-left corner of the screen, the x value will always increase as the object moves toward the right, and the y value will always increase as the object moves downward.
 
The code example above does the following:
 
  1. First, it determines if the left edge of Object1 is more than the left edge of Object2.
  2. Next, it evaluates if the right edge of Object1 is less than the right edge of Object2 (left edge + object width).
  3. Then, it finds out if the top edge of Object1 is more than top edge of Object2.
  4. Finally, it checks if the bottom edge of Object1 is less than the bottom edge of Object2 (top edge + height).
To clarify how this works, I've created a diagram that identifies each of these object properties in relation to the Stage (see Figure 3).
 
By comparing each object's x and y values in relation to the Stage, object collision can be detected.
Figure 3. By comparing each object's x and y values in relation to the Stage, object collision can be detected.
 
 
Tip #5: Select the best event structure for function calls
When dealing with events in your Flash Lite file, it is a best practice to maintain a balance between time-based ActionScript and frame-based ActionScript. Time-based ActionScript refers to the practice of calling a function or a method at periodic intervals at runtime. Frame-based ActionScript refers to executing a block of code when the playhead enters a keyframe in the Timeline.
 
When your game's frame rate is set to 12 fps, this means the playhead executes a frame every 1/12 of a second or 1/12 of 1000 milliseconds. Using this basic calculation, you can choose to use either of these two approaches to call functions.
 
With time-based ActionScript, you can use the setInterval function:
 
setInterval ( function(){ trace("enemy updated"); }, 1000 );
With frame-based ActionScript, you place a block of code on a specific frame and invoke the gotoAndPlay() function:
 
Frame 1
 
trace("enemy updated");
Frame 2
 
gotoAndPlay("previousFrame");
It is a best practice to avoid using too many instances of time-based ActionScript function calls, because doing so can slow down your game's performance. Frame-based function calls are useful if you want to simulate slower animations in SWF files with higher frame rates, because the time interval is ignored if it is less than the movie's frame rate. For example, in a game like Asteroids, it is best to control the enemy ship's movement with frame-based ActionScript function calls and control the user's spaceship (the main focus of animation) with time-based ActionScript function calls.
 
 
Tip #6: Add incentives for user participation
Imagine a level-based game where the objective is to collect all 30 pick-up items within a time span of 90 seconds. Now imagine the same game without panels displaying the user's score and elapsed time.
 
When gamers are not provided with a measurement of their progress, the user experience of even the most fantastic-looking game can fail. In addition to tracking their own progress, gamers like to compare their scores against the scores of the other players. The scoreboard is a core component of any game because it helps stimulate replay of challenges, encourages the recommendation factor, and adds to the depth and feeling of achievement—which are all essential attributes for any great game.
 
Scoring can be incorporated locally on the device or stored on a global system. If you are developing games for player versions above Flash Lite 1.1, you can use shared objects to achieve this goal. Shared objects offer the flexibility of maintaining scores and progress through multiple game sessions. To learn more about working with shared objects, read the Mobile and Devices Developer Center article Persistent data: Saving user preferences and game scores.
 
 
Tip #7: Keep your code organized and easy to maintain
Flash Lite 2.x/3.0 supports both ActionScript 1.0 and 2.0. Although code developed in ActionScript 2.0 compiles to ActionScript 1.0 and then is converted to Byte code as a SWF file is published, it is recommended to develop games using ActionScript 2.0 whenever possible. The structure of ActionScript 2.0 facilitates better object-oriented programming, making the code easier to update and debug. It also makes it easier to keep track of the various elements in the project.
 
It's a common misconception that objects are too slow to work well in games. In real applications, objects do not cause your game to respond sluggishly, if you use them appropriately and only in situations where they're a benefit to your design.
 
Object orientation is especially handy in game programming. Take for example a game that involves the slaying of enemies. Every time you slash an enemy, you want to show that attack. You also want each enemy to react differently. Using objects would be helpful in this type of game, because you could pass a value called "enemy_type" to a function react_to_attack(), and each instance would animate based on the object's type specification. Alternately, you could just call an enemy[x].attack() function, because all instances of enemies would include an attack() function, along with all the data they need to interpret it.
 
Another advantage of using objects when developing games is the concept known as inheritance. Inheritance is very efficient and useful when programming games. It helps you to reuse code while leaving the existing code unmodified. In this imaginary game example, if attack() is not a function defined on the enemy, then whenever the function is called, the compiler will look at the enemy's superclasses or parents by default. To learn more about inheritance, read the section Key object-oriented programming concepts in Colin Moock's article Object-Oriented ActionScript.
 
A full discussion on working with object-oriented programming is outside the scope of this article, so for the sake of brevity, I'll just say that I've found developing games using classes to be a great strategy when used appropriately.
 
 
Tip #8: Choose the right font for each part of your game
Pixel fonts render best on mobile phones. This is due to the fact that mobile screen sizes are small and sometimes have limited color and resolution compared to desktop systems. As a result, pixel fonts (which are smaller) look sharp and legible, and have the added bonus of occupying less space when used in Flash Lite games.
 
Decorative fonts quickly increase your file size and they can appear blurry. Decorative fonts look best when displayed across a large part of the screen, such as title screens (see Figure 4).
 
In general, decorative fonts should be reserved for use on title screens.
Figure 4. In general, decorative fonts should be reserved for use on title screens.
 
When working with pixel fonts, follow these guidelines for best results:
 
  • Place the font location on whole numbers, such as x = 30, rather than x = 30.4.
  • Avoid setting the font to a bold style.
  • Always keep your text left aligned for best display.
  • Select the font rendering method to Bitmap text for best rendering.
  • Maintain your font sizes in multiples of 8: 8, 16, 24, and so on.
 
Tip #9: Replace arrays with strings for Flash Lite 1.1 games
You might be curious why I'm mentioning developing for Flash Lite 1.1 when a newer version—Flash Lite 3.0—is available for download on Adobe Labs. Although Flash Lite 3.0 holds a great promise for future devices, the market is currently populated with devices supporting Flash Lite 1.1. Whenever you are developing a new game, be sure to consider your target audience and choose your target device accordingly.
 
When you are developing mobile games for Flash Lite 1.1, you may often feel the need to use arrays in your code. The most common solution is to simulate arrays by creating a set of variables using ActionScript and a counter:
 
Another approach for working with an array of values is to reference them as strings. This method works well if you are developing simple grid-based games, like Brick Breaker, Tic Tac Toe, Whack a Mole, and so on. Using strings rather than arrays makes it easier to maintain runtime data in your file, and strings are also convenient to reference during development.
 
For example, imagine a game is based on the Tower of Hanoi, and the player has to move the blocks from their present location to the final destination highlighted in yellow, while taking care not to place a bigger block on top of a smaller block (see Figure 5).
 
eval("number" add 1) = 1;
In grid-based games, strings can be substituted in place of arrays to achieve the same functionality
Figure 5. In grid-based games, strings can be substituted in place of arrays to achieve the same functionality
 
As I developed this game, I needed to maintain three arrays of information in order to keep track of the position of the blocks as they are repositioned. Since I was building this game for Flash Lite 1.1, I decide to maintain strings with corresponding variables, like this:
 
str1 = "321"; str2 = ""; str3 = ""; str2 = substring (str1, 1, 1) add str2; str1 = substring (str1, 2);
The logic is set up so that when the user moves the first block from grid 1 to grid 2, I shuffle the values in the string as well, as illustrated in the code above. This strategy also allowed me to avoid creating an extra variable for storage, because I could simply swap the values of the two variables.
 
 
Tip #10: Test on the actual device
Testing your game is very important, because you'll want to ensure your game is free of bugs before releasing it to the market. All games can potentially be susceptible to two kinds of bugs: Technical bugs and performance bugs.
 
Technical bugs arise when a game encounters errors related to mistakes in the ActionScript syntax or logic. Syntax errors can be detected using the Flash debugger on compilation; however, logic errors can only be detected by actual testing during playback. Emulators work best here, because they save you the trouble of constantly transferring SWF files to the handset for tweaks and testing purposes.
 
Performance bugs appear when the device starts running low on memory as your game is running. It is imperative that you check the clarity of all content and functions by performing call tests, SMS tests, and so on. For this purpose, testing your game on the actual handset is an absolute must.
 
It is recommended to perform tests on the actual handsets of your target devices, even after testing your content on emulators or using Adobe Device Central. However, since it is not really feasible to own all of the handsets available, try sharing your content within a close circle of friends and colleagues in order to perform remote testing. Gather feedback and make adjustments as needed. You should only launch your game into the market after you are sure that your content is stable on the different handsets you are targeting.
 

 
Where to go from here

In this article, I've provided some basic tricks and tips that can be useful when developing a game for the Flash Lite platform. Game development is an exhaustive topic and best practices can only become second nature through the process of creation. When you have an understanding of creating games, these practices will become an integral part of your development skills.
 
To learn more, refer to the in-depth articles and tutorials on working with Flash Lite on the Adobe Mobile and Devices Developer Center.