Andreas Heim

www.smashingideas.com

Last November I attended the Macromedia MAX conference in New Orleans, and when I arrived back home, I was all pumped up. I had just learned a whole lot about the progress Macromedia has made in integrating Flash technology in mobile devices to bring to mobile users rich and engaging experiences as memorable and personalized as the experiences we get from our browsers. For the first time, I saw some really impressive content on mobile phones that made the phones look even cooler. At the conference, Macromedia also announced the first Flash Lite Content Contest.

On the way back home I started thinking about how we at Smashing Ideas could win in this contest. Back in the office, we decided to get a couple of mobile phones and create content for two contest entries: games and animation. For the animation category, we decided to put one of our favorite animations, "2001," on the phone. "2001" is a two-minute-long animation that features our mascot robot in a challenge to buy a bag of candy from a really tall vending machine. To view the "2001" animation, click the phone key pad just below the Start text on the LCD screen.

At the time, we were no strangers to devices; we already had experience creating content for the Pocket PC platform, and we were familiar with the Flash 4 ActionScript syntax, which is supported by Flash Lite. However, little did we know how small our world had just become. In this article, I'm sharing the lessons we had to learn to get our "2001" animation to work on a mobile phone (and actually win the best animation category). The tips and tricks mentioned in this article also apply to creating new games and applications for mobile devices in general.

Requirements

To complete this tutorial you will need to install the following software and files:

Macromedia Flash MX 2004 (7.2 update)

• Try
• Buy

Note: If you already have Flash MX 2004, make sure to download the latest 7.2 update

• Download the 7.2 update

Flash Lite CDK (optional)

• Flash Lite CDK download for developers

A Symbian Series 60 phone with the Flash Lite 1.1 player preinstalled

Tutorials and sample files:

• Download the "2001" animation from the Macromedia Flash Lite Exchange

Prerequisite knowledge:

This article targets developers with general Flash and Flash animation knowledge. For an introduction to Flash Lite, check out "Best Practices for Developing Macromedia Flash Lite 1.1 Content" or "Introducing Macromedia Flash Lite 1.1."

 

From Tweening to Hand-tuning—Technique Matters

Flash was originally created as a 2D (character) animation tool, at a time when computers were really slow compared to today's standards—14.4K was the standard connection speed. Not surprisingly, this particular content category is also well-suited for mobile phones, which today, in many ways, resemble desktop computers from only 10 years ago in terms of bandwidth and memory limitations.

Slick motion graphics in Flash often require high frame rates to look smooth. You can see people using 30, 60, or even 100 frames per second (fps) to achieve the appearance of smooth motion with tweens. Try that on a mobile phone, and chances are you will only see something stuttering across the screen, which is anything but a pleasant experience.

Hand-tune It

The secret to successful animation with Flash Lite is what I call hand-tuning, the process of manually adjusting your animation keyframe by keyframe. A lot of motion in real life doesn't happen in even increments, nor does it follow an easing curve. Even if it does, we often don't perceive it that way. You need to trick the human eye, so the animation appears where the eye expects it to be, not where it should be placed according to some mathematically correct calculations. Believe it or not, we often don't see what's really there. Filmmakers, and in particular cartoon artists, have exploited this phenomenon for over a century. When an object doesn't move fast enough to fool your sensory systems into believing that you are seeing a continuous motion, you need to exploit the phenomenon commonly known as persistence of vision and present your eyes with what they expect to be there.

In the case of motion graphics, this translates into the following: Start with tweens as you usually would, then hand-tune your animation, frame by frame, to get the result you want the user to experience. This is a lot of work, but it's well worth it.

Likewise, you will have to adjust your thinking when creating animated transitions for mobile devices. For example, a cool transition that shows a transparent object speed onto the screen will work just fine on a desktop monitor, but on a mobile phone it will run in slow motion and ruin the effect of a smooth transition. In this case, you have to focus on what is the most important part of the effect that you really see. Most likely, you will not even notice something transparent is moving. You just assume it is transparent, because it is transparent at the end. However, while the object is moving, all you really see is a shape and a color.

The first step to making this transition effect smoother is to use a less intense effect during the motion—for example, tint the object or reduce its brightness, and only set its transparency one frame after the transition has completed. The object may still be graphically too complex for a smooth animation. So you may be able to use only a flat shape with a color for the actual transition. What you are starting to create here is called a blur in cartoon jargon (see Figure 1). Instead of moving something at 50 fps, you create what your eyes perceive during the motion. Don’t combine transitions with changes in transparency or other graphical effects; this will slow down your animation. Check out Chris Georgenes' article "Creating Lifeline Motion Blur Effects" for more information on some of the techniques you can use.

