I am trying to implement client side prediction as in this article http://www.gabrielgambetta.com/fpm2.html

Currently I'm doing it like this: the game runs at 60 FPS. 60 times per frame I check if an arrow key is pressed, if so, I move the player character slightly and send the message about the movement done to the server (direction + delta time). The server applies the movement. On the next player positions broadcast, the server also sends the ID of the last_received_input. Client then updates the state based on what it received from the server, then reapplies all the inputs after the last_received_input.

It works in general. The problem is, that now client packet send rate is tied to the client framerate. If I keep rendering at 60 FPS, but check inputs/send input packets at only 30 FPS, I will start to experience jerky movement on the player character. How is it done properly? How to reduce the client tickrate, but still achieve smooth movement?


1 Answer 1


One approach is to give each server step a incrementing number. For example, a server may be currently executing step 500, and after one second, this server running at 60 FPS will have reached step 560.

The client keeps count of the steps on the client side, and tries to stay within a certain time-bound from the corresponding server step.

That way when a client receives new data from the server, it knows two things: (1) which inputs have already been applied in the new data, and (2) which steps it needs to re-enact (on the physics engine) and at what client step.

This approach has another nice advantage: it removes the assumption that the client loop and the server loop will always be in sync. In reality there can be drift, or network spikes between the game loop on the client and the server. They both attempt to run at 60 FPS but with time they drift apart.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .