From SmashWiki, the Super Smash Bros. wiki
|
You aren't logged in. While it's not a requirement to create an account, doing so makes it a lot easier to keep track of your edits and a lot harder to confuse you with someone else. If you edit without being logged in, your IP address will be recorded in the page's edit history.
|
Log in
|
Create account
|
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. 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. |
|
| |
|
| 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 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. |
| | |
| 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== |