Player prediction across clients, minimizing latency

Olle Håkansson · 2012-04-19T16:56:52

Hi there! I'm working on my network code and I've run into a minor snag that someone perhaps can help me with. I went with the Quake 3 network model and I've used Gabriel Gambetta's excellent blog posts as a reference when implementing the finer points such as server reconciliation. However, there's a situation that occur when there's more than one client in the picture. Lengthy example ahead: Say that Client A runs three frames, then decides to send an update to the server. I.e, three input structures are sent to the server. The server receives the update after a few moments, say SendTime(Client A) or ST(A) time units later. The three inputs are queued for Client A for three server update ticks in the future, meaning that the server will be fully up to date with the client after ST(A) + 3 ticks. This is all fine and dandy, since Client A's prediction and server reconciliation will hide all this latency for Client A. What bothers me is when Client B enters the picture. One could argue that he should be able to know Client A's newest position after ST(A) + ST(B) time units, but if the system is implemented exactly as described above, the input may not show until ST(A) + ST(B) + 3 ticks. This is because the server would have to update the state in order for the input's effect to show. Exactly how much delay Client B would experience also depends on how often the server sends updates. My question is, do I have a fault in this design or is this how it usually is? One improvement I can see now would be for the server to send over A's remaining inputs to B when doing an update, letting B predict some of A's "future" inputs also. Another thing to try out would be to let Client B just extrapolate A's previous input until the server sends fresher updates. Any more takes on this?