Hacker News new | ask | show | jobs
by Terr_ 4113 days ago
Another fun exercise is dealing with players who say "OMG teh netcode sux" for online first-person shooters, especially when they have patently unrealistic expectations for how well the software should break the speed of light.

Sometimes the hardest part is getting them to understand exactly how much of what they take for granted is an illusion... Often even before any packets leave their machine.
1 comments
Dylan16807 4113 days ago
It's less speed of light at fault than other factors, though. Bufferbloat is terrible, and it's hard to make netcode that reacts well when a few percent of packets are lost or slow.
link
Terr_ 4113 days ago
Sure, other factors predominate, but even in a significantly-more-ideal world, a signal from LA to NY is still going to be a 40ms round-trip. (3940km one-way along the surface of the earth, 200,000km/s signal speed in the glass.)

That's still more than enough time to require algorithmic trickery from games in order to provide the illusion of "real-time" gaming over the internet.

link
Dylan16807 4113 days ago
Think about how many console games run at 30fps. Then consider that a fully framebuffered game running at 30fps, even under ideal conditions, has 70ms of latency by the time a frame finishes displaying. 40ms isn't a big deal.
link
Terr_ 4113 days ago
Even assuming a perfect computer with zero input latency and zero display latency the network part still matters when it comes to knitting an area like "North America" into a game region. It feeds into longer causal chains.

For example, consider two players in LA both using an NY server over the dedicated zero-overhead fiber-optic network mentioned above, with a relatively modern game-networking stack.

(1) Player A raises an energy-shield t=0 ms. (Client-prediction.)

(2) The server agrees as of t=20.

(3) Player B shot an instant-travel hitscan weapon at t=39, while the victim was still exposed on his screen.

(4) The server gets the shot-message at t=59, and honors it (Latency Compensation), sending a damage/death message out to Player A.

(5) Player A receives the news of his damage/death at t=79.

Even in that world of unattainably-good equipment, that's 80ms of "wait, that doesn't look right".

link
Dylan16807 4113 days ago
Lag compensation has flaws, but you don't have to lag compensate. You can delay player input until the server's processed it and responded. Even better if you're clever you can delay player input by half the ping time.

Edit: Also don't double your ping by putting relay servers only on one edge of the country.

link