Jump to content
  • Advertisement
Sign in to follow this  

snap-back synchronization?

This topic is 2175 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

so... i send position+state(left/right/forward/back keypress bools) updates at 30 Hz ... so between two received packets, the client extrapolates movement using the local client timestep for smooth non-jittery movement...
the problem comes when the next position update packet comes in, and it doesn't match the interpolated position...
so with this issue, the "real" and "extrapolated" positions could be as much as or more than a body's distance away... so i can forsee obviously running into tweaky issues when testing multiplayer
since the positions are different like you could be standing there and the guy shoots a rocket 5 feet to the left of you but it still hits you
or on your screen you shoot a rocket 5 feet to the left of the visible render and still hit it. or shoot directly at it and not hit it
i came up with a small temorary solution, which i wouldn't be surprised if it was "at good as it gets" and commercial stuff even does
basically, the rudimentary thing to do, if you wanted proper synchronization is to "snap" to the "real" position when the state is zero (no movement)... but that looks bad because it just "jumps" that 5 feet in one single frame
instead it extrapolates through the difference vector (real vs extrapolated position) until the distance is within an epsilon (body width)
it's not horrible, but still slight movements when they're not actually existed
kind of displayed here (mainly towards the end/second half/after second 6)
any idea of a better solution?

Share this post

Link to post
Share on other sites

This is the base trade-off in networked games. You either show predicted positions, and predict wrong, and have to "hide" it, or you show positions only when you have all the information, which means you show them "late."


One useful way of predicting is to not predict only on the given data, but instead, predict where the character will be when the next packet comes in, and interpolate between whatever the current position is, and that next-predicted position, over the time until the next packet arrives. Then, when the next packet arrives, predict where it will be when the next-next packet arrives, and move the character to that position over the next time interval.


The EPIC library (entity position interpolation code) implements this forward-prediction model, and shows that it's pretty smooth: http://www.mindcontrol.org/~hplus/epic/

Share this post

Link to post
Share on other sites

What you describe sounds like the client is only interpolating between packets of data received from the server.

With such an approach smooth movement is hard to achieve:

1. Due to network latency, data displayed on the client side is never up-to-date. The client "lags".

2. Due to network latency, the packets don't arrive at perfectly regular intervals. Latency will cause "jumps" in your movement animations.


The better solution is to implement client-side movement prediction, as hplus0603 pointed out. With a good movement prediction algorithm, corrections will happen rarely.


Here's an article that explains the whole issue very clear and from a high level perspective:



Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!