Hi, I have a question in response to this article from Gamasutra (Dead Reckoning: Latency Hiding for Networked Games - http://www.gamasutra.com/features/19970919/aronson_01.htm) about dead reckoning. I tried to email the author but it got bounced back as an invalid address - to which I'm not totally surprised given the age of the article. I was hoping that someone here could help me out with the questions I had about it. With regards to calculating the updated positions using the dead reckoning algorithms shown, what are the intervals that these dead reckoned values are calculated for? What I mean is, is the position update algorithm (let's say #3) used every frame for the new position, or is there like a 1 second lookahead with the DR algorithm, and then the actual frame-to-frame position is interpolated between the current and DR position? And if the DR positions are being calculated every frame, how then is smoothing used to adjust the position of the object? The way I'm thinking about it, is if my plane (to follow the example diagram) is off by 6 metres to the left of where it should be, and my updated position is the current position of the actual plane... wouldn't I be just moving myself sideways if I was going to try to smooth between my current position and the 'correct' received position? Any help will be greatly appreciated, David

Thanks hplus,

So - if the positions being used are the dead reckoned positions, my time delta for the DR alogirhtm is then the fraction of the second between frames, right?

If my positions starts to sway off course, with the network delay, won't I run into a situation where I'll step backwards a bit, since there position I'm getting will be slow?

But as you say, I guess how acceptable those kinds of jumps are are application dependant.

Thanks,
David

It's been a while since I've read that and I don't remember my gama login so I hope I don't repeat what's already in there.

It also depends on how the object is moving and the rate at which you send out updates. So if you have something that is constant velocity and heading ( maybe like a passenger jet ) then you only need few updates. If, however, you are a fighter jet making many movements and velocity changes you need to ramp up the rate at which the server sends out the DR data in order to keep things in sync.

The 'jump back' problem exists in almost every multiplayer game and its up to you to figure out how much is acceptable. By having some smart client prediction and a variable correction rate you can reduce it to be 'reasonable' :)

hplus: So in DIS - how far are you extrapolating? Is it only as far as the next position?

acraig: You mean if it's more of a constant motion, you can extend the look ahead time (the DR position and then move to it) or you mean since it's not really doing anything fancy, the DR positions will have less chance of being incorrect?

I figure that as something starts to turn and move around quickly the updates will become harder to predict. I'm still just trying to wrap my head around what the updates are doing for me - calcualing every step or calculating assumed larger steps that I can move towards and using easier calculations to get there.

Thanks!