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 21: | 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, 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. | 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. | 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 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. | ||
==Replay desynchronization== | ==Replay desynchronization== |