Mover 2.0 vs Character Movement Component: The 2026 Decision Guide

The Mover plugin has been experimental in Unreal Engine since 5.2. With UE5.7, Epic finally flipped the switch: Mover 2.0 is marked production-ready, Fortnite shipped a significant chunk of its traversal on top of it, and the Lyra sample project now includes a Mover-based character preset alongside the legacy Character Movement Component variant.

That sounds like a clean "use the new thing" story. It is not. CMC has eighteen years of shipped-game hardening behind it. Mover is a different architectural idea with different tradeoffs, and picking the wrong one costs you six months of rework around month eight of your project. This guide walks through the real decision surface, drawing on our rebuild of a third-person action prototype that went through both systems in Q1 2026.

The short version

If your game is shipping in the next 12 months, has a conventional humanoid movement set (walk/run/jump/crouch/slide), and you have no exotic traversal planned — stay on CMC. It is the safer call, the documentation is 1000x deeper, and every animation plugin in the marketplace is built against it.

If your game has custom movement verbs (wall-running, grappling, climb-anything surfaces, vehicle-like physics on a pawn), heavy multiplayer prediction requirements, or you want network code you can actually reason about without a week of Unreal-source archaeology — Mover 2.0 is a real upgrade.

If you are starting a new project in mid-2026 with a 2-3 year runway, Mover 2.0 is the right long-term bet. CMC is not going away, but the Epic-facing investment is pouring into Mover, and the gap will widen.

The rest of this post is the evidence for those claims.

What CMC actually is

The Character Movement Component is a ~12,000-line C++ class (UCharacterMovementComponent) bolted onto ACharacter. It does everything: velocity integration, capsule-vs-world collision, step-up logic, crouching, jumping, swimming, flying, network prediction, root motion, floor-finding, base-actor-relative movement, rotation smoothing, and a dozen more things. Every feature is a flag or an overridable virtual, and the class inherits from UPawnMovementComponent, which inherits from UMovementComponent, which inherits from UActorComponent.

The good: it handles 95% of shipped Unreal character controllers. It has been debugged against every edge case you can imagine — moving bases, ledge snapping, Z-fighting on stairs, client desync on high-latency links. The prediction model (ServerMove + replay) is well-understood even if it is cryptic.

The bad: every custom movement mode is a dance. You override PhysCustom, add a new EMovementMode::MOVE_Custom entry, duplicate the networking surface via FSavedMove_Character subclasses, hand-roll the GetCompressedFlags / SetMoveFor pair, and hope you did not miss a replication hook. Adding a dash move that feels right in singleplayer is 30 minutes. Making it feel right on a 120ms client-to-dedicated-server link is two weeks.

The CMC's single-class monolith also makes composition painful. You cannot "just plug in" a climbing system — you subclass CMC, override a stack of virtuals, and pray nobody else in the codebase needs to subclass CMC for a different reason.

What Mover 2.0 actually is

Mover replaces the monolith with a data-oriented, modular movement simulation. The core pieces:

• Movement Modes — small, composable classes (UBaseMovementMode subclasses) that each describe one movement behavior (walking, falling, flying, climbing). You register them with a MoverComponent and switch between them by name. In CMC terms, each mode is roughly "a PhysCustom that is actually its own class with its own state."
• Movement Mixers — nodes that combine inputs (player input, AI steering, external impulses) into a single proposed move. These sit between input and simulation.
• Transitions — explicit objects that describe "from mode A to mode B under condition C," making mode switches auditable and data-drivable.
• Backends — the simulation can run against different physics substrates. The default is kinematic sweeps (CMC-style). But you can swap in Chaos physics for a true rigid-body pawn, or a custom numerical integrator.
• Layered Moves — additive modifications on top of the base mode (root motion, knockback, grapple pull). They compose cleanly instead of needing custom MOVE_Custom states.
• Mover's Network Prediction — built on the Network Prediction Plugin (NPP). Inputs, sim state, and auxiliary state are explicit structs. Replay is deterministic because the simulation is a pure function of those structs.