Figure 1: Head snaps off the body, everything is squished on its way down, then all parts snap into place.

Unless you have done this before, you may not believe me. You may think that users will notice that the object moving across the screen is not the real object. Get over it, they won't (if you do it right)!

You need to realize that you're creating motion here, not a series of static images.

Exaggerate

Another very useful technique that you can borrow from cartoon animation is called exaggeration. This technique enables you to create animations that feel more "natural." Exaggeration can be part of a blur, or ease the transition from a blur to the real object. For example, try this exercise: Ask someone to point quickly with his or her hand at an object on the other side of the room. Pay very close attention to where you think the person's hand is pointing. Repeat this a few times and you'll notice two things: While the arm is moving, you don't see the arm moving at a certain speed—it becomes a blur. When the arm is stretched out, the hand, for a brief moment, will appear as if it is a bit closer to the object than it actually is, and then it snaps back to its real position.

In the example of a moving object in your Flash animation above, you may want to move the object just a bit further than it should move. Then, in the next frame, put it in the proper position—think of its motion as resembling a rubber band that snaps back. Or when you create a zoom-in effect, make the object just a tad bigger at the end of the transition, and then set it to the intended size one frame later (see Figure 2).

Figure 2: See how the feet turn larger than life then snap back.

You can take this one step further by adding a flash effect: Insert a frame where the object's shape is completely white. Or even add just a white rectangle on top of it for one frame. This "blink" really draws the eye's attention, yet you'll only see what's there now, not how it got there. In other words, it helps to complete the transition.

Don't get discouraged when you try this for the first time, and it doesn't come out right—it takes a little practice. Don't forget to test your effect on the target device.

In the end, when you've done everything right, what you'll get is smooth-looking animations at 10 to 15 fps on a mobile phone. You may even use these techniques on your desktop projects.

Creating Experiences for the Small Screen

Before you get started, you have to realize how small the screen you're targeting really is, not just in terms of resolution, but also in terms of physical size. Take a business card, and cut it in half—that's about the size you are designing for.

In technical terms, the display on a Symbian Series 60 phone is 176 x 208 pixels, which is only slightly bigger than the screen size of other Flash Lite–enabled phones. Of course, if your application is not running in full-screen mode, you have even less room to work with.

Note also that mobile phones use a vertical aspect ratio. Desktop content is often created with a TV-like 4:3 or a cinematic 16:9 aspect ratio. On a small device screen, you don't want to waste a pixel, so you really have to think through the design of your animation to make the most of the limited space.

Don't let the resolution of the device fool you; it is actually pretty decent. However, each pixel is smaller than on your desktop monitor, because the dots-per-inch (DPI) ratio is higher. You can easily verify that by holding the phone next to a Flash movie of the same size on your desktop monitor. Depending on your monitor, the phone display will have only some 70% of the screen real estate.

Be Bold and Simple

The problems you face are further complicated by varying lighting conditions. Mobile phones are used everywhere—indoors, outdoors, at night, and in bright sunlight. For mobile Flash content in general and animation in particular, this means you have to be bold—don't focus on small details. Users most likely will not even notice subtle smooth color transitions, unless they just can't tell anymore what they are looking at. Pump up the contrast. Even if that bothers your color-sensitive eyes, your users will thank you for it.

For animations, focus on close-ups, while avoiding panoramic views and pans (see Figure 3). A lot of detail will be lost on the small screen, and as great as your animation may look on your desktop computer, if it can't be seen on the mobile phone the user will not appreciate it.

Figure 3: Close-ups immerse you in the content.

The same principle holds true for the artwork itself—the simpler the better. Stylized cartoonish characters will come across much better than realistic looking ones; the details will be lost in translation. The more you'll try to squeeze onto the small screen, the more you'll lose. Instead, focus on what is really important and leave out space fillers.

Test and Test Often

Before I continue, a word on testing. Nothing can replace frequent testing on actual devices. Ideally test your animation on different devices, because devices differ in performance, color depth, and sound. You won't encounter memory problems on your desktop, or even get a glimpse of actual device performance using the emulators that you can use in Flash. Be warned that testing can be quite painful, because you can't see how much memory is actually being used. Unfortunately, this means a lot of trial and error. You should never assume that your content will work on a device until you actually have tested it on the target device. Developing for a device means at times rather tedious work. However, if you think about what you can actually put on these tiny devices today, you know there is a reward for your effort.

So take testing your animation (or application) on your target devices seriously. Don't wait until the very end only to be in for a big surprise.

