3 ms·

I read some articles on synchronizing game state in networked games that had a specific name. I remember seeing some mortal-combat/killer-instinct videos though

I read some articles on synchronizing game state in networked games that had a specific name. I remember seeing some mortal-combat/killer-instinct videos though my interest is in RTS so probably discovered it that way. Oh yes, it's called Rollback Netcode[0]. Probably from this Stormgate status update[1]. This is much more complex in that the client and server share commands rather than state and they both have to be exactly deterministic in processing commands to get the new states. There's also computational overhead when rolling back then replaying forward which can be a lot if the game state is large. Searching "netcode" in reddit.com/r/gamedev could show other solutions like the one you've come up with. Netcode has been mentioned on HN in the past as well, though I don't remember--only found by searching. Nice work BTW, on both the game progress and smooth playable sync. [0] https://en.wikipedia.org/wiki/Netcode https://en.wikipedia.org/wiki/Netcode [1] https://nichegamer.com/stormgate-first-rts-rollback-netcode https://nichegamer.com/stormgate-first-rts-rollback-netcode

vvanders 4y ago
There's broadly 2 types of state synchronization, lockstep and dead-reckoning. From the article it sounds like this is doing dead-reckoning where you let clients simulate locally and then resolve those differences on a continuous basis. It works really well in games where you're trying to "predict" what another player is doing at some future point in time but does worse for instant-reaction type game types. It also has the problem where bandwidth scales with each entity so it can get out of hand pretty quickly with a large number of entities. The other approach(and the one most RTS games use) is called lockstep where you have a fully deterministic game simulation and clients send each other's input's to each other and all of them run in "lockstep" with each other. Generally this adds latency but has the benefit of scaling well to a large number of entities. It also requires your game simulation be deterministic which is extra fun when you have crossplay with different CPU architectures/OSes. If you've ever hit a "sync/divergence" error in those types of games that's usually a gamestate checksum that failed and bailed(some games were smart enough to re-sync the gamestate which is similar to host migration in P2P titles). Rollback is a bit of a hybrid of both where you run closer to dead-reckoning(I.E. clients simulate all entities) but as inputs from other clients come in the simulation is re-wound to that point(I.E. "rolled back") and then re-run with the new inputs + some smoothing. It works really well for reaction based games which is why you see it widely used in fighting games and an early version of that was used in many FPSes for critical things like hit-tests(with fun byproducts of getting "warped" around a corner in high latency situations if getting hit changed things like movespeed). Networking in games is an absolute blast, you have the fun technical problems outlined above but there's also an aspect of psychology/game design where a lot of what you're doing is "masking" latency in a way that's not visible to the user. A simple example here is playing hit sounds/effects locally but resolving them server-side. The 100-200ms latency isn't noticable if there are things happening client-side. From the game design side you can have games where it's about predicting where an action will happen 200ms-1000ms+ in the future which is much more latency tolerant. It's how games like Subspace[1] back in '99 was able to do 100s of players with 250-500ms latency and still have a high fidelity game since it was all about prediction instead of twitch reaction. [1] https://en.wikipedia.org/wiki/SubSpace_(video_game) https://en.wikipedia.org/wiki/SubSpace_(video_game)
- twodave 4y ago
  I think I probably wasted half my teenage years on Subspace/Continuum. What a blast that game was! Not to mention the diverse player base. I noticed they even listed on Steam a few years back, but being 38 with 4 kids doesn’t lend much time to such things anymore.
ilitirit 4y ago
Rollback netcode ("RBN") is a big thing in Fighting Games. One of the big problems though is that a large part of the community don't fully appreciate some of the technical challenges developers have to deal with when implementing RBN. They think that because GGPO (a RBN framework) can "easily" be used on old arcade/console games, it shouldn't be an issue to implement it in newer titles. Well, that's not entirely true for a number of reasons. For example, if you look at a game like Street Fighter II, there are around 4 unique frames of animation for throwing a fireball. So any rollback that occurs there will hardly be noticeable. In newer games though animation frames are interpolated in different ways so you might have 10x more frames of "unique" animation. This makes rollbacks much more noticeable and jarring, especially in games with 3d models. Then you have the much trickier issue of audio rollbacks. This is even noticeable in games like SFIII:3rd Strike, where you might have the "KO!" audio effect play right as a rollback occurs, leading one player to think the round has ended before they realise a rollback occurred. For some extremely bad examples, search for some videos on Street Fighter x Tekken's, terrible RBN implementation. One of the ways developers get around these challenges is to add artificial delay to things like sound effects, adding more startup frames to moves, and adding massive amounts of hit-stun AKA "impact freeze" making games feel less snappy. For some games these things are not such an issue because traditionally these games rely on "slower" inputs and higher impact freeze because of the game's system mechanics, but in other titles the games just feel worse to play "offline" than their predecessors. For the most part, these are just "veteran player" issues. Newer players are not likely to notice them. In any case, the bottom line is that RBN is not a panacea to online lag. Your game needs to be designed from the ground up to cater for it, unless you're willing to make certain compromises in online play.

