would you think it would be required to implement client-side prediction, lag compensation (normalization) and etc on a simple tron-like multiplayer game?
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.
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.
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.
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.
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.
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.
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)?
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:
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:
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
"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)
How would you ever find yourself on the same plane as the other players? Or even on any plane that they had ever been on? If the trails are infinitely thin lines arbitrarily positioned in 3D space then it's effectively impossible to hit them.
You could quantize them on some or all of the axes but I would find that less elegant than keeping the game in continuous space and making the trails planar somehow.
no, because everyone's moving in x,y,x integer coordinates limited to the cube's dimension, max x,y,x = 1000 for example, and the server records the coordinates you'be moving along (0,0,1), (1,0,0), (2,0,0). when you move into a coordinate someone (or you) has been, its a collision.
although you move 1 point at a time, the line thickness in the Ui may be more than 1 pixel, it's just on the UI level.
you start on the usual plain:
y
|
| *-->
|
z-------x
y is the vertical coordinate and x is the horizontal. that's the plane your're seeing on your game client. if you're moving right along the x line, you're increasing the x coordinate (x,y, z) while the others are constant
if you press 'D' or 'right', you "turn" the view on the y axis, and then the plane you're on becomes:
y
|
| *-->
|
x-----z
now, y is the (same) vertical but the horizontal has become z, you keep moving right but x value has fixed and now z is increasing. if you press up, you start increasing y, but x, and z are still fixed (since you havent moved on their axis)
the server records the x,y,x coordinates you been through (for everyone) and when someone moves into a recorded coordinate, game over man.
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 and play a network game to see how it works.
EDIT: Wait a moment, it wasn't GLTron, it was Armegatron
