Server client ticks, lag compensation, game state, etc

bgilb · 2016-11-08T22:21:02

I'm trying to implement FPS style game networking, and have a lot of it understood and have implemented them. But there are parts that all the material I can read has kind of glossed over. The only meaningful things I can find are actually forum posts on here (mostly by hplus0603 and fholm). So I guess to start I will explain how my system currently works: Simulation is 60Hz on both server and client Client sends input commands every other frame Once per tick, the server goes through all pending commands and applys them to the game world. This means a user can apply more than one user command per server tick. From reading Valve's articles it seems they do it this way, but I'm not 100% sure. After applying on the user commands, the server reads the physics of the world and stores it into a world game state object that includes all the entities and sends this to the users with the server tick. I imagine you can already see the problems in this system: When doing client server reconciliation, the ticks and positions don't really match up 100%. Maybe this is okay though? Lag compensation definitely won't work.. This is because the users position inside the gamestate will actually jitter around. Also the client tick and server tick don't match up. Interpolation probably won't work either.. So the first way I thought to fix it is to always have the server tick only execute 1 user command per tick. But I can't just tick 1 user command at a time, since user commands would end up missing. Especially since I send 2 at a time. Also how do I match up the user command tick to the server tick it was actually applied on? One issue I had with this was that the buffer was inexplicably filling up with like 20 user commands, and never draining them. So the player would end up very far behind (20 * 16ms) = 320ms. Also the receiving first game state is confusing to me. Client: Client connects and receives first game state Sets its own local tick to the server tick it received in the game state. Let's say tick 1300. Client sends it's first user command with it's local tick (which will be the server tick it just received, we'll also just assume 1 user command per packet). The result of that user command was a position of 1,0. Server: Client connects, add player to game state Send game state to everyone with server tick (1300) At this point a couple ticks will have passed (let's just say 5) before we've even received the first user command. That client's buffer is empty. Let's assume we don't execute anything when the user command buffer is empty. We received the previously connected users first command stamped with tick 1300. But the server is already on tick 1305. So it applys the user command on tick 1306 and send's it to the client with the stamp 1306. Client Client has sent a few user commands by now without a game state. Receives second game state 1301 on the server. Checks his own history and the result of 1301 was 2,0. But the server says he was at 0,0 since it hasn't even applied any user commands.

Networking and Multiplayer Programming

Started by bgilb November 04, 2016 04:47 AM

25 comments, last by bgilb 7 years, 5 months ago

bgilb

232

Author

November 07, 2016 05:29 PM

I'm mostly talking about the single delays like you outlined. I'll call these latency spikes. These could be either FPS drops on the client or actual latency on the network.

I think I'll implement the clock syncing because it will probably make things easier. But I don't really understand the roll of the buffer anymore when using clock syncing. Do I get rid of it?

With clock syncing though, what happens also during latency spikes? Doesn't the server go to grab a user command during a tick and it's not there? Won't this also fill up the buffer?

Maybe pseudo code would help me understand?

Here is how it works currently for me:

Tick loop (at 60hz) on client:

Generate usercommand by polling input. User command is tagged with current client tick.

Send usercommand to be client side predicted

Send usercommand over network (Which waits until 2 are available and sends then).

Tick loop at(60hz) on server:

Once per render frame (higher than ticks) check for any incoming usercommand message. If any add to the players user command buffer

Per tick check for the lowest client tick if there are any and apply it to that player.

Both loops can play catchup

hplus0603

11,916

November 07, 2016 06:10 PM

The buffer is still important. The buffer is a priority queue of "tick number" mapping to "command for this player," and you flush any commands that arrive for ticks that are already executed, or that arrive for the far future.
With clock syncing, you can throw away events that arrive too late, but keep the ones that still have time to execute.
If you get lots of events arriving too late, then the server will tell the client to adjust the clock to send packets sooner, which will build up more buffering, which will help when the spike happens.
You have to figure out how much you want to be tolerant against latency spikes, versus how much overall latency you are prepared to accept in buffering.

enum Bool { True, False, FileNotFound };

bgilb

232

Author

November 08, 2016 04:41 PM

After doing some research, it doesn't appear the source engine uses a buffer, at least not exactly.

https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/server/player.cpp#L3192

http://forums.steampowered.com/forums/showthread.php?t=3119525

It lets the user run up to the max allowed user commands per server tick. This is actually only recently added to the source engine in the last 3 years. I'm not sure how it worked before.

The github line is where the source engine actually processes user commands on the server. It doesn't seem to care at all about the current server tick?

It would make lag compensation easier because I wouldn't have to worry about the buffer size when the command was received. Although some form of speed hacking seems possible?

hplus0603

11,916

November 08, 2016 06:29 PM

It does keep a clock, but it's implicit. This line in DetermineSimulationTicks() seems to be the way that happens:

simulation_ticks += ctx->numcmds + ctx->dropped_packets

Note "ctx->dropped_packets" -- the invariant is that "numcmds" plus "dropped_packets" equals the total number of time steps lapsed.

enum Bool { True, False, FileNotFound };

bgilb

232

Author

November 08, 2016 08:03 PM

It seems the server keeps track of missed user commands, and that becomes the number of ticks the client is allowed to execute. The "CCommandContext" from what I've read is just a set of user commands that were received on the network.

What I'm getting at is that it doesn't appear to care that the client sends his user commands "just in time" for the server tick. They're allowed to play catch-up or fall behind. Wouldn't this be more robust? Save for players sometimes skipping around.

hplus0603

11,916

November 08, 2016 09:21 PM

it doesn't appear to care that the client sends his user commands "just in time" for the server tick. They're allowed to play catch-up or fall behind. Wouldn't this be more robust? Save for players sometimes skipping around.

This is more robust in the sense that a single client's path forward through time will be tracked on the server.
It is less robust in the sense that the server may resolve different clients at different points in time, and thus cannot have a cohesive "these players collided" view that is agreed by everybody.
Which gets even harder when you try to make the determination of "this client fired in this direction at this time; what did they hit?"

enum Bool { True, False, FileNotFound };

bgilb

232

Author

November 08, 2016 10:21 PM

But the clients are always at different points in time because of latency. I don't think this system rewinds server gamestate or changes history or anything. So as long as an unlaggy player shot the lagged out version, it will go back to previous ticks and the player will still be in the lagged position for that snapshot and it will let him kill/hit him.

Server client ticks, lag compensation, game state, etc

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Server client ticks, lag compensation, game state, etc

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines