Tips and Tricks When Developing Your Flash Game on Android

This is a collection of thoughts and tips when developing Flash games targeted to a mobile, more specifically to Android using Adobe’s AIR . I write these notes with a specific focus on full screen games. I’ll cover a few things to think about when designing your game, and a then a few tips and tricks to keep in mind that will [hopefully] save you finding out the hard way.

Planning for Mobile

Before you start making a game for mobile there are some important things to consider, which will save a lot of time and stress if you plan for them.

Type of Gameplay

The type of games typically played are very short bursts of gameplay – while traveling, sitting on the toilet, watching TV. Gameplay that can be stopped and started very quickly. Short bursts of gameplay are very typical of the mobile platform and your games should be made to work with this.

A couple of your options are:

  • make your games levels short and sweet, saving the players progress as they complete stages
  • make the game save it’s state so that it can be stopped quickly and continued at a later time very easily
  • make a game that is only about the score from a single session of play, save that score as soon as it’s achieved

I recommend you keep your games very simple (though still fun) at first, until you get the hang of publishing for this platform and finding out it’s pitfalls. It’s better to get content out there and learn from your mistakes than embark on a huge project and make costly mistakes.

Controls

With mobile phones mostly having touch screens, and a few phones having very small keyboards it’s important to make your game very easy and simple to control. Typically there is no mouse, no arrow keys (or space bar) and screen sizes can be a factor in how much you can fit on a screen at once.

The best option is to choose an intuitive control method, that perhaps adapts to the gameplay. For example, with a vertical scrolling space shooter game you could make the players ship constantly fire bullets with the player simply steering the ship around with their finger, and for a powerful shot the player could double tap their ship. It also pays to remember that fingers get in the way of the screen, so your gameplay should allow for rather large obstructions (for example: my hands are much bigger than my wife’s). If you have a character or ship that the character controls, consider positioning them above where the players touch point will be so that it is still visible during play.

One of the downsides of the need for such large buttons (and fingers blocking the view) is that your gameplay area gets greatly reduced. Consider this when designing your gameplay! If a game is frustrating to see while playing, your game will be quickly become ignored.

Finger controls on mobile screens can also be fairly inaccurate, sometimes not quite registering touches or finger presses accurately, and this varies quite a lot from phone to phone. The best option is to simplify controls and allow for players not always being able to accurately touch the screen. A simple way to deal with this is to make hit spots larger, or take the average values of input (depending on the gameplay).

Give the player a clear and easy way to quit your game. I have received several frustrated comments about this. Players need a large button labeled ‘exit’ or ‘quit’.  Don’t make it hard for them to find.  If they like your game, they will be back.

Note: You don’t have to use “TouchEvents” to capture a player’s input, traditional mouse events work fine.  In fact, I haven’t used TouchEvents in any games I’ve made.

Screen aspect ratio

Modern phones introduce an interesting difference to traditional web based games. Online game resolution varies widely, depending on the developers preference. With the current range of mobile phones we pretty much have a standardised format – depending on whether your content is horizontal or vertical we now have wide screen (or very tall) proportions that take up the entire screen.

There is a rapidly growing number of Android phones, each with slight differences in proportions. Do a little research into the main phones you will be targeting and establish a format that works for as many as you can. If you don’t use up the entire screen your game can look unpolished or poorly adapted. Make sure your background images bleed enough off-screen to cover such slight differences in size, or smartly design your content to look good even if there is extra space around the edges.

An added benefit of using the full screen is that your games don’t have to compete with with the surrounding webpage elements, allowing you to create a much more engrossing experience.

Tips and Techniques

Screen resolution

Even though the screens of mobiles are small, with the current high end phones they pack in a lot of pixels into that tiny space. A fairly typical resolution (at time of writing) is around the 480 wide x 800 high pixels – it can vary slightly from phone to phone, and whether you go full screen or not.
If you make a Flash game this size on a desktop browser you’ll still have a little trouble displaying that size flash file (vertically or horizontally) due to task bars, ads etc being displayed all around it. If you’re making a game that scrolls/refreshes the entire screen area you’re going to encounter some real performance problems if you don’t plan carefully – even on the desktop.

One technique I’ve used is to blit my MovieClips to bitmapData and render everything to a single bitmap that is only half the dimensions (240 x 400 px) then scale that bitmap up to the size of the screen. With a game that has a lot of motion you will often not even notice the double sizing. With pixel art games this is the perfect technique and can massively reduce the drain on performance.
Rendering performance will typically be the biggest slowdown you will encounter when making a game for mobile, so it pays to plan in some time for heavily optimising your game engine to work with this. One of the benefits is that if your game runs well on a phone, it will run well on just about any desktop computer.

Phones are not just for playing games

Although it’s very easy to only focus on your game and it’s internal workings, phones are used for more than just playing games. A player may receive a phone call, have to get off the bus or interrupt your game for any number of reasons. Android phones are great for multitasking and will happily juggle multiple apps running at once.

This creates several problems to a game developer. Unlike the browser version of the flash player, a deployed Android Flash app will happily keep running as fast as it can – consuming battery and CPU. Before you know it the player has a flat battery and is blaming your game for doing it, not good.

Flash in the background…

You can detect when Flash loses (Becomes deactive) with the following …

addEventListener(Event.DEACTIVATE, flashDeactivated);

function flashDeactivated(event:Event):void{

//this function is called when flash has gone to the background

}

and detect when it again gains focus …

