Understanding Lag Compensation & Timestamps Hello, I have a basic "greedy" server authority architecture with client side prediction and reconciliation. The client sends inputs to the server with a sequence number (or command number). It stores that locally, and waits for the server to acknowledge it. In the mean time, it performs the input as if the server already has. The server processes the input on the first update when it becomes available, hence I'm calling it "greedy". It just consumes inputs as soon as they show up, and then sends the real position back to the player (with the sequence number) and any other players so they can render this player's new position. The client who sent the input in step 1 receives the acknowledgement, looks at the sequence number in its history of inputs it stored, then replays any unacknowledged inputs that have accumulated since that was sent. This is fine and dandy for a really simple game, maybe two players. But, once you start having more players from all over, with different connection speeds, things will fall apart because there's no lag compensation or sense of "time" on the server's simulation. So, this leads me to my search. I've found a bunch of articles - gafferongames, gabrielgambetta, valve's wiki, Overwatch & Halo Reach GDC presentations, Qing Wei Lim's writeup The terms used in each are actually kind of loose, I'd argue some of them don't line up with each other. Some are talking about different implementations, or parts of one another. Example - gabrielgambetta talks about reconciliation however it's really *client-side reconciliation with the server* like I have now. It is *not* lag compensation or "server-side reconciliation with the client" depending on which phrasing you wish to use. None of them really discuss time in depth and what it means to timestamp everything in order for the server to perform lag compensation specifically. I'd say gafferon comes close in his "fix your timestep" article. Here's my current understanding of Lag Compensation and hope someone can correct me and fill in any gaps Client sends command, like walk or shoot, at CLIENT TIME X Server receives this command at SERVER TIME Y X is older than Y - IE the server is always ahead time wise. Server sees the command took HALF ROUND TRIP TIME Z to reach it. Server looks into its position history at time Y - Z, applies the command in that historical context If needed, server will then replay all accumulated inputs from players again from that history. There may be situations where this isn't necessary - for example, player 1 shot at player 2 and missed, just disregard it. Or, player 1 moved forward but nothing went wrong (didn't collide with anything). My questions: What are times X and Y based on? Is it real world time? How is this Z found? Is it Y-X? Or is it assumed from the last known ping/pong? If it is based on real world time, and Z is found from Y-X, what happens when the player's timestamp is not a real or accurate timestamp? How do you deal with time differences, just track and stamp all commands in UTC ticks? What happens if Z is beyond the positional history buffer? For example, Counterstrike says it saves up to a maximum of 1 second of positional history. What if the command is for an action that occurred beyond that time buffer in the past? Ignore it? https://ift.tt/eA8V8J

Hello, I have a basic "greedy" server authority architecture with client side prediction and reconciliation. The client sends inputs to the server with a sequence number (or command number). It stores that locally, and waits for the server to acknowledge it. In the mean time, it performs the input as if the server already has. The server processes the input on the first update when it becomes available, hence I'm calling it "greedy". It just consumes inputs as soon as they show up, and then sends the real position back to the player (with the sequence number) and any other players so they can render this player's new position. The client who sent the input in step 1 receives the acknowledgement, looks at the sequence number in its history of inputs it stored, then replays any unacknowledged inputs that have accumulated since that was sent. This is fine and dandy for a really simple game, maybe two players. But, once you start having more players from all over, with different connection speeds, things will fall apart because there's no lag compensation or sense of "time" on the server's simulation. So, this leads me to my search. I've found a bunch of articles - gafferongames, gabrielgambetta, valve's wiki, Overwatch & Halo Reach GDC presentations, Qing Wei Lim's writeup The terms used in each are actually kind of loose, I'd argue some of them don't line up with each other. Some are talking about different implementations, or parts of one another. Example - gabrielgambetta talks about reconciliation however it's really *client-side reconciliation with the server* like I have now. It is *not* lag compensation or "server-side reconciliation with the client" depending on which phrasing you wish to use. None of them really discuss time in depth and what it means to timestamp everything in order for the server to perform lag compensation specifically. I'd say gafferon comes close in his "fix your timestep" article. Here's my current understanding of Lag Compensation and hope someone can correct me and fill in any gaps Client sends command, like walk or shoot, at CLIENT TIME X Server receives this command at SERVER TIME Y X is older than Y - IE the server is always ahead time wise. Server sees the command took HALF ROUND TRIP TIME Z to reach it. Server looks into its position history at time Y - Z, applies the command in that historical context If needed, server will then replay all accumulated inputs from players again from that history. There may be situations where this isn't necessary - for example, player 1 shot at player 2 and missed, just disregard it. Or, player 1 moved forward but nothing went wrong (didn't collide with anything). My questions: What are times X and Y based on? Is it real world time? How is this Z found? Is it Y-X? Or is it assumed from the last known ping/pong? If it is based on real world time, and Z is found from Y-X, what happens when the player's timestamp is not a real or accurate timestamp? How do you deal with time differences, just track and stamp all commands in UTC ticks? What happens if Z is beyond the positional history buffer? For example, Counterstrike says it saves up to a maximum of 1 second of positional history. What if the command is for an action that occurred beyond that time buffer in the past? Ignore it?

from GameDev.net https://ift.tt/2SQcCeg