Creating Character Animation Assets

Editor's note: This paper was originally published in the 1999 Game Developer's Conference proceedings.

As soon as any of the film-based computer graphics production houses develop a new technique, game developers want to try and include a less expensive version of it in their next game. And while the ability to deliver beautiful, detailed, cutting-edge imagery to the gaming public is wonderful and exciting, it's also a bit intimidating. How can you efficiently meet the public's rising expectations? How can you engage their ever-more-discerning eye and still deliver on time and on budget?

This article will focus on the techniques I use to create motion assets efficiently. These techniques are based on experience I have gained doing computer animation over the past 10 years, and more specifically while developing Major League Baseball Featuring Ken Griffey Jr. (KGB) for the N64, and an LBE attraction called Virtual Jungle Cruise for DisneyQuest in Orlando. I hope that the issues covered here help you to avoid some of the pitfalls and frustrations of creating video game animation, and allow you animators and animation programmers out there to bring the quality of video game animation up to the next level.

Three Steps to Generating Game-ready Motion Assets: Design, Create, and Implement

These three time proven steps should be considered in some form or another every time you generate motion assets. Adapt them to your needs and working style and you'll be on the path to success.

Step 1: Design

This step consists of the following four sections: Motion Archetyping, Camera Positioning, Character Design and Flow Charting

Motion Archetyping: What makes a character your character? The great Warner Brother's animation director, Chuck Jones, identified five essential questions, which help define a character. All right, so we're making games and not animated shorts, but surprisingly, these questions will still help you to define your characters:

1. How does your character stand? What sort of posture best defines your character's outlook on the world?

2. How does your character carry its weight? When your character initiates an action, which body part moves first and which moves last?

3. How does your character locomote? Do they always run? Do they walk bow-legged?

4. What style of body language does your character use when expressing itself to other characters? When interacting during the game, is your character more conscious of itself or others?

5. How does your character use it eyes communicating to the audience, or in our case, the gamer? Is the gamer a co-conspirator, an adversary, or generally ignored?

Once you've answered these five questions for yourself, you need to clearly communicate these characterizations to your team. One great way to communicate this is by using comparison,"Her eyes always look mysteriously into the distance, like Garbo, and she moves real sexy, like Kathleen Turner in Body Heat." Use these kinds of pose and motion archetypes when defining your character's behavior. don't leave it at that though! Get up and move around; act things out! Start a photo archive on each character and scribble down the ideas you don't find in magazines and books. Anything goes when you're showing your teammates exactly what you want from your future femme fatale.

Camera Positioning: Now that you've vogued like Madonna and pranced around like Jerry Lewis to the delight of your colleagues, its time to design your camera views. Is your game camera first or third person? If it's first person, that could cut your motion requirements considerably, while a third person camera will give you a chance to show off some of your animation muscle. What is the distance from the camera to your character? Will the gamer be able to see small, precise motions? If those are necessary for gameplay, you'll either need to bring the camera in close or animate the actions more broadly. Will you use cinematic camera cuts, or is the camera continuously following your character no matter what happens? Does the camera run along a rail, where its XYZ position is pre-set based on the character's position, or is the camera dynamic, where the players have a lot of control over where they can look?

On KGB we frequently used a rail-cam. Since our animation testing software didn't let us use an in-game camera, we had no idea that, when our outfielder stood in the warning track facing away from the camera in his relaxed pose, it looked like he was relieving himself against the outfield wall. Thankfully the Nintendo testers found this "bug", and it was relatively easy to fix.

Character Design: Once your camera position questions are answered, it's time to finalize your character designs. The vagaries of character design create lots of very complex, interdependent questions. You already know that it's an important issue and that there's no single approach that guarantees success, so I'm only going to give you some resource suggestions: Next Generation issue number 46 has a great synopsis of some video game industry's most famous characters. The Naughty Dog web page (www.naughtydog.com) has some interesting notes on how Crash evolved. Josh White's article in the November '97 issue of Game Developer had lots of good ideas. I'd also like to recommend some books: Toy Story: The Art and Making of an Animated Film by John Lasseter, and Nightmare Before Christmas by Frank Thompson. For a great anatomical reference, look at Drawing Lessons from the Great Masters, by Robert Beverly Hale, and An Atlas of Animal Anatomy for Artists, by Ellenber/Dittrich/Baum.

