Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Riot Games: Artificial Latency for Remote Competitors

lolesports.com

Post reply on HN
Print view View original

51–60 of 160 posts

Re: Riot Games: Artificial Latency for Remote Competitors

#51

Post by someweirdperson »

Artificial or natural delays, I am somewhat confused that one end measuring/calculating ping can end up with a wrong value. Transmit at local time x, receive at local time y, subtract. It only needs a working local clock.

Second surprising thing is artifical latency added on the client. Anything on the client I would avoid, if possible.

Third, this all looks like magically connecting two ends. But it is packets flowing from one to the other, and the other to the one. Latency could be added to each independently, even on one end, by artificially buffering to-be-send and/or received packets.

What are the implications for game-play with an asymetric latency, e.g. theoretical 0 delay to receive vs. long delay to transmit, or vice versa?

Re: Riot Games: Artificial Latency for Remote Competitors

#52

Post by tester756 »

colinmhayes wrote: post #32
tester756 wrote: post #12

I still don't understand they didn't let anyone proficient at LoL even try using it?

The difference was .01 seconds. It's not immediately obvious that there is a problem.

>The difference was .01 seconds. It's not immediately obvious that there is a problem.

in games you really feel ping differences

if you were playing e.g for a year on 5ping and then jumped on 30, then you'll feel that in games like LoL and probably CSGO? idk about the second one.

Re: Riot Games: Artificial Latency for Remote Competitors

#53

Post by infinityio »

bob1029 wrote: post #41
Kuinox wrote: post #7

Seems something very hard to do in software but very easy to do in hardware.

I'd argue the complexity of trying to achieve this at all is too much to bear in practice, especially considering the type of customers this would be inflicted upon. Competitive gamers will now also be wondering if the "fake lag" system is bugged, in addition to all of the other problems that could still exist. Some problems cannot be solved with clever tricks.

if they pulled an IEX and just ran the Busan clients through a few km of fibre to induce delay they could use native pings and verify easily

Re: Riot Games: Artificial Latency for Remote Competitors

#54

Post by gmueckl »

JamesSwift wrote: post #35
jedberg wrote: post #20

Earlier quoted context omitted.

It's complex on one end to reduce complexity on the other -- the trading companies wouldn't have to worry about millisecond optimizations if they trading batches were 200ms windows. So the wire lengths wouldn't matter but also not mattering is the processor, memory, software, etc. for the trading companies. Seems like a good tradeoff. And honestly the wire thing probably isn't real. Light moves 30cm in a nanosecond.…

I think it just moves the goal post of the problem. If I now have a 200ms window, then I need to optimize for that 200ms cutoff. I want to do as much work as possible while _still reaching the cutoff_ and so minimization of "non work" still matters. Not only that, but now you incentivize filling up that 200ms with 200ms of analysis.

Isn't that where the randomness of the trading interval comes in? How do you optimally fill out a time interval with a length that is unknown to you?

Re: Riot Games: Artificial Latency for Remote Competitors

#55

Post by colinmhayes »

tester756 wrote: post #52
colinmhayes wrote: post #32

Earlier quoted context omitted.

The difference was .01 seconds. It's not immediately obvious that there is a problem.

>The difference was .01 seconds. It's not immediately obvious that there is a problem. in games you really feel ping differences if you were playing e.g for a year on 5ping and then jumped on 30, then you'll feel that in games like LoL and probably CSGO? idk about the second one.

They said the ping was 45 instead of 35. I'm not denying that the pros can tell the difference, I'm saying it wouldn't be obvious to whatever tester they had that it was 10ms off.

Re: Riot Games: Artificial Latency for Remote Competitors

#56

Post by jchw »

vikingerik wrote: post #44
dematz wrote: post #8

As context this was a big international fiasco. Nobody was acting maliciously but fans of RNG and other teams felt wronged. RNG didn't want to attend due to covid restrictions on travel but Riot really wants Chinese viewers in international tournaments, hence all this online latency work. Pros on other teams were lied to by the false latency information which must be almost paranoia inducing to be told it's only 35ms…

You can in fact have that magical time-travel approach to get apparent latency lower than the real number. Keep a history of the game state at every tick, so you can roll back to any previous instant. If real latency from one client is 50 ms, and you're targeting 35 ms, you roll back the game state by 15 ms each time input comes in from that client, and re-run the game logic from that point forwards and send the resu…

