Online desynchronization

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:

• Alice is playing as usual, while Bob has a hack that makes his character half their regular size.
• Alice attacks Bob.
  • On Alice's system, the attack connects.
  • On Bob's system, the attack misses due to his character being smaller.
• The match is now desynched.

Overview

Once a match is desynched, the players are essentially playing different matches. Inputs will be sent and acted upon as usual, but the results of the inputs can be wildly different - a control stick input might be a down throw on one system, but the other system believes the grab whiffed, so the fighter simply crouches on that end. Re-syncing a match is sometimes possible, but requires an extensive and usually unfeasible amount of coordination between the players involved, and the cause of the original desynch will likely cause another disconnection later.

All Smash games with an online mode can disconnect players when it detects a desynch. When playing online, the games send information about the actions performed, mostly, but they can also send information that needs to be loaded. While less common event then a desynched action, an element that loads on one end can sometimes not load on the other for some reason. For example, a player may open a Smash Ball on one screen during a desynched online match, but not on another. On the console where the Ball is opened, the game will load data for the corresponding Final Smash, and will send all other players a message saying that the Final Smash has been loaded. Since the other consoles believes no Smash Ball has been opened, and no Final Smash had to be loaded by extension, this "loading successful" message is treated as a mistake. After around 10 seconds, both ends acknowledge that a desynch has occured, and all players are disconnected.

Causes

Desynchs can happen for several reasons. The most common catalysts are hacks and mods. Players using identical hacks generally do not cause a desynch, but any hack that not all players share carries a risk of desynching. Some categories of hacks, such as textures, carry very little risk of desynching, while things such as model hacks are very likely, and moveset and physics hacks are nearly guaranteed to desynch. Desynching also prevents players playing a proper match online using game mods, such as Balanced Brawl and Brawl-, unless all players use the same mod. The effects of this type of desynching can also be viewed by watching the same saved replays while using different hacks/mods. In Super Smash Bros. for Wii U and Ultimate, the player using a hack is instantly disconnected from the match upon using a move that could desynchronize the game.

Desynchs can also happen if one of the participating players or the server is experiencing connection difficulties. This is normally rare, as most networking devices have built-in safety measures, created for the purpose of avoiding the sending and receiving of incorrect data, but given the amount of data that's sent per match, and given the variety of players and their hardware, as well as the fact that perfect connection conditions simply cannot be met all the time, this type of the desynch is occasionaly seen. This happens when, for instance, Alice presses X and A at the same time, but for some reason, one of the bits isn't sent (and, as described above, the hardware fails to catch this flaw), her console could end up sending data for only A being pressed. While in her console, she sees her character jumping and performing a neutral aerial attack, other players' Wiis will only receive the A button, and hence, will have that player's character perform a neutral attack.

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.

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.

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.

Stage desynchronization

In Super Smash Bros. for Nintendo 3DS group matches, a rare glitch may occur that causes each game to load different stages for the same match, during which a 3DS may disconnect while the other 3DSs load the result screen. It is currently unknown if the different stage layouts can cause desynchs during actual gameplay.

External links

• Example of a desynchronized online match
• An in-depth description of rollback netcode and its benefits
• A stage desynchronization in Smash 3DS; A description of the glitch can be found in the video's description