Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have many entities on the client side that are simulated (their velocities are added to their positions on a per frame basis) and I let them dead reckon themselves. They send updates about where they were last seen and their velocity changes. This works great and other players see this work find. However, after a while these players begin to desync after some time. This is because of latency.

I'd like to know how I can interpolate between states so they appear to be in the correct position. I know where the player was LAST seen and their current velocity but interpolating to the last seen state causes the player to actually move -backwards-. I could not use velocity at all for other clients and simply 'lerp' them towards the appropriate direction but I feel this would cause jaggy movement. What are the alternatives?

share|improve this question

2 Answers 2

up vote 8 down vote accepted

For this reason, you'll find simulations are often run 1 or more frames ahead of what is in fact being rendered at given point in time on a give client. So in other words, what you render might in fact be the second last frame, not the last frame.

Search this article for all instances of the word "ahead" and I think you will start to get the picture better than I may have explained it above.

share|improve this answer
    
Okay, so are you implying I really should render the player as they were 300 ms ago and interpolate towards the future? (In a separate state, when a new state arrives; this would switch) –  Vaughan Hilts Dec 19 '12 at 4:39
    
@VaughanHilts Again, please read the article and the comments. Gaffer's an expert in that field and he explains it a lot more clearly than I can. But the general idea is that yes, your simulation model is ahead while your rendering is somewhat behind that to account for the effect you described. It not by any means the only place I've seen this technique described. –  Nick Wiggill Dec 19 '12 at 4:41

When you say:

these players begin to desync after some time

it makes me think that your issue may have more to do with your clocks getting out of step than with any latency issues. If it's latency, it should be just as bad at the start than 10 minutes in. If one game clock is running slightly faster than the other, there will be some weird jitter artifacts that will get worse and worse over time. A client could be simulating in the future, when the present packets arrive from the server, it'll pull the client back, causing entities to jump around. Run some more tests to find out.

If out of sync game clocks are indeed an issue, you'll need to look very carefully at your update loop and make sure that every update is based on the amount of game-time passed (either fixed or variable), and that the game-time is advanced using something like the wall-clock (not render time or other variables). Gaffer has some good articles on this, and there's a decent question on here talking about fixed vs variable timesteps. Hope this helps.

share|improve this answer
    
This is not the case, the case is indeed the fact that I dead-reckon too far (a lag spike or something - the packet to 'stop' is not received in time and the client cannot correct itself in time. I know this defintely the case because after the client has stopped I can most DEFINTELAY interpolate back into position. –  Vaughan Hilts Dec 20 '12 at 5:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.