Flow Charting: When complete, your flow charts will describe every single possible combination of motions that can occur in your game. Creating a flow chart that accurately reflects your final game is difficult, frustrating, and time-consuming; but without creating them you're headed for trouble. The simplest possible flow is a linear-type, where you go directly from move to move in a fixed order.

In the above scenario your character couldn't stand from a walk or jump from a run. Obviously, this type of flow is very limited. The next simplest flow chart is a radial-type, where all branches start and end from the same position:

The radial-type of flow provides slightly deeper game play, but is still too confining for most gamers. The flow-chart style I've found effective is the descending type. Its most significant strength is that it allows infinite complexity and its biggest weakness is that it can be challenging to use effectively. Let's create a simple example of a descending flow with the following moves:

The parenthesis around the moves on the bottom row represent the idea that gameplay continues by jumping up the flowchart to an earlier move or "state." This means that you go from any (Stand Relaxed) up to Stand Relaxed at they very top. Note that Die is the only move that isn't followed by another move.

Before you generate any motion assets, the art director has to approve the way Stand Relaxed looks in the game. Before you set a single key-frame or plan your motion capture shoot, find a photo or draw a picture describing exactly what Stand Relaxed should look like, then generate some data that closely matches the pose and look at it in the game. With sports games you can use magazines and trading cards, but with most other genres you're going to have to draw a picture of the pose. Doing this may sound like a lot of extra work, but I guarantee that it will save you lots of time in the long run.

Here's one way this extra work up front will save you time: Let's say the director and the animator sit down and talk about how Stand Relaxed should look, but they don't use visual reference. At the end of the meeting, the animator "knows exactly" what the director wants and creates Stand Relaxed. Then, since the animator "thought he knew exactly" what it should look like, he goes ahead and generates Walk, Run, Jump, Punch and Get Punched without getting Stand Relaxed signed-off by the director. What happens when the director takes a look at Stand Relaxed and says, "this looks good, but the right arm should be raised a bit higher?"

In order to avoid popping, the animator now must go and fix the first portion of all five moves. Multiply that by the estimated total number of moves and then multiply again to account for the art director changing his or her mind and you're talking about a lot of animator time. I'm embarrassed to say that on KGB, I ignored this rule more than once and got burned nearly every time. I'd love to save you the trouble!

You may have noticed that our flow doesn't let you Jump from a Run! If you simply play Jump directly after Run, chances are that no amount of interpolation will give you an accurate-looking transition, while no interpolation at all will result in a pop. A pop is a visual anomaly when you see the "seam" between two moves. A really noticeable pop can actually break the gamer's immersion in your game. One way to remedy both of these visually disruptive situations is to create the transitional move Jump to Run. You'd probably flowchart it like this:

Here again, be as thorough as possible when defining how your transitional moves will look. Don't skip over pre-production! Video, acting it out in front of everybody and drawings are worth a thousand words and can save lots of animator time to boot.

Jump to Run's first frame should be the same as the last frame of Run. Jump to Run's last frame would match the first frame of Jump. Conceptually, this is great because you won't see any popping, but if you're not careful, a new sort of visual anomaly will appear. Since the last frame of Jump to Run is the same as the first frame of Jump, you will see a single frame of animation held for two frames. Visually, this can be almost as distracting as pop. On KGB, we did our best to avoid these "holds" by trimming the first and last frames of all transitional moves. Programmers out there please take note: animation exporting utilities should always include a widget to set the range of frames that the animator wants to export.

Let's add a new move, called "Stand Crouched." Let's assume all the moves that come out of Stand Relaxed will also come out of Stand Crouched. Now you've got two initial states from which your character can interact with the world. That could double the number of transitional moves you need between your two initial states and the five states that follow. Here's a way to estimate how many transitional moves you need to create:

Two states that go only between each other equals two transitional moves.

Relaxed RelaxedToCrouch Crouch

Crouch CrouchToRelaxed Relaxed

