Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization I’m Curtis

Networked FPS games are difficult to make • But not too interesting if they’re not networked • Broadband is pretty nice • But we can’t rely on it 

Basic Architecture • Client / Server set up • Server handles logic • Clients (initially) just to get player input • Simplified version below

Client Frame Loop • Sample clock to find start time • Sample user input • Package up and send movement command using simulation time • Read any packages from the server from the network system • Use packets to determine visible objects and their state • Render scene • Sample clock to find end time • End time minus start time is the simulation time for the next frame • What about ‘framerate jitter’?

Server Loop • Sample clock to find start time • Read client user input messages from network • Execute client user input messages • Simulate server-controlled objects using simulation time from last full pass • For each connected client, package up visible objects/world state and send to client • Sample clock to find end time • End time minus start time is simulation time for the next frame

Not the only way to do it • Suggestions?

Half-Life User Input • Most important fields in the struct are • Interpolation time on client • Duration in ms of command • Command view angles • Forward/Sideways/Upwards velocity • Attack buttons • Other stuff • Any comments?

So here’s what happens • Client creates and sends a user command to the server • Server executes the command and sends updated positions of everything back • Client then renders the scene • Simple, and doesn’t do well in real situations. Why?

Client is too stoopid • All it does is react. If there’s a certain amount of latency the client has no choice but to wait. • So what does the client need to do?

Client Side Prediction • One option: perform it locally and assume the sever is going to be cool with it. • Client still not in control • Server will shove objects back where they should be • Can look pretty crappy

A better way • Client samples input (same) • Client sends off the commands (same) • Client keeps a copy of each command and when it was generated (different!) • First perform the last acknowledged movement from server • Then performs any outstanding commands in a similar method as the server would.

Algorithm for last slide “from state” /*state after last command acknowledged by server*/ “command” /*first command after the from state*/ while (true){ run “command” on “from state” to generate “to state”; if (this was the most up to date “command”) break; “from state” = “to state”; “command” = next “command”; };

Client will run same commands over and over until acknowledged • Sounds should not be re-created • Server should not send info predicted by the client. • Client still has to re-run the old commands • Fix: client marks those not yet predicted and only plays if it’s the first time

Client only state data • If none, just use last state from server as a starter and run prediction commands • If any, you need to store the intermediate results of prediction • Store them in a ‘sliding window’ • Actuate them as they should be, using server acknowledgment • So far, just using this for movement

Weapon firing • We can do the same as the last slide for weapon firing • Need to know • Which weapons are being held • Which is active • How much ammo each has • Can be complicated if client and server shooting logic is difficult

Why stop there? • This leads us to also predict . . . • Weapon switching • Deployment • Holstering • “Umm, This is a Lot of Work” • Do they expect us to do this for MazeWar?

You still need to have a feel for your latency to determine how to lead your targets • Quake3 made a sound when you hit someone to make it easier • Jitter will make it very hard to get a good feel

But enough about me . . . • Now we need to worry about rendering the other players correctly • Two main methods – Extrapolition and Interpolition

Extrapolation • Other players/objects simulated forward in time • Works nicely for people running in straight lines • Bad news: many players move like Mexican jumping beans with too much coffee • Can clean this up a bit by putting a limit on the extrapolation time • This can make it so there is less warping, which will hurt gameplay and nullify the reason for putting extra work in

Interpolation • Always moving objects in the past • Slow render a bit to compensate for some lag • Missed a packet? • Extrapolate the player position • Or have the player rest (and stutter the movement)

Interpolation Algorithm Each update contains the server time stamp for when it was generated From the current client time, the client computes a target time by subtracting the interpolition time delta (100 ms) If the target time is between the timestamp of the last update and the one before that, then those timestamps determine what fraction of the time gap has passed. This fraction is used to interpolate any values (e.g., position and angles

It’s basically buffering an additional 100 ms of data on the client • Any longer is a trade off, since the smoother vision will make others harder to hit • It requires a fixed time interval between server updates • Problems?

Interpolation visual quality • For example: if the player is jumping around they spend the average of the time at the middle of their jump • If we interpolate at the last position they might just be seen floating up and down without ever reaching the ground or the height of their jump.

Vision fix • Each server update creates a new position history entry • Search backwards through the history looking for a pair that straddles the target time • What if something was SUPPOSED to teleport? • Set a flag

Lag Compensation • Normalizing server-side the state of the world for each player as that player’s user commands are executed. • Algorithm on the next page

Before executing a player’s current user command, the server: • Computes a fairly accurate latency for the player • Searches the server history (for the current player) for the world update that was sent to the player and received by the player just before the player would have issued the movement command • From that update (and the one following it based on the exact target time being used), for each player in the update, move the other players backwards in time to exactly where they were when the current player’s user command was created. This moving backwards must account for both connection latency and the interpolation amount8 the client was using that frame. • Allow the user command to execute (including any weapon firing commands, etc., that will run ray casts against all of the other players in their “old” positions). • Move all of the moved/time-warped players back to their correct/current positions

Now a player can directly aim at other players without wondering if they’re actually there. • Is this fair?

Well, someone with a lot of lag could shoot someone with less lag after that person had taken cover . . . • But does that happen very often? • Who is right in those cases? • Half-Life gives the points to the shooter • Probably because it’s more fun to shoot

So, it’s still inconsistent with a perfect view of the world • But the benefits still outweigh those inconsistencies • Benefits?

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization