Skip to content

Character Movement Component: the knobs that matter

The Character Movement Component is the walking, falling, jumping, and networked movement system that makes Character different from a plain Pawn. Most beginner movement tuning is changing a few values on this component, not rewriting movement from scratch.

The one-minute version

  • A Character already has a Character Movement Component. It moves the capsule, tracks velocity and acceleration, handles walking/falling modes, and consumes movement input from nodes such as Add Movement Input.
  • Max Walk Speed is the usual "how fast do I run on the ground?" knob. It is measured in Unreal units per second, which are centimeters by default.
  • Max Acceleration controls how quickly the Character reaches that speed. Braking Deceleration Walking and friction settings control how quickly it stops when input is released.
  • Jump Z Velocity, Gravity Scale, and Air Control are the first jump/fall feel knobs. They work together; changing only one can make a jump feel floaty, heavy, or hard to steer.
  • Rotation Rate, Orient Rotation to Movement, and Use Controller Desired Rotation decide how the Character turns when Character Movement is allowed to own facing.
  • In multiplayer, Character Movement already has prediction and correction. Client-only speed or position changes can appear to work briefly and then get snapped back by the server.

What the component owns

A Character is not just a Pawn with a mesh. It has a capsule, a skeletal mesh, and a Character Movement Component designed to work together. The movement component owns the ordinary humanoid movement simulation:

flowchart LR
    Input[Input events] --> Add[Add Movement Input]
    Add --> Pending[Pending input vector]
    Pending --> Move[Character Movement Component]
    Move --> Mode[Walking / Falling / Swimming / Flying / Custom]
    Mode --> Capsule[Character capsule location and velocity]
    Capsule --> Anim[Animation Blueprint reads velocity]

That is why Scale Value on Add Movement Input is not the run speed. The input request feeds Character Movement; Character Movement then applies its settings, movement mode, floor/collision checks, gravity, and networking rules.

The settings beginners reach for first

Setting Category in Details Beginner meaning
Max Walk Speed Character Movement: Walking Top ground speed while walking. Also caps lateral speed while falling.
Max Walk Speed Crouched Character Movement: Walking Top ground speed while crouched.
Max Acceleration Character Movement (General Settings) How quickly velocity can change toward the input direction.
Braking Deceleration Walking Character Movement: Walking How strongly the Character slows when walking with no acceleration.
Ground Friction Character Movement: Walking How much ground contact resists sliding and affects control.
Braking Friction / Braking Friction Factor Character Movement (General Settings) Extra drag used while braking, if separate braking friction is enabled.
Jump Z Velocity Character Movement: Jumping / Falling Initial upward jump velocity.
Gravity Scale Character Movement (General Settings) Multiplier on gravity for this Character.
Air Control Character Movement: Jumping / Falling How much lateral steering is allowed while falling.
Rotation Rate Character Movement: Rotation Settings How fast Character Movement can rotate the Character when one of its rotation modes is active.

Treat these as a tuning set. A fast character with low acceleration can feel sluggish. A high jump with low gravity can feel floaty. A high ground speed with weak braking can feel slippery even though the top speed is correct.

Speed, acceleration, and stopping

For ground movement, start here:

Max Walk Speed
-> top speed on the ground

Max Acceleration
-> how fast the Character reaches the desired speed

Braking Deceleration Walking + Ground Friction
-> how fast the Character stops or changes direction

If "my character is too slow," change Max Walk Speed first. Do not multiply Add Movement Input by bigger and bigger values hoping to make normal walking faster; Scale Value is input strength, not the character's configured speed.

If "my character takes too long to get moving," look at Max Acceleration. If "my character slides after I let go," look at Braking Deceleration Walking, Ground Friction, and whether separate braking friction is in use.

Useful debug values:

  • Get Velocity -> Vector Length XY for actual horizontal speed;
  • movement input axis/action values before Add Movement Input;
  • Character Movement Acceleration, if you are watching values in the debugger;
  • current Movement Mode.

Jumping and falling

Jump feel usually starts with three values:

Setting Raise it when Lower it when
Jump Z Velocity The jump needs more height or a stronger initial pop. The jump is too tall or too abrupt.
Gravity Scale The jump hangs too long or falling feels floaty. The character drops too fast or has no airtime.
Air Control The player cannot steer enough in the air. Air movement is too strong or feels like flying.

Changing one value can hide what the other values are doing. For example, a large Jump Z Velocity plus low Gravity Scale gives a very high, slow arc. Raising Gravity Scale without adjusting Jump Z Velocity can make the jump feel heavy and short.

For variable-height jumping, the Character itself also has jump settings such as Jump Max Hold Time and Jump Max Count. Those belong to the Character jump system, while Jump Z Velocity, Gravity Scale, and Air Control belong to the movement component that simulates the resulting motion.

