Slightly jumpy ghosts - unpackUpdate + prediction/interpolation
by Jon Boy · in Torque Game Engine · 02/05/2005 (6:39 am) · 0 replies
Hi,
I've been putting quite a lot of work into the networking code on my Torque game.
The problem I've been having is to do with the 'wobblyness' of ghosts. Thats non control object ghosts (ie they get all their information from the server).
I think the problem is due to ghosts not being predicted/exterpolated suitably, because the client does not know when to predict from/to.
This contrasts with control objects. If I understand it correctly, control objects will be 'processTick'd up to the current time on the client. The ticks being any pending moves which haven't been ack'd by the server. So on a control object the client will receive a 'readPacketData' with each packet, then the control object will be predicted forwards with any 'Moves' which haven't been performed on that data by the server (because the moves haven't been ack'd).
For non controled ghosts, the client just appears to take information received as the current state and therefore time. The only trick being done in code I've seen being to interpolate from received time to the next full tick. From my tests there don't appear to be any 'pending ticks' applied to the ghosts.
So anyways to cut to the chase I think this is what gives my objects the jitters. That the latency between the server and client varies, and this being taken as the 'current' time cause the object to jump backwards and forwards.
Also there doesn't appear to be any concept of a global time, synchronised with the client and the server? If there was I could transmit the time on the server in the ghost packet, and then when I received it on the client I could predict/exterpolate it, and therefore have less jumpy ghosts.
So questions:
Is it the correct assumption that a ghost receiving an unpackUpdate does not get ticked up to the 'clients time', like controlled object ghosts do?
Is there some mechanism that solves the problem that I should be using?
Is there a 'global time' api/system? I did have a look around, but nothing seemed to fit the bill.
If there isn't a 'global time' api, is there any reason why (as it would be quite useful) - or am I missing something obvious here?
I 'spose its also worth asking about the interpolate system - in that its purpose appears to be in smoothing motion on the client. So all interpolation is just done at the 32ms tick rate. There doesn't appear to be any interpolation/smoothing over a longer period in the base api.
I have tried doing some nonlinear smoothing on the client to help solve this problem, and it does work sorta okay, although it introduces some extra lag. And I'm a bit worried that nobody else seems to be doing it in any code I've seen.
Thanks,
Jon
I've been putting quite a lot of work into the networking code on my Torque game.
The problem I've been having is to do with the 'wobblyness' of ghosts. Thats non control object ghosts (ie they get all their information from the server).
I think the problem is due to ghosts not being predicted/exterpolated suitably, because the client does not know when to predict from/to.
This contrasts with control objects. If I understand it correctly, control objects will be 'processTick'd up to the current time on the client. The ticks being any pending moves which haven't been ack'd by the server. So on a control object the client will receive a 'readPacketData' with each packet, then the control object will be predicted forwards with any 'Moves' which haven't been performed on that data by the server (because the moves haven't been ack'd).
For non controled ghosts, the client just appears to take information received as the current state and therefore time. The only trick being done in code I've seen being to interpolate from received time to the next full tick. From my tests there don't appear to be any 'pending ticks' applied to the ghosts.
So anyways to cut to the chase I think this is what gives my objects the jitters. That the latency between the server and client varies, and this being taken as the 'current' time cause the object to jump backwards and forwards.
Also there doesn't appear to be any concept of a global time, synchronised with the client and the server? If there was I could transmit the time on the server in the ghost packet, and then when I received it on the client I could predict/exterpolate it, and therefore have less jumpy ghosts.
So questions:
Is it the correct assumption that a ghost receiving an unpackUpdate does not get ticked up to the 'clients time', like controlled object ghosts do?
Is there some mechanism that solves the problem that I should be using?
Is there a 'global time' api/system? I did have a look around, but nothing seemed to fit the bill.
If there isn't a 'global time' api, is there any reason why (as it would be quite useful) - or am I missing something obvious here?
I 'spose its also worth asking about the interpolate system - in that its purpose appears to be in smoothing motion on the client. So all interpolation is just done at the 32ms tick rate. There doesn't appear to be any interpolation/smoothing over a longer period in the base api.
I have tried doing some nonlinear smoothing on the client to help solve this problem, and it does work sorta okay, although it introduces some extra lag. And I'm a bit worried that nobody else seems to be doing it in any code I've seen.
Thanks,
Jon
