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

• [email protected]
 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 weight
Walk slow = walk * slow_walk * steady
Walk med = walk * med_walk * steady
Walk fast = walk * fast_walk * steady
Walk med accel = walk * accel
Walk med decel = walk * decel
Run slow = run * slow_run * steady * no_turn
Run med = run * med_run * steady * no_turn
Run fast = run * fast_run * steady * no_turn
Run med accel = run * accel * no_turn
Run med decel = run * decel * no_turn
Run med left = run * left_turn
Run 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

[email protected]
Tom Forsyth
RAD Game Tools