Repurposing Existing Content

You can always start from scratch, and the tips and tricks in this article should help you to get off to a good start. However, one of the strengths of Flash is that you can reuse content across platforms—you just can't use everything anywhere.

For the "2001" animation, we began by asking ourselves, "Can we get our original animation to work on a mobile phone?" From the beginning, we considered the length of the animation a challenge. However, the original animation itself met several key criteria that are important for an animation created for desktop systems to work on mobile devices, including:

• Character animation that changes only a small region of the screen
• A majority of medium shots and close-ups, and only few panoramic scenes
• Limited full-screen motion
• Full-screen pans that can be removed without affecting the content
• A simple background
• Repurposing of symbols, which facilitates optimizing the animation

Our project proves that it is possible to port a two-minute animation to a mobile phone. It still has a significant file size of just under 300K. Thus it may not be suitable for distribution over a 2 or 2.5G network, but that was not our target in this case.

When deciding on whether to repurpose content, you need to consider whether the content will play on a phone and whether it will fit within any file size constraints, among other specifications that you may need to meet.

You will get a head start when you're able to repurpose well-suited content. Even then, most likely you will still have some work ahead of you to make it run on a mobile phone.

While our original "2001" animation was deemed well-suited for mobile devices, it was far from perfect. It was created as a streaming animation for the desktop. While file size mattered at the time of creation, the most important measure was to keep the file size small enough that people with dial-up connections could access it without problems. That required much less optimization than the memory constraints you'll face on Flash Lite–enabled phones.

We actually didn't face too many performance issues; we just had to do some tweaking, such as removing a full-screen pan of the vending machine and replace it with a static cut. In that sense, the original animation was really well-suited for repurposing.

Our two biggest issues were sound and memory.

Performance Issues and How to Resolve Them

It's no secret that devices are slower than desktop computers. In the case of Flash content, this means optimize, optimize, optimize. For example:

• Start your project with a frame rate of 10 to 15 fps.

  Apart from making it easier for the Flash Lite player to keep up, a lower frame rate will also lead to a smaller file size. Remember, each keyframe of a symbol adds 12 bytes to a SWF movie. This may not sound like much, but it sure can add up, especially in the case of animations.

• Place your artwork in symbols rather than on the main Timeline or in groups.

  Optimize the symbols by selecting Modify > Shape > Optimize or by hand with the subselection tool. Remove unnecessary points, and any hidden shapes and symbols. This can be tedious work, but it'll make your content look and perform better and it will reduce the SWF file size.

• Simplify your animations.

  Don't have too many things going on at the same time. Avoid performance killers such as alpha transparencies and gradients. They create a better-looking animation, but they also affect performance. Besides, on a small phone display, much of the effect is lost anyway; it may even look worse. Simpler graphics will often look better and perform better on the small screen.

• Avoid pans and alpha fades.

  Short (five-frame) fades over a static background may work just fine. If possible, work only with shapes and remove lines, including outlines around shapes. Lines are more complex to render for Flash, and thus slower. Create outlines using shapes instead if needed.

All of the above also applies to desktop animations; however, when creating animations for mobile devices, you will run quickly into problems when you ignore these best practices.

Sound and How It Affects Playback

Audio is a very important element of an animation like "2001." We could have saved ourselves a lot of time by just removing the audio from the file, but it would not have been the same experience.

Our first major challenge was to get the animation to work on the phone—with sound. We were able to get it to work without sound relatively quickly, but when we published it with sound, we would get an out-of-memory error as soon as we started to play the animation.

Length Matters

To resolve this issue, we began by slicing up the animation and putting each scene or cut into a movie clip that we would then place on the main Timeline. Then we added the audio one cut at a time into the matching movie clip, not the main Timeline, and tested the result on the phone—it worked!

However, that didn't resolve all of our problems. Sometimes, one audio piece would cover several cuts, like the music at the beginning, and there was no easy way to have it exactly timed to match each Timeline. So we just put the entire longer section into the first cut, and extended the Timeline with blank frames. Unfortunately, as soon as we published this to the device, the phone would run out of memory halfway through the animation.

We concluded that running audio in two clips simultaneously causes a problem. We removed the sound from the clip where it would overlay the first longer sound, and tried that—and it played just fine. Of course, now we were missing a piece, and we stuck it in the first clip—and, surprise, it played! We still don't know the exact cause for this; all we know is that playing sounds in two clips at the same time is a bad idea.

We also never understood why we could not put the entire soundtrack on the main Timeline. Our best guess is that the Flash Lite player caches the sound for an entire Timeline all at once, and handling all the sound at once was just too much. However, it seems to handle memory for each movie clip separately, which is why this segmenting technique succeeded.

