How To Walk

1. How To Walk A Complex Tutorial on a Seemingly Simple Subject

2. Who Am I? • Tom Forsyth • I work at RAD in Seattle • I work on Granny • tomf@radgametools.com

3. 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

4. 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

5. 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

6. 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)

7. 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

8. 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

9. 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!

10. 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…

11. 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”

12. 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

13. 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

14. 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

15. 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

16. 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!

17. 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

18. 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

19. Animation Blending Summary Anim nameResulting 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

20. 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!

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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)

27. 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!

28. 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

29. 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)

30. 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

31. 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!

32. 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)

33. 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

34. 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!

35. 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!

36. 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)

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. Thankyou tomf@radgametools.com Tom Forsyth RAD Game Tools