vvanders 4y ago

There's broadly 2 types of state synchronization, lockstep and dead-reckoning. From the article it sounds like this is doing dead-reckoning where you let clients simulate locally and then resolve those differences on a continuous basis. It works really well in games where you're trying to "predict" what another player is doing at some future point in time but does worse for instant-reaction type game types. It also has the problem where bandwidth scales with each entity so it can get out of hand pretty quickly with a large number of entities. The other approach(and the one most RTS games use) is called lockstep where you have a fully deterministic game simulation and clients send each other's input's to each other and all of them run in "lockstep" with each other. Generally this adds latency but has the benefit of scaling well to a large number of entities. It also requires your game simulation be deterministic which is extra fun when you have crossplay with different CPU architectures/OSes. If you've ever hit a "sync/divergence" error in those types of games that's usually a gamestate checksum that failed and bailed(some games were smart enough to re-sync the gamestate which is similar to host migration in P2P titles). Rollback is a bit of a hybrid of both where you run closer to dead-reckoning(I.E. clients simulate all entities) but as inputs from other clients come in the simulation is re-wound to that point(I.E. "rolled back") and then re-run with the new inputs + some smoothing. It works really well for reaction based games which is why you see it widely used in fighting games and an early version of that was used in many FPSes for critical things like hit-tests(with fun byproducts of getting "warped" around a corner in high latency situations if getting hit changed things like movespeed). Networking in games is an absolute blast, you have the fun technical problems outlined above but there's also an aspect of psychology/game design where a lot of what you're doing is "masking" latency in a way that's not visible to the user. A simple example here is playing hit sounds/effects locally but resolving them server-side. The 100-200ms latency isn't noticable if there are things happening client-side. From the game design side you can have games where it's about predicting where an action will happen 200ms-1000ms+ in the future which is much more latency tolerant. It's how games like Subspace[1] back in '99 was able to do 100s of players with 250-500ms latency and still have a high fidelity game since it was all about prediction instead of twitch reaction. [1] https://en.wikipedia.org/wiki/SubSpace_(video_game) https://en.wikipedia.org/wiki/SubSpace_(video_game)

twodave 4y ago
I think I probably wasted half my teenage years on Subspace/Continuum. What a blast that game was! Not to mention the diverse player base. I noticed they even listed on Steam a few years back, but being 38 with 4 kids doesn’t lend much time to such things anymore.

ilitirit 4y ago

Rollback netcode ("RBN") is a big thing in Fighting Games. One of the big problems though is that a large part of the community don't fully appreciate some of the technical challenges developers have to deal with when implementing RBN. They think that because GGPO (a RBN framework) can "easily" be used on old arcade/console games, it shouldn't be an issue to implement it in newer titles. Well, that's not entirely true for a number of reasons. For example, if you look at a game like Street Fighter II, there are around 4 unique frames of animation for throwing a fireball. So any rollback that occurs there will hardly be noticeable. In newer games though animation frames are interpolated in different ways so you might have 10x more frames of "unique" animation. This makes rollbacks much more noticeable and jarring, especially in games with 3d models. Then you have the much trickier issue of audio rollbacks. This is even noticeable in games like SFIII:3rd Strike, where you might have the "KO!" audio effect play right as a rollback occurs, leading one player to think the round has ended before they realise a rollback occurred. For some extremely bad examples, search for some videos on Street Fighter x Tekken's, terrible RBN implementation. One of the ways developers get around these challenges is to add artificial delay to things like sound effects, adding more startup frames to moves, and adding massive amounts of hit-stun AKA "impact freeze" making games feel less snappy. For some games these things are not such an issue because traditionally these games rely on "slower" inputs and higher impact freeze because of the game's system mechanics, but in other titles the games just feel worse to play "offline" than their predecessors. For the most part, these are just "veteran player" issues. Newer players are not likely to notice them. In any case, the bottom line is that RBN is not a panacea to online lag. Your game needs to be designed from the ground up to cater for it, unless you're willing to make certain compromises in online play.