Movement modes

Character Movement is mode-based. The same input can behave differently depending on whether the Character is walking, falling, swimming, flying, or in custom movement.

Common examples:

  • while walking, ground speed and walking friction matter;
  • while falling, air control and gravity matter;
  • while swimming or flying, their own max speeds and deceleration settings matter;
  • in custom movement, your custom logic may suspend ordinary walking/falling behavior.

If a setting appears to do nothing, first confirm the Character is in the mode that setting affects. Tuning Max Walk Speed will not explain a Character that is actually falling, flying, disabled, or running custom movement.

Character Movement can also rotate the Character, but only if you choose one of its rotation behaviors.

Orient Rotation to Movement = true
-> rotate toward acceleration/input direction using Rotation Rate

Use Controller Desired Rotation = true
-> rotate toward controller desired/control rotation using Rotation Rate

Use Controller Rotation Yaw on the pawn = true
-> pawn yaw follows the controller directly, outside the movement component

The safest beginner rule is to pick one facing owner. If you want the body to turn toward movement, use the movement-oriented setup. If you want strafing or aim-facing, let controller yaw or controller desired rotation own facing.

See Why won't my character face where it's moving? for the full checkbox decoder.

Class defaults vs placed instance

There are two places you can be looking at values:

Blueprint class defaults
-> what newly spawned or newly placed instances start with

Placed level instance details
-> overrides for this one copy in this one level

If your Blueprint says Max Walk Speed is 600 but one character in the level still moves at a different speed, select the placed instance and check whether the Details panel has an override. Also check whether a runtime graph changes the setting on BeginPlay, on sprint, during crouch, or after a pickup.

For spawned characters, class defaults and construction/runtime setup matter. For already placed characters, instance overrides can be the hidden reason one copy behaves differently from the class you edited.

A practical tuning loop

Use one small test map and change one family of settings at a time:

  1. Set input and facing first so the character moves in the intended direction.
  2. Tune Max Walk Speed until the top speed is right.
  3. Tune Max Acceleration until starting and turning feel responsive.
  4. Tune Braking Deceleration Walking and friction until stopping feels right.
  5. Tune Jump Z Velocity and Gravity Scale together until jump height and hang time feel right.
  6. Tune Air Control only after the basic jump arc works.
  7. Check animation after movement values are stable. Animation should react to motion, not hide broken movement settings.

This is the best overall path for month-one projects. The quick path is to keep increasing speed or input scale until the character "feels better," but that buries separate problems: acceleration, braking, turn rate, and animation state all get harder to debug later.

Why the server snaps you back

Character Movement includes client prediction and server correction. In a network game, the owning client predicts movement locally, sends move data to the server, and the server checks whether the result is acceptable. If the server disagrees, it sends a correction and the client replays saved moves from the corrected state.

That means:

  • changing Max Walk Speed only on the client is not enough;
  • teleporting or forcing location only on the client can be corrected away;
  • custom movement needs a deliberate networking plan, not only local Blueprint movement;
  • simulated proxies on other clients are following replicated movement, not your local input events.

For single-player, this mostly stays invisible. For multiplayer, treat the server as the authority for real movement settings and state.

When a setting appears to do nothing

  1. The graph never sends movement input. Prove the input event fires before tuning movement.
  2. The Character is not possessed. A character in the level is not necessarily the pawn your PlayerController is driving.
  3. The movement mode is not the one you are tuning. Walking settings do not explain a Character in falling, flying, disabled, or custom movement.
  4. A placed instance overrides the class defaults. Check the copy in the level, not only the Blueprint asset.
  5. Runtime code changes the same setting later. Sprint, crouch, damage, buffs, and menus often overwrite movement values after BeginPlay.
  6. Animation/root motion is moving the mesh separately. The capsule may be correct while the visible mesh appears to drift or turn differently.
  7. The server corrects the client. Multiplayer movement changes need to exist where the authoritative movement is simulated.
  8. Collision or floor checks block the result. A high speed value does not guarantee the capsule can move through the world.

Lookalikes

Thing Use it when Not the same as
Character Movement Component You are tuning built-in walking, falling, jumping, rotation, and networked Character movement. A generic component you add to any actor for free movement.
Add Movement Input You need to request movement this frame. The speed/acceleration settings that decide how the request becomes motion.
Get Velocity You need to read current movement result, often for animation. A movement setting.
Set Actor Location You intentionally place/teleport an actor. Normal Character walking with movement modes and prediction.
Launch Character You want a one-time launch velocity on a Character. Held walking input or the normal Jump request.
Projectile Movement Component A projectile or simple moving actor should simulate projectile-like motion. Humanoid Character movement.
Floating Pawn Movement A simple Pawn should drift/fly without Character features. Character walking/jumping/capsule movement.

Going deeper