Preparing animation

It is impossible to imagine a modern game without animation. The game world should be alive to compel attention. There are two major types of animation: based on programming code and frame based stored in animation sprites. The first type requires some programming algorithm to move or transform a graphic object; in most cases, this is a linear process. An object is moved from location A to location B with predetermined speed, its size is increased, and its alpha channel is changed. Such type of the animation with automatic incrimination is called motion tween in Adobe Flash. At a more complex level, the object has curved trajectories and moves with some acceleration and there is inertia in its movement; the games in which such interpretation is used require advanced control on an element's dynamics; first of all, I'm talking about various physics puzzles.

Frame-based animation on the other hand is a way to beautify the motion. Besides the automatic animation successfully moving a sprite around the screen, the illustration inside the sprite would be still; for example, a character would not step. Several images to illustrate the walking cycle are needed so that the game can form animation sprites. This is a bunch of images, portraying various phases of motion. Modern SDKs usually have rich collections of methods to work with the animation sprites. They can be played in the order in which they are stored in the animation sheet, or they can be organized by using an array with a custom order, which is very useful because more complicated animation sequences can be created with a minimum number of images.

Here are some tricks: if there is a portion of opposing movements (for example, a character is showing up from a hatch and then hides back), the animation sheet can include only half the frames, displaying the motion in one direction; the other part would be constructed from the same frames but played backward. A pause in an animation of given duration can be organized by simple repetition of one of the sprites. Another interesting option of non-linear frames are extra frames, which helps to deal with sameness of animation cycles. Each gesture and movement an object makes in the real world is pretty unique. Take for example a passerby walking in the street, his legs make steps in cycles; the cycles are pretty similar, but not quite the same. There is a beautiful metaphor:

"Sometimes a butterfly lands on the shoulder, so step at this moment is a little bit different."

So, it is good to add the unexpected touch to the animation frame sometimes. It can be done by replacing an ordinary frame with one differing frame that has some small unique detail. There can be several extra frames; the game would choose them randomly.

It is good to animate characters in Adobe Flash and then to export the result as separate still images, finally collecting them into one Adobe Illustrator document and exporting it as an animation sheet. It is worth mentioning about a very interesting tool for creating smooth and natural character animation called Spine (http://esotericsoftware.com/). Its general advantage is that it is a 2D skeletal system with various fragments of a character (head, body, legs, feet, and so on) attached. Positions of bones and their angles are calculated in real time and interpolations are very smooth and correlated with the frame rate; therefore, the motion is very smooth. Moreover, because animation is not tied to strictly defined frames, the system is very flexible; this means that some combination of motions can be easily introduced without redrawing a full sequence of frames. For example, by default in traditional frame-by-frame animation, a character running and the same character running and shooting are two separate sequences, which increases consumption of memory resources and makes animation exporting a bit complex. A skeletal animation has no such complications; various gestures of the character can be combined more easily with minimum memory costs. Of course, this is possible only if a game did not use a raster output of Spine in the form of video files or sprites, but used binary data of virtual bone positions and keyframes stored in special documents instead.

Different special effects are based on animation too. For example, smoke can be created by using a translucent and blurry circle being duplicated around the screen; the opacity of each circle should be reduced softly, but their sizes should be increased.