Even with this technique, we would still run out of memory at some point of adding sound to the animation. We solved this by optimizing the animation scene by scene. Sound and animation do share memory resources, so it only makes sense that a cleaner animation allows for more sound. For more information on optimizing sound, see, "The KILL THE SILENCE® Technique: Optimizing Digital Audio in Flash Lite," by Frank Gelat.

And Then There Is Volume

After we resolved these issues, we could look into some other issues related to sound. The first one was that the soundtrack played awfully loud on the phone, and we had to really lower it. You will have to experiment with that, but we found that we had to set the audio to about 50% volume of what sounded fine on the desktop.

The very beginning of the soundtrack was pretty much bass only. On the phone all you could hear was something crackling and we just had to remove that part. We concluded that the small speaker of the phone was just not capable of playing sounds of that frequency.

However, this also has its benefit—you can reduce the audio quality pretty drastically, and you still don't hear a difference on the phone.

Sound playback shares processor resources with the display. As a result, you may notice a delay in the animation when a sound starts—at that point Flash is starting up the sound device, causes a delay in the display.

We had a particular problem in the scene where the robot is kicking the vending machine. It would just freeze for a second making him stick to the machine, and then the kick sound started playing. We solved this problem by playing a silent sound from the beginning of that scene. That triggers Flash to start the sound device before the scene, when the user doesn't notice the delay as opposed to in the middle of the action.

Note: On the desktop, we sometimes use a two-frame looping clip with a silent streaming sound to keep the sound device active, and to avoid such delays. Unfortunately, this doesn't work with Flash Lite. Firstly, it will slow down the playback. Secondly, it triggers the out-of-memory alert when running sound in two clips.

The sharing of processor cycles with the animation has another side effect: Heavy animation or a scene cut may cause hiccups for the sound, noticeable as small cracking sounds. To work around this issue, try to avoid the particular situation or make the transition easier on the CPU.

On the Nokia 6600 phones we have also noticed a cracking sound after a sound has finished playing, even with nothing else going on. We're still looking for a solution to this problem. It seems to be an issue with the device, maybe it's just our phone. Note: Not all devices can play all sounds! Flash Lite can embed sounds in different formats (MP3, ADPCM, MIDI, or raw) for better cross-platform distribution. It can even embed alternate sounds in the same file, and then choose the appropriate one. For more details see Nader Nejat's article, "Using Sound in Flash Lite 1.1."

Bitmap Images Versus Vector Graphics

Bitmap images improve performance, because they are rendered already. The caveat is that they will often result in larger file sizes. For complex backgrounds, there's no way around using bitmap images, because animation on top of a complex vector background would be very slow. However, on a small device screen, a lot of that detail will be lost anyway.

Vector backgrounds, on the other hand, can scale without loss in quality. This can be very beneficial to your file size, or when creating Flash Lite content for more than one screen size. For bitmaps to look their best, they need to be displayed at 100%, no scaling applied.

For our "2001" animation, we optimized the original vector backgrounds (see Figure 4).

Figure 4: A simple vector background helps animation performance.

They were simple enough, and are used at different sizes. However, on the splash screen, we're using a 2K PNG file (see Figure 5). There was just no way to create the polka dots small enough in Flash. And with the PNG file there's no quality loss—a JPEG would have either been the size of the vector art, or shown too many artifacts to be useful.

Figure 5: Bitmaps help performance and can be smaller in size.

Bitmap images versus vector graphics is not an either-or question—each has its place, so choose wisely.

Memory, Memory, Memory

The biggest enemy when creating Flash Lite content is not performance, but running out of memory. I touched on this already in various places throughout this article, and it really is most likely the issue on which you'll spend most of your debugging time. First, you need to realize that file size is not equal to memory used. File size is an important indicator, but it is simply not the same as how much memory your movie needs to run. For example, JPEG images are compressed inside the SWF file, but they need to be restored to their full size for display. The same is true for sound files—an MP3 or ADPCM compressed sound file is a lot smaller than a raw sound file, but when played, it has to be turned back into raw sound. Other objects, such as movie clips or code, need more memory at runtime by themselves than they would if they were stored in the SWF movie.

Additionally, you're able to create more objects when the movie is running, for example, by duplicating movie clips. Each new object uses additional runtime memory without adding to the file size.

That doesn't mean file size is not important; you may still have to meet file size limit specifications, and bandwidth when the file is received over the air is still very limited, similar to the bandwidth of a 14.4K modem—unless you are fortunate enough to develop for 3G networks only. You also need to keep in mind that most phones have rather limited storage capacities.

