5 ms·

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 y

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 resulting state update to all clients. Those clients will see a bit of jumpiness in the game state, which isn't ideal, but may be the lesser evil compared to enduring more latency. (I have no idea what LoL in particular supports or implements, but that's the general idea.)

meinersbur 4y ago
That's just another kind of latency. Additional time has still passed from you (or the enemy player) doing an action, and you seeing the results of that action on your screen. By contrast, the server rolling back the game state is indistinguishable from the server always being 15ms behind and the clients running the simulation ahead of time (which they do anyway for fluency [1]). The "jumpiness" is called rubberbanding [2]. [1] https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html https://www.gabrielgambetta.com/client-side-prediction-serve... [2] https://www.urbandictionary.com/define.php?term=rubberbanding https://www.urbandictionary.com/define.php?term=rubberbandin...
jchw 4y ago
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.
- skocznymroczny 4y ago
  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.
  - causality0 4y ago
    Maybe I'm just a fuddy-duddy, but for me there's no room for remote competitors in a serious competition. Either it all happens on the same LAN or its just playing for funsies.
    - russellendicott 4y ago
      I know right, what about home court advantage or any slight imbalance that great 70's movies are made of?
  - reitzensteinm 4y ago
    What to do when one player is lagging is a design choice. You can instead keep the game going and feed in their delayed inputs.
  - bee_rider 4y ago
    I can definitely see why the maphack thing would be an issue generally, but in the case of a broadcast esports competition is it so significant? They seem to have put an awful lot of engineering effort into their special lag system for this tournament, so I assume they at least have some pretty decent budget. So, presumably they could create a special client (possibly even sending the competitors locked down hardware). This seems like it would let them do some things we'd normally consider impossible or 'magic' -- assume both sides of the pipes are going to tell you the truth about everything...
    - jimmydorry 4y ago
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
__turbobrew__ 4y ago
I really dislike games which rewind state based upon latency. It penalizes people with good ping and can lead to very weird game states where a large rollback can cause teleportation of a laggy player as seen by non laggy players. Team Fortress 2 is particularly bad where high latency players can teleport around or you can shoot and hit a laggy player but it doesn’t register by the server due to a rollback. Some players purposely exploit this function by artificially increasing their ping values to absurd levels (700ms or more) which makes them very hard to hit. Many community TF2 servers enforce maximum ping limits for this reason. Most notably high pings are used to exploit when playing as the Spy class due to the fundamental purpose of the class is to get behind you to backstab you. If you have 700 ping can abuse the fact that you you can get behind players due to the game being out of sync and if you can backstab a player the server will roll back and kill the non-laggy player even though you were no where near behind them from their non-laggy perspective.
- camgunz 4y ago
  There's a difference between backwards reconciliation (rolling the game world back to process a lagged player's input) leading to "shot around a wall", and packet loss/jitter leading to jumpy player and teleporting. I make this distinction because I actually think backwards reconciliation is table stakes for any kind of precision game and is usually pretty easy to implement. It can also help solve teleporting: you run backwards reconciliation on movement commands also (not just shooting or other actions), and combine with a little player position extrapolation. Nothing fixes a 700ms, actually I would guess the ceiling on competitive play is somewhere around 200ms with incredible netcode. But 200ms gets you pretty far: across the US or the Atlantic Ocean for sure (packet loss over those distances is another story though).
- ben-schaaf 4y ago
  While the exact logic TF2 uses leaves a lot to be improved, you absolutely need this kind of lag compensation. Without rewinding any amount of latency results in having to aim where an enemy gamer will be by the time your packet reaches the server instead of where they are on your screen. If you remember before they patched the Pyro class you had to aim significantly in front of players because the flames weren't lag-compentated.

meinersbur 4y ago

That's just another kind of latency. Additional time has still passed from you (or the enemy player) doing an action, and you seeing the results of that action on your screen. By contrast, the server rolling back the game state is indistinguishable from the server always being 15ms behind and the clients running the simulation ahead of time (which they do anyway for fluency [1]). The "jumpiness" is called rubberbanding [2]. [1] https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html https://www.gabrielgambetta.com/client-side-prediction-serve... [2] https://www.urbandictionary.com/define.php?term=rubberbanding https://www.urbandictionary.com/define.php?term=rubberbandin...

jchw 4y ago

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.

skocznymroczny 4y ago
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.
- causality0 4y ago
  Maybe I'm just a fuddy-duddy, but for me there's no room for remote competitors in a serious competition. Either it all happens on the same LAN or its just playing for funsies.
  - russellendicott 4y ago
    I know right, what about home court advantage or any slight imbalance that great 70's movies are made of?
- reitzensteinm 4y ago
  What to do when one player is lagging is a design choice. You can instead keep the game going and feed in their delayed inputs.
- bee_rider 4y ago
  I can definitely see why the maphack thing would be an issue generally, but in the case of a broadcast esports competition is it so significant? They seem to have put an awful lot of engineering effort into their special lag system for this tournament, so I assume they at least have some pretty decent budget. So, presumably they could create a special client (possibly even sending the competitors locked down hardware). This seems like it would let them do some things we'd normally consider impossible or 'magic' -- assume both sides of the pipes are going to tell you the truth about everything...
  - jimmydorry 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

__turbobrew__ 4y ago

I really dislike games which rewind state based upon latency. It penalizes people with good ping and can lead to very weird game states where a large rollback can cause teleportation of a laggy player as seen by non laggy players. Team Fortress 2 is particularly bad where high latency players can teleport around or you can shoot and hit a laggy player but it doesn’t register by the server due to a rollback. Some players purposely exploit this function by artificially increasing their ping values to absurd levels (700ms or more) which makes them very hard to hit. Many community TF2 servers enforce maximum ping limits for this reason. Most notably high pings are used to exploit when playing as the Spy class due to the fundamental purpose of the class is to get behind you to backstab you. If you have 700 ping can abuse the fact that you you can get behind players due to the game being out of sync and if you can backstab a player the server will roll back and kill the non-laggy player even though you were no where near behind them from their non-laggy perspective.

camgunz 4y ago
There's a difference between backwards reconciliation (rolling the game world back to process a lagged player's input) leading to "shot around a wall", and packet loss/jitter leading to jumpy player and teleporting. I make this distinction because I actually think backwards reconciliation is table stakes for any kind of precision game and is usually pretty easy to implement. It can also help solve teleporting: you run backwards reconciliation on movement commands also (not just shooting or other actions), and combine with a little player position extrapolation. Nothing fixes a 700ms, actually I would guess the ceiling on competitive play is somewhere around 200ms with incredible netcode. But 200ms gets you pretty far: across the US or the Atlantic Ocean for sure (packet loss over those distances is another story though).
ben-schaaf 4y ago
While the exact logic TF2 uses leaves a lot to be improved, you absolutely need this kind of lag compensation. Without rewinding any amount of latency results in having to aim where an enemy gamer will be by the time your packet reaches the server instead of where they are on your screen. If you remember before they patched the Pyro class you had to aim significantly in front of players because the flames weren't lag-compentated.