motion matching feels like magic but is it actually feasible outside of AAA

the GDC talks consistently undersell how much work goes into authoring a motion matching database that actually performs well. the algorithm is elegant but you still need enough motion variety that the system has good options to match against, and capturing, cleaning, and tagging that data at any real scale is not trivial. the ue5 demos look seamless because they're backed by enormous capture budgets. for a small team i'd pick one specific locomotion problem to solve with it rather than reaching for it as a general solution. walk/run with good blending? totally achievable. full-coverage locomotion plus combat plus environmental reactions? that's where the database scope quietly becomes the whole project.

Something that hasn't come up in this thread and bites almost everyone rolling their own: feature vector normalization. When building the pose database, the raw numerical scale of your features matters enormously. Joint positions in world units, joint velocities in units/sec, trajectory directions as unit vectors. Completely different scales. Without per-feature normalization to zero mean and unit variance, the matching silently over-indexes on whichever features happen to have larger raw values, regardless of what weights you set.

The fix is mean/variance normalization baked into the database build step, with per-feature weights applied after normalization. The reason this doesn't come up in GDC talks is that most AAA implementations have it handled at the engine level and presenters just don't think to mention it. If you're rolling your own and tuning weights seems to do basically nothing, that's almost certainly why.

One thing the AAA framing tends to obscure: motion matching doesn't have to cover the whole body. Locomotion-only with a hand-keyed upper body layer is actually pretty manageable. You're covering walk, run, stop, and turns, maybe 8–12 minutes of clip data if you're disciplined about coverage, and the upper body handles all actions separately through the animation tree.

The database size scales with locomotion variety, not with every action in your game. Once you frame it that way it stops feeling like a AAA problem. Still non-trivial to implement, but it's not "we need a team of technical animators" territory.

The data requirements question is worth unpacking, because the AAA framing really does warp the perception of what's actually achievable. Daniel Holden's original motion matching write-up benchmarked the brute-force nearest-neighbor search at around 1000 poses and it clears 1ms on a single CPU core with no spatial indexing at all. The algorithm isn't the expensive part at indie scale. It's the motion database, because you need variety of transitions, speeds, and directions to cover your game's movement space, not just raw clip volume.

For a single character with a bounded locomotion set (walk, jog, stop, turn, idle), a functional dataset is achievable in a structured day of capture. The genuinely hard part is defining feature descriptors that match your game's specific movement style and feel. That takes iteration and there's no shortcut I've found for it, but it's an animation and design problem, not a budget problem.

Feasible outside AAA, but the data requirements are the real barrier, not the algorithm. The core matching loop (pose + trajectory feature query, nearest-match search, crossfade to result) is actually pretty approachable. Daniel Holden's blog series covers the math clearly, and there are standalone Godot and Unity implementations on GitHub worth reading through.

The hard part is that motion matching needs dense, continuous coverage of every locomotion state, because it's literally searching your capture library. AAA databases run into thousands of seconds of mocap. You don't need that scale for an indie game, but sparse data produces jarring nearest-match transitions and the magic evaporates quickly.

Practical middle ground: use motion matching for the locomotion loop where you have solid coverage, fall back to traditional blendtrees for everything else. The seam between the two systems takes some work but it's manageable, and the locomotion feels noticeably better even with limited data.