3 ms·

See http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp for an explanation of what I meant when

See http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp for an explanation of what I meant when I suggested he use lag compensation. There is a lag to tell the server when you want to move and a lag when the server tells the other player where you moved, so the lag compensation is for the server to guess where you thought the other player was when you made your move. This is used extensively in Counter-Strike, and I think it has its uses here.

extension 16y ago
How would that be used in light cycles? Would you see your opponent's trail jump around as the client prediction is corrected? Would the game let you pass through your opponent's trail if you couldn't see it at the time? Lag comp takes advantage of the independence of your gaming experience and your opponent's. It effectively hides inconsistencies in places you aren't paying attention to, like where your opponent is aiming. In light cycles, your actions and consequences are much more tightly coupled to those of your opponents. There is nowhere to hide the inconsistency.
- coderdude 16y ago
  Don't get me wrong, I understand the stark contrast between CS and this style of gameplay. >>Would you see your opponent's trail jump around as the client prediction is corrected? The prediction in this game would only be which direction the opponents are moving in. Between packets the client would continue moving opponents in their last known direction. Once the client knows better it must change the game state to the player. If that means one opponent moved several game units in one direction and must be moved back those several units and then turned in a different direction then that is what must happen, and yes it will be jarring to the player, but this happens all the time in online gameplay. >>Lag comp takes advantage of the independence of your gaming experience and your opponent's. It effectively hides inconsistencies in places you aren't paying attention to, like where your opponent is aiming. I'm not sure I actually agree with this statement. Client-side lag compensation as far as I understand it (or at least how I'm describing it) is to allow the client to predict what is going in-between server updates. Server-side lag compensation takes into account the latency of each client and attempts to give a fair assessment of each player's actions based on what they must have been shown by the server at the time. >>Would the game let you pass through your opponent's trail if you couldn't see it at the time? I suppose it depends on how long that trail existed. This is certainly a difficult problem when it comes to a Tron/snakes/nibbles kind of game online. I do see where you are coming from here with the difficulty of deciding who or what should take precedence. That is the issue one will always have when employing these techniques and I think it would require some bit of experimentation to get right.
  - extension 16y ago
    By the conventional terminology (which could admittedly be less ambiguous) "client prediction" is where the client shows the player a locally predicted present game state inferred from stale authoritative information. The client guesses what is actually happening right now based on what it knows was happening some time in the past, as told by prior updates it received from the server. This works if there is a lot of temporal continuity in the game, such as there is when the laws of physics are obeyed. Sources of entropy, like player input, can't be predicted and so that is where inconsistencies will appear. "Lag compensation" is where the server accounts for client latency when making certain authoritative game logic decisions i.e. "did a bullet hit a target y/n"? Essentially, it decouples the when and the where of the event. So a target can be hit by a bullet now but the hit took place where the target was some time in the past. Since that would generally feel ridiculous to the player, it can only be done in very particular situations where the event is mostly entropic and instantaneous, and therefore unpredictable (e.g. a player firing a bullet with infinite velocity) and where the inconsistency is unlikely to be noticed (because you typically aren't paying much attention to where other players are aiming). The lag comp described on that page you linked to is only for player vs NPC, where the NPC is totally predictable and therefor always appears in the same place to all players. If you tried to lag comp a slow moving projectile with player vs player then the projectile would have a curved path, following the target around as they tried to dodge it. It would give a blatant unfair advantage to lagged players. I don't see any lag comp options for light cycles since your only real options for bending the game rules are a) letting players pass through walls/crash into walls that aren't there or b) moving players/walls around retroactively, both of which will appear obvious and unfair.
- endergen 16y ago
  I think I understand your point, in that with the game play of light cycles there are only absolute moves that you've made. You still want to the player's action to play instantly on his and show up as fast as possible in the server's and other players' simulations. Obviously lag in a moment of high importance is really going to feel unexpected in a light cycles match so it isn't a game suited to high amounts of lag. You still want to see the other player move smoothly, and you can have that happen if you guess where he is rather than wait for acknowledgement. His prediction happens to be super easy while also being dangerously wrong if he's turned in front of you. There is no solution to this type of gameplay being networked synced. Low latency is your only bet.
  - zemanel 16y ago
    something that occurs me is that the server has to keep track of every point of every player to track collisions, basically a table of "playerID,x,y,timestamp", so when the client gets a status update, instead of receiving the current position of other players, he would get the moves of all players since the last update, limited to the x1,y1,x2,y2 of the client's viewport. Then the client would normalize the data (over time)?

