🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to Networking and Multiplayer

Understanding Lag Compensation & Timestamps

NetworkDev19 · 2019-09-03T15:36:26

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?

Networking and Multiplayer Programming

Started by NetworkDev19 July 28, 2019 02:07 AM

20 comments, last by NetworkDev19 4 years, 9 months ago

NetworkDev19

Author

September 03, 2019 03:36 PM

I *think* I figured out why it was oscillating so much.

At a tickrate of 60, my server was ticking sporadically because performance is not refined yet. I started to count how many ticks occur in an Update() loop in Unity, and it would bounce between 1-4 frequently. This means that the game client has to continually change its guessing.

I dropped the tickrate to 30, my server is currently running around 40FPS anyway, and now I get a much more stable guess at the server's tickrate. The delta is closer to 2 after the game client connects and syncs up a bit.

I'll have to ramp up the tickrate when I get better performance.

🎉 Celebrating 25 Years of GameDev.net! 🎉

Understanding Lag Compensation & Timestamps

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

🎉 Celebrating 25 Years of GameDev.net! 🎉

Understanding Lag Compensation & Timestamps

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines