Free Candy For Everyone

Christian Gyrling’s talk on the AI/animation system used for Uncharted: Drake’s Fortune was easily the most anticipated talk at GDC 2008 for me. I am currently working on AI for a console action title and this is a subject near and dear to my heart. Hearing how other people have made this system work is fascinating and helps me think about how I can learn from other’s work.

They were facing many problems going into this project. It was a new codebase, a new franchise and a new console. The goal was to make everything bigger! They were expecting 10-20 times the number of animations for each character compared to the last generation of console games. But they still were only planning on having one programmer and one animator for every two characters. You cannot put 20 times the content in with the same number of people.

They decided to figure out which things they could address. First was gameplay scope - they couldn’t make everything better, so what parts should they make better? Next was asset creation - how could they create all these animations? How could they decrease iteration time? Finally, the issue was programming. How should they organize all the animations? With all those anims, how will they choose which ones to play? Do they need complex selection logic?

Their approach was to get something working very rapidly. They got a very bare bones version of the AI up and running. It could stay and shoot, go to cover, get hit, and die. Christian and a designer played with it and took notes on what they saw as a player. When they were having fun what were they seeing on the screen? The average lifetime of an enemy in Drake’s Fortune is 15 seconds. Enemy hit reacts and death were fun. The rest of the time the enemy was in cover or shooting at you. The goal became to make these interactions as interesting as possible.

Problems to solve were that they had a lot of animation files. It was slow for an animator to open them all in Maya. With so many anims, they had mismatching keyframes, especially with transition animations where they go from one state to another. The start and end frame need to be the same, but to check this they had to open another Maya file. To solve this they decided to have fewer actual files and keep all related animations in the same Maya file. For example, all cover animations were in one Maya file that the game extracted the needed frames out of. This solution only works if you have one animator per character, since you cannot share the Maya file. But they found that the animator really took things to heart and felt a sense of ownership when they did own a character like this.

Another problem was that the animator shouldn’t have to go through a programmer to fiddle with his animations. They should be able to tune their anim blends without having to restart the game. They created a tool called the In-Game Character Animation Test Bed. Instead of having the AI contol things, they map all possible AI actions to a controller. Then the animator can run the character around and move it to cover to see all the anims. Time to go from animation creation in Maya to controlling an NPC was around a minute. They also let you reload animation scripts at run-time. They only have a PS3 build of the game, there is no PC build. So letting the animator tweak the blends on the fly on the devkit was really critical.

Next Christian got into a lot of specifics on how they structured their AI and animation layers. I think the most important things to take away were how separate they kept the two layers. The AI would tell the character to move to cover and just trust that it would get done. The animation scripting took care of which animation would play to make it happen. They could have many different enter cover animations and the AI logic would never need to know about any of them.

The other big thing that was fascinating was the technique of Additive Animation (or Delta/Diff Animation). We are all using technology to blend multiple animations together to ease the load on animators. For example, playing a walk animation on the legs at the same time layering on an aim anim with the upper body. But this idea takes it one further. If an animator makes a run animation, then makes a tired run animation, you can basically subtract the run from the tired run to get something that equals “tired”. Then you can add that “tired” bit on to any animation to make the character look fatigued. Add it to the idle, the walk, the run or more and you create a lot of animations without any new work. Awesome.

They also use something he called animation layers. Each of these layers is independent of the others for purposes of deciding when they start and stop. So on one layer you may be playing a run animation that is 30 frames. On another you have an additive run-noise anim that is 300 frames. On the final layer you have some facial animation that’s 160 frames. As the one starting these anims, you don’t worry about syncing them up. Each layer is responsible for itself only, so the run-noise layer isn’t worrying about if the run layer is going to loop, it just plays.

Other interesting bits - they using additive animations for their aiming and look ats. They tried using IK but it caused skinning problems when the character was lying down in low poses. They tried partial animations where they only animated the neck/spine but it made the character look very stiff, and you’d need lots of unique head idle anims. Ultimately they used additive anims that contain the difference in aiming with the neck, back, spine and preserve the base animation motion. Using additive anims gave the animator the power to control the look and feel. Animators will always make things look better than your tech. If not, find better animators.

This was all running on SPUs so had very good performance. 9 clips and 9 blends in normal battle took about 10 microseconds. 2 or 3 times that if the character was changing direction. Memory footprint was about 1 Kb per animation.

He gave some guidelines on what they learned from this technique as dos and don’ts.
no y-translation on hip joints in base anim
little to no hip rotation (use rotated base anims)
high and low poses worked great

He summed up with these parting points.

- choose wisely where to spend your time
- hide animation complexity form the AI through some kind of action interface
- animation states are autonomous
each contains not just an animation but the blend tree
can be tested/verified in isolation
no surprises
- additive animations
cheap - so much bang for the buck
more power to the animators - better visual quality

Tags: AI, Christian Gyrling, Drake's Fortune, GDC, Uncharted

This entry was posted on Wednesday, February 27th, 2008 at 12:28 am and is filed under Games. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.