razcodes said:
This works fine, the clients then take the game snapshot and do interpolation, CSP and different things. It works.
It will depend on your game, but it does trigger skepticism. Have you tried this under bad network conditions? High latency, high traffic, and error-heavy network conditions tend to break this down badly. I've seen a few games where people thought it was fine, but their testing was only on their local network.
Running physics across a network is an amazing way to destroy network performance, as values are updated and sent back over the wire. One I was brought in to help with a game that had implemented a physics-driven bowling game, worked great in the office but anything over about 8ms latency caused massive issues as the networked data was more than one frame behind.
20 Hz rate can be tolerable, 50ms round trip works if people are on good, modern connections and aren't too far away on the globe. 60 Hz is 16ms, which is often 1 graphics frame but for people with gaming monitors often 6ms is the better framerate target.
In any event, if you don't have it already, be sure you're testing under “typical" and “bad” network conditions. 200ms and 5% loss might be “typical”, and 500ms with 20% loss might be "bad" test settings, or something else that fits your game.
razcodes said:
Then why would I want to sync clocks? Why would anyone want to do it?
It depends on the type of game.
A turn based game the synchronization is your turn. It might be chess or a dungeon explorer, you can transmit the state as it exists on turn 24, the move, then the state on turn 25.
In a competitive action game or shooter, the difference between clients is far more important. Round trip time begins to matter, because what one person sees is going to be different from what another person sees, and something has to reconcile the differences.
If there is no accounting for time and you've got a star architecture, a client notifies the server then the server notifies the client. Assuming we don't have any other delays or prioritization, client A sends their position to the server with a latency delay (perhaps 75ms), the server has a tick to process it (we'll say 20Hz so it might take 16ms), and then the server sends the update to client B (perhaps another 50ms), and finally Client B processes it on the next tick which is also up to 16ms. Then you're waiting a graphics frame for it to render and present on screen, another 16ms. So 75 + 16 + 50 + 16 + 16 = 173 milliseconds. So the action shown on Client B is about 11 graphics frames behind what was done on Player A. Then the process returns as Client B's response is transmitted through the chain back to Client A, another 173 milliseconds later. Now Client A sees what happens, and from their perspective, B took advantage of where A was about a third of a second ago, which feels like ages and ages. It feels like the other player is cheating simply by being out of date through latency.
Depending on the game that might not matter. A casual turn based game it isn't a problem. Notification of events that happened like a Tetris game where you occasionally queue up dropped blocks, the drop might happen on a slightly later piece but it isn't normally critical to gameplay. On a competitive shooter, however, that same time feels like an eternity. They might be killed by a position they used to be at but no longer are; they might have seemingly dodged a headshot because they were gone on the opposite side but not the local side. Resolving that is quite complex.
If you're in a game where it matters, with competitive shooters, brawlers, MOBA, and other action combat games, highly competitive players can see an enormous impact. Network jitter can absolutely destroy top-tier players, and latency differences between players of high skill has a very strong, almost linear correlation with loss. Give them a latency difference of more than about 20ms and it becomes a clear play advantage to the lower-latency machine.
In those games, you need to do everything you can to mitigate the effects of latency between clients. That's why you see it in major engines like Unreal and Source and see it (or don't because it isn't public) in Halo and LoL in their own engines take a lot of effort to reduce the harm it can do. Even so, it is about containing the harm because it cannot be prevented entirely.
