23 May 2011
Experience developing games or creating animations with Adobe Flash will be helpful in making the most of this article.
Animated models are the moving objects within a game that represent your characters, vehicles, monsters, and any other interactive objects not explicitly drawn in the background. They are the objects that not only move around the screen but also animate as they move. For example, a walking game character that not only moves horizontally but also moves his arms and legs as part of the animation is an animated model. Animated models bring your game to life. They are also, with a few exceptions, the most performance-demanding element of your game application.
Flash Professional supports two types of graphics that can be used to render your animated models: vector and bitmap. Vector graphics will result in smaller files and can be scaled to any size without visible distortion, but they demand significant processing power. Unless your game uses very simple vectors or contains very few of them on the display at any given time, chances are that animated game models built using vectors will deliver less than desirable results on mobile devices. Bitmaps will result in larger files and require more memory. They also cannot be scaled as nicely as vectors, but they can be quickly drawn to a display canvas by the central processor or moved around the display list by a mobile device's graphics processor. Through proper use of bitmap driven animation, you can dramatically enhance the performance of animated models so that your game runs smoothly whether you're using a high-end PC browser, mobile device, or netbook.
This article covers three methods for rendering your game's animations using bitmaps: stage blitting, partial blitting, and bitmap armature models. It introduces the basic concepts of each method, the pros and cons of using each method, and suggestions for when to use each method so that you can determine which technique is most appropriate for your game.
Blitting is the process of copying pixel data from one bitmap, the source bitmap, to another, the destination bitmap. With stage blitting, the destination bitmap is your display canvas, a single, blank bitmap representing the entire visual area the game user sees (your display stage). The source bitmap is a sprite sheet (also called a tile sheet), an image divided into evenly sized cells each representing a single frame of an animation sequence. If you think of your sprite sheet as a painter's palette, then blitting is like your computer processor dipping its painter's brush onto your animation frame and blotting an exact copy of that frame onto the canvas.
While a description of the code used to implement stage blitting is beyond the context of this article, the basic steps are as follows:
Because the source bitmap data puts the entire animation sequence readily available in memory, blitting provides outstanding performance when animating a large number of game models on screen at once compared to using the traditional Flash display list. It is also very memory efficient if you're animating multiple copies of the same model since each model is only stored in RAM once. The computer can quickly dip from this "palette" to draw new models on screen without the overhead of instantiating new objects or reserving excess memory on the interactive properties of sprites and movieclips.
Another benefit of blitting is that you can control the animation refresh rate independent of your application's frame rate because blitting does not involve a timeline. This enables you to skip redrawing the canvas if the device's frame rate drops below a desired level so that it can remain synchronous with game events or other users in a multiplayer game.
The greatest downside of stage blitting is that it is much more difficult to program, especially if you're used to using the Flash display list. Remember, with stage blitting there are no display objects beyond the canvas bitmap for Flash Player to manipulate. If you need your models to be clickable or if you need to rotate, scale, or layer them in any way, you'll need to write custom code to add this functionality or leverage a third-party framework with bitmap animation capabilities such as Ginger, Flixel, or Push Button.
Another factor to consider with blitting is how many different types of models you need on the display at one time. Each model you want to blit must be stored in RAM as bitmap data, which can quickly consume available memory if a large number of different model types must be animated at the same time. Consider that a 100x100 pixel image stored as bitmap data in Flash Player uses approximately 40KB of RAM and an animation game model that comprises 400 frames would take up approximately 16MB. With 20 models, the application would require 320MBs of RAM just to store the bitmap data necessary for your animations, let alone the RAM you'll need to operate the rest of the game. Granted, in extreme cases such as this, you'd have to break up your sprite sheets into smaller animations so that only the sequences you need readily available are stored in RAM, but that would entail additional overhead to create and destroy bitmap data instances.
Depending on how you create your sprite sheets, your game's initial load time performance or file size will suffer. If you prerender your animations as sprite sheet images, your file size increases. If you cache your animations at runtime, your game load time increases. If you have numerous animations, storing prerendered sprite sheets will vastly increase the file size of your application. For example, I developed a game that has 21 character models with approximately 400 frames of animation each. Storing the models as sprite sheets as opposed to movieclip vectors increased the file size from 2MB to 40MB. Conversely, caching the same animations at runtime might take 15-20 seconds on a mobile device per model, or 5+ minutes overall to initially load the game.
Note: Typically, it is necessary to store additional bitmap data for each direction you want your animated model to face, so be sure to multiply your total frames by this number of directions when factoring these balance costs.
Stage blitting is best suited to games that require frequent redrawing of the entire screen area because either the game background is changing (such as 2D side-scrollers) or because there are numerous objects constantly moving all over the screen (such as an Asteroids style arcade game). It is particularly useful when the game artwork is pixel art with simple and short animation sequences (such as Nintendo-style Mario or Bomber Man) since these types of graphics generally require significantly fewer frames to maintain a fluid animation look, and therefore need to cache fewer frames as bitmaps.
Partial blitting is a rendering method that blends the benefits of using the Flash display list with the performance advantages of blitting. The difference between partial blitting and stage blitting is that instead of copying pixels to a single stage canvas bitmap, you copy them to an individual model's bitmap canvas. With this method, game model bitmap canvases are added to the Flash display list and can be moved around (using their x and y properties), rotated, and scaled as you'd typically create animations in Flash Professional. The models' animation states, such as walking and attacking, however, are blitted using the method described above.
The obvious advantage of partial blitting is its ability to deliver high performance model animations and still manipulate models on the traditional Flash display list. If you enable smoothing on the models' bitmap canvases, you can rotate the model without the visible distortion typically associated with manipulating bitmaps. As a result, you don't need to store bitmaps facing a variety of directions for each model as you do with stage blitting. Below a certain threshold, partial blitting is also less taxing on the system than stage blitting since only the objects that are moving or changing need to be redrawn, not the entire stage.
Note: It is possible to program redraw regions for stage blitting to maximize performance, though the coding is more complex than with partial blitting since Flash Player automatically handles redraw regions for you.
Like stage blitting, partial blitting will increase file size, memory usage, or CPU overhead depending on the number of sprite sheets used and the methods used to store them. Partial blitting will also consume more memory than full stage blitting since each model requires a separate bitmap container. Finally, overall performance with partial blitting will be worse than with stage blitting when you've added enough simultaneous models on screen to warrant a full screen redraw on every frame.
Partial blitting is great alternative to stage blitting when you don't need to constantly redraw the entire display or when it's advantageous to rotate your game models instead of storing prerotated states.
An armature is a skeletal framework of a figure composed of body parts that, when repositioned overtime, can be used to animate a game character. Instead of drawing a unique illustration for each frame of the model's animation, armature models are drawn as a series of body parts that move in relationship to each other just like the bones in your skeleton. Animations are achieved by positioning the arms, legs, head, and body, for example, on one frame of a timeline, repositioning them in a different pose on a later frame, and using motion tweens to have the limbs move from the starting pose to the ending pose.
Armature models will typically perform well on desktop computers whether their parts consist of vector or bitmap graphics. For mobile devices, it is definitely best to use bitmap parts because there are fewer calculations involved with moving and intersecting bitmaps.
Armature models offer two distinct advantages over blitting: smaller files and customization. They don't result in large files because the only images you need to store in the file are the model's body parts; all of the various animation frames are derived through the movement of these parts. If all of the model's animations are on a single timeline without gaps between frames, Flash Player will reuse the images for each animation instead of recreating them, meaning less instantiation overhead and less memory garbage collection to worry about. This enables you to have longer, smoother animations without having to store additional sprite sheets in your document and load extra bitmap data into memory. You can also add new animations to the model (such as alternate attack or movement animations) with virtually no increase in file size or memory use. Creating new animations is also easy to do since you don't need to illustrate new frames; you just reposition the parts in a new pose and tween the difference to animate.
Customizing models with different markings, armor, or weapons is straightforward due to the component structure of the model. For example, if you want to designate a shoulder pad on your model's armor with a unique color, you can tint the individual piece directly. This is particularly useful for strategy games in which you must indicate to which team each model belongs.
Note: Blitted images can also be modified to show team color markings, although the process is much more difficult because you are limited to using filters to selectively replace one designated color with another.
While they enable smaller files and are often easier to work with, armature models will not perform as well as blitted models as you add more and more models to the display list. This performance difference is due primarily to the numerous individual parts that compose the armatures. Blitted models need only a single bitmap object on the stage (or they are part of the stage canvas bitmap itself) and so use far less resources for the actual graphics rendering. Note that this performance decrease will be apparent even if most of the armature models on stage are not moving. It is the number of total bitmaps on the display list that matters, not just the number of moving bitmaps. For this reason, it is a good practice to draw the idle pose of the model (the inactive, non-moving position), as a separate bitmap image and put this on stage in place of the armature model when you don't need to animate it.
The complexity of the armature—that is the number of moving parts—also decreases performance, while complex blitted frames do not (since they have no part structure and no overlapping issues), so be sure to delete or hide unused body parts in your armature's animations.
Armature models are typically a good solution for games with a large array of different model types on screen at once that don't have to animate at the same time, such as turn based tactical strategy games or role-playing games. They are particularly helpful when you need to customize the models with unique team markings or alternative weapons and armor since their components can be modified individually.
It can be tempting to believe that a single, best practice method exists for delivering optimal animation performance regardless of the type of game you're building. As you've seen however, each method for rendering your game's animations has its own strengths and weaknesses, which make it more or less suitable to the kind of game you are developing.
Now that you understand some of the different techniques available to you, it's time to think about the type of game you are building and figure out which method is most appropriate for the results you are trying to achieve. Is the application being developed for a phone for which download time (and thus file size) is important, or are you making an iPad application where faster performance is more important than the size of the download? Does your game involve simple pixel graphics so that stage blitting would maximize game speed, or do you plan to use a large array of models with numerous animations, for which an armature solution might be best?
Below are some excellent tutorials that will help you learn how to program the methods described in this article: