3 ms·

> Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. It depends on whether the game is multi-player

> Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. It depends on whether the game is multi-player and, if so, how it keeps the different players in sync with each other. Games that rely on deterministic gameplay can desync (two players don't see the same world state) and abort if one player's simulation drops a frame while the other doesn't.

Groxx 3y ago
If you have multiplayer like this, you absolutely do not have a hard requirement on frame latency. You don't control network latency spikes. Latency tolerance is a hard requirement, or you will have constant problems and likely be unplayable. Or custom networking and hardware stacks, which is deep into esoteric territory.
electroly 3y ago
That's still just a degradation of user experience and not a fatal fault. Indeed, support for running in desynced mode is written is because they know deadlines can be missed. In hard realtime, deadlines can't be missed. There's no recovery; it's a critical fault and you have to halt or failover to a backup.
- munificent 3y ago
  > That's still just a degradation of user experience and not a fatal fault. I don't know how you'd describe a game spontaneously aborting not a "fatal fault". Yes, it's not turning off someone's pacemaker, but within the scope of what a game is able to do, kicking the player back to the matchmaking screen in the middle of a game is about as fatal as it gets.
  - fluoridation 3y ago
    That's only going to happen if the client has such a massive network latency spike that the server thinks it's disconnected. At least half a second, possibly more. You're never going to get that kind of delay from synchronizing threads, unless the process totally deadlocks. EDIT: Well, there is one situation where you might get delays like that: if the computer is so woefully inadequate to run the game that it consistently misses frame deadlines by several hundred milliseconds. Of course, in such a situation a different concurrent algorithm wouldn't have solved anything anyway.
  - fiddlerwoaroof 3y ago
    What I don’t understand here is how missing a frame deadline in this situation (<1/60 of a second or 16ms) is intolerable when typical network latency varies constantly by much more than this. It seems to me that if the latency requirements were this strict you could only support LAN multiplayer.
    - squeaky-clean 3y ago
      The only scenario I can imagine is some interactive game installation at Disney/etc. But there'd still be no actual benefit over an architecture more lenient to timing deviations.
  - caconym_ 3y ago
    Literally any multiplayer game will have a "fatal fault" if its connection to the other players and/or server is interrupted for long enough, but it seems disingenuous to describe a system tolerant of delays variable across several orders of magnitude, up to hundreds of milliseconds or even full seconds, as "hard real time" in the sense in which the term is generally understood.
dzaima 3y ago
If you want to support players with ping over 16ms, there's no way you're gonna be synchronizing input from one frame to the output of the same frame for another player; there'll necessarily be some latency hiding, at which point any freeze should be coverable via just treating it as a temporarily-high ping and thus temporarily more latency hiding.
ack_complete 3y ago
Lockstep simulation can't be hard tied to frame rate. Two computers will never have precisely the same frame timing -- even if they are running identical video modes, clocks are only accurate to within a tolerance and will diverge. The simulation has to allow for simulation ticks running independently from rendering frames.
forrestthewoods 3y ago
> Games that rely on deterministic gameplay can desync (two players don't see the same world state) and abort if one player's simulation drops a frame while the other doesn't. Right. This is why lockstep deterministic (LSD) games are bound to the SLOWEST player's machine. No LSD game in existence crashes the game if one player's machine falls behind. Instead you either pause the simulation for all players until they catch up or you slow down time itself. Source: shipped RTS games that were lockstep deterministic.
friendzis 3y ago
If your program state tracking/management is so tightly coupled to renderer that missing a frame can desync, then you have much bigger architectural problems anyway. Network latency is a thing and your state management subsystem absolutely has to be fault tolerant.
meheleventyone 3y ago
Since you can’t control latency of individual packets let alone that the hardware timing is identical this isn’t practical as a requirement. Deterministic gameplay means after the same x frames with the same external inputs you will end up with the same state y on different hardware. Therefore we only need to make sure the clients stay within a reasonable margin. We can do this by waiting for all players inputs so moving at the slowest speed possible which is the lock-step method. Or we can change our measured frame time so each tick (which still ticks the same amount of sim time) is seen as faster or slower. That way we can track the other frames that other clients have completed from the input they send and slow or speed ourselves up to maintain a decent margin. This is the scheme used in rollback networking as the naïve implementation where this isn’t the case forces all rollbacks onto the faster machine.

Groxx 3y ago

If you have multiplayer like this, you absolutely do not have a hard requirement on frame latency. You don't control network latency spikes. Latency tolerance is a hard requirement, or you will have constant problems and likely be unplayable. Or custom networking and hardware stacks, which is deep into esoteric territory.

electroly 3y ago

That's still just a degradation of user experience and not a fatal fault. Indeed, support for running in desynced mode is written is because they know deadlines can be missed. In hard realtime, deadlines can't be missed. There's no recovery; it's a critical fault and you have to halt or failover to a backup.

munificent 3y ago
> That's still just a degradation of user experience and not a fatal fault. I don't know how you'd describe a game spontaneously aborting not a "fatal fault". Yes, it's not turning off someone's pacemaker, but within the scope of what a game is able to do, kicking the player back to the matchmaking screen in the middle of a game is about as fatal as it gets.
- fluoridation 3y ago
  That's only going to happen if the client has such a massive network latency spike that the server thinks it's disconnected. At least half a second, possibly more. You're never going to get that kind of delay from synchronizing threads, unless the process totally deadlocks. EDIT: Well, there is one situation where you might get delays like that: if the computer is so woefully inadequate to run the game that it consistently misses frame deadlines by several hundred milliseconds. Of course, in such a situation a different concurrent algorithm wouldn't have solved anything anyway.
- fiddlerwoaroof 3y ago
  What I don’t understand here is how missing a frame deadline in this situation (<1/60 of a second or 16ms) is intolerable when typical network latency varies constantly by much more than this. It seems to me that if the latency requirements were this strict you could only support LAN multiplayer.
  - squeaky-clean 3y ago
    The only scenario I can imagine is some interactive game installation at Disney/etc. But there'd still be no actual benefit over an architecture more lenient to timing deviations.
- caconym_ 3y ago
  Literally any multiplayer game will have a "fatal fault" if its connection to the other players and/or server is interrupted for long enough, but it seems disingenuous to describe a system tolerant of delays variable across several orders of magnitude, up to hundreds of milliseconds or even full seconds, as "hard real time" in the sense in which the term is generally understood.

dzaima 3y ago

If you want to support players with ping over 16ms, there's no way you're gonna be synchronizing input from one frame to the output of the same frame for another player; there'll necessarily be some latency hiding, at which point any freeze should be coverable via just treating it as a temporarily-high ping and thus temporarily more latency hiding.

ack_complete 3y ago

Lockstep simulation can't be hard tied to frame rate. Two computers will never have precisely the same frame timing -- even if they are running identical video modes, clocks are only accurate to within a tolerance and will diverge. The simulation has to allow for simulation ticks running independently from rendering frames.

forrestthewoods 3y ago

> Games that rely on deterministic gameplay can desync (two players don't see the same world state) and abort if one player's simulation drops a frame while the other doesn't. Right. This is why lockstep deterministic (LSD) games are bound to the SLOWEST player's machine. No LSD game in existence crashes the game if one player's machine falls behind. Instead you either pause the simulation for all players until they catch up or you slow down time itself. Source: shipped RTS games that were lockstep deterministic.

friendzis 3y ago

If your program state tracking/management is so tightly coupled to renderer that missing a frame can desync, then you have much bigger architectural problems anyway. Network latency is a thing and your state management subsystem absolutely has to be fault tolerant.

meheleventyone 3y ago

Since you can’t control latency of individual packets let alone that the hardware timing is identical this isn’t practical as a requirement. Deterministic gameplay means after the same x frames with the same external inputs you will end up with the same state y on different hardware. Therefore we only need to make sure the clients stay within a reasonable margin. We can do this by waiting for all players inputs so moving at the slowest speed possible which is the lock-step method. Or we can change our measured frame time so each tick (which still ticks the same amount of sim time) is seen as faster or slower. That way we can track the other frames that other clients have completed from the input they send and slow or speed ourselves up to maintain a decent margin. This is the scheme used in rollback networking as the naïve implementation where this isn’t the case forces all rollbacks onto the faster machine.