Client Side Prediction and Server Reconciliation When Sending Player Speeds Hello everyone, So I have finally gotten around to implementing client side prediction. It seemed rather simple at first; set the state on the client to what it was at the tick the server sends back, then re-simulate your inputs. I've read the likes of Gabriel Gambetta, and I'm really close to something that works.However, I think my math is off or I am misunderstanding something. You see, the entity the client controls moves essentially at a constant velocity based on input. Most examples of client side prediction, as far as I can tell, implement movement instructions as a series of 'nudges', i.e. "Move 10 to the left", followed by another message saying "Move 10 to the left". I didn't want to do this because A) I theoretically don't need to send that much information if I know when this linear movement started, and B) Using this strategy may allow multiple instructions to execute in the same frame, resulting in a small but noticeable hitch. So my solution was just to send a packet to the server saying "Move this portion of your top speed starting now". On the server side, this appears to work without a hitch. Then's there's the client. Here's my strategy regarding reconciliation and prediction; as usual, I eliminate inputs from my prediction list that have already been executed by the server. However, as I do that I keep track of the last velocity at which the player was confirmed to be moving. When I reconcile, I start from the last acknowledged input frame, and move as far as I can at the saved velocity until I reach another input in my prediction list or the current frame number of the client. If I find another input, I change the velocity and the start frame and continue onward. This, at least to me, seems like a sound means to handle both reconciliation and prediction. In fact it almost works. However, at surprising regularity the entity being predicted jitters around a bit. It looks as though it happens when I actually receive new state from the server. Specifically, it doesn't look like my prediction method is aware that now that I've received a new frame from the server, my predicted change in position needs to be smaller. But I have no clue what the math is to do this correctly. I'm sure its something quite obvious, but it currently eludes me. I've been struggling with this issue all week, and I could really use some help. I apologize if I'm not clear at the moment; I'm a bit tired. If needed, I can provide clarifications tomorrow. Thank you very much for your help. https://ift.tt/eA8V8J

Hello everyone, So I have finally gotten around to implementing client side prediction. It seemed rather simple at first; set the state on the client to what it was at the tick the server sends back, then re-simulate your inputs. I've read the likes of Gabriel Gambetta, and I'm really close to something that works.However, I think my math is off or I am misunderstanding something. You see, the entity the client controls moves essentially at a constant velocity based on input. Most examples of client side prediction, as far as I can tell, implement movement instructions as a series of 'nudges', i.e. "Move 10 to the left", followed by another message saying "Move 10 to the left". I didn't want to do this because A) I theoretically don't need to send that much information if I know when this linear movement started, and B) Using this strategy may allow multiple instructions to execute in the same frame, resulting in a small but noticeable hitch. So my solution was just to send a packet to the server saying "Move this portion of your top speed starting now". On the server side, this appears to work without a hitch. Then's there's the client. Here's my strategy regarding reconciliation and prediction; as usual, I eliminate inputs from my prediction list that have already been executed by the server. However, as I do that I keep track of the last velocity at which the player was confirmed to be moving. When I reconcile, I start from the last acknowledged input frame, and move as far as I can at the saved velocity until I reach another input in my prediction list or the current frame number of the client. If I find another input, I change the velocity and the start frame and continue onward. This, at least to me, seems like a sound means to handle both reconciliation and prediction. In fact it almost works. However, at surprising regularity the entity being predicted jitters around a bit. It looks as though it happens when I actually receive new state from the server. Specifically, it doesn't look like my prediction method is aware that now that I've received a new frame from the server, my predicted change in position needs to be smaller. But I have no clue what the math is to do this correctly. I'm sure its something quite obvious, but it currently eludes me. I've been struggling with this issue all week, and I could really use some help. I apologize if I'm not clear at the moment; I'm a bit tired. If needed, I can provide clarifications tomorrow. Thank you very much for your help.

from GameDev.net http://bit.ly/2WBbCM4