Street Fighter V and Rollback Netcode 101
An explanation, and why it’s so important to players
Street Fighter V first launched in 2016, and Capcom had run online closed beta tests for their new title prior to its release. Like Street Fighter x Tekken before it, Capcom would be implementing their own in-house developed rollback netcode solution for the game’s online play. Astute players, including developers like Mike Z, Keits, and the Cannon brothers, recognized that the game’s rollback solution had some crucial flaws. These developers were able to pinpoint the possible bug that was causing the issues without looking at the source code due to their experience with creating fighting games. The problem seemed to be that the game allowed the clocks of the two game machines to fall out of sync with each other, which meant that data was transmitted at an uneven rate. As a result, this would heap an intense amount of rollbacks on one of the players while the other would still appear to have a seamless experience. This “one-sided rollback” would continue to exist in the game for the next four years with no fix in sight, and would sour a lot of players’ opinions about rollback netcode.
So what is rollback netcode? A lot of people can probably explain it with more depth and detail than I can, and while I’ll link to their expertise, I’ll do my best to summarize it for you here. Modern fighting games generally have two types of netcode solutions- two different ways they handle players connecting to each other to play the game together. The first type is delay-based netcode, and the second type is rollback netcode.
In delay-based netcode, the game measures your ping to the other player. (Your ping is the round-trip time for data sent from your machine to reach another machine and come back to you. In a peer-to-peer connection, the other machine is your opponent; in a shooter game, the other machine is the server you’re connected to. Fighting games usually use peer-to-peer connections even when matchmaking lobbies are involved.) Once it has your ping established, it decides how long that time is measured in frames, and will then delay your inputs by that amount of frames during play. For instance, if your ping is 100ms, that means it takes roughly 50ms for your inputs to be received by your peer, and since it takes 50ms for the game to render three frames (one frame being 1/60th of a second, or 16.67ms,) your input delay will be set to a value of 3. This means that ideally, when you press your jab button, it will take an additional three frames before you see that jab animation begin to play on the screen.
The problem with delay based netcode is that we know this isn’t how it works all the time. Networks are unstable. You may be playing on Wi-Fi (you really shouldn’t be,) or you may live in a rural area with poor network infrastructure. When you experience packet loss, high traffic on your network, or anything else that may raise your ping, your frame delay will increase in real time along with it. Since the ping is dynamic and will fluctuate during the match, that means your frame delay will also change constantly. After having finally gotten used to the 3f delay, you may suddenly have to jump to a 4f or 5f delay. Furthermore, if the delay increases drastically, the game will simply be unable to load anything until the connection stabilizes- if it can’t render the next frame, the game has to stop until it can. This causes the visual elements of lag, such as freezes and mid-match loading screens. A drastic delay increase also results in your inputs being ‘eaten’ and unregistered. Good luck trying to reversal DP out of that Ky mix now.
Rollback netcode attempts to solve the issues of delay-based solutions. In rollback netcode, the underlying concept is similar to what already exists in delay-based, but with a few tweaks. First, the frame delay is static, not dynamic. This can be fixed by the players at the beginning of a match after an in-game recommendation based on ping, or it can be forcibly fixed by the developers, usually at a 2f or 3f minimum. Second, rollback handles lag spikes in a different way in order to seamlessly replicate the offline gameplay experience. When your network suffers from a drop in connection, packet loss, lag spike, what have you, the game continues playing as normal rather than stuttering or freezing. The way it does this is by predicting what your actions are during the drop. These predictions are achieved by the game assuming that you will continue to be pressing whatever button you were pressing prior to the drop. For instance, if Ryu is throwing a fireball at you and you’re holding back to block, and then you suffer a lag spike, the game will remember that you were holding back on your stick, and continue blocking for you until the lag spike ends. These assumptions are correct roughly 90% of the time due to the nature of fighting game animations that last for multiple frames. By the time the startup and ending frames of a particular attack or action have completely taken place, the connection issues will have corrected themselves. When you block that Ryu fireball, you will be stuck in the blocking animation and subsequent blockstun for so long that you won’t have noticed the lag spike at all!
So what happens during that 10% of time when the game’s prediction of your actions is wrong? If you were holding back on Ryu’s fireball, then your ping spiked as you were inputting a Tatsumaki through it, the online gamestate being transmitted to your opponent is now different than your local gamestate where you hit Tatsumaki through the Hadoken. As a result, your opponent’s screen will have you blocking for a few frames longer than you really were. Then, when the lag spike is over, the online gamestate recognizes a discrepancy between what it predicted and what actually occurred- it thought you’d continue to hold down and back, but you hit Tatsumaki. The match’s gamestate now corrects everything in a single frame so that the Tatsumaki comes out, passes through your opponent’s fireball, and hits him. This correction where the gamestate “rolls back” to the correct version of events in a single frame is where rollback gets its name. This is rollback netcode working as intended. The “rolling back” to the correct gamestate is almost imperceptible to the naked eye in most cases because only a few frames, maybe two or three out of 60, are incorrect during the lag spike. There’s videos of rollbacks rendered at slowed speeds and the difference is completely unnoticeable. Your Tatsumaki out of block simply has a few frames of startup animation shaved off it. When connections get really unstable, rollbacks likewise become more severe, which is where you get weird visual artifacts, such as characters warping back and forth while standing in place or moves coming out earlier than normal. However, in a functional system this hardly occurs until you approach 200ms connections.
Why is netcode so important? There is an obvious answer: The efficacy of a game’s netcode means that matches online are far more stable and closer to the online experience. You have more fun playing in matches where your inputs are accurate, and it’s also better practice since you don’t have to adjust to severe frame delays on the fly. However, the less obvious answer is when you consider how games conduct online matchmaking. Typically, games will prioritize three categories when connecting you to another player: Finding you a match quickly, your connection strength, and your matchmaking level. When a game is unable to find you an opponent within your matchmaking level and connection level quickly, it will take a longer time and must cast a wider net, which may mean you end up playing someone out of your skill level and with a poor connection. If the netcode is good, then the range of possible connections is often doubled, which means it can prioritize finding close-in-skill matches much quicker.
Phew! I spent a lot of time explaining the background stuff, didn’t I? You can likely see now what this all means for fighting games, even outside of SFV. If the game’s netcode is bad then playing online becomes a miserable experience- laggy matches, frequent connections against people much better than you, long wait times. If the game’s netcode is good then you experience none of that and you can even get better at the game faster since the online experience matches the offline one so closely. This is why games that use rollback netcode, like Killer Instinct and Skullgirls, retain an active online playerbase to this day despite their development cycles being over. There’s always someone to play, and the quality of those matches is exceptionally close to replicating the experience of sitting right next to your opponent at a local.
SFV unfortunately had a lot of issues plaguing its online play for nearly four years. For a game promoted heavily at events like Evo, Capcom Cup, online qualifiers, and even the Tokyo Olympics, this was a huge problem. However, all of that changed about a month ago. On January 8th, 2020, reddit user Altimor posted a download link to the /r/streetfighter subreddit for a fanmade netcode patch that players could apply to PC copies of SFV. Altimor is a member of the FGC who is also known for developing fanmade mods for other titles, such as hitbox/hurtbox viewers for Guilty Gear. Altimor alleged that the initial fanmade netcode patch was developed via two days of reverse-engineering, and that a better fix could be made in less than an hour with access to the source code. The fanmade patch addressed the main issue caused by the bug in SFV’s code, which was that the two player’s machine clocks would desync and transmit data incorrectly. In the Altimor patch, the clocks would attempt to resync much sooner and do so much faster.
SFV PC players reported that their online experience drastically improved after using the patch. Players were participating in matches much farther than their normal connection range that felt smooth and relatively lagless. High quality connections were now intercontinental rather than simply within the same state or region! There were a few issues: in an attempt to correct the more severe clock desyncs, the game would often get caught in a stuttering state not too dissimilar than those experienced in delay-based solutions. Beyond that, the patch was PC only, and crossplay between PS4 and fan-patched PC players became a miserable experience.
Not long after the Altimor patch became widespread, SFV director Yoshinori Ono cryptically tweeted that he and his team had “grasped the situation,” implying that a fix would be incoming. Eventually, as the 2/14/2020 release of SFV Champion Edition approached, it was confirmed that a netcode fix would be incoming within a week after launch.
When the 5.14 netcode patch finally debuted, however, it seemed at first that nothing at all had changed. Most notably, the PC versions of the game needed file validation in order to be played (users weren’t banned, but they would be unable to open SFV without removing the Altimor patch.) Online matches still seemed miserable and unplayable for a certain portion of players. However, upon further inspection, and as more and more players got to try the patch, it was revealed that Capcom had in fact implemented a cross-platform fix to the netcode. The changes seemed to take cues from Altimor’s patch in their attempt to correct the main issue: the clock desyncs. The window of “acceptable” desynchronization was changed to scale off of ping, in a manner different than the fanmade patch. This reduced one-sided rollback, but didn’t entirely remove it from the game. Furthermore, this meant that the main issue with Altimor’s patch- the microstuttering- would still occur and inputs could be dropped as the game would freeze. In general, though, Capcom’s fix was much better than the existing netcode prior to January 8th, 2020, and players on both major platforms experienced better online gameplay overall.
Players were frustrated, and then simply disappointed, for a lot of reasons. At first, people were angry, myself included, because it seemed as though all Capcom had done was ban the Altimor patch- that is, they removed the one thing that made online play relatively stable in order to appease the PS4 userbase. Beyond that, many players had either reinstalled the game or newly purchased it after the Altimor patch launched, and then even more new players arrived due to Capcom digital discounts, the reduced price of SFVCE, and the promise of a netcode patch. To many, it felt like Capcom had made a bunch of money off a fanmade patch and a false guarantee. Then, when the patch was revealed to have actually been a real fix, the playerbase’s emotions were tempered, but still wounded. The general agreement was that it shouldn’t have taken Capcom four years to implement a fix that a fan made in two days. Furthermore, it should have been the perpetuity of fan outcry that convinced Capcom to fix the netcode, rather than the immediacy of the aforementioned fanmade patch. Because of the SFV media team’s poor communication, it was hard to tell that there was even a fix at all until players got their hands on the game and began experimenting.
It’s hard to give Capcom praise or a pat on the back after everything SFV has been through, from the infamous “eight frames of delay” debacle, to the PC version’s anticheat software, to this. Eventually, the game has been molded into an iteration that now appeases the most players, but it’s still frustrating that it took so long for basic gameplay and quality of life fixes to be implemented. Capcom’s version of rollback netcode is also still not a perfect shining example of its functionality- they got it right in Marvel vs. Capcom Infinite, but it was still very messily implemented in SFV and Street Fighter x Tekken. The fear in many players’ hearts is that Japanese developers will see SFV as the main example of failed implementation of rollback and refuse to use it in their games- we’re all waiting for the Guilty Gear Strive open beta with baited breath. Still, Capcom is finally making these long-overdue fixes and listening to feedback, so communication between player and developer should be encouraged, with hopes that the netcode will be improved even further.
I’m enjoying my time with SFVCE a lot, and don’t regret my purchase of it at all, especially since I was able to take advantage of the sale. That being said, this sort of behavior from the developer is what has discouraged me from paying full price for a Capcom fighting game title since 2011 (Marvel vs. Capcom 3.) All any of us in the fighting game community can do is hope that monetary votes and loud feedback will show developers that implementing and maintaining rollback netcode will be better for the health of their game than delay-based solutions.
