Client Prediction Whipping
Hello again. First and foremost I would like to deeply thank everyone on the forum for the great advice thrown my way as I work on my senior project. The engine has come a long way over the past month and I owe most of it to people like you guys who are willing to create this great learning environment on the forums.
Ive reduced most of my lag down to acceptable and there is only one major issue that im encountering at the moment. Currently I send keystate information to the server and the server relays back positional information every so often. The problem that I am having is that when a key is pressed, for example the key to move left, By the time it is sent to the server a packet or two is recieved from the server that does not reflect the recent keypress. This creates a whipping effect when trying to change movement direction. I have synchronized timers on the server and client so I tried disregarding packets that were sent before the movement direction occured but it only seems to make the problem worse.
Basically if I move a character in a constant direction with no keystate changes it looks smooth, but when direction is changed I can visually see the character whip around a lot.
If anyone has any suggestions I would be greatful.
Thanks,
Daniel Doptis
Quote:
By the time it is sent to the server a packet or two is recieved from the server that does not reflect the recent keypress.
Sorry, but I don''t really understand. By following up the suggestion that those guy gave you in the previous thread, that wouldn''t cause much problem no? Esentially, you will just keep sending the action (or action changes) of the player to the server, and the server will always update you with the current game state intervally. So in your case, the packet that the server send to you might be the state resulted from the actions that the player took a moment ago. If you consistently update the your local state based on what the server send you, and with some extrapolation to smooth out the in-between states, that won''t cause any problem, isn''t it?
Call me stupid if I missed out something. I am new here.
By the time it is sent to the server a packet or two is recieved from the server that does not reflect the recent keypress.
Sorry, but I don''t really understand. By following up the suggestion that those guy gave you in the previous thread, that wouldn''t cause much problem no? Esentially, you will just keep sending the action (or action changes) of the player to the server, and the server will always update you with the current game state intervally. So in your case, the packet that the server send to you might be the state resulted from the actions that the player took a moment ago. If you consistently update the your local state based on what the server send you, and with some extrapolation to smooth out the in-between states, that won''t cause any problem, isn''t it?
Call me stupid if I missed out something. I am new here.
![](smile.gif)
Thomas CheahTechnical DirectorBad Nose Entertainment - Where games are forged from the flames of talent and passion.http://www.badnose.com/
Actually the client immediatly reflects all input actions the moment he sends it to the server. It was my thought that by having the client run the logic for keystates immediatly it would result in smoother movement. The server is the absolute authority and the client abides by all positional packets to synchronize himself. Does anyone know if this is wrong? should i only be acting on positional packets or delay all keypress actions by the ping time?
I do it like that
"TIME n" is a tick or ms or whatever you use to time your simulation.
TIME 1
the client send the key and start moving(save infos to step back)
------------
TIME 2
the client keep on moving(save infos to step back)
the server receive the packet and extrapolate the current
client position from the key received.
This mean that simulates the client movement from TIME1 to
TIME2(now)
------------
TIME 3
the client keep on moving(save infos to step back)
the server sends an update to the client state
------------
TIME 4
client receive the update. steps back to TIME 3.
resimulates his action from TIME 3 to TIME 4(now)
and compares to his current predicted pos with the one
sent by the server.
if the position is very close or perfect, nothing changes
if the position is "not too close" interpolates the pos(small jump most of the time not noticeble)
if is very far from the server pos jumps to the server
pos(whipping...should only happen if the ping floats or
a lot of packet loss occur)
ciao
Alberto
-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net
"TIME n" is a tick or ms or whatever you use to time your simulation.
TIME 1
the client send the key and start moving(save infos to step back)
------------
TIME 2
the client keep on moving(save infos to step back)
the server receive the packet and extrapolate the current
client position from the key received.
This mean that simulates the client movement from TIME1 to
TIME2(now)
------------
TIME 3
the client keep on moving(save infos to step back)
the server sends an update to the client state
------------
TIME 4
client receive the update. steps back to TIME 3.
resimulates his action from TIME 3 to TIME 4(now)
and compares to his current predicted pos with the one
sent by the server.
if the position is very close or perfect, nothing changes
if the position is "not too close" interpolates the pos(small jump most of the time not noticeble)
if is very far from the server pos jumps to the server
pos(whipping...should only happen if the ping floats or
a lot of packet loss occur)
ciao
Alberto
-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net
-----------------------------The programming language Squirrelhttp://www.squirrel-lang.org
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement