More studios are adding online components to their games every year and many game programmers do not have networking experience. Some studios have dedicated multiplayer teams that are responsible for networking all features of the game, regardless of whether that team implemented the initial feature. This may come as a shock, but it is my belief (and practice at High Moon Studios) that every game programmer should be responsible for ensuring their mechanics and AI work over the network. Understanding how player motion works in a network environment is important so that mechanics can be designed with networking in mind. Over the next few posts I will explain how player motion works in a client-server architecture for fast paced games. Part 1 will focus on laying the foundations for basic player motion and how to handle common problems encountered due to latency. In writing this post I’ve found that explaining player motion to people in a room is much easier than in a standalone document. I’ve done several presentations on the subject at work and going through the steps interactively yields the best results. Network traffic combined with player motion is complicated to diagram. I hope that the images and animations provided will help assist the reader in the learning process.
There are many different types of network transport level problems that can have an effect on player motion.
- Lag): This is the travel time of packets between the client and server, we will always have latency so we need to get used to dealing with it.
- Jitter): Packet latency is not a constant, it fluctuates over time which can wreak havoc in online games.
- Packet Loss: Dropped packets means missing information, typically we can expect about 2% packet loss.
- Out of Order Delivery: Receiving packets out of order can lead to tricky problems, many engines handle this for the user by buffering until all have been received (reliable delivery), or disregarding a packet that has been received that is older than the most recent packet (semi-reliable or unreliable delivery).
In a client-server architecture the server is traditionally the authority over all player movement. A straightforward approach to player motion in this type of environment is to send input to the server, have the server perform the move, and send the results back to the client to perform the same move locally. This results in a lag between the player’s input and the actual movement of the player. In a typical network environment you could be waiting over 100ms between input and movement, which is clearly unacceptable for fast paced games. The communication pattern is shown below:
The animation below shows what the user experiences in this motion model. On the left is the client’s view, the server’s view is on the right. Important Note: The animations will only show important moves where motion changes (start, stop, turns) instead of messages every frame which would be a bit confusing to look at.
QuakeWorld to handle movement in high latency environment. The technique allows the client to respond to input locally and predict movement instantaneously instead of waiting for the server to send a response. The client’s move is sent to the server which then performs the same move and verifies the results, sending the client the updated state.Now we are in a state where the server needs to correct the client’s location to match his. There are several techniques for handling this type of scenario.
- Teleportation: Pros: The client is in the correct location. Cons: The user just experienced a discontinuity in his motion and view of the world, which can be disorienting. This technique is also referred to as “rubber-banding”.
- Interpolation: Pros: The client smoothly moves towards the correct location over time avoiding discontinuities in motion and view of the world. Cons: Since the client is not in the correct place, additional moves will still be incorrectly predicted and cause more corrections to be handled from the server.
What is the best option to use? The answer is often times, all of the above. If the delta is small then interpolation might be the best method of correction. However if the delta is sufficiently large then a fallback might be to teleport immediately to get the player back into a good state for future prediction. These techniques are potential solutions for a player that has stopped moving, but what happens when a correction happens while the player is still moving? The next example shows the change direction move being delayed, causing the server to overshoot the turn point, leading to a different end point. Now we have a major problem, the server receives the change direction move, simulates the move, and determines that the client is in the wrong position and sends a correction. The client receives the correction at a point in time much later along his path. Now the fun begins. The approach used in the previous example breaks down immediately. Let’s try teleporting the player to the corrected location at a previous point in time.
The resulting location delta is much smaller and now we can use either teleportation or interpolation to get the client back to the new predicted location. We have now laid the foundation for basic player motion in a network environment. There is a lot more to cover including complex motion (jumping, dodging, special moves, etc.), collisions, predicting motion of other players, animation, physics, controlling vehicles, optimization, etc. Please feel free to suggest improvements to the post and ask questions. I love talking about network gameplay and am more than willing to tweak this post to help clear up any confusion.
Acknowledgements
I’d like to thank the programming team at High Moon Studios for their help in constructing and refining the text and media for this post.