"2001" in Memory Space

Our first attempt to put the "2001" animation on the phone worked just fine regarding the file size. We put it on the phone, and opened it. However, as soon as we pressed Play it ran out of memory. The Flash Lite player simply needed more memory to play back the animation than to load it.

As discussed earlier in the section on sound, this had a lot to do with the soundtrack, and we found a way to help the Flash Lite player manage its memory better by splitting up the animation into shorter segments, each placed in separate movie clips.

In a linear animation like this one, without duplicating clips or any code apart from a few gotoAndPlay actions, the runtime memory is determined strictly by how much memory the objects that are currently on the Stage use, how much sound uses, and how Flash handles the objects that are not used right at this moment.

Unfortunately, we don't have access to tools that enable us to see how memory is handled. However, I can make some educated guesses: For sound, as described above, Flash loads and decompresses all the sound for a specific movie clip and keeps it in memory, ready to play whenever you go to any frame. Flash does this for every nested clip separately. That is why splitting the soundtrack over multiple movie clips made such a difference.

Something very similar is the case for all shapes, outlines, and graphic symbols placed in a movie clip (and the main Timeline of the FLA file is also a movie clip for that matter): It loads everything into its runtime memory, as soon as that movie clip is in a keyframe. The more such objects Flash needs to keep track of, the more memory it uses. Again, this does not relate directly to file size; it is about the number of objects, along with their complexity.

This explains why an animation may run fine on its own, but when adding more and more audio, it will eventually run out of memory. However, after we optimized the animation—by putting 10 symbols that make up a hand in a movie clip and move them together—it all worked fine again. The player has fewer objects to keep track of, and, even though the file size went down just a little bit, it requires less runtime memory.

This may sound like voodoo to you, but until we have better tools that show exactly how much memory is used and by what, this is all we have to work with.

Tips to Remember

Now on to a few more practical tips for optimizing animation for both runtime memory and file size:

• Put your graphics in symbols, and optimize them, either by selecting Modify > Shape > Optimize or using the subselection tool. Remove all unnecessary points.
• Use graphic symbols for flat shapes and lines, and use movie clips when nesting symbols.
  
  • Graphic symbols render faster since they are not "active objects" at runtime. Nested graphic symbols (static and animated) are broken down when exported; each nested symbol is exported with its own 12 placement bytes for each keyframe of the parent.
  • Movie clips on the other hand are exported only once, complete with all their child content. Again, 12 bytes may sound like nothing. However, if you have 12 nested symbols, you are adding about 150 frames for each keyframe where you use a nested graphic symbol.
    
    By comparison, a movie clip uses only 12 bytes per keyframe after the 150 bytes it uses when it is used for the first time. Again, this doesn't sound like much of anything, but if this is used over 10 frames (for example, a tween), you are already saving 1.2 KB in file size. This reduction in file size also corresponds to fewer objects that Flash needs to handle. Yet, you still see the exact same objects as the SWF plays. This is because the movie clip (instead of each nested graphic for each keyframe) is tracked, and the movie clip keeps track of its own contents. If that doesn't change, nothing else needs to be memorized.

Remember that graphic symbols and movie clips function very differently when exported. When I first discovered this, my initial reaction was to use only movie clips. However, a movie clip carries a runtime overhead, because it is an active object. If you use movie clips for simple graphics (nothing nested, just shapes, outlines, and text), you don't gain anything; you only end up using more runtime memory.

Keep in mind that motion tweens are exported as individual keyframes; you don't save anything compared to using a keyframe each frame.

Summary

In this article, you have learned a number of tricks that ensure that your Flash animations run and look good on mobile phones. I have shared with you some tips on how to work around the size and performance limitations of mobile devices, including the sound and memory pitfalls to avoid. I have introduced you also to the nitty-gritty details on how to optimize your animation for memory usage, file size, and performance. You should now be well-equipped to get started with your own project.

At this point you may wonder, "Is it really worth all the trouble?" The answer is a resounding "Yes." If you're not trying to squeeze a two-minute-long animation onto a phone, you'll probably not even face half the troubles that we went through. For us, it was a challenge we couldn't refuse, and we succeeded. And I hope that what we learned will save you some headaches and trouble as well.

If you haven't tried to put your first animation on a mobile phone—what are you waiting for? Get a compatible phone, get the Flash Lite player, and get started already! Download the "2001" animation from the Flash Lite exchange and view it on a phone for your inspiration.

And by the time you see your own content on a phone, you'll be a Flash Lite convert, for sure.

About the author