4 ms·

This is a pretty dated article -- 2001 -- but the basic concepts still hold up. I came across this a few months ago when I wanted to write some net code for a c

This is a pretty dated article -- 2001 -- but the basic concepts still hold up. I came across this a few months ago when I wanted to write some net code for a canvas game project I was tinkering on. This resource helped.

zemanel 16y ago
would you think it would be required to implement client-side prediction, lag compensation (normalization) and etc on a simple tron-like multiplayer game?
- coderdude 16y ago
  Honestly, it's difficult for me to say. Is this two players over the Internet? More than two players? The movement mechanics matter a lot. I've never seen Tron or played any Tron games, but if it will play something like this: http://www.virginmedia.com/images/tron2-431x300.jpg http://www.virginmedia.com/images/tron2-431x300.jpg Which appears to be kind of like snakes/nibbles then I could see you requiring some of the techniques the article describes. Since players are mostly moving in a single direction for a period of time you could extrapolate their movements by continuing their motion in that single direction until the server is made otherwise aware of where the player decided to move. Then you can reset the player back to the position they were at when they changed direction and then continue them along that path. However, for when the action gets close-up and quick, where perhaps the two players are twitching back and forth trying to avoid or ensnare each other then yes I can see how lag compensation will be necessary so that the server can accurately figure out where each player thought the other player was when they made their move. Here are two articles that I think will help you, and they helped me when I was working at this problem: http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php http://www.gamasutra.com/view/feature/3230/dead_reckoning_la... http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp
  - zemanel 16y ago
    yeah i was wondering about creating a single arena with a million square points or more, each player would see a smaller viewport focused on his cycle (snake/nibble), new players would spawn in a empty spot and so on. the server would have to store each point of the trail to calculate collisions. EDIT: the game's not particularly exciting but i'd imagine that being on the same canvas avoiding the trail of potentially thousands of players (plus your own) could be cool EDIT2: also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome
    - extension 16y ago
      also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome Hmm.. what would the trails look like? A line is pretty easy to avoid in three dimensions. Maybe rectangles could be extruded from the line segment between the last two turning points. Or you somehow control two light cycles and extrude the line between them.
      - zemanel 16y ago
        "turning on the Z axis" (dunno if i said it correctly, could be also X or Y) would essentially be changing the plane, meaning, the arena would be a cube instead of a 2 dimensional plane. Let's say a couple of players would create a dead end you couldn't avoid by going up, down, left or right, you could rotate the view. For example on a normal snake 2D game, pressing the key oposite and to the direction your'e heading is meaningless, you can't go straight back and your'e already going forward. On a cube those keys could be mapped to 3D rotation. You would still see the game as 2D and depth would be emulated for example with transparency, were close trails are opaque and deeper objects are transparent, so that you could know if you could turn or not, for example on a trail right in front of you. edit: fix typos ps.: of course playing on a cube is only be interesting when you have a lot of players in the game, or else it would be very impractical to corner someone (since you would need to get him wrapped completely)
        16y ago
- extension 16y ago
  It doesn't matter per se how simple the game is. If the game mechanics are sensitive to temporal latency between players then the game can benefit from these methods. However, I don't see how a light-cycles game could use any kind of prediction or lag comp. Since players can change direction instantaneously and at arbitrary times, there is nothing that can be predicted. And any kind of lag comp would appear as obvious breaches of the game rules.
  - coderdude 16y ago
    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.
- gcr 16y ago
  Armegatron has a little triangle around multiplayer opponents that describes where their light cycle could be with respect to the moves they could make until the packet reaches you. It's quite interesting; go grab http://armagetronad.net/screenshots.php http://armagetronad.net/screenshots.php and play a network game to see how it works. EDIT: Wait a moment, it wasn't GLTron, it was Armegatron EDIT 2: See http://wiki.armagetronad.net/index.php?title=Lag http://wiki.armagetronad.net/index.php?title=Lag

zemanel 16y ago

would you think it would be required to implement client-side prediction, lag compensation (normalization) and etc on a simple tron-like multiplayer game?

coderdude 16y ago
Honestly, it's difficult for me to say. Is this two players over the Internet? More than two players? The movement mechanics matter a lot. I've never seen Tron or played any Tron games, but if it will play something like this: http://www.virginmedia.com/images/tron2-431x300.jpg http://www.virginmedia.com/images/tron2-431x300.jpg Which appears to be kind of like snakes/nibbles then I could see you requiring some of the techniques the article describes. Since players are mostly moving in a single direction for a period of time you could extrapolate their movements by continuing their motion in that single direction until the server is made otherwise aware of where the player decided to move. Then you can reset the player back to the position they were at when they changed direction and then continue them along that path. However, for when the action gets close-up and quick, where perhaps the two players are twitching back and forth trying to avoid or ensnare each other then yes I can see how lag compensation will be necessary so that the server can accurately figure out where each player thought the other player was when they made their move. Here are two articles that I think will help you, and they helped me when I was working at this problem: http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php http://www.gamasutra.com/view/feature/3230/dead_reckoning_la... http://www.gamedev.net/reference/articles/article1370.asp http://www.gamedev.net/reference/articles/article1370.asp
- zemanel 16y ago
  yeah i was wondering about creating a single arena with a million square points or more, each player would see a smaller viewport focused on his cycle (snake/nibble), new players would spawn in a empty spot and so on. the server would have to store each point of the trail to calculate collisions. EDIT: the game's not particularly exciting but i'd imagine that being on the same canvas avoiding the trail of potentially thousands of players (plus your own) could be cool EDIT2: also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome
  - extension 16y ago
    also if it was possible to add 3D to it (the ability to turn in the Z axis) could be pretty awesome Hmm.. what would the trails look like? A line is pretty easy to avoid in three dimensions. Maybe rectangles could be extruded from the line segment between the last two turning points. Or you somehow control two light cycles and extrude the line between them.
    - zemanel 16y ago
      "turning on the Z axis" (dunno if i said it correctly, could be also X or Y) would essentially be changing the plane, meaning, the arena would be a cube instead of a 2 dimensional plane. Let's say a couple of players would create a dead end you couldn't avoid by going up, down, left or right, you could rotate the view. For example on a normal snake 2D game, pressing the key oposite and to the direction your'e heading is meaningless, you can't go straight back and your'e already going forward. On a cube those keys could be mapped to 3D rotation. You would still see the game as 2D and depth would be emulated for example with transparency, were close trails are opaque and deeper objects are transparent, so that you could know if you could turn or not, for example on a trail right in front of you. edit: fix typos ps.: of course playing on a cube is only be interesting when you have a lot of players in the game, or else it would be very impractical to corner someone (since you would need to get him wrapped completely)
      - 16y ago
extension 16y ago
It doesn't matter per se how simple the game is. If the game mechanics are sensitive to temporal latency between players then the game can benefit from these methods. However, I don't see how a light-cycles game could use any kind of prediction or lag comp. Since players can change direction instantaneously and at arbitrary times, there is nothing that can be predicted. And any kind of lag comp would appear as obvious breaches of the game rules.
- coderdude 16y ago
  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.
gcr 16y ago
Armegatron has a little triangle around multiplayer opponents that describes where their light cycle could be with respect to the moves they could make until the packet reaches you. It's quite interesting; go grab http://armagetronad.net/screenshots.php http://armagetronad.net/screenshots.php and play a network game to see how it works. EDIT: Wait a moment, it wasn't GLTron, it was Armegatron EDIT 2: See http://wiki.armagetronad.net/index.php?title=Lag http://wiki.armagetronad.net/index.php?title=Lag