I am a newbie game developer and I have been researching about multiplayer games. I observed that there's always some latency, the players always get updates from past actions. But there are techniques like dead reckoning to handle the latency. I can predict the movement and make movements smooth. But how would I make actions synchronize like jumping, stopped walking, etc.

Suppose, client A was moving, he was at 100m at 10.2 time with 100m/sec velocity and sended this information. Client B would receive this information somewhat later, let it be 10.4. So at client B, I can use prediction and place client A at 120m. But what if, client made a jump at 110m at 10.3. I can't predict that and since I have been using prediction I can't show client A jump in past.

I may deal with this problem by not sending jump action at all. But what if my game has some voids where players can fall and die. So, If I don't sync jump actions, other players will observe that one player was running then he falls in void and then again appear on the screen destroying the visual engagement.

Jump is just an example, there might many scenarios where prediction can't work. So, How do deal with them. One such example can be Multiplayer Online battle arena games like Awesomenauts.

  • \$\begingroup\$ I don't know much about Multiplayer, so I won't be able to give a proper answer. But from what I've picked up, the ideal setup would be that your clients would be more or less dumb and only send keyboard, mouse, gamepad or whatever input to the server, and the server does that whole movement and world updating stuff and sends positions and all other relevant data back to the clients, which then display the result. This all but eliminates prediction and similar things. \$\endgroup\$
    – Christian
    Commented Jul 30, 2013 at 9:59
  • \$\begingroup\$ @Christian hey! thanks for the reply. I know about this approach but this can make gameplay jerky if the latency is high and moreover I use AppWarp's BaaS realtime system, so my all logic lies at client side only. \$\endgroup\$ Commented Jul 30, 2013 at 10:05
  • \$\begingroup\$ Combining both of your methods is the authoritative server. Clients and server both simulate, clients send their input, server sends back the authoritative state. Clients adjust their state to match authoritative state. So, when states match up, the clients run like they're being simulated locally (no lag). \$\endgroup\$
    – House
    Commented Jul 30, 2013 at 14:37
  • \$\begingroup\$ i recently found this tutorial series to give good tips on managing latency, it seems like it would be relevent to your interests: link \$\endgroup\$
    – Kris Welsh
    Commented Aug 2, 2013 at 2:22

2 Answers 2


Dead reckoning may not be the best idea in this case; you should do entity interpolation (effectively rendering the other players in the past, which always gives you real, valid positions). I've written about this with much more detail here. Whether or not seeing players slightly in the past is acceptable or not depends on the details of what you're trying to do.

  • 4
    \$\begingroup\$ I used this approach when writing my first networked multiplayer game. In fact I used @ggambett's as reference. It worked well for me. \$\endgroup\$ Commented Jul 30, 2013 at 16:36

There is a fairly detailed write up regarding the source engine. It would appear some of the relevant source code is also available as part of the Source SDK.


It uses a number of techniques to try and deal with network latency in a server-client model. The main point seems to be that the local client handles input and other events locally as if there was no server, and then deals with the possibility the server says the client did it wrong later.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .