Delay-Based Netcode
As a reminder of the problem, fighting games are used to processing inputs from both players at the same time. When playing online, your own inputs are received immediately, but your opponent’s inputs for the same frame need to be sent over the network and will arrive late. The game needs a strategy for how it will deal with these late inputs while keeping the game feeling as close to offline play as possible.
(As a side note, we won’t even talk about the naive solution where both clients simply wait for remote input before completing the game loop for each frame. Here, you could wait 100ms or more, instead of the tight 16ms we require. This would slow the simulation down to a crawl and make your fighting game instantly unplayable.)
The first strategy, called delay-based or input delay, is the simplest and most common implementation for games using lockstep networking. If a remote player’s inputs are arriving late because they need to be sent over the network, delay-based strategies simply artificially delay the local player’s inputs by the same amount of time. Then, in theory, both inputs will “arrive" at the same time, and can be executed on the same frame as expected.
Let’s illustrate this more clearly with a video example. Here, two players are playing UNIST, a fighting game that uses delay-based netcode, over a connection that has 90ms ping. This means it takes half of that time on average (45 ms, or about 3 in-game frames at 16 ms each) for your opponent’s input to reach you. The local player presses a button on frame 3. In offline play, we would see this move begin to animate immediately, but instead, the game will delay the input by 3 frames and begin executing the move on frame 6.
These extra 3 frames give the necessary time for your opponent’s input from frame 3 to reach you over the internet. On frame 6, we’ll have input from both players and the game can proceed. As long as every input from your opponent can travel the network in these 3 frames, the game remains stable and consistent.
Unfortunately, this is not the reality of the internet.
The Problems with Delay-Based Netcode
You might suspect the main problem is that, if your inputs are delayed any amount, it will hugely impact your reactions and gameplan and make the game unplayably different from offline matches. While delays are not ideal, there are many players who will not be able to notice small delays on the order of 2 or 3 frames. For those that can notice it, or are training to do well at offline tournaments where there will be no delay, clever game design and the delay remaining consistent can mitigate the effects of the delay surprisingly well and still allow online play to be a useful method of practice.
But no, the main problem is consistency. Because networks are notoriously inconsistent, delay-based strategies struggle because they are terrible at handling network fluctuations. Suppose there is a spike in the connection and some information from your opponent takes a little longer than the estimated 3 frames to reach you. Because the game simply cannot proceed without information from both players, it has no choice but to stop and wait for the input to arrive, causing the game to chug and lurch along during moments of prolonged network trouble.
Since pausing the game even briefly is pretty detrimental to a player’s experience, most delay-based implementations will try to prevent it from happening as much as they can. By keeping an eye on the network conditions, they can change the amount of input delay on the fly to match the current connection health. But because network behavior is very difficult to predict, it will often change too late to avoid having a few game pauses, and it will often keep the input delay inflated for longer than is needed. For example, before switching to a rollback approach, Mortal Kombat X’s delay-based netcode would fluctuate between 5 and 20 frames of delay, and connection spikes would inflate the delay for many seconds, even if the spike only affected a few frames. It can lead to instances where players feel the game is lagging a lot more than it is reporting.
Delay-based netcode is also hyper-sensitive to the distance between you and your opponent, because a greater distance increases the travel time across the network and therefore the game must also increase the artificial input delay. Distance plays a factor in all online connections regardless of netcode choice, but it’s particularly difficult to play delay-based games even just a single time zone away, let alone trying to unite the player base globally.
And finally, one last drawback that may not be obvious at first is that delay-based solutions do not care about the game state. Whether the announcer is calling “Round 2, Fight", your opponent is knocked down, or both players are walking around in neutral, a delay-based game treats connection issues identically in all cases. This means there is no place to hide from a bad connection, even if your opponent’s inputs would not impact the match in any way.
Ultimately, delay-based solutions fail to provide a good user experience because unlike offline play, player inputs are not consistent or responsive. Fighting game players thrive on reproducible and trainable situations that are tied heavily to reactions and reflexes. If the opponent jumps, I can input my anti-air. If I land this combo starter, I can continue the combo with muscle memory. When I knock my opponent down, I can meaty them with this specific setup. When input delay fluctuates wildly, whether it’s between two different matches or even during the same match, fighting game players lose confidence that anything they do will work as expected. And when they are unable to enact the gameplan they know would help them win, online play becomes extremely frustrating and often useless.
But What if I Have a Good Connection?
People drastically overrate their connections. While it’s possible you may have a fast, stable connection to some people near you, it’s impossible to control the quality of the connections to every other potential player. Some players may be far away from you, or might have a higher tendency to drop information over the network. Even two people near each other with normally fast connections may struggle to maintain a stable connection to each other, for reasons uncontrollable by either party.
But yes, it’s possible that, in some subset of connections with suitably small input delay, some matches in delay-based games will perform well. However, netcode needs to be judged based on how it handles bad connections, not good ones. If given a perfect connection with inputs that always sync up, there is no need for any clever strategy to approximate offline play -- you’re already there! It’s the netcode’s job to cleverly hide latency, and if your strategy falls apart at even the slightest sign of network trouble, then it’s not an effective method after all.
Why is Delay-Based Still Used?
The main reason so many fighting games implement delay-based netcode is because it is relatively simple. Your gameplay logic is largely unchanged from offline play, since you can always assume both players’ inputs are provided at the start of your game loop. There is also no extra game state processing that needs to occur, which means your game takes roughly the same amount of resources from the computer to run both offline and online matches. It is likely the cheapest, easiest option for developers looking to provide a barebones online mode.
Unfortunately, it’s been mostly Japanese developers who continue to use delay-based approaches, as virtually every fighting game made in America has given up on delay-based netcode and made the switch to rollback. This includes titles from big publishers, like Killer Instinct and Mortal Kombat 11, to smaller indie games like Skullgirls, Punch Planet, Pocket Rumble, and Them’s Fightin’ Herds. It’s possible the larger geographic area of America and Europe has encouraged these developers to make netcode a bigger priority, but it’s not like people playing in Japan are safe from bad connections and the frustration of bad netcode, even though they live closer together and have strong online infrastructure.
Due to the insistence of fans and trends in the industry, it’s also increasingly unlikely that Japanese developers are simply unaware of rollback as an option for their games. Capcom, one of the premier Japanese fighting game developers, has attempted rollback netcode in three different titles (Street Fighter x Tekken, Street Fighter V, Marvel vs. Capcom Infinite), with varying degrees of success. Daisuke Ishiwatari, Chief Creative Officer at Arc System Works, admitted that fans have been bugging him about rollback netcode, but they still chose to use in-house delay-based netcode for 2018’s Blazblue: Cross Tag Battle. Some fans (and even some developers) have theorized that this may be due to some companies’ preference to write their own solutions to solved problems, an issue that seems to especially impact Japanese studios. But because so many popular fighting games in our community are made by Japanese developers, delay-based netcode continues to be prevalent. Over a decade after rollback netcode was first pioneered, only 2 of the 9 games at EVO 2019 used rollback for their online multiplayer, and only one of these two games has had good fan reception to their netcode. (2022 update: In the time since this article was written, many Japanese studios have put a focus on implementing rollback in their new titles, and even retrofitting some of their old titles with rollback solutions. The future is looking bright!)
With all this said, it’s time to talk about exactly how rollback works.