3 ms·

That's kind of fascinating. Would you suggest some reading on this? Question: if I send to other 3 players (via gossip say) the event "in frame N, I clicked the

That's kind of fascinating. Would you suggest some reading on this? Question: if I send to other 3 players (via gossip say) the event "in frame N, I clicked the B button that causes monster to die" but my network lags and in the mean time they do other events where someone else kills the monster and they see the monster dying from another player event. After a few ms my events gets to them, their state is rewind with the monster dying because of me instead of the other player. In other words, this causes players to see the monster dying twice.

derefr 6y ago
> In other words, this causes players to see the monster dying twice. The frames that are replayed aren't visibly replayed. They're re-computed, but the visible effect is more of a "lurch" from one world-state to another one. In this case, the monster has been dead for a second or two already, but suddenly each player's score counter would jump around to show that it's actually player P who did it, and gained the points for it. Except for player P themselves, who experiences no change. It's very similar in experiential effect to the effect when an inherently-networked client-server game does client-side prediction, and then the server sends the canonical state which disagrees from the client's predicted state, and the client has to lurch into the server's canonical state. People's avatars pop into different positions; in an FPS, you might suddenly be dead "out of nowhere"; in a racing game, you might suddenly be spiralling out of the way because your path turned out to collide with that of another car that wasn't originally there; etc. Inherently-networked games sometimes have interpolation ("lerp"-ing) code to smooth out this lurch between client-side predicted positions and canonical server-side state — usually, if the only thing that's incorrect is positioning, the client will try to generate a few interpolated frames of movement that takes objects from their incorrectly-predicted positions to their server-prescribed positions; and then it'll play those frames in fast-forward, so that they've all been played out well before the server sends its next update. But this only works when the server isn't communicating every single frame (otherwise there's no time to replay the lerp); and it basically only works for positioning changes — if someone does manage to cause a discrete alteration to the game-state (like changing who killed an enemy), that will still usually cause a sudden "lurch" into the new game-state in these engines. The interpolation-frame generator code just gives up. (Though, for especially-important things like who won a match, inherently-networked games just do a hard consensus-sync of all players — usually during a screen transition — before actually showing a results screen. People get quite cross when their results lurch!) And, of course, games that weren't inherently-networked, but which are instead being networked "on the emulation layer", have no logic for lerping, and cannot, unless lerping logic is hand-written by some kind soul for each emulated game's engine. Possible if you're hand-crafting an emulator designed to play a single game; quite unlikely if you're just building a general system emulator — especially if, as with most authors of general-system emulators, your goal is faithful reproduction of the behavior of the original system. > Would you suggest some reading on this? No idea if there is any reading on how emulators do this, tbh. (I'm self-taught on this subject, from working with open-source emulator codebases.) But any modern textbook on [inherently-]networked client-server game-engine development should talk about client-side run-ahead prediction and interpolation-frame generation. I believe there's some book which deep-dives into the network architecture of Doom, or Quake, or Unreal Tournament, or one of those early networked games, and uses it to explain the history/invention of these client-side prediction features. I can't seem to Google it for the life of me, though. Can anyone here assist?

derefr 6y ago

> In other words, this causes players to see the monster dying twice. The frames that are replayed aren't visibly replayed. They're re-computed, but the visible effect is more of a "lurch" from one world-state to another one. In this case, the monster has been dead for a second or two already, but suddenly each player's score counter would jump around to show that it's actually player P who did it, and gained the points for it. Except for player P themselves, who experiences no change. It's very similar in experiential effect to the effect when an inherently-networked client-server game does client-side prediction, and then the server sends the canonical state which disagrees from the client's predicted state, and the client has to lurch into the server's canonical state. People's avatars pop into different positions; in an FPS, you might suddenly be dead "out of nowhere"; in a racing game, you might suddenly be spiralling out of the way because your path turned out to collide with that of another car that wasn't originally there; etc. Inherently-networked games sometimes have interpolation ("lerp"-ing) code to smooth out this lurch between client-side predicted positions and canonical server-side state — usually, if the only thing that's incorrect is positioning, the client will try to generate a few interpolated frames of movement that takes objects from their incorrectly-predicted positions to their server-prescribed positions; and then it'll play those frames in fast-forward, so that they've all been played out well before the server sends its next update. But this only works when the server isn't communicating every single frame (otherwise there's no time to replay the lerp); and it basically only works for positioning changes — if someone does manage to cause a discrete alteration to the game-state (like changing who killed an enemy), that will still usually cause a sudden "lurch" into the new game-state in these engines. The interpolation-frame generator code just gives up. (Though, for especially-important things like who won a match, inherently-networked games just do a hard consensus-sync of all players — usually during a screen transition — before actually showing a results screen. People get quite cross when their results lurch!) And, of course, games that weren't inherently-networked, but which are instead being networked "on the emulation layer", have no logic for lerping, and cannot, unless lerping logic is hand-written by some kind soul for each emulated game's engine. Possible if you're hand-crafting an emulator designed to play a single game; quite unlikely if you're just building a general system emulator — especially if, as with most authors of general-system emulators, your goal is faithful reproduction of the behavior of the original system. > Would you suggest some reading on this? No idea if there is any reading on how emulators do this, tbh. (I'm self-taught on this subject, from working with open-source emulator codebases.) But any modern textbook on [inherently-]networked client-server game-engine development should talk about client-side run-ahead prediction and interpolation-frame generation. I believe there's some book which deep-dives into the network architecture of Doom, or Quake, or Unreal Tournament, or one of those early networked games, and uses it to explain the history/invention of these client-side prediction features. I can't seem to Google it for the life of me, though. Can anyone here assist?