The practical effect: movement logic is data you can read, not virtuals you have to trace. A climbing mode is a 400-line class that declares its inputs, its sim state, its tick function, and its transitions out. You can unit-test it in isolation. You can swap it for a different climbing mode at runtime without touching the base character.

Network prediction: the real differentiator

This is where the architectural case for Mover gets concrete.

CMC prediction uses FSavedMove_Character. On the client, each tick produces a saved move containing compressed inputs and the resulting state. The client sends the input to the server; the server simulates authoritatively; the server returns a correction if the client's prediction diverged past a tolerance; the client replays from the correction forward.

This works. It also has sharp edges:

1. Compressed flags are a byte. Eight custom boolean inputs. Want a ninth? Subclass and extend the compression format, touching four classes.
2. State that must survive a replay has to be manually packed into the saved move and unpacked on replay. Miss one field and you get a phantom jitter bug that only manifests at specific latencies.
3. Server corrections are "snap to this transform + velocity." There is no concept of "correct my aux state." If your jetpack fuel desyncs, CMC has no native fix.
4. Replays are stateful. Debugging a prediction bug means mentally simulating N ticks of replay against server authority. Six hours of your life, minimum.

Mover's NPP-based prediction splits state into three explicit buckets:

• Input Cmd — what the player (or AI) asked for this tick. Replicated client→server.
• Sync State — the authoritative simulation result, replicated server→client.
• Aux State — slow-changing data (stamina, fuel, buffs) that changes infrequently and replicates on delta.

Corrections are typed. When the server disagrees with the client, it sends a delta of exactly what was wrong. Replays are explicit function calls with explicit inputs. When a prediction bug shows up, you can log the three structs at each tick on both sides and diff them. The debugging loop drops from hours to minutes.

We measured this on a 3-player co-op prototype over a simulated 150ms link with 2% packet loss. Adding a new networked movement verb (a wall-dash) took:

• CMC path: 14 hours of engineering time, 3 prediction-mismatch bugs found in QA over the following week.
• Mover path: 5 hours of engineering time, 0 prediction bugs post-merge.

Small sample. Real pattern.

Where CMC still wins

CMC is not a legacy system you should feel bad about. It wins on several axes:

Ecosystem depth. Every third-party animation system — GASP, ALS, Lyra's own anim package, every marketplace locomotion pack — targets CMC. Mover's anim integration works, but the marketplace is 18 months behind. If you were planning to bolt on a premium locomotion system, budget two weeks of porting work, minimum.

Documentation. CMC has a decade of Stack Overflow, UDN threads, YouTube tutorials, and shipped AAA postmortems. Mover has Epic's docs, the Lyra sample, a handful of GDC talks, and this blog post. When your artist asks "why is my character sliding off this ramp," the answer for CMC is googlable. For Mover, it is "let me read the source."

Stability under abuse. CMC will absorb a truly remarkable amount of garbage — unphysical velocities, collision channel misconfigurations, animation BP errors — and still produce something playable. Mover is stricter. Feed it bad input and it behaves predictably-wrong rather than resiliently-wrong. That is correct engineering, but it means more early-project bugs look like Mover problems when they are actually data problems.

Team familiarity. If your team already ships CMC-based games, you have five engineers who can debug a floor-finding edge case at 2am. On Mover, you have zero. That is a real cost.

Simple games. If you are making a third-person shooter with walk/run/jump/crouch and no exotic traversal, CMC's monolithic convenience is actually a feature. You configure a component and move on. Mover asks you to make more decisions upfront.

Migration effort: what the numbers look like

We ran a migration on a vertical slice: one playable character, seven movement modes (walk, sprint, crouch, slide, vault, mantle, wall-run), single-player + 4-player co-op, ~8,000 lines of CMC-derived C++.

Phase breakdown, actual hours:

For a full-scope game — AI characters, NPCs, vehicles, destructibles that interact with movement — multiply by 2.5-4x. Budget a calendar quarter of focused engineering for anything non-trivial.

Key finding: the animation BP port is underestimated by most teams. Mover exposes different state to the ABP (curves come through a different path, acceleration vectors live on the sim state struct instead of the CMC object). If your locomotion ABP is complex, plan for it to take as long as the movement modes themselves.

Decision matrix

Here is how we advise our clients in early 2026:

Pick Mover 2.0 if any of these are true:

• Custom movement is core to the game feel (parkour, grappling hook, wall-running, swimming as primary traversal, vehicle-like pawns)
• You have a networked multiplayer mode with competitive requirements
• You are pre-production with a 2+ year runway
• Your team has one or more engineers who enjoy reading engine source
• You want physics-backed character motion (Chaos-backend pawn)

Pick CMC if any of these are true:

• You are shipping in the next 12 months
• Movement is "standard humanoid" and not a game-feel differentiator
• You depend on a marketplace locomotion system (GASP, ALS, etc.)
• Your team is small (1-3 engineers) and new to Unreal
• You are making a singleplayer game and prediction nuance is not a concern

It is genuinely ambiguous if:

• You have 1-2 exotic moves and mostly standard locomotion. In this case, benchmark both on a throwaway prototype for a week each. The "feel" difference when implementing your weirdest move will tell you.

Integration with gameplay systems

Movement never lives alone. It couples to combat, abilities, animation, AI, and UI. Here is how each system interacts with the choice:

Gameplay Ability System (GAS). Both systems integrate with GAS, but Mover's input/state separation maps more naturally to GAS's ability-driven state changes. Applying a root motion source from a GAS ability is a Layered Move in Mover — clean composition. In CMC, it is RootMotionSource_* classes and some careful bookkeeping.

Animation Blueprints. CMC drops state into the ABP via the movement component reference. Mover exposes sim state and last-tick input through a dedicated interface. Porting a locomotion ABP means re-pointing ~40-80 variable references per character. Tedious, not hard.

AI Navigation. Both use the NavMesh. Mover's modular modes make it easier to give AI agents different movement repertoires than the player (a patrol AI gets walk+run, a boss AI gets walk+run+teleport+phase-shift) without CMC subclass explosions.

Gameplay templates. If you are using our Blueprint Template Library, the combat and interaction templates are CMC-based as of this writing. A Mover-compatible branch is on our roadmap for Q3 2026. For now, the templates provide the systemic patterns — ability dispatch, state machines, interaction volumes — and rebinding them to Mover is straightforward because they do not couple to CMC internals beyond input polling.

AI-assisted iteration. One underrated factor: debugging Mover is much friendlier to LLM-assisted workflows. The explicit sim state structs produce readable logs you can paste into a prompt and get useful reasoning about. CMC's replay-based debugging produces state transitions that are harder to summarize. If your team leans on the Unreal MCP Server for AI-driven iteration, Mover's data-oriented architecture makes it significantly more useful.

Practical setup recommendations

If you pick Mover:

1. Start from the UE5.7 Lyra sample's Mover preset, not from the empty project template. The sample has production-quality default modes you should clone and modify rather than reinvent.
2. Commit to the Network Prediction Plugin from day one. Do not try to run Mover without NPP "until you need it." The data flow assumes NPP, and retrofitting is painful.
3. Build your movement mode inventory on paper before implementation. List every verb (walk, run, crouch, slide, vault, climb, swim, grapple). For each, write one paragraph: input surface, sim state, transitions in, transitions out, animation requirements. This document is the contract between design and engineering, and Mover's explicitness rewards having it.
4. Invest in a "movement test room" — a level with ramps of known angles, platforms of known heights, moving bases, trigger volumes for transitions. Run it at every PR. Mover's strictness makes regressions more visible but also more frequent.

If you pick CMC:

1. Stay on UCharacterMovementComponent unless you are 100% sure you need a deep subclass. Many "I need a CMC subclass" problems are actually "I need a separate component that coordinates with CMC."
2. Keep your FSavedMove_Character extensions tight. Every compressed flag is precious. If you find yourself adding a fourth custom bool, reconsider whether you should be doing the logic in GAS instead.
3. Standard CMC config values that ship: GroundFriction = 8.0, BrakingDecelerationWalking = 2048.0, MaxAcceleration = 2048.0, JumpZVelocity = 620.0 for a ~1.85m character. These are reasonable starting points that most shipped games sit within 20% of.
4. If you suspect a prediction bug, enable p.NetShowCorrections 1 immediately. 80% of CMC networking issues show up here within five minutes of play.

