How To Walk

A Complex Tutorial on a

Seemingly Simple Subject

Who Am I?

• Tom Forsyth

• I work at RAD in Seattle

• I work on Granny

• tomf@radgametools.com

How To Walk

• Players spend most time walking around– They’re looking at their 3rd-person avatar

• Other time is mainly shooting at stuff– But they’re looking at the enemy

• Most visually important thing characters do:– Walking/running– Shooting at player

• Games already good at doing the second

Presenting…

• Granny is our favourite model– But she wears a long heavy dress– Not very good for showing a walk

• So we show her ancestor:

Granny: Warrior Queen Mother

Principles of a Good Anim System

• Anims do not drive character movement• Character movement:

– Player determines movement directions– Game logic decides speeds– Collision system prevents some movements– Physics does all sorts of modifications

• Anim system must respect above• Then move limbs to make it look good

Principles of a Good Anim System

• Animations determine default motions– Extracted from animations at start of day

• Used as references by game logic• Anim system given control for complex

motions:– Mantles, commando rolls, acrobatics– Hand-to-hand grappling

• Must be interruptible (e.g. being shot)

Principles of a Good Anim System

• Must try to cope with unnatural “gameisms”– Zero-windup jumps– WASD strafing and instant stand-to-run– Nose-scraping on walls

• AI-driven characters can be denied these– Restricted, but more natural movement– This can change gameplay

Walking Forwards

• Artist creates multiple walk cycles– Each has different stride length and duration– Here we use three – slow, medium, fast – Each anim is a single walk cycle– Each starts and ends in mid-stride, left foot down

• Calculate actual speed in m/sec for each– Start of day or offline– Allows artist to create at whatever speeds they like

• For target speed, find closest two anims

Walking Forwards

• For each anim, calculate frequency in cycles/sec required to achieve target speed

• Lerp frequency to find global cycles/sec

• Play both anims, weights lerp between them

• Apply same frequency to all animations– Manually keep them all in phase– Can’t blend correctly unless all anims in phase!

Walking Forwards

• Sounds needlessly complex

• But it copes correctly with animations that:– Have few cycles per second, but long strides– Have many cycles per second, and short strides

• And lerps smoothly between them

• Can cope with more than two anims– As we shall see…

Changing Speed

• Subtle change in walking style to change speed– Slight body lean– Heel/toe balance changes– Arm motions become exaggerated

• Even at low speeds• Effect is visually subtle

– Perceived subconsciously by most– Animators trained eyes can see it consciously

• Increases immersion– Reduces “robotism”

Changing Speed

• Add two more walk anims– One for speed up, one for slow down– Both are actually constant speed!– Both at speed & frequency of middle walk– Both are extreme versions

• Find out what desired acceleration is– Heuristics depending on game– Then damp fairly heavily: 1-2 seconds to full

Changing Speed

• Play all anims in lockstep phase, as above• Blend from the three walks towards the

respective accel/decel anim• Means that at full accel/decel, there is only

one anim for all speeds• Could author three versions of each

– But not usually worth effort & memory– Usually only have a small fraction blended in

Walking and Running

• Running is just different anim set

• Three speeds, plus accel and decel

• Run anims generally faster than walks– But considerable overlap in speeds– Slowest run is same speed as medium walk

• Exactly the same blending and lockstep

Walking and Running

• Transitions triggered by speed– Going slower than slowest run switches to walk– Going faster than fastest walk switches to run– Gives considerable hysteresis

• Transition starts as either (soonest) foot lifts• Transition ends as the same foot touches• Simple lerp in between

– Could be an animation instead

Turning

• When turning at speed, body leans– Legs, arms and hips also change slightly

• At low speeds, effect is much less– For walking, leaning is totally ignored– So slight, it’s not worth the art time

• Two more anims at medium run speed– Exaggerated extreme lean left and right– Anims actually go straight, not a curve!

Turning

• Calculate turning amount from game input– Heavily damp to prevent “body lurch”

– Same as with accel/decel leans

– Again, actual rotation is not damped

• Turning lean is multiplied by speed• Lerp from standard runs to leaning animations• Footstep prediction (see below) also uses turn

Blending Summary

• Sparse 4D blend space• Axes are:

