31–40 of 57 posts
I don’t recommend lag compensation. It’s a bad idea because it degrades the experiences of more-committed / better players in order to cater to the less-committed / worse players.
A statement befitting the co-author of an unpopular online game.
P.S. Someone the other day asked why I don’t post much to HN (and don’t put much effort in when I do). This kind of junk is exactly why!
I don’t recommend lag compensation. It’s a bad idea because it degrades the experiences of more-committed / better players in order to cater to the less-committed / worse players.
how are they less committed? it's their fault that they live in a country which doesn't exist on the server installation roadmap of stupid greedy corporation? that suggestion was really American for the lack of better word. let them run their own servers? tough luck, most games in 2017 don't allow dedicated server setup
Yes, good connections are expensive for some people. If you want to do something about that, maybe you include amount of latency in a player’s ELO or something. I am just saying that I do not like Valve’s approach to the problem (which has been inherited by many other games) because I care about games and it makes games worse overall.
I don’t recommend lag compensation. It’s a bad idea because it degrades the experiences of more-committed / better players in order to cater to the less-committed / worse players.
edit: Maybe you mean that lag compensation makes it harder to avoid others' shots. But does that really reward less skilled players? If anything it rewards players with higher ping, but that's not necessarily the same as worse or less committed. I suppose that really uncommitted players are more likely to try to game over some crappy Wi-Fi or even cellular connection, whereas for committed players, latency is more likely to result from distance. But that's a rather low threshold of commitment. In any case, having a really high ping comes with serious disadvantages, including rubber-banding, a harder time avoiding shots, a harder time aiming with anything that isn't lag compensated (e.g. projectiles), etc...
Also,
> High-budget games these days locate servers around the world, so that is not an issue.
Even assuming there are enough players to fill the severs, it's only a non-issue if you're matchmaking alone. If you want to play with specific people - through either a party system or traditional named/player-operated servers - and they happen to live far away, you can't avoid latency. Of course, there's always going to be some ping value beyond which the game isn't worth playing, even with lag compensation - but it's a higher value than without. And at intermediate levels of latency - say, 100ms - lag compensation can be the difference between a passable experience and an effectively perfect one.
It is a 17-year-old article. Did the fundamentals stayed the same or has there been any significant paradigm shifts in how game networking is done?
Still the same :)
Earlier quoted context omitted.
On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.
> any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP Assuming that's true, that doesn't change the fact that TCP is unusable for real-time gaming. So the solution sounds like a formally specified, bug tested, and fast implementation of half of TCP, as long as it's not the half that breaks soft real-time gaming.
Only for the twitchiest of twitch games really needs lower latency than TCP provides. So many amateur/indie game devs waste huge amounts of time messing with UDP because "everyone knows TCP isn't realtime" when TCP would have been perfectly suitable for their game.
Earlier quoted context omitted.
how are they less committed? it's their fault that they live in a country which doesn't exist on the server installation roadmap of stupid greedy corporation? that suggestion was really American for the lack of better word. let them run their own servers? tough luck, most games in 2017 don't allow dedicated server setup
I am talking about peoples’ home internet connections (or the PC bang where they play, etc). High-budget games these days locate servers around the world, so that is not an issue. Yes, good connections are expensive for some people. If you want to do something about that, maybe you include amount of latency in a player’s ELO or something. I am just saying that I do not like Valve’s approach to the problem (which has…
exactly what I'm talking about. "around the world" may not be enough. And since they don't allow dedicated servers hosted by players, they better have lag compensation or to hell with them.
I don’t recommend lag compensation. It’s a bad idea because it degrades the experiences of more-committed / better players in order to cater to the less-committed / worse players.
Earlier quoted context omitted.
> any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP Assuming that's true, that doesn't change the fact that TCP is unusable for real-time gaming. So the solution sounds like a formally specified, bug tested, and fast implementation of half of TCP, as long as it's not the half that breaks soft real-time gaming.
> TCP is unusable for real-time gaming. Only for the twitchiest of twitch games really needs lower latency than TCP provides. So many amateur/indie game devs waste huge amounts of time messing with UDP because "everyone knows TCP isn't realtime" when TCP would have been perfectly suitable for their game.
PSA: Add print=1 to old gamasutra articles to get a single page. https://www.gamasutra.com/view/feature/131577/halflife_and_t... Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.
On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.
PSA: Add print=1 to old gamasutra articles to get a single page. https://www.gamasutra.com/view/feature/131577/halflife_and_t... Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.
SCTP provides a nice protocol that gets you the best of both worlds in many ways between TCP and UDP. It features: - hybrid reliable and unreliable, ordered and unordered delivery semantics - automatic MTU fragmenting, to avoid router fragmentation - ordered multi-channel multiplexing Unfortunately SCTP never took off, but it is the data channel protocol for WebRTC, which uniquely positions WebRTC as a nice platform…
EDIT: https://github.com/kripken/BananaBread/issues/40
Seems WebRTC wasn't mature enough at the time. Would be a good showcase if it was brought back.