Replicating Player Animations - Keith Babcock

The Problem:

At the beginning of this week's sprint our player's replication was all out of order; sprinting for the client could only be seen on the host, all movement couldn't be seen by the clients, aiming was out of order, no one could see shooting animations or specialty animations like reloading. The key to replication is to move as little information over the network as possible as infrequently as you can get away with, so just copying all bone positions from the client, to the host, and then back down to the other clients isn't going to work. To get around this we have to send the variables that trigger animations over the network, however some of them have to be updated every frame, some only happen once in a while, and all have to take different paths depending on if the signal is coming from the client or the host, and how do we get around the host having an advantage over the clients when it comes to seeing their animations?

The Solution:

When it comes to replication, every challenge more or less needs a bespoke solution to achieve as much of an impact as possible as cheaply as possible. When it came to updating the look rotation of the player while aiming, we send a new look rotation every frame we've moved our camera only when the rotation has changed beyond a degree. For the more sporadic pieces of data like a boolean that tells the animator whether or not the character is sprinting we simply need to send that data on change when it happens. To get data from one client to the others it has to go to the host server who then disperses the information back to the client, whereas if a player is the host they only need to multicast to the other clients. Because there's inherent latency when sending anything over the internet, anything that happens visually on a player's button press, such as animations, can't come from over the server, so the data has to take two paths simultaneously, one to the server and to the other clients and the other is straight to the animator to update the client's own animator in real time.

There are many more fringe side cases like when to use replicated variables versus RPCs, how to get the most efficiency out of what were sending, and what information we can get away with being unreliably sent, but overall, the results speak for themselves: both the client and the host can see each other animate, and it took a good 8 hours to do it.