Gut feeling/sanity check on a locomotion system implementation

So, with my current project, I am at the point of working on a locomotion system.

(Which is, of course, generally at least a little bit of a pain point even at the best of times.)

My previous locomotion system was based entirely off of root motion animations, and thus cannot really be applied to a game that is inherently multiplayer; even if Unreal would let me replicate root motion movement, it feels to me like that would be a very bad idea for any sort of reliable/smooth/unable-to-be-abused network locomotion system. So, this means starting from ground zero. So long as I’m doing that, I’ve decided I want this locomotion system to be fairly reusable, i.e. suitable for both multiplayer and single-player games.

(In no small part because then I can have just one locomotion system I maintain and tweak and improve going forward. Yay, code reuse?)

However, I’m finding myself mired down in making a couple of decisions, so I’m curious if folks have experiences to share that might help inform the choice I make.

In particular, it’s the gait transition that I’m mulling over. I have three gaits: “walk”, “jog”, and “run”. Fairly standard. For keyboard/mouse, it’s easy enough: if you push forward, I can start with the ‘standstill to jog’ animation, because I know you’re accelerating into a jog. If you have the sprint/run button down when you start, I can start from standstill to run. If you are jogging and hit sprint, I can kind of make do since I know you’re going to be accelerating to a minimum of a given speed.

Where the issue comes in is for the walk → jog portion when you’re using an analog axis input; first off, I have no walk-to-jog transition animation, and moreover there is (unsurprisingly) a gap between the movement speed of the walk loop and the movement speed of the jog loop. Now, I can obviously take the axis value when the character starts from a standstill, and if it’s past a certain point just start with the ‘jog’ animation rather than ‘walk’.

But that leaves the obvious case where someone pushes the stick forward only enough to walk, and then pushes the rest of the way to jog once already walking. That wasn’t so much of a problem in the root-motion system (for various reasons, but mostly coming down to “the game for which that system was written did not support analog input”). Obviously, it’s a bit more of a consideration here.

My initial gut feeling is that I should simply write an editor plugin that slurps in the existing root motion animations, calculates the various curve tracks et al (“movement speed”, “turn angle”, etc.), and writes out new in-place animations with the appropriate metadata for something in the neighborhood of the animation logic that the Windwalker Echo demo uses. And that then I should basically cap ‘walk’ at the maximum movement speed of the walk animation sequence (rather than just accelerating the ‘walk’ animation past the 1.0 play rate until you hit job) and then only transition to jog when you would hit the baseline ‘jog’ speed.

(Before anyone asks, yes, I’m aware of the Root Motion Extractor plugin in the marketplace. It’s pretty cool! But it doesn’t quite give me all the data I’d want, thus I suspect I need to write my own solution which will.)

However, I also have this sneaking feeling there’s a gotcha there in replication which I’m seeing only unconsciously and can’t quite drag out of the back of my mind into the light of day.

So I suppose, in addition to “am I right about my gut feeling of a pain point, or just overthinking this”, my other – and more broad – question is “Have folks hit on a better method of handling the shift between movement gaits when dealing with in-place animations and network replication than the one I’m likely about to start implementing?”