Our team is evaluating GASP 5.7 as the foundation for our upcoming title. We noticed that while Locomotion Setup 0 allows for a “Pure Motion Matching” experience (where one large Chooser/Database handles Starts, Stops, and Loops implicitly), the default GASP architecture relies on a State Machine to explicitly drive these transition states before handing off to MM for the loop
In our testing, switching to Setup 0 (Pure MM) feels nearly identical to the default Hybrid setup for basic locomotion. This raises a critical question about asset volume and complexity.
Is the GASP “Hybrid” (State Machine → Chooser) model strictly a Quality of Life feature to guarantee responsiveness (e.g., forcing a “Start” state vs. hoping the MM node selects it), or is it a necessity for Data Efficiency?
Going forward, is the recommendation to treat Motion Matching primarily as a “Loop/Cycle Solver” inside a traditional State Machine, rather than a “Whole Locomotion Solver”?
We want to avoid building a pipeline that relies on the “Pure MM” dream if the reality is that we will eventually need to rebuild the State Machine layer to regain control over transient actions like Stops and Pivots.