Guide

Game locomotion explained

Before players read your tutorial or admire your art, they press a movement key. If the character slides like ice, snags on invisible corners, or jumps a frame too late, they assume the whole game is broken. Locomotion is the engineering of how avatars move through space — not just speed numbers, but acceleration curves, ground contact, collision response, and the small forgiveness windows that separate a platformer people speedrun from one they refund. This guide covers kinematic vs dynamic controllers, ground probes, slope and stair handling, jump design, root motion, genre-specific patterns, networked prediction, and how locomotion ties into input handling, animation blending, and physics simulation.

What locomotion is — and why it is not "just physics"

Locomotion is the player-facing movement layer between raw input and world collision. Pure rigid-body simulation gives realistic tumbling crates; it rarely gives a hero who stops on a dime, climbs a chest-high ledge, or air-dashes with frame-perfect reliability. Most action games therefore use a character controller — a specialized mover that cheats physics in controlled ways to prioritize responsiveness and predictability.

Three axes define your locomotion stack:

Representation — capsule, box, or custom mesh swept each frame against the environment.
Integration model — kinematic (you set velocity/position directly) vs dynamic (forces and constraints drive a rigid body).
Feel tuning — acceleration, friction, coyote time, jump buffering, and air control that sell weight without sacrificing control.

Animation is downstream: locomotion decides where the character is; blend trees decide how it looks getting there.

Kinematic vs dynamic character controllers

Kinematic controllers

A kinematic controller treats the avatar as a collider you move explicitly each frame — typically with capsule casts or swept collision tests. You compute desired velocity from input, resolve overlaps against static geometry, then apply the final displacement. Unity's CharacterController, Godot's CharacterBody3D, and Unreal's UCharacterMovementComponent follow this pattern.

Advantages: predictable stair stepping, slope limits, and no tipping over when hit by physics props. Disadvantages: the character does not naturally receive impulses from explosions unless you add custom knockback code.

Dynamic (physics-driven) controllers

Here the avatar is a rigid body with constraints — locked rotation, high friction material, or a configurable joint to a invisible anchor. Forces or velocity changes move the body; the physics engine resolves contacts. This shines in physics puzzlers and ragdoll-heavy games where tumbling is the feature.

Hybrid approaches are common: kinematic locomotion on foot, switch to ragdoll on death; or kinematic horizontal movement with dynamic vertical velocity for certain platformers. Pick based on whether players need arcade precision or emergent physical comedy.

Ground detection and the "am I grounded?" problem

Almost every locomotion bug traces back to wrong grounded state. A single downward ray from the capsule center fails on ledges, stairs, and moving platforms. Production setups typically combine:

Sphere or capsule cast slightly below the feet with a skin width margin — detects ground before visual penetration.
Multiple probe points — center plus toe and heel offsets so hanging off a ledge correctly flips to airborne.
Ground normal tracking — store the surface normal for slope projection and aligning the character up vector on hills.
Coyote time — a 80–150 ms grace period after leaving a platform where jump still counts as grounded (see input buffers).
Ground stick — small downward velocity while grounded to prevent micro-bouncing on triangle edges.

Moving platforms need parent velocity added to the character's world velocity on detach, or players get launched or left behind. Track the platform's transform delta each frame while grounded.

Acceleration, friction, and movement curves

Instant max-speed snaps feel robotic; infinite acceleration feels mushy. Tune separate curves for ground and air:

Ground acceleration — ramp to target speed over 100–300 ms for walk; shorter for sprint or dash abilities.
Ground deceleration — often faster than acceleration so release-to-stop feels crisp; ice surfaces lower decel.
Air acceleration — lower cap than ground so jumps have commitment; strafe-jump games raise air accel deliberately.
Direction change — reversing input mid-sprint may apply a higher decel multiplier (counter-strafe in shooters) or preserve momentum (momentum platformers).

Express tuning in meters per second and seconds, not arbitrary "speed = 5" constants — it makes cross-level balancing and network sync reproducible across frame rates when you integrate with delta time.

Jumping: height, buffers, and variable gravity

Jump feel is a stack of small affordances:

Jump buffer — pressing jump 100–200 ms before landing still triggers a jump on touchdown; removes "I pressed it!" frustration.
Coyote time — jumping still works briefly after walking off a ledge; pairs with the buffer for maximum forgiveness.
Variable jump height — release jump early to cut upward velocity (multiply vy by 0.4–0.6) instead of a fixed apex.
Jump cut gravity — apply stronger gravity when falling than rising (asymmetric gravity) so hops feel snappy without floaty apex hang-time.
Coyote + buffer stacking policy — document whether both can apply in one air sequence to avoid infinite mid-air jumps from exploits.

Wall jumps, double jumps, and dashes are separate ability states with their own cooldowns and animation gates — do not overload the base jump handler or debugging becomes impossible.

