Dev Log#24: Learning about client side prediction and server side rewind

Unreal has packet emulation in the editor preferences to be able to test your game in high lag situations and it highlighted how delayed everything.

Client side prediction is where the client changes the state of the owning player and sends that information to the server for example I'll use the player's position . The server then verifies that position. If it is accepted by the server that position becomes the authoritative version on the server as well. But the server still holds authority on the game state so if the information is rejected the client state will revert back to the last known position that the server holds about the client's player.

The downside of client side prediction is the amount of time it takes for server to process the clients information. If you were using client side prediction for updating the player's position you would notice a lot of rubber banding and jittering because your player is essentially always one step ahead of the server but the server holds the authoritative version of the game so the server is pulling you back to the position that you were last in.

For that reason I used client rpcs to predict ammo usage and gaining ammo.

The key part about the ammo usage is I created a an int32 variable called Sequence. Sequence is the number of unprocessed server requests for ammo. This is incremented in UseAmmo() and decremented in ClientUpdateAmmo(). By subtracting sequence from ammo it verifies what the actual amount of ammo should be.

Server side rewind is a method of keeping a small window of game history only few milliseconds at most but guns in shooter games can have even faster travel time. And with no lag compensation players will often hit a player on their screen but due to the inevitability of latency the authoritative server position of the enemy was different than on the players screen.

I created this feature by using a double linked list to store a separate set of hitboxes for the character.

FFramePackage also stores time because only the last few milliseconds of the player's position will be recorded at any time during the game.

The process starts with a function named "SaveFrame" which is called in the tick function so that every frame is recorded.

Save Frame Package stores ThisFrame in the HitboxMap found in the FFramePackage struct

The next part is a function called Get Frame to check.

History is initialised as FrameHistory

Frame To Interp interpolates from the older FramePackage's hitbox location and rotation to the younger FramePackage's hitbox location and rotation

The final part of server side rewind is confirming the hit.

Its important to disable the character mesh's collision during the confirm hit so that the line trace hits the server side rewind hitboxes and doesn't the character's mesh. Once the line trace is executed we reenable the character's mesh collision

This function returns two booleans which are part of a struct called serversiderwindresult

If confirm hit returns true = player was hit.

If the function confirm hit returns true apply damage will be executed

Score request is a server rpc that is called on the weapon classes such as hitscan and projectile weapon. So the logic procedure is the weapon classes call score request which triggers the Get Frame to check function if the frame is valid then subsequently confirm hit function is executed.