Technical Challenges & Experience

Client-Side Prediction and Reconciliation

In a multiplayer FPS game, responsiveness is key to a fun experience. Shooting and movement should feel effectively instant to maintain good gamefeel. With a client-server model, which Build Fight Game uses for security, the server maintains final authority over the state of the game and is responsible for relaying that to all connected clients. Whenever a client makes an input, it must be sent to the server, processed, and then the result is sent back to the client. Due to the inherent latency between client and server, this can create a sluggish feeling during gameplay. There's nothing worse than giving an input and having to wait at least 50ms before the player gets any feedback, especially in a fast-paced FPS game like Build Fight Game.

The solution to this is client-side prediction and reconciliation, a system wherein each client 'predicts' their own movement locally, applying changes instantly, and then validates that their predicted state is correct once it recieves the 'offical' state from the server. Under perfect conditions, there is no difference between the predicted movement and the server state, leading to fully responsive movement. Under less-than-ideal network conditions, where the server may not recieve all of the player's inputs, the predicted state must be reconciled to match the server state.

For Build Fight Game, I developed a generic CSP (Client-Side Prediction) system, wherein any script can implement the basic requirements for prediction - a way to get input, a way to set state, and a way to process input - and subscribe to the central 'prediction manager', which maintains two buffers of input and state ordered by tick. Both the 'authority' (usually the server) and 'predictor' (usually the client) will process an input at a given tick and then assign the state at the same tick to the processed state. The authority then sends this state over the network to the predictor. When the predictor recieves an authoratative state, it sets the state at the given tick to the new authoratative states, and then uses the buffer of inputs to re-compute each state following that tick that has not yet had its state received by the server. The effect of this is that, if the predicted state matches the server state, all the following states will also be the same. Otherwise, the following states will now be adjusted as if they had been calculated given the correct state.