Slopes, stairs, and ledge traversal

Slope handling

Project movement input onto the ground plane using the ground normal so walking uphill does not add phantom vertical speed. Cap max walkable slope (often 45–50 degrees); steeper surfaces slide the player down with a controlled slide velocity. Align character rotation to slope gradually (slerp) to avoid jitter on noisy mesh normals.

Stair stepping

Kinematic controllers implement step offset — if horizontal motion is blocked by a low obstacle under the step height threshold (typically 30–45 cm), teleport the capsule up and forward. Too-large step offsets let players climb walls; too-small ones cause stair-snagging.

Ledge grab and mantle

Detect forward-up probe hits a ledge within arm reach; transition to a scripted or root-motion mantle animation that temporarily disables player steering. Snap to ledge anchor points authored in level geometry for reliability in narrative games; use procedural detection for open-world traversal.

Root motion vs in-place animation

In-place locomotion drives translation from code; animations cycle feet in place while the controller moves the capsule. This gives designers full numeric control and is standard for shooters and top-down games.

Root motion extracts translation and rotation from the animation clip's root bone each frame — common for attacks, dodges, and cinematic mantles. Risks: animation-driven movement can clip through walls if not root-motion warped or collision-tested; networked games need to replicate root-motion events as authoritative ability casts, not per-bone streams.

A practical split: everyday walk/run uses in-place + blend tree speed matching; combat dodges and finishers use root motion with motion warping toward targets.

Genre patterns: platformer, third-person, top-down

2D and precision platformers

Tile-snapped or sub-pixel positions, tight coyote/buffer windows, and discrete jump heights dominate. Hitbox size is a difficulty knob — smaller capsule, harder game. Integrate with tilemap collision layers for one-way platforms (collision only from above via platform effectors).

Third-person action

Camera-relative input, rotate-toward-movement with turn rate limits, and separate strafe mode for aiming. Lock-on targeting may override facing. Blend locomotion speed to animation via 1D blend trees; foot IK from animation layers hides uneven terrain.

Top-down and twin-stick

Movement is often omnidirectional with no facing requirement, or facing is decoupled (body aims at mouse, movement is WASD). Acceleration can be higher because camera distance forgives less weight. Avoid physics rotation entirely.

Networked locomotion

Local locomotion is deterministic given input; networks are not. Common patterns:

Server-authoritative position — client sends input; server simulates and broadcasts state. Simple but latency-sensitive.
Client prediction + reconciliation — client moves immediately, server corrections snap or blend back on mismatch. Standard for responsive multiplayer action.
Input replay — server stores inputs and replays through the same locomotion code for anti-cheat consistency.
Snapshot interpolation — remote players render slightly behind real time, lerping between past snapshots for smoothness.

Keep locomotion code identical on client and server where possible. Floating-point order differences across CPUs cause desync — use fixed timesteps for simulation and quantize positions sent over the wire. See multiplayer netcode for rollback and tick-rate tradeoffs.

Common anti-patterns

Single center ray for ground — causes false air state on edges and stairs.
Frame-rate dependent movement — multiplying by delta time is non-negotiable; fixed 60 Hz assumptions break on 144 Hz monitors and mobile.
Identical ground and air max speed — removes jump commitment and breaks level spacing math.
Physics material friction as the only decel — unreliable on kinematic controllers; set deceleration explicitly.
Animating speed without matching capsule velocity — foot slide destroys polish; match blend tree speed to actual m/s.
Unbounded step offset — players climb unintended geometry; validate step height against nav and art metrics.
Ignoring moving platform parenting — classic "elevator launched me into the ceiling" bug.

Production checklist

Document target speeds (walk, run, sprint) in m/s and level grid units.
Implement multi-probe ground detection with configurable skin width.
Tune coyote time and jump buffer; playtest with fresh eyes at 30 and 60 FPS.
Set max slope, step height, and slide speed; block vault on unapproved angles.
Separate base locomotion from ability states (dash, wall jump, grapple).
Match animation blend parameters to measured capsule velocity.
Test on moving platforms, one-way platforms, and destructible floors.
Profile collision query count — capsule casts per frame add up in crowds.
For multiplayer: shared simulation code, input timestamps, reconciliation tests.
Record locomotion tuning in data (ScriptableObjects, JSON) for designer iteration.

Key takeaways

Locomotion is a designed system, not default physics — most action games use kinematic controllers with tuned cheats.
Ground detection quality determines jump, slope, and platform reliability — invest in probes early.
Feel comes from curves and forgiveness — acceleration, asymmetric gravity, coyote time, and jump buffers matter more than top speed.
Root motion is for moments; in-place movement is for everyday control.
Networked games need identical simulation and prediction strategy from day one, not a bolt-on patch.