[In this reprinted #altdevblogaday-opinion piece, 5th Cell's Tim Borelli explains how he learned everything he needed to know about animation from Looney Tunes, specifically from Acme's best customer Wile E. Coyote.]
Everything I ever needed to know about animation, I learned from watching Looney Tunes.
Sure, I went to school. I learned HOW to animate there and from other sources, but none of that taught me what I needed to know about animation as much as watching Bugs outsmart Elmer, Daffy play the second banana, Foghorn Leghorn fumble about, or Wile E. Coyote fall to yet another demise.
Gravity Doesn't Exist Until You Look Down
Bugs is the popular one. Daffy is the memorable one (Stuuuuuuupor Duck!). Foghorn, well, I say, I say, he was fun to watch with his contraptions. However, Wile E. Coyote is the one that sticks out the most to me.
Not only is it entertaining to watch poor Wile E. try and try again to catch the Roadrunner (with a seemingly unlimited credit line with the Acme corporation), it is also a very good study of how developing a formula can allow an animator to work efficiently while keeping a high quality bar.
Take the timing of Wile E.'s fall, for instance. Did you know that every time he falls, it happens in the same exact number of frames? He tends to walk/fly/float/propel himself over a ledge, and doesn't fall until he looks down (for Wile, gravity doesn't exist until he does this). He then falls over N frames until you see a puff of smoke and hear a distant "splat."
This comedic timing (combined with a happy accident regarding the audio level of his "splat") allowed the Looney Tunes animators to build up to this punchline without worrying if the punchline itself would feel right. It also ensured that re-takes weren't going to be needed -- once that formula was set, it was followed.
Set Your Pace
For game animation, I take the same approach, especially for transition animations. In fact, on our current project, we try to animate all transitions to occur on 6, 12, 18 or 24 frames. Each of these frame counts corresponds with the desired perceived pacing of the character's thought process. For example:
"Ready now!" - 6 frames
"Get moving and STOP!" - 12 frames
"I gotta be ready before
I get there" - 18 frames
"OK, I'm gonna pick my spot and get ready when I'm there." - 24 frames
These frame numbers allowed us to build a visual language with these transitions. For example, the faster ones are more immediate and needed for faster gameplay responsiveness (say, for aiming and shooting). Having them all on a 6-frame count holds the player's expectation that if "I've gotta shoot, I'll get there in .2 seconds." It also allows us to later add interruptible follow-through for an extra 6 or 12 frames without that extra motion feeling out of place.
In contrast, the 18/24 frame transitions typically denote the end of longer, deliberate movement- the player knows they are moving at a certain speed and when they have reached their destination, the transition will carry that speed to a stop. These extra frames allow us to sell the character's weight at that stop, which in turn creates a mental acceptance by the player that it took longer than the 6/12 frame motions.
Sweet, sweet consistency
The next benefit to the frame counts is that they are easily scalable from one to the other. Personally, I set poses every 3-6 frames. This lets me easily slide the keys around if I need to make timing adjustments after the animations are implemented. These adjustments can also be easily scriptable (for fast tests), so I can adjust the timing of 160 animations very quickly to see if the new length feels right before going ahead and hand-tweaking them.
Since I've spaced out my keys in a uniform way, I can re-time the motions much more efficiently.
Lastly, these frame formulas give us efficient consistency. Since a uniform length exists, once we nail down the first key animation, we can modify it to create other motions in the same pool. For example, If we need to transition from a non-shooting pose to a shooting pose, we'll work on a key motion that gets across the character's intent and the player's feel. Once design deems the look and feel to be good for gameplay, we can create every other transition in that pool much quicker.
Much like the audio level on the splat of Wile E. Coyotes's fall (see the book Chuck Redux), coming up with the multiples of 6 formula was actually a happy accident -- the Source Engine's default engine blend value is .2 seconds (6 frames!). In order to not disrupt existing gameplay, we started animating to that frame number. After implementing many transitions, it was apparent that not all of them could or should work on 6 frames. The easiest thing to do was scale the motion by 200 percent and work back from there. Lo and behold, 200% worked great, so we redid all of those motions with twice the frame count.
Since that pacing looked good, we extrapolated that 18 and 24 frames would be logical to try next. It worked, and now we have a (undocumented till now) visual language for our transitions. We've since extended this philosophy to our movement system, and the animators who work on that pump out high quality motions like nobody's business.
It's Still Creative!
Purist animators out there might be shocked that we take shortcuts in order to produce efficient, high-quality animation at a fast pace. The fact of the matter is Warner Brothers, and even Disney, did the same thing! Read Chuck Redux, or watch this video
The key is to not get so married to those formulas that we are unwilling to change them when they no longer work, or get stale. If that happens, we play with new formulas and do more timing tests until we get it right. In the end, the better we can nail down the punchline, the more time we can spend on the fun part of getting there.
I'd love to hear from other animators and designers what their processes for this are, as well! So speak up, tell your friends to read this and rip me to shreds, tell me how awesome I am or somewhere in between. I'm always looking for different techniques and opinions!
[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]