Have you ever wondered how networked games actually run on different machines and how they communicate with one another? Some of the possible rookie mistakes, and one I was guilty of, is that we think that there is this online virtual world that we all go to, and we just render its graphics in our machines. Although this is the case WAY back then, this isn't how networking games are developed now. Synchronization is a pretty complex problem in games because players must be assured that despite their location or internet speed, they should approximately have the same game state at the same time as the other players.

What usually happens with most games now is that you emulate the 'real game world' in your own machine, and each client runs the same set of processes.

Let's assume that there are 4 players, namely Player A, B, C, and D, in our following examples. If Player A does an action (say, moves a unit to a specific location), a message will be sent from Player A to the Server, then the Server will send the message to all other players so that they can emulate Player A's actions.

Do you see the problem now?

Players B-D will only receive Player A's move action a few milliseconds after, therefore causing a delay! This is because sending packets/messages over any network is not instant. Of course, 10 milliseconds doesn't really matter, but there may be hundreds of events per second, and these small delays will add up to become a very noticeable one.

Several algorithms/techniques are available to address this issue, and Dead Reckoning is one of them.

Dead Reckoning, in the context of networking games, is a synchronization technique that uses a function of the difference of the time the message is sent and the time that message is received to predict the new location/state of the object(s) affected.

Nosebleed? In layman's terms, the receiving player adjusts the speed or magnitude of the action based on the delay or the time difference between the time the message is received by the receiving player, and the time the message is sent by Player A.

For example, an arrow that Player A fires will travel at a normal speed for Player A. Let's say Player B received the message 0.5 seconds after. Player B will emulate Player A's arrow at an increased speed so that the arrow will hit the target at the same time, even though Player B received the message with a delay of half a second.

For every game, there will be a different set of special cases and things you have to catch when objects don't get synchronized. Different games also apply different physics libraries and collision detectors, among other things.

Therefore, learning the theory of Dead Reckoning or other synchronization techniques i necessary in order to implement a localized version of it in your own game.

Synchronization is a vast topic with so many things to consider, and I cannot discuss them all, nor do I perfectly know them all. If this article strikes your curiosity and leads you to study more on this topic, then I believe that I have done my job. Go forth and learn!Readability Is The Way To Go.