Online desynchronization: Difference between revisions

you can't just say "wordy" and then go on to remove corrections and restore inaccuracies
m (→‎Causes: Why not use the other example player's name?)
(you can't just say "wordy" and then go on to remove corrections and restore inaccuracies)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{ArticleIcons|allgames=y|online=y}}
{{ArticleIcons|allgames=y|online=y}}
:''For information on the Ice Climber technique, see [[desynching]].''
:''For information on the Ice Climber technique, see [[desynching]].''
'''Online desynchronization''' (sometimes shortened as '''desync''' or '''desynch''') occurs when the perspectives of multiple players competing in one match are inconsistent with each other. The concept is best explained by example:
'''Online desynchronization''' (sometimes shortened as '''desync''' or '''desynch''') occurs when the perspectives of multiple players competing in one match are inconsistent with each other.


The concept is best explained by example:
* [[wikipedia:Alice and Bob|Alice]] is playing as usual, while Bob has a [[hack]] that makes his character half their regular size.
* [[wikipedia:Alice and Bob|Alice]] is playing as usual, while Bob has a [[hack]] that makes his character half their regular size.
* Alice attacks Bob.
* Alice attacks Bob.
Line 20: Line 21:


==Solutions==
==Solutions==
There have been several proposed solutions to desyncs attempted by many game developers over the years. Most of them involve implementing certain types of online netcodes. The ''Smash'' series has historically used a delay-based netcode for their online services. This works by the game pausing on both ends until a player's given input is communicated to and confirmed on the opponent's side. While this is effective at minimizing desyncs, it has the side effect of causing significant slowdown, gameplay stuttering, and disconnections in extreme circumstances if a connection weakens for any reason. This would not be a problem in the theoretical situation where both players always have perfect connections, but that is simply not feasible in the current day.


Other methods of online play like [[Project Slippi]] take a different approach with rollback netcode. This system attempts to predict a player's next move one frame in advance and displays that predicted action on the opponent's end. If the system's prediction is wrong for any reason, it will undo the incorrect action and start the actual input, skipping the beginning of the animation by the amount of frames it spent being wrong. While this method is not perfect, sometimes causing players with poor connections to teleport around their opponent's screen and forcing the match to roll back a significant amount of time in extreme cases, this type of netcode is often regarded as the superior netcode due to its upsides heavily outweighing its downsides, especially in relation to its delay-based alternative.
There have been several proposed solutions to desyncs attempted by many game developers over the years. Most of them involve implementing certain types of online netcodes. The ''Smash'' series has historically used a "delay-based" netcode for their online services. This works by the game pausing on both ends until a player's given input is communicated to and confirmed on the opponent's side, usually combined with an artificial delay of a couple frames to give time for inputs to arrive without having to stutter constantly. While this is effective at minimizing desyncs, it has the side effect of causing noticeable gameplay lag even in good conditions, while less-than-perfect conditions lead to stuttering and (in extreme circumstances) hangs and disconnections. This would not be a problem in the theoretical situation where both players always have perfect connections that can transfer every input before the next frame elapses, but this is improbable at short range, and impossible over any significant distance due to the limit of the speed of light.
 
Other methods of online play take a different approach with "rollback" netcode. This system attempts to predict a player's next move in advance and displays that predicted action on the opponent's end. If the system's prediction is wrong for any reason, it will reset the game's state to the time of the incorrect guess, apply the corrected input, and skip back ahead to the "present" time. This method is good at disguising small amounts of lag and creates a smoother match when both players have good connections. But it is far less predictable in non-ideal circumstances, causing players with poor connections to teleport around their opponent's screen and throw out moves with seemingly unreactable speed, as well as possibly turning apparently-confirmed hits into misses and vice versa. Many players prefer rollback netcode over delay-based netcode.
 
[[Project Slippi]] uses a slightly less accurate version of rollback that, instead of undoing and fast-forwarding the game state, begins the correct animation and skips ahead to its intended frame. This can cause desyncs if physics bones have hurtboxes in them, such as {{SSBM|Fox}}'s tail.<ref>https://www.youtube.com/watch?v=GD8mBlmxCPE&t=19m26s</ref>


==Replay desynchronization==
==Replay desynchronization==
A common error noted in replays is that they may "desync" over time; the effects vary, though among the most common are actions occurring that did not previously occur, excessive lag followed by significantly increased playback speed, and the replay abruptly ending. With the Pokémon Trainer, particularly unusual effects can occur, such as him sending out a Pokémon which never loads or leaves the revival platform. Replays of Wi-Fi matches are more likely to desync than local matches due to the frequent lag experienced in games, but local replays can also be subject to the problem. The cause of "desyncs" is unknown, though it is speculated it has to do with save data of replays becoming corrupted by some outside factor. In addition, it is possible for a replay that plays fine to randomly desynchronize when played again, and after some tries, play correctly again. These desyncs are possible because the replay is not a video file, but every input being recreated in real time.
A common error noted in replays is that they may "desync" over time; the effects vary, though among the most common are actions occurring that did not previously occur, excessive lag followed by significantly increased playback speed, and the replay abruptly ending. With the Pokémon Trainer, particularly unusual effects can occur, such as him sending out a Pokémon which never loads or leaves the revival platform. Replays of Wi-Fi matches are more likely to desync than local matches due to the frequent lag experienced in games, but local replays can also be subject to the problem. The cause of these desyncs is unknown, though it is speculated it has to do with save data of replays becoming corrupted by some outside factor. In addition, it is possible for a replay that plays fine to randomly desynchronize when played again, and after some tries, play correctly again. These desyncs are possible because the replay is not a video file, but every input being recreated in real time.


''Smash 4'' and ''Ultimate'' introduced an additional issue of gameplay altering post-launch updates. Because replays are still real time recreations, any fighter adjustment will make desyncs inevitable. [[Nintendo]] addressed this issue by simply not allowing replays made before the current version of the game to be viewable. Nintendo often announces updates several days to several weeks in advance and always advises players to convert replays into video files if they wish to keep them.
''Smash 4'' and ''Ultimate'' introduced an additional issue of gameplay-altering post-launch updates. Because replays are still real-time recreations, any change to the characters, stage, or items involved in a match will make desyncs inevitable. [[Nintendo]] addressed this issue by simply not allowing replays made before the current version of the game to be viewable. Nintendo often announces updates several days to several weeks in advance and always advises players to convert replays into video files if they wish to keep them.


==Stage desynchronization==
==Stage desynchronization==
Anonymous user