Online desynchronization: Difference between revisions

no edit summary
m (Text replacement - "{{ArticleIcons\|([^}]+)}}" to "{{ArticleIcons|$1|online=y}}")
No edit summary
Line 18: Line 18:


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]].
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==
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.


==Replay desynchronization==
==Replay desynchronization==
6,046

edits