[Proposal] Layered Hybrid Locomotion Architecture

[Proposal] Layered Hybrid Locomotion Architecture (State Machine Base + Contextual & Action-State Motion Matching)

Core Objective:

Eliminate procedural input delay during high-precision mechanics (building, boxfighting, editing) while leveraging Unreal Engine 5’s Motion Matching (PoseSearch) exclusively for complex, contextual actions—such as moving while healing, parkour wall scrambles, and environmental physics transitions.

Technical Breakdown

1. Core Ground Locomotion (State Machine Base)

  • Function: Standard standing, sprinting, crouching, strafing, building, and weapon editing run on lightweight Animation State Machines.

  • Impact: Restores instant, frame-one WASD input response, removes unnatural strafe velocity penalties, and optimizes single-core CPU overhead for stable 1% low FPS.

2. Action-State Motion Matching (Healing While Moving)

  • Function: The moment a player activates a consumable (e.g., Medkit, Shield Potion) while walking, the animation system dynamically swaps from the State Machine into Motion Matching (PoseSearch).

  • Why This Works: Moving while healing is inherently a slower, tactical state where procedural weight, realistic footplanting, and torso turns enhance gameplay. Because building/editing is disabled during item consumption, procedural inertia does not compromise input precision.

  • Exit Logic: The exact frame the healing item finishes or is canceled, the animation engine seamlessly blends back into the Layer 1 State Machine for immediate combat readiness.

3. Contextual Traversal Motion Matching (Wall Scrambles & Parkour)

  • Function: Trigger PoseSearch procedural blending dynamically only upon contact events (e.g., raycast detection for wall scrambles, ledge grabs, or mantling).

  • Exit Logic: The moment the player completes the wall scramble or kicks off the surface, control instantly reverts back to the State Machine to ensure crisp landing control.

4. Physics Overrides (Chaos Engine Ragdolls)

  • Function: For knockdowns, explosions, and hill rolls, disable animation evaluation completely and hand the skeletal mesh directly to Chaos Physics.

  • Impact: Offloads CPU animation calculations to native GPU physics, delivering natural ragdoll visuals without impacting main thread frametimes.

Value Proposition for Epic Games

  • Preserves Competitive Integrity: Gives Battle Royale players the high-precision, low-latency movement required for high-level building and boxfighting.

  • Showcases UE5 Innovation: Maintains visually impressive engine features—like moving while healing and realistic parkour—by using Motion Matching where it actually enhances the experience rather than hindering it.

  • Cross-Mode Standardization: Allows UEFN and platform modes to share the exact same character pipelines, enabling high-quality asset compatibility across the entire ecosystem.

Not really sure about this tbh.

You already have upper body blending possibilities for gameplay (e.g. healing). You can also swap within a State Machine or a MotionMatching setup itself for macro anim stance changes.

There is already an experimental State Machine + MM (BlendStack) example in GASP. If you want to use that, you can.

Thanks for the feedback

To clarify my original thought on moving while healing: I agree that swapping the underlying animation system over to Motion Matching (PoseSearch) just for a walking-while-healing state is unnecessary over-engineering.

A much cleaner pipeline—and the core of what I’m advocating for—is keeping the entire ground locomotion layer (Standing, Walking, Sprinting, Crouching, and Healing-while-moving) strictly on Animation State Machines.

  • Why State Machines for Walk/Sprint: Sprinting and walking are deeply tied to combat, building entries, and piece-control. Keeping both on State Machines (using Distance Matching and Sync Groups to prevent foot sliding) guarantees zero input latency, no procedural trajectory lag, and rock-solid 1% low FPS. Upper-body layered montages (spine_01 masks) handle the item consumption seamlessly over the legs.

  • Where Motion Matching Belongs: Reserving PoseSearch strictly for contextual contact events—like wall scrambles, ledge mantling, and steep terrain sliding—where procedural alignment to complex geometry adds high visual fidelity without compromising frame-one WASD responsiveness during boxfights.

  • keeping the entire ground locomotion layer (Standing, Walking, Sprinting, Crouching, and Healing-while-moving) strictly on Animation State Machines.

Yeap, I would agree with that. “Healing-while-moving” could very easily be just an upper body blend and you can use walking/sprinting/crouching as your “stance”. But if you have a “healing-while-moving” stance library, go for it

  • Where Motion Matching Belongs: Reserving PoseSearch strictly for contextual contact events—like wall scrambles, ledge mantling, and steep terrain sliding—where procedural alignment to complex geometry adds high visual fidelity without compromising frame-one WASD responsiveness during boxfights.

I would not agree with that. Motion-Matching shines (in my view) where it can take the inputs of character-specific states (current pose, current movement & future movement) and blend really nicely into relevant animations. It is not really designed for non-character specific lookups.

You mention “procedural alignment to complex geometry”; I would suggest IK & FKIK methods, including maybe an advanced control rig setup for that. Not motion-matching.

But you could totally have a Motion-Matching base plus additive layers that have control rigs / FKIK stuff. Be aware though that is an advanced setup, high reward but high effort as a developer. Choose carefully!

Unless it is a core mechanic or you are a AAA development team, be mindful.