Add a third state, called "Ready." Now you've got six transitional moves.

Relaxed RelaxedToReady Ready

Relaxed RelaxedToCrouch Crouch

Ready ReadytoRelaxed Relaxed

Ready ReadytoCrouch Crouch

Crouch CrouchtoReady Ready

Crouch CrouchtoRelaxed Relaxed

See a pattern? Here's a formula for calculating the number of transitional moves between states:

(# of states) * (# of states - 1) = # of transitional moves

Now that you've defined the look of all your states (and gotten them approved), act out the transitional moves in front of the entire motion team. There are so many approaches to even the simplest motion that you must do everything you can to be sure you've clearly communicated your ideas to everyone involved.

Bust-A-Groove recently came out over here and at first, it really blew me away with the apparent complexity of its flow-charting. The dance moves are so inventive, clever and engaging that at first glance the motions appeared impossible to flow chart. but if you look closer, you realize that branching can only happen at the first beat of every musical measure. Since the gamer chooses a single key-combination to follow and can only succeed or fail to be on the beat, the code knows at the beginning of every musical measure exactly which two moves can be played after the current one. If the gamer succeeds in staying on the beat, the gamer is rewarded with an even more complex dance move, which begins exactly where the previous move left off; the transition to the next move is visually seamless. If the gamer fails to tap the key-combination on the beat, the character lerps to a less interesting move. The trick here is that the gamer is so busy focusing on how to succeed on the next key-combination that they don't really notice the lerping. The game also includes special offensive and defensive moves and these follow the flowcharting pattern established in the dancing portion of the gameplay.

Now that you've got a fleshed-out flow chart, you can create your list of moves. Write down all the states and transitional moves on your flow chart and your move list is complete. You may want to include other information of the list - maybe a description of what the move looks like, the file's status (captured, edited, in game), and who the tasks are assigned to. Ideally this list will help you track the progress of the project. On KGB we had an automated move tracking system. The producer assigned a task on our intranet, and the animator received mail with the name of every move they were to work on and what sort of work they had to do. Every night at midnight, a utility program would automatically look through our directories, note newly added or updated files, and mail the producer with the tasks that had been completed. It worked great and saved production people from going into a master file and updating all of that information by hand.

Some games feature cinematic sequences. In real-time environments (where pre-rendering may not be an option), you're going to have to plot the motion which will occur in your cinematics. Storyboards can really help with this task since they describe not only the character's motions but also the cameras that those scenes will require. The cinematic moves you include in your game have one significant difference between the gameplay moves: frame count. Game play moves require the fewest possible frames but cinematic moves can be full of lush, expressive motion.

Step 2: Create

This step consists of the following three sections: Model, Skeletonise and Test your Production Pipeline

Model: Now that you've got piles of delectable, director-approved photos and/or drawings of your character in action, its time to start modeling. In my opinion the animator should model the characters. That way, when problems crop up later, it's clear who should do the fixing. If the schedule doesn't permit this, have the modeler and the animator meet regularly. A good-looking model isn't necessarily an animatable one. Character modeling is a critical step in the animation process, but it's also a very complex issue. I've read several good articles recently, especially Josh White's article, "Birthing Low-Polygon Characters", in the November '97 issue of Game Developer. The best general advice I can give is this; view your model inside your game environment as soon as you possibly can. I can't tell you how many times I've seen scale, texture, polygon count and design issues come up very late in the production process and stress the whole team out. Viewing the model in the game as soon and as often as possible can help prevent those situations.

Skeletonise: Now its time to add a skeleton to your beautiful character model. This task is generally best left to animators, because they'll be using the skeleton once it's complete. Since they built it, they'll be eager to help with any problems that will crop up later. Adding a skeleton is a very tricky process and can only be properly learned through experience. Problems can arise with software skeleton building techniques, legacy design, modeling techniques, poor communication, or incorrect implementation in software - among many other areas.

I would like to emphasize two things about adding a skeleton: don't start adding the skeleton until the model is approved by the director in the game, and be sure that there are absolutely no discrepancies between the animator's skeleton and the one the programmer is using in the game. This second point gets me all the time! Whether its because joints shift position when you attach IK components or the artists round off joint positional values differently than the programmers, every bit of meticulousness you can muster must be applied in this step.

There was a recent article in Game Developer that covered some of the most important artistic issues very nicely. It was in the October '98 issue, written by Stephan Henry-Biskup, and called "Anatomically Correct Character Modeling". I keep a copy of this article close at hand whenever I do this sort of work.

Test Your Production Pipeline: Ok, you're model is textured and scaled properly. It has a skeleton, and the game designer has seen it in the game and has approved everything. Now its time to start testing your production pipeline. Hopefully, while the animator was modeling the creature, he was also designing the production pipeline with the animation programmer. Keep the design of the production pipeline very simple. If you're not careful, it'll quickly get more complicated than you can believe.

Some of the issues you'll face in designing your production flow are whether to use motion capture or key-framing, directory structures, file naming conventions and converting data-intensive animation files into economized game-ready motion data, but believe me, there'll be plenty of others.

Step 3: Implemention

The implementation step consists of six sections: Exporting, Faux Moves,Vellums, Efficient Work Habits, and Set Standards For Quality. Let's look at each one in detail.

Exporting : Approach your first set of animations as a technical exercise in exporting. Your goal is to establish that the motion data you export is exactly what you see in the game. For this first animation, define strict rules for the animator to follow, things like; set all key-frames at 10 from intervals, apply only 90-degree joint rotations, and apply only fixed-distance translations. If the animator sticks to these standards and the programmer implements the data properly, what you see in the game is exactly what you see in your animation software.

Once you're happy with that portion of the pipeline, head back to your flow chart and pick the simplest thread you can find, say "Stand Relaxed" to "Jump" and back to "Stand Relaxed." Generate your motions, convert them to game ready data, and implement.

Now is when you say, "Hey wait a second, it looks totally different in the game than it did in 3DSMax/Softimage/Lightwave! We tested our animation production pipeline, how can this be happening!" You tested every step of the pipeline as thoroughly as possible, it worked perfectly in your technical tests. How can there still be technical issues to work out? Joints suddenly rotate in the opposite direction (or not at all); popping may appear at loop points or at transitions; the list of possible problems is a long one.

Be patient, buy the animation programmer a soda and work through the issues one by one. Do whatever you have to to make sure that what you see in the game is exactly what you see in your animation software. Keep in mind that sometimes you have to accept a solution that is less than ideal. On a recent sequel project, the programmer and I realized six weeks into the animation schedule that the motion conversion code was removing every other frame from my animation and replacing it with a linear interpolation! So guess what, I went into my animation, applied a key on every joint on the odd frames, deleted the even frames and reset my curve types to linear. Linear interpolation isn't how I'd choose to animate, but that's just the way it goes sometimes.

One often-overlooked test is to check the way your moves work in a sequence on the game platform! This test involves a lot of extra work for the animation programmer so they might say you're crazy or they might way you don't know what you're talking about. If you can get a system like this in place, take the animation programmer out the most expensive dinner you can afford.

Also obvious but often overlooked is to keep the method you use to test motion sequences quick and simple. How many times have you waited five minutes to compile a tester only to forget what you were testing! Make sure the move sequence testers use up-to-date in-game cameras. After all, we don't want our character to inadvertently appear to be relieving himself against the outfield wall!

Faux Moves: Game play is really the only thing that really matters. The gamers of the world will absolutely hate your beautiful animation if it takes too long to play back and spoils their control of the character. But how do you figure out the right number of frames for a single animation? Make a faux move, of course!

What are faux moves? They're moves that help you plot out technical requirements on a per move basis. A faux move is a pre-determined length and moves through a pre-determined space. Faux moves should take an absolute minimum amount of time to generate. Ideally, they're just a start and an end key-frame but you may need one in the middle somewhere if it covers a lot of round or re-orients during the course of the animation. Faux moves can also help you decide if you're going to need detailed transitional moves, and to see if you're happy with your camera angles. Faux moves are your friend!

Let's say you're creating a flying kick. You go and motion capture a Kung-Fu Master's quickest flying kick. His actions look great in your animation software, so you convert it and drop it straight into the game. When you play the sequence back on the game platform, it seems to take an eternity for the Kung-Fu Master to execute his move. He also lands facing the wrong direction. Since the Kung-Fu Master is no longer available for capture sessions, you have to sit down with the animation programmer and revise your flow charts, or significantly edit the Master's motion data. Creating faux moves before your session could have saved you this trouble.

Vellums: The use of vellum is, perhaps, the most top-secret labor saving device that the animation team developed during KGB. Vellum is strong, semi-transparent paper. Today, off-the-shelf software tools make the use of vellum somewhat obsolete, but here's how we used it:

Early in the capture process we realized the importance of "registering" the capture subject's beginning and end poses to the moves that preceded and proceeded it. The closer those two poses are in the captured data, the less blending you'll have to do between moves. We never managed to get the previous and following moves viewable during a capture session. We compromised by recording (on vellum) the subject's begin and end foot positions. For the above flow chart, we would have recorded Stand Ready and Stand Crouched. Here's how we recorded the foot positions:

When we wanted to start the subject in a previously recorded state, we'd pull out the corresponding vellum and lay it in a appropriate spot in the capture area. We had a piece of blackened cardboard, from the middle of which we'd cut an oversized foot shape. We'd slide the cardboard under the vellum and mark the feet onto the floor. Down and dirty perhaps, but who says every solution has to be a technical one?

Efficient Work Habits: Our final creative issues deal with some necessary but humdrum items: naming files and creating directory structures. Name your files something short but meaningful. If you end up with hundreds off moves, only a freak can remember what the hell RE_353_A.trs looks like. Directory structures are also very important to working efficiently. Give each character one directory for work-in-progress and one for game-ready motions - maybe even on a per-level basis. Experiment to find what works for you.

Set Standards For Quality:: Two more concepts will help you get ready to begin motion production. The first is that your final motions, taken as a whole, should display as wide a range of detail as you can manage. The question you need to answer here is, how much detail does each animation for each character require? The motion on a distant character won't require the fine motion details that your main character (who is close to the camera) will. Define your cameras before you do any detailed animation!

The second concept: what's more important to your game, control or animation? If you put control first, you may not be able to include things like special turning moves. What you gain by this is that the player has precise control of the character at every moment. What you lose is the chance to include interesting, character-defining motions. An example of this type of game is Mario64. The flip side, valuing interesting motions equal to control, gives the animator precious frames to reinforce the character's identity but also forces the player to give up pinpoint control. An example of this sort of game is Spyro the Dragon. Both games were hits, so depending on the genre, don't let anyone tell you to sacrifice your animation purely for the sake of gaining control.

Now You're Ready To Generate Some Assets

Now that your foundation has been solidly laid, actual motion asset generation can confidently get underway. Some fine articles have been written about tricks of the motion capture trade: see Melianthe Kines' articles in Game Developer's September and October '98 issues and the Darnell Williams/Steve Grey article in a back issue of Digital Magic. Even that old staple franchise, Quake III, has upped the animation ante with an animation system that pushes the visual envelope. Who would have thought a first person shooter would "require" interesting solutions to animation challenges?

Before we go on to compare the pros and cons of motion-capture and key-framing, let me say this, motion-capture captures motion, not emotion. When you want more than simulated human motion or are looking for a deep emotional response from the audience, it's generally best to stick with key-framing.

Game Animation's Future: It's Up to You

Quality animation assets are a higher priority than they've ever been in the history of video games, but there is so much we can do to raise the bar! In order to stay ahead of the pack, we, as animators, need to create streamlined approaches to the way we work. When we are able to work quickly, we'll create more iterations of each motion, and hopefully spend the final portion of our production schedule fine-tuning rather than slapping moves in and just trying to get the project done and over with. Every aspect of gaming is benefiting from the growing power of consoles and PC's (and Mac's), let's work together and make sure that animation takes its rightful place beside coding and game design in every game developer's bag of tricks.

Jeff Hayes has been working in computer animation for the past ten years. His projects include Major League Baseball Featuring Ken Griffey Jr. for the N64, and an LBE attraction called Virtual Jungle Cruise for DisneyQuest in Orlando. He can be reached at [email protected].