Online desynchronization: Difference between revisions
(Most of those changes make it unnecessarily wordy.) |
(you can't just say "wordy" and then go on to remove corrections and restore inaccuracies) |
||
Line 21: | Line 21: | ||
==Solutions== | ==Solutions== | ||
Other methods of online play | 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== |
Latest revision as of 17:27, August 18, 2024
- 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[edit]
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[edit]
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, Bob's Wii will only receive the A button, and hence, will have Alice's character perform a neutral attack on Bob's console.
Solutions[edit]
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 Fox's tail.[1]
Replay desynchronization[edit]
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 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[edit]
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[edit]
- 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