This strategy is commonly referred to as being in the class of “latency hiding” as it doesn’t actually improve latency, it just allows you to reduce apparent latency. In practice it’s still useful but I think it’s mainly useful because it allows for local input to be buffered significantly less than if you were to compensate for lag by adding buffering only. However, that is not always useful. It is mainly useful in games where netplay is handled in a lock-step fashion, where each peer needs to keep every action coherent frame-wise. That makes sense for things like fighting games, but it doesn’t make all that much for say, puzzle games, even though those can be quite latency sensitive too.

Either way, there is nothing magic. At the end of the day, the soonest you can see an action is still physically unchanged. Especially since the prediction model that makes the most sense is just assuming no action.

That said, I dunno enough about MOBAs to try and postulate on how much it matters, and I have no idea if LoL is using lockstep or some other approach.

Re: Riot Games: Artificial Latency for Remote Competitors

#57

Post by JamesSwift »

gmueckl wrote: post #54
JamesSwift wrote: post #35

Earlier quoted context omitted.

I think it just moves the goal post of the problem. If I now have a 200ms window, then I need to optimize for that 200ms cutoff. I want to do as much work as possible while _still reaching the cutoff_ and so minimization of "non work" still matters. Not only that, but now you incentivize filling up that 200ms with 200ms of analysis.

Isn't that where the randomness of the trading interval comes in? How do you optimally fill out a time interval with a length that is unknown to you?

Ah, I didnt interpret the comment as being a variable delay. I think the point still holds though that you would still optimize for the lower bound.

Re: Riot Games: Artificial Latency for Remote Competitors

#58

Post by skocznymroczny »

jchw wrote: post #56
vikingerik wrote: post #44

Earlier quoted context omitted.

You can in fact have that magical time-travel approach to get apparent latency lower than the real number. Keep a history of the game state at every tick, so you can roll back to any previous instant. If real latency from one client is 50 ms, and you're targeting 35 ms, you roll back the game state by 15 ms each time input comes in from that client, and re-run the game logic from that point forwards and send the resu…

This strategy is commonly referred to as being in the class of “latency hiding” as it doesn’t actually improve latency, it just allows you to reduce apparent latency. In practice it’s still useful but I think it’s mainly useful because it allows for local input to be buffered significantly less than if you were to compensate for lag by adding buffering only. However, that is not always useful. It is mainly useful in…

LoL is not using lockstep. Lockstep has two big disadvantages for a competitive game. Tt requires both client to have the full game state to run the simulation, which makes creation of maphacks trivial. The second issue with lockstep is that if one player is lagging, all players are lagging, which is also not something you'd like to have in a fast paced competitive game.

Re: Riot Games: Artificial Latency for Remote Competitors

#59

Post by whateveracct »

holmium wrote: post #36
whateveracct wrote: post #9

A good software lesson here. They built a complex system to tweak tens of ms (at most) of ping to equalize. And they had a bug and it disadvantaged on team. Thus, they have to replay due to unfairness introduced by Riot itself. They could've gone Option 1 - all teams at their natural ping. While it wouldn't be as perfect in theory, it wouldn't have resulted in replaying matches. Plenty of other esports and fighting g…

> People play Melee with ping differences bigger than that and it works fine lol. Waaay more technical game shows that there's tolerance. I dunno; I'd imagine people would be mad if there was a 15ms ping differential in Melee. I think the online/netplay tournament results are already looked at different than offline, console results. Moreover, I'm pretty sure that you can't have a differential ping in a P2P game with…

Most Melee players use a frame delay that's equivalent to the lag present in a Gamecube + CRT setup. A little artificial input lag goes a long way!

Re: Riot Games: Artificial Latency for Remote Competitors

#60

Post by Karrot_Kream »

NelsonMinar wrote: post #23

Some data: 8 years ago someone found going from 35ms to 0ms latency meant you were likely to win games 1-2% more of the time: https://www.reddit.com/r/dataisbeautiful/comments/1t23a0/lat... And this is a little different, but Riot found that playing on ethernet instead of wifi made you about 1% more likely to win games. https://web.archive.org/web/20160814131032/http://na.leagueo...

I'm going to guess this effect is lower because it's being marginalized across all player skill levels (ELO). In Riot's post you can see that the higher tier the player is at, the more likely they are to use Ethernet. If you conditioned on ELO I suspect you'll find a much larger effect.
Post reply on HN