In the previous blog post, we learned how one should plan and build the game architecture to reduce the network load and to use network resource in a more optimized way. It particularly talked about the game physics involved in multiplayer games.
But incorporating physics in multiplayer games, leads to another challenge and probably the biggest challenge i.e. synchronizing the game physics.
The reason this challenge arises is the fact that every network struggles with some latency. You might install the best servers and use optimized network algorithms like we did in AppWarp, but you can’t guarantee the same quality of network on client side e.g. the client may be running on slower networks like 2G or dial-up or may be they are geographically far away from the server etc. Therefore, different users might get same information at different instants of time e.g. different players might see the same player at different positions while the actual player has already moved on to a new position.
Take a look at the following figure:
In the above figure, information sent at instant t by Client A arrives at instant t’ at Client B, hence client B always gets the information about client A that happened in the past. Similarly, client A gets past information of client B.
You can not remove this latency but you can compensate it using some techniques. Here, we will be discussing about the client side prediction techniques. As the name describes itself, client side prediction is about predicting the position of a player at client side. The classical client side prediction was done to predict one’s own position in authoritative servers where one has to wait for the server to validate his action but we can easily extend it to predict other player’s position in BaaS multiplayer game engines.
One popular prediction algorithm is “Dead Reckoning” (also ded (for deduced) reckoning or DR) is the process of calculating one’s current position by using a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time, and course. (Source: Wikipedia)
Suppose Client A sends his position
x(t) = x + v(t)
at instant t
This information arrives at client B at instant t’ but till now client A has already been moved to
x(t’) = x + v(t’)
If client B places client A in his simulation at x(t), it will not be correct; hence client B should itself predict the new location of client A by using the velocity and time difference dt = t’-t. The new position predicted is
x(t’) = x(t) + v(t’-t)
The time difference is the round trip of the message i.e. the time taken by the message to travel from client A to server and then from server to client B. The latency is calculated as half of this round trip. Hence, latency becomes an important factor in multiplayer games to synchronize all the physics across the clients.
There are two basic ways to incorporate latency in calculating physics, one way is to send timestamps in your message. So, at client site you can easily calculate the time difference but the clock should be uniform across all the clients and server. Another and a better way is to calculate the latency and send it with the message. Every message(request) sent by the client to AppWarp triggers a callback response. You can easily calculate your latency by halving your message’s round trip time, and then sending that latency with your next message. When this message arrives at another client, he might have also been calculating his latency, so the actual time difference at client B will be the latency of client A received plus the own latency of client B.
This way you can synchronize your game physics. Hope this article helped you.If you have any questions or need any further assistance, please feel free to write us at firstname.lastname@example.org