So here is the thing about root motion and networking: I don’t understand how it isn’t implemented already.
I understand that hard numbers are more reliable than the progress of an animation, but why can’t we separate a loop movement animation as its own type that can be baked with movement data. The main reason I’m talking about this is because I think the solution is simple and straightforward. But let’s get to the problem.
What works in networking? Movement speed, regardless of anything else. But it only looks good if you can approximate the movement speed to the steps of the animation, or it otherwise won’t matter.
Example: A drunk walking animation, or an injured leg animation. There is no way to realistically animate it on a network as things currently are, while keeping fidelity to the appearance of the character moving across the screen.
So now to the solution: being able to choose the start and end points in a loop, and then have calculations that bake and record the movement. It takes note of the starting vector of the root at the start of the loop, as well as the vector of the root at the final frame of the loop. It will also record the total amount of time it took for the whole loop. Boom. You have distance over time. Speed. Now it will also record the difference in speed between the root animation’s local vector comparatively to where they are supposed to be if approximating speed*totalDelta. That data can be stored with the animation. Now all you have to relay is the speed for the animations (which should be baked in), but the server can relay whatever replicative variables and the location of the deltas made so that a person can better approximate where they are. Granted, uneven movement is a pain because it’s uneven, but this should be a simple solution. Even if you have animations that are used in the form of 1D/2D blending animation, if you have the speeds, the time, and delta distance, and whatever variables needed for those blending animations to blend, you should approximate where they are pretty accurately.
Now a problem obviously is ping time and synchronization. That’s why keeping track of input changes becomes important. Solutions such as smoothing within a certain range, anything out of that range just snapping, etc are still valid techniques that will help tremendously. So will sending the location of the person making the delta as well as the client’s location, upon the server receiving any kind of input update that would affect the client’s velocity. Once received by the client (who will be keeping a buffer history of their locations on their own computer), it will approximate the time distance of the update with their location to find out how long ago the player was at X point in the buffer history, then calculate the difference and make the adjustments depending on whether they are close enough in synch that it can just show the changes with some smoothing but keep track of the new (approximate) acceleration/orientation/direction.
I’d like for this to be a back and forth discussion, so let me know what you guys think, including criticisms on the entire theory.
)