   Timing issues with client movement
  I'm trying to figure out how to keep the client's own player movement synchronized with the server without making it feel less responsive, and I'm hitting a wall. If the player has a 50ms ping to the server, and the client game is always interpolating over the last 50ms of server updates, then you automatically have a 100ms difference between what the client sees and what the server knows.The problem is, the client game is also immediately reacting to local player input. So we have new player input being combined with 100ms old world data, part of which includes the location of the current player, 100ms ago. How do you prevent the local player from being snapped backwards every 100ms to line up with where the server says they should be? I don't see how you can interpolate between world states of the local player when the local player is making it up as they go, and may have made significant directional changes in the last 100ms.Obviously current multiplayer games don't suffer from this problem, so what am I missing? Where does local player input get applied in the stream of interpolated server updates?   
  Keep a record of where the player has been in the last second, and when you receive an update, if the client position for that time is close enough to the server position for that time, don't snap the displayed client avatar. If the update is far enough separate from the record, then snap the avatar.   ;  Ah I see, I didn't think of keeping a local player history to compare to the server update. When you say to snap if the difference is too far, I assume you're not JUST snapping to the server position, but realigning that point in the local history and then reapplying everything that came after, to guess at where the server thinks they are now?And this is how it's usually done? I keep thinking there would still be differences between where the server thinks they are and what all really went on on the client to cause some continual snapping, but I suppose that is just a matter of the quality of the data sent between the client and server?;  Actually, when I say "snap" I mean throw away everything that happened since the server update, stop applying user inputs, and move the player to the position in question. A "snap" would be disruptive enough that you're probably better off teleporting and getting in sync for real, than trying to apply control data based on a false image of reality.The theory is that snaps should happen unless you have edge cases in collision, differing versions of level data, or actor/actor interactions that can't be resolved on the client.