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.
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
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 …
//this function is called when flash has gone to the background
and detect when it again gains focus …
//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
- 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.
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 …
Cheers and good luck!