3 ms·

Thanks very much for this, these are great articles. It seems one would need some way of synchronizing clocks (or measuring the lag between server and client).

by Luc 11y ago

Thanks very much for this, these are great articles. It seems one would need some way of synchronizing clocks (or measuring the lag between server and client). Do you know if there is a standard way of accomplishing this?

exDM69 11y ago
> Do you know if there is a standard way of accomplishing this? Synchronizing clocks is one of the difficult problems in distributed computing. Games tend to avoid doing proper synchronization of clocks by working in discrete time steps (frames). Because games run at 15-60 frames per second (a bit more for simulators), you can get away with synchronizing the clocks to +/- a few frames, ie. an accuracy of tens of milliseconds is good enough to provide a perception of real time. In other words: game time is measured with an unsigned integer that tells how many time steps have elapsed since the game started.
- techdragon 11y ago
  Sorry but that needs a rather large asterisk applied to it. In the current era of 120Hz LCD displays and a Billion dollar market for video games. It's becoming very evident that the "best", not in a AAA title sense, but in the 'so popular it becomes a sport with professional players" sense, games are those that have put a LOT more effort into the implications of their network synchronisation algorithms. Some game engines have extremely long tail lives as popular mods take advantage of reliable network behaviour to create gaming experiences that don't infuriate passionate players keeping them alive many years after the game that wrote the engine moved on.
  - exDM69 11y ago
    Very good point! Back in Quake 1 days, the gameplay framerate was only 15 frames per second, so a more crude mechanism would do. I guess modern AAA games synchronize their clocks with an algorithm similar to what NTP is using. We're still talking about discrete time steps, though, so there's some tolerance for a little clock mismatch.
    - animal531 11y ago
      Usually these days we use client/server for most games, meaning that initially the server is taken as being authoritative on time. It can collect and use a running average of pings to/from all clients which it can then use to order events (ie. did I do X before you did Y?). But that's where the really hard (and fun!) coding and choices start, such as for example future prediction and unrolling of actions. Roughly speaking, for prediction (to lessen the effect of perceived lag), the server could predict that I was moving forward up to the last packet received, so I'm probably still going to be moving forward. It can then use the predicted values in all calculations until it receives an actual packet informing it what actually happened (at which point it will need to decide how to handle possibly conflicting information, which is handled the same as below). For unrolling, if you have for example a 50ms ping and I 100ms; then at T+51ms you tell the server that you killed me, but I do the same at T+100ms - effectively compensating for the 50ms of lag difference between us you should die since I killed you 1ms before you killed me. BUT now it really depends on the server choices, do you kill me because your message got there first (old-school FPS); or does the server wait for my info since I'm involved in the action and then retroactively adjust you? Worse, since the server only gets my info on T+100 you will at best only get it at T+150, meaning that you will perceive 99ms of being alive (and maybe during which you killed someone else) which the server will then have to discard before killing you (some modern FPS use this scheme, you'll notice it where you peek out around a corner from safety and then go back, before suddenly being dead from an impossible shot). Also tough is the fact that it's not a single unroll, during the extra 99ms of being alive you would have still been sending packets to the server which then all have to be unrolled.
kaoD 11y ago
I've used this technique[0] successfully in a networked minesweeper game I made ages ago. Wikipedia lists more algorithms[1]. [0] http://www.mine-control.com/zack/timesync/timesync.html http://www.mine-control.com/zack/timesync/timesync.html [1] https://en.wikipedia.org/wiki/Clock_synchronization https://en.wikipedia.org/wiki/Clock_synchronization

by Luc 11y ago

exDM69 11y ago

> Do you know if there is a standard way of accomplishing this? Synchronizing clocks is one of the difficult problems in distributed computing. Games tend to avoid doing proper synchronization of clocks by working in discrete time steps (frames). Because games run at 15-60 frames per second (a bit more for simulators), you can get away with synchronizing the clocks to +/- a few frames, ie. an accuracy of tens of milliseconds is good enough to provide a perception of real time. In other words: game time is measured with an unsigned integer that tells how many time steps have elapsed since the game started.

techdragon 11y ago
Sorry but that needs a rather large asterisk applied to it. In the current era of 120Hz LCD displays and a Billion dollar market for video games. It's becoming very evident that the "best", not in a AAA title sense, but in the 'so popular it becomes a sport with professional players" sense, games are those that have put a LOT more effort into the implications of their network synchronisation algorithms. Some game engines have extremely long tail lives as popular mods take advantage of reliable network behaviour to create gaming experiences that don't infuriate passionate players keeping them alive many years after the game that wrote the engine moved on.
- exDM69 11y ago
  Very good point! Back in Quake 1 days, the gameplay framerate was only 15 frames per second, so a more crude mechanism would do. I guess modern AAA games synchronize their clocks with an algorithm similar to what NTP is using. We're still talking about discrete time steps, though, so there's some tolerance for a little clock mismatch.
  - animal531 11y ago
    Usually these days we use client/server for most games, meaning that initially the server is taken as being authoritative on time. It can collect and use a running average of pings to/from all clients which it can then use to order events (ie. did I do X before you did Y?). But that's where the really hard (and fun!) coding and choices start, such as for example future prediction and unrolling of actions. Roughly speaking, for prediction (to lessen the effect of perceived lag), the server could predict that I was moving forward up to the last packet received, so I'm probably still going to be moving forward. It can then use the predicted values in all calculations until it receives an actual packet informing it what actually happened (at which point it will need to decide how to handle possibly conflicting information, which is handled the same as below). For unrolling, if you have for example a 50ms ping and I 100ms; then at T+51ms you tell the server that you killed me, but I do the same at T+100ms - effectively compensating for the 50ms of lag difference between us you should die since I killed you 1ms before you killed me. BUT now it really depends on the server choices, do you kill me because your message got there first (old-school FPS); or does the server wait for my info since I'm involved in the action and then retroactively adjust you? Worse, since the server only gets my info on T+100 you will at best only get it at T+150, meaning that you will perceive 99ms of being alive (and maybe during which you killed someone else) which the server will then have to discard before killing you (some modern FPS use this scheme, you'll notice it where you peek out around a corner from safety and then go back, before suddenly being dead from an impossible shot). Also tough is the fact that it's not a single unroll, during the extra 99ms of being alive you would have still been sending packets to the server which then all have to be unrolled.

kaoD 11y ago

I've used this technique[0] successfully in a networked minesweeper game I made ages ago. Wikipedia lists more algorithms[1]. [0] http://www.mine-control.com/zack/timesync/timesync.html http://www.mine-control.com/zack/timesync/timesync.html [1] https://en.wikipedia.org/wiki/Clock_synchronization https://en.wikipedia.org/wiki/Clock_synchronization