What we are actually doing at StraySpark

Our internal stance: all new 2026 projects with multiplayer start on Mover. Singleplayer prototypes start on CMC for speed and migrate if the movement verb count climbs past five custom modes. Our Blueprint Template Library will ship a Mover-compatible branch in Q3, tracking the 5.7/5.8 Mover API. Client engagements follow the matrix above — we do not push Mover on teams where CMC is the obviously-correct call.

A worked example: the wall-dash

To make the architectural differences concrete, here is the same feature — a forward wall-dash triggered by double-tap — implemented in both systems.

CMC implementation:

1. Add MOVE_WallDash to your custom movement mode enum (in a subclass).
2. Override PhysCustom to dispatch to PhysWallDash. Implement PhysWallDash with the dash velocity integration, a timer to end the move, and a wall-collision check.
3. Subclass FSavedMove_Character as FSavedMove_MyCharacter. Add a bWantsToWallDash bool. Override SetMoveFor, Clear, PrepMoveFor, GetCompressedFlags.
4. Override UpdateFromCompressedFlags in your CMC subclass to unpack the flag.
5. Override AllocateNewMove in your CMC subclass to return your saved-move type.
6. In your character, handle the double-tap input and call a custom method on your CMC that sets the wants-to-wall-dash flag.
7. Test. Discover that the server sometimes ends the dash one tick before the client. Debug with p.NetShowCorrections. Discover that the dash velocity does not survive a correction replay because it was in a transient member and not the saved move. Add it to the saved move. Test again.

Honest time estimate for a middle-skill Unreal engineer who has done this before: 10-14 hours. For someone doing it the first time: 24+ hours.

Mover implementation:

1. Create UWallDashMovementMode : UBaseMovementMode. Define its input struct (duration remaining, target direction), sync state struct (current velocity, time elapsed), and tick function.
2. Register it with the MoverComponent.
3. Create a transition from WalkingMode to WallDashMode on double-tap input detection.
4. Create a transition from WallDashMode back to WalkingMode on duration expiry or wall impact.

That is the whole feature. NPP handles prediction because the state is already in typed structs. Corrections are typed deltas.

Honest time estimate: 4-6 hours.

This is the per-feature productivity gap. A game with 15 custom movement verbs compounds this into months.

The team-shape question

The above is the technical decision. There is also a team-shape decision nobody talks about: Mover pushes movement design earlier in the process. Because every mode needs explicit inputs, state, and transitions before you write it, designers and engineers have to agree on the movement model up front. CMC lets you iterate into a movement system — you start with walk/jump and bolt on more later.

For teams that discover their movement design through prototyping, CMC's exploratory flexibility is a real asset. You can hack in a new verb in a morning, playtest after lunch, tear it out and try another one tomorrow.

For teams that plan their movement model on paper and then implement, Mover's structure matches their process. The explicit-ness that looks like overhead to the prototyper looks like organization to the planner.

Know which team you are before you pick.

Bottom line

Mover 2.0 is a real upgrade for the projects it fits. The architectural improvements — modular modes, explicit network state, composable layered moves — translate into less debugging time and cleaner extension points. They do not translate into magic. A bad movement system is a bad movement system in either framework.

Pick based on the decision matrix, not on novelty. Ship the game. Revisit the choice on your next project.

The bet we are making: in UE5.9, Mover becomes the default template and CMC goes into maintenance mode. That is 18 months out. For anything shipping before then, CMC is still a fine answer — a very fine answer for the right project. The worst outcome is picking Mover because it is new and spending your prototyping energy on framework rather than game, or picking CMC because it is familiar and then fighting it for two years because your game actually needed Mover.

Map the matrix to your project honestly. Commit. Do not relitigate the choice every sprint.