I'm currently working on an online game and basing my networking architecture around this Source Multiplayer Networking article. However, I'm a little stuck on how the user input works. The article describes that a snapshot of the keyboard/mouse state is sent from the client at the same tick rate the server is running. I am doing this in my game, which seems to me working pretty good, but the simulation on the server is slightly different then the client prediction resulting in the clients player eventually becoming out of sync with the server. I believe this discrepancy is a result of ping jitter.

For example, if the client is sending input every 25ms, theoretically if the server is receiving input every 25ms it will have an identical simulation. However, with any jitter, the server might not receive any input for 30ms for example. This means it will not be able to process the input until the next tick because it didn't arrive on time, and the entity on the server will become out of sync with the client eventually.

What are some methods for solving this issue? Maybe I'm missing something in the Source Multiplayer networking example. If anyone could explain better or provide any advice it would be much appreciated.


  • \$\begingroup\$ jitter means that at one point a packet takes 20 ms to reach the server while another packet might arrive after 30 but the next might arrive 10ms right after, so on average this will even out \$\endgroup\$ Commented Aug 27, 2013 at 8:14

2 Answers 2


The general gist is that you have two concepts of "state".

  • Local state (your client)
  • Ghost state (the server)

You take input from your client, and update your local client state (and send this to the server). You then "predict" what happens to everyone else, assuming some amount of spatial consistency to last frame.

When you get information from the server, you update the "ghost" state. This is effectively the authoritative state of the world according to the server (n ms ago)

What happens next is that you end up always lerping your "local" state towards the "ghost" state. If the differences are beyond a certain threshold you can snap players into position, but in most cases the visual discrepancy to their actual position will be acceptable. Whether you perform authoritative actions against the local, or ghost state is up to you, but these days I think things such as hit detection are done on ghost position.


I ended up solving this based on a few things:

Firstly, I made the mistake of predicting input on the client based directly off the keyboard. I changed it so the client predicts movement based off of keyboard states it sends to the server (every 25ms). This gives it a much more accurate prediction.

Secondly, I previously had the server simulating players based off the latest input received. I've implemented a queue of input so the server will simulate all input that hasn't been processed yet, instead of only simulating the latest input snapshot.

As of right now, the client prediction is pixel perfect with the server simulation which is what I was aiming for.

Thanks to anyone who provided input/suggestions.


You must log in to answer this question.

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