Editing Online desynchronization
From SmashWiki, the Super Smash Bros. wiki
Jump to navigationJump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
{{ArticleIcons| | {{ArticleIcons|ssb=y|ssbm=y|ssbb=y|ssb4=y|ssbu=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. | '''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 11: | Line 10: | ||
==Overview== | ==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 | 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 and a fastfall on another. Re-syncing a match is sometimes possible, but requires extensive co-ordination between the players involved, and the cause of the original desynch will likely cause another disconnection later. | ||
''Brawl'' 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 a loadable element has finished loading. If a match is desynched, a player may open a [[Smash Ball]] on one screen, 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 on the other consoles no Smash Ball has been opened, and no Final Smash had to be loaded, this "loading successful" message is treated as a mistake. After around 10 seconds, it's acknowledged that a desynch has inevitably fallen into place, and all players are disconnected. | |||
==Causes== | ==Causes== | ||
Desynches are generally caused by hacks. Players using identical hacks generally does not cause 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 guaranteed to desynch. Desynching also prevents players playing a proper match online using ''Brawl'' 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 [[replay]]s while using different hacks/mods. In {{forwiiu}}, 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 | 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 can't be met all the time, this type of the desynch is not completely implausible. 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== | ==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 because of its upsides heavily outweighing its downsides, especially in relation to its delay-based alternative. | |||
Other methods of online play take a different approach with | |||
==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 | 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. | ||
==Stage desynchronization== | ==Stage desynchronization== | ||
Line 37: | Line 31: | ||
==External links== | ==External links== | ||
*[http://www.youtube.com/watch?v=HQmrz4XuV9o Example of a desynchronized online match] | *[http://www.youtube.com/watch?v=HQmrz4XuV9o Example of a desynchronized online match], on YouTube | ||
*[https:// | *[https://m.youtube.com/watch?feature=youtu.be&v=2aEnvdPSiBE A stage desynchronization in Smash 3DS]; A description of the glitch can be found in the video's description | ||
[[Category:Online play]] | [[Category:Online play]] | ||
[[Category:Technology]] | [[Category:Technology]] |