addEventListener(Event.ACTIVATE, flashActivated);

function flashActivated(event:Event):void{

//this function is called when flash comes back in focus

}

When you detect Flash is no longer running in the foreground

  • Pause/Save the gameplay – resume it or put up a pause screen that the player can continue with.
  • Stop all music/sound effects – if your game is in the background playing music it will cause great frustration
  • Remove all event listeners – I found this out the hard way, event listeners continue to eat cpu cycles. Listeners to look out for especially are Accelerometer and EnterFrame events. Accelerometer events can use as much as 15-20% while running in the background. Simply re-add them once the app is resumed

Performance tips

  • Publishing for phones is like making games for old PC’s, the cpu and graphics are very slow in comparison to computers even 2 years old.
  • Use blitting when appropriate – this technique is a personal favourite (Links at end of this article)
  • Depending on your game you may benefit from using ‘cacheAsBitmapMatrix’, a new API introduced recently that will make use of hardware acceleration. This can consume a lot of ram, but can be a real performance boost; however, it’s not suited for animated MovieClips. (Links at end of this article)
  • Avoid using Filters like DropShadow, Bevel etc. While you can use these on screen with little animation, they are particularly slow on phones. You could instead create specific bitmaps that contain shadow, it’s a lot more work but can make a huge difference.

Final thoughts

It’s very rewarding watching someone enjoying one of your games on their phone. The tactile nature of touch screens allows players to connect with games like never before, opening a wide range of possibilities. Flash is positioned well to make use of mobile features and performance of the player is improving rapidly.

If you haven’t experimented with Adobe’s AIR platform, I highly recommend you do, they’ve done great work in making it very easy to port Flash to a mobile environment. I would also recommend you test your games on a real device before publishing, it’s the only real way to know how your games will perform. Furthermore it’s also very very easy to publish a game to the Android Marketplace, in fact you can have a game available for download in less than 5 minutes!

I encourage you to get into this space, it’s a lot of fun (and you could even make some money) :)

Lastly here’s a couple of videos demonstrating some of my AIR for Android games …

Maze Ball

POGZ

Useful Links

Android Market
http://market.android.com/publish/Home

Adobe AIR (To publish Flash content as a native Android application)
http://www.adobe.com/products/air/

Blitting

cacheAsBitmapMatrix

Cheers and good luck!

  • http://bowlerhatgames.com/ Josh

    “Give the player a clear and easy way to quit your game.”

    If you mean to return to the title screen, then yes, I totally agree. If you mean to exit the game and return to the operating system, then that’s questionable. Android hardware offers a Home button for that purpose. By default the hardware Back button does the same thing in an AIR app.

    Speaking of the Back button, I’m surprised you didn’t mention it. If your game has menus, you should use it to control navigation, or your game will definitely feel much less native.

  • http://www.terrypaton.com Terry Paton

    Hi ya Josh,
    Regarding the home button/back button – I neglected to mention them in the article, so great point. BUT even when I had these buttons enabled I still got complaints from users that they didn’t know how to quit.

    Also pressing home/back to exit out of your application will not quit it unless you set it up to do so, the apps continue to run in the background. It seems people need very clear indicators on how to quit a game.

  • http://ben-games.com/ http://ben-games.com/

    Very interesting, I have made several games that supposed to work on mobile phones, but haven’t tested yet.

  • http://physicsgamesbox.com/ PHYSICS GAMES

    Hm, very useful, thanks for info…

  • http://www.astaza.com noor

    hello it’s will work on idroid? thats in iphone ?
    thank you & very usefull

  • http://www.revolucija.hr Gorjan

    Nice article. The only thing I am not so sure about is blitting. In my last game, the player character (a bitmap) is viewed from a birds eye view and can move in any direction (360°). I tried blitting and rotating the bitmap and got better results with rotating rather than blitting. I made it so that the character rotates only every 10° and so greatly reduced the number of times the bitmap gets rotated. I did the same with blitting, but still performace was not good. I found this strange since I am a fan of blitting and often use it in flash games.
    But, I would still recommend blitting some things like ScoreBoards and other elements that do not change every frame, but are visually complex (a lot of transparency) and that overlap the “playing area” that changes every frame.
    Good tip about blitting the smaller bitmap and resizing it later, I have not tried that yet :)
    Oh, and one more thing, I found performance to be about the same on HTC Desire (Android 2.1) and iPhone 4, I haven’t tested on other phones.

  • http://www.terrypaton.com Terry Paton

    Thought I should add that I’ve posted some test videos and source code I did in regards to rendering with AIR for Android, using blitting techniques – http://pixelpaton.com/?p=3129

  • http://twitter.com/craigbesweth Craig Beswetherick

    This is more applicable for AIR for iPhone, but from what i have found marking classes and methods as Final does help. Its also good practice ;)

  • http://twitter.com/torres_jonathan Jonathan Torres

    About the screen size, I’m making an Air for Android game in FlashCS5, which I’m planning to distribute on Android and IPhone & IPodTouch. My question is, the game on Android is 480 x 800 and the IPhone is 320 x 480. Can I export the same FLA for both? Or must I make the same game at different sizes to support each platform? Thanks in advance.

  • Guest

    Please, write more about mobile Adobe AIR’s GPU render mode.

  • Guest

    Please, write more about mobile Adobe AIR’s GPU render mode.

  • Pingback: Photon Storm » Blog Archive » Get a Google Nexus One working on Windows 7 for Android Development