– Linear speed– Turning speed– Accelerate / decelerate– Gait (walking or running)

• Most corners of blend space not filled in– Almost never used – not worth art time– Less important characters can have sparser blend space

Animation Blending Summary

Anim name Resulting weightWalk slow = walk * slow_walk * steadyWalk med = walk * med_walk * steadyWalk fast = walk * fast_walk * steadyWalk med accel = walk * accelWalk med decel = walk * decelRun slow = run * slow_run * steady * no_turnRun med = run * med_run * steady * no_turnRun fast = run * fast_run * steady * no_turnRun med accel = run * accel * no_turnRun med decel = run * decel * no_turnRun med left = run * left_turnRun med right = run * right_turn

Strafing

• Slightly unrealistic, but expected in games

• Game code does what it wants– Animation tries to do its best– But there’s always a limit

• In RPG like this, would probably turn body– But in shooters, this is very distracting– For demo we do strafing, because it’s hard!

Strafing

• Can have 8 walk cycles in each direction– No running sideways allowed!

– Extra art effort is considerable

– Doing short steps is tricky to do well

– But sustained sideways walking looks odd

– AIs can help by hinting what they are about to do

• Here we just let game logic move the body– Foot IK just copes

– Footstep prediction uses current strafe amount

Footfalls

• Measures times of foot contacts• Used for IK, turn prediction, gait changes• Artist creates animated flag for each foot

– Created as attribute in art package– Number from 0.0=up to 1.0=down– Fractions for slipping feet and weight balance

• At start of day, scan for transitions– Produces a single up and down time per cycle

Footfalls

• Utility functions to find:– Time to next up or down

– Time to last up or down

– Fraction through current up or down state

– All handle looping correctly

• Functions to blend multiple footfalls together– Each animation has two (one per foot)

– Blended with exactly the same weights as anims

– Allows code to query footfalls of blended anim result

Footsteps

• Footstep = position of foot plant• Each foot has a future and a past/current• Past/current is set the instant a foot touches

– Never moves after that– In real game, would move in some cases

• Sliding on slippery surfaces• Explosions, being shot, etc

– Used as target by IK system while foot is down

Footsteps

• Future footstep is continuously computed:– Find time to next foot down (footfall data)– Predict current motion forwards to that time– Sample animations at that time– Find (X,Z) where foot lands– Sample landscape height Y at that (X,Z)– IK “seeks” foot towards future footprint

Footsteps

• Strafes and turns are special

• Time to next mid-step used

• Not just time to next foot down

• Foot is still nailed down at time of contact

• So when you get to the mid-step, foot is:– Pointed in line with body (turn influence)– Underneath body centre of gravity (strafe)

Footsteps

• Foot IK seeks towards predicted footprint• Changes in speed/turn/strafe change predicted

(X,Z), can change predicted Y discontinuously– So damp predicted footstep height to prevent pops

• Predicted footstep position can be tweaked– Stay away from ledges and curbs

– Avoid rocks, equipment, bodies

– Dancing!

Foot IK

• Uses footsteps as guide

• Footsteps only describe an instant of time– Instant when foot went down

• IK needs to be applied to feet at all times– Otherwise, sudden pop as IK turns on/off

• Three distinct phases– All use same logic with different inputs

Foot IK

• All three phases produce:• Desired pos & orn of footprint

– Next or previous actual footprint

• Reference pos & orn of footprint– Where foot will/did fall without IK– Forward and reverse sampling of anims used

• Desire factor– From 0.0 (no IK) to 1.0 (full IK)

Foot IK

• Foot is down– Reference is animation state at last foot plant– Desired is current(/last) footprint– Desire = 1.0

• Foot is in first half of swing– Reference is animation state at last foot plant– Desired is (current/)last footprint– Desire = 1.0 at foot up, to 0.0 at mid-swing

Foot IK

• Foot is in second half of swing– Reference is animation state at next foot plant– Desired is next predicted footprint– Desire = 0.0 at mid-swing, to 1.0 at foot plant

• Desire curves are simple, but acceptable– Could be spline-softened for better tangents– Could be artist-defined using animated curves– But hard to preview in art package!

Foot IK

• Now find delta from reference to desired• Scale by desire factor• Apply position delta to ankle

– Move knee joint as necessary– Standard 2-bone IK– Simple knee-pop control

• Orientation delta applied to metatarsals– (bones from ankle to ball of foot)

Hip Height

• Can make legs shorter by bending them

• Cannot make legs longer! (hyperextension)

• If stepping down, hips need to move too

• If stepping up, hips cannot move too soon

• Hip height not controlled directly

• Instead move “ground shadow” root bone

• Then feet will IK back up to correct place

Hip Height

• Always at least as low as lowest foot

• But causes “bumpiness” during foot swings

• So during foot swing, use virtual foot height– Lerp from last footprint to next footprint

• But also blend to other foot in mid-swing– No hard reason for this, just looks better!

The Skirt

• (and shoulder straps)

• Offline cloth sim in Maya

• No runtime cloth sim at all– Far too expensive!

• Recorded as vertex animation

• Encoded as spline curves for space– Keyframed vertex animation gets big!

The Skirt

• Cloth sim does not loop perfectly– Do “settle down” phase of ~10 cycles– Take next 2 cycles– Copy & offset by a cycle– Crossfade to make a perfect loop!

(a standard trick in audio processing)

The Skirt

• Only stored for six anims– Three speeds of walk and run– Not leans or accel/decel– Quality increase is tiny– Would double the memory & authoring effort

The Skirt

• But vertex anim blending doesn’t work!

• Bones slerp & preserve lengths

• Vertex animation can only lerp

• Mismatch where they (should) meet

• When the legs IK, what should the skirt do?– When blending, waistband doesn’t meet hips– Skirt penetrates legs with blending or IK

The Skirt

• So don’t store object-space vertex anims• Skin the skirt, as if it were a miniskirt

– But doesn’t influence actual animation shapes

• Vertices can now be transformed back into the default pose on each frame

• Removes effect of bones• Just effect of “being cloth” preserved• This is now stored as the vertex animation

The Skirt

• At runtime, replay vertex anims• Blend together in “default pose space”

– All vertex anims stored in the same pose– So lerps “make sense” here– They don’t penetrate body (usually)

• Then animate using standard skinning– IK “just works”– Vertex animation is simpler – less memory

The Skirt

• This trick can be used for most fine anims– Hair, cloth, muscles, facial expressions

• Large-scale movements encoded in bones

• Small movements encoded per-vertex– Lerps have minimal artefacts– Small motions, so simple curves = low memory

• Don’t need to be present in every anim

What’s Next

• Demo is still work-in-progress!• More emotions (aggressive, defensive)• Walk to stand and back again

– When is a single step just the start of a walk?

• Standing pose transitions– Transitions done while keeping one foot still– Foot chosen according to weight distribution

• Turning on the spot– Again, moving just one foot at a time

What’s Next

• Attacks– IK’d attacks to precisely strike target

(allows stabs, not just big dramatic slashes!)– Hits taken are tricky (blend with ragdoll?)

• Looking around– Multiple (9) head poses – lerp to required dirn– Bone-masked blend onto body animation

What’s Next

• Upper & lower body anims– Move + attack at same time

– Each upper-body anim has a mask per-bone

– Says how much that bone is required for anim

• Jumping– No-windup jumps are unrealistic

– But required for responsiveness

– Therefore, hard to get looking right

– AIs can be forced to do windups

What’s Next

• Noise to hide repetitive walk cycle– Player is looking at the walk 50% of the time

• Crossfade multiple versions of anim– If your artists have time

• Add position noise – makes them look old!• Add noise into phases of bone motions

– Only works for cyclical motions (not poses)

• May need IK fixups to nail hands/feet

Summary

• Walk cycle is very important– Hard to get perfect, unlike stationary poses

• Most benefit from sticking feet down– Control hip height to prevent hyperextension

• Good transitions get next most benefit– Accel/decel leans surprisingly important

• Then correct prediction of foot plants– Rough terrain, turning and strafing prediction

The Golden Rule

• At all times, game logic/player decides:– Position of player (centre of gravity)– Actual speed and turn rate

• Animation system must try to cope– Pick appropriate speed walk anim– Blend in leans (accel/decel/turn)– Foot sticking & prediction– AIs can look better by being constrained

Thankyou

tomf@radgametools.com

Tom Forsyth

RAD Game Tools