extension 16y ago

How would that be used in light cycles? Would you see your opponent's trail jump around as the client prediction is corrected? Would the game let you pass through your opponent's trail if you couldn't see it at the time? Lag comp takes advantage of the independence of your gaming experience and your opponent's. It effectively hides inconsistencies in places you aren't paying attention to, like where your opponent is aiming. In light cycles, your actions and consequences are much more tightly coupled to those of your opponents. There is nowhere to hide the inconsistency.

coderdude 16y ago
Don't get me wrong, I understand the stark contrast between CS and this style of gameplay. >>Would you see your opponent's trail jump around as the client prediction is corrected? The prediction in this game would only be which direction the opponents are moving in. Between packets the client would continue moving opponents in their last known direction. Once the client knows better it must change the game state to the player. If that means one opponent moved several game units in one direction and must be moved back those several units and then turned in a different direction then that is what must happen, and yes it will be jarring to the player, but this happens all the time in online gameplay. >>Lag comp takes advantage of the independence of your gaming experience and your opponent's. It effectively hides inconsistencies in places you aren't paying attention to, like where your opponent is aiming. I'm not sure I actually agree with this statement. Client-side lag compensation as far as I understand it (or at least how I'm describing it) is to allow the client to predict what is going in-between server updates. Server-side lag compensation takes into account the latency of each client and attempts to give a fair assessment of each player's actions based on what they must have been shown by the server at the time. >>Would the game let you pass through your opponent's trail if you couldn't see it at the time? I suppose it depends on how long that trail existed. This is certainly a difficult problem when it comes to a Tron/snakes/nibbles kind of game online. I do see where you are coming from here with the difficulty of deciding who or what should take precedence. That is the issue one will always have when employing these techniques and I think it would require some bit of experimentation to get right.
- extension 16y ago
  By the conventional terminology (which could admittedly be less ambiguous) "client prediction" is where the client shows the player a locally predicted present game state inferred from stale authoritative information. The client guesses what is actually happening right now based on what it knows was happening some time in the past, as told by prior updates it received from the server. This works if there is a lot of temporal continuity in the game, such as there is when the laws of physics are obeyed. Sources of entropy, like player input, can't be predicted and so that is where inconsistencies will appear. "Lag compensation" is where the server accounts for client latency when making certain authoritative game logic decisions i.e. "did a bullet hit a target y/n"? Essentially, it decouples the when and the where of the event. So a target can be hit by a bullet now but the hit took place where the target was some time in the past. Since that would generally feel ridiculous to the player, it can only be done in very particular situations where the event is mostly entropic and instantaneous, and therefore unpredictable (e.g. a player firing a bullet with infinite velocity) and where the inconsistency is unlikely to be noticed (because you typically aren't paying much attention to where other players are aiming). The lag comp described on that page you linked to is only for player vs NPC, where the NPC is totally predictable and therefor always appears in the same place to all players. If you tried to lag comp a slow moving projectile with player vs player then the projectile would have a curved path, following the target around as they tried to dodge it. It would give a blatant unfair advantage to lagged players. I don't see any lag comp options for light cycles since your only real options for bending the game rules are a) letting players pass through walls/crash into walls that aren't there or b) moving players/walls around retroactively, both of which will appear obvious and unfair.
endergen 16y ago
I think I understand your point, in that with the game play of light cycles there are only absolute moves that you've made. You still want to the player's action to play instantly on his and show up as fast as possible in the server's and other players' simulations. Obviously lag in a moment of high importance is really going to feel unexpected in a light cycles match so it isn't a game suited to high amounts of lag. You still want to see the other player move smoothly, and you can have that happen if you guess where he is rather than wait for acknowledgement. His prediction happens to be super easy while also being dangerously wrong if he's turned in front of you. There is no solution to this type of gameplay being networked synced. Low latency is your only bet.
- zemanel 16y ago
  something that occurs me is that the server has to keep track of every point of every player to track collisions, basically a table of "playerID,x,y,timestamp", so when the client gets a status update, instead of receiving the current position of other players, he would get the moves of all players since the last update, limited to the x1,y1,x2,y2 of the client's viewport. Then the client would normalize the data (over time)?