Explaining netcode in games, and why rollback is overrated (though still worth adopting)

27 min readDec 17, 2021

I had a rather fun time poking fun at the FGC back in February with this tweet:

“Down here, salt is a way of life…”

That said, I figured it might be time to write up something proper on the subject, and to give that tweet some context, as it was rather purposefully devoid of much context. For this article I’ll focus on fighting games, though it applies to almost any real-time networking situation really.

Before starting, I should point out that Ricky Pusch has written a pretty good article on this subject. It contains a lot of very useful graphics and demonstrations that show visually some of the ways in which rollback works, which are very well done.

Additionally, while I am indeed stating that rollback is overrated, that doesn’t mean it isn’t good. It’s just overrated, as a result of a lack of understanding of how it works, and a lack of standardisation in game netcode. It’s still a vast improvement on purely delay-based code for casual and non-competitive play; however, it has significant issues that need to be carefully considered in competitive, for-money play, which is a huge consideration for just about any game.

TL;DR

The essential points of the article are thus:

Rollback is excellent for casual play but has significant vulnerabilities in competitive for-money play; it’s not a silver bullet, nor is it a strict improvement on purely delay-based systems — it does have drawbacks.
It is my view that many players don’t understand the unequal nature of, and exploitability of, rollback in competitive situations.
Rollback in tournaments should require specific rules regarding the relationship between player distance/ping to one another and input delay settings, and game implementations that publically show each player’s settings for a match, to ensure fairness.
GGPO is excellent and ought to be adopted by as many fighting games as possible, which will also come with the bonus of better standardising game netcode.
Game developers need to do more than they’re currently doing to properly explain how rollback works to players, so that they understand how to set their input delay and other settings appropriately.

∘ Basics of network interaction during play
· The history of rollback, and why it is a relatively recent addition to online games
· Why purely delay-based systems have often been received very poorly
∘ Lack of foresight and market considerations
∘ Difficulty of predicting network stability
· The benefits of rollback
∘ Much smoother play in most cases
∘ Lower input latency
∘ Better at handling large numbers of small lag spikes
· The downsides of rollback
∘ Cost and complexity of development
∘ Unequal to each player
∘ Much worse at dealing with large lag spikes
∘ More problematic in dealing with desyncing
· The problem of letting players decide input latency
· A common logical fallacy of rollback impacts
∘ Comparing this to purely delay-based systems
· Tournament considerations for rollback
∘ Survivorship bias, and its effect on players’ perception of rollback
∘ COVID-19, and a rise in online tournaments
∘ Recording games
· Conclusions

Basics of network interaction during play

To begin, there are a few terms to be familar with:

Input latency: The delay between you pressing a button, and that action being processed and displayed in-game. Having input delay is crucial to ensure that each player is seeing the same state of the game at a given time, as it allows your inputs to reach the other person’s screen before it has to show them.
Network latency: The delay between sending information from your side of the network, and it being received on the other side, i.e. at the other player’s game.
Lag freezes: this refers to when a game has frozen in place, waiting for one player’s connection to catch up. This occurs when a player’s connection has a sudden temporary increase in network latency (e.g. because it’s congested or due to a brief disconnection).
Rollback: An alternative to lag freezes. Instead of freezing the game while a connection catches up, the game continues and predicts the inputs that have not arrived from one player’s connection yet — if those inputs were predicted incorrectly, the game “rolls back” to the correct state of play instantaneously.

Because all internet connections have some network latency, most games will have some level of input delay on your actions no matter what netcode they use. This allows the game to flow smoothly —this is because it allows the time needed for your inputs to reach the other player’s machine, allowing both players’ screens to show the same state of play.

As such, there are generally two ways that most fighting games are implemented when it comes to the network part of game code (often referred to as “netcode”):

Purely delay-based systems: Games that don’t use rollback. If one player’s connection has a latency spike or other slowdown event, the game will momentarily stop so that ensure both players remain in sync.
Delay-based systems with rollback mechanisms. Note that both systems require some input delay in practice: it’s possible to have rollback with 0 input delay, but that’s generally a disaster except on extremely good connections.

There are advantages and disadvantages to both of these systems. The former — purely delay-based systems — have gathered a deservedly bad reputation in recent times, for several reasons that require some explanation.

The history of rollback, and why it is a relatively recent addition to online games

The first thing to say here is that rollback is a concept almost as old as networks themselves. It is simply one possible solution to the problem of “what do we do in a network situation when information doesn’t arrive in time, but both computers must remain in the same state (i.e. synchronized)?”.

If you must keep both computers in the same state — for a game, that means each player is seeing an identical screen and state of play — then you have two options. You can either freeze the game — allowing you to wait until the information has arrived, so the game can continue — or you can continue by predicting what the state of the game will be once that information arrives, effectively predicting the future. This comes with the caveat that should you predict it incorrectly, you must immediately and instantly change the state of the game to what it truly is.

However, predicting the future is a tricky business. The longer the period you have to predict, the less likely it is that your prediction will be accurate; for example, if someone asks you to predict the next 60 seconds, it’s a lot easier than trying to predict the next 60 days. The exact same problem applies to using rollback in networking: the longer the period of prediction that is required, the less likely the rollback prediction is to be accurate, forcing it to change the state of the game instantly.

In times past — and still in some places — connection quality and speed were terrible. For example, in the early 2000s I was playing StarCraft semi-seriously, and playing on a 56k modem was the norm back then; it was practically standard to set the game to ‘extra high latency’ upon starting a match (which was around 1000–1500ms — not something anyone playing a modern game will even have to deal with in nightmares).

This is relevant because in these scenarios, where big lag spikes were commonplace and happened many times in most games, rollback was not even a feasible option. Because the length of time it would need to predict was so long, and the chance of it being accurate in its prediction therefore so low, the game would look like a giant mess of teleporting assets that the player could barely make sense of — lag might be bad, but rollback in such scenarios is flat out unplayable.

As a result, for games of all types, rollback simply wasn’t plausible in earlier times because it’s only a viable solution if the prediction accuracy is high enough, and this is turn is only possible if connection ‘quality’ is good enough — and even then, only for certain types of games.

Two things affect prediction accuracy:

Connection ‘quality’. This doesn’t mean bandwidth, but rather how much a connection’s response time fluctuates. This has improved in modern times, making rollback a much more viable option than it once was.
The type of game. Because rollback needs you to be able to revert the state of the game in some cases, trying to implement it in a game with hundreds of different units all acting at once is extremely challenging (not to mention very offputting for the player). As a result, it’s more suited to fighting games and other games with fewer player-controlled assets flying around at any given time.

On top of the above, rollback is uniquely suited to fighting games because they’re often played in a restrictive fashion(e.g. you can move your character left, right, up, down but not any possible direction you like). Trying to predict where the player last moved a unit on a 3D map with 360 degrees of possible directions, or predicting what their last input might have been, is vastly more difficult and tends to lead to far more visual rollbacks.

Why purely delay-based systems have often been received very poorly

There are two main answers to this: a lack of foresight plus market considerations, and a general difficulty in predicting network stability that applies to rollback as well. Let’s examine each reason in turn.

Lack of foresight and market considerations

For veteran FGC players, it seems almost ridiculous to even consider the notion of delay-based netcode with no rollback: outside of really good connections, lag can be very irritating to play with as it interrupts the feeling and flow of the game, makes it difficult to time combos correctly, etc etc.

Game designers, however, weren’t trying to sell their games to veteran FGC players. Casual gamers — the much bigger market, especially in previous times — are people who don’t even know what frames are or why they matter, haven’t a clue what “FGC” even means, and aren’t looking to master characters or perform difficult combos — they’re mostly just there to have a bit of a laugh with friends or enjoy the arcade mode.

For those casual gamers, rollback is quite an unpleasant concept in design terms. Imagine you’re walking down a street full of people trying to navigate your way through, and every so often someone suddenly teleports a few feet away from where they were; you’d feel afraid to decide your next move, unsure where people are going to be when you take your next step. This is the kind of feeling rollback can elicit in casual players; the sudden “teleport” of a character that was previously walking, who in fact turned out to be in the middle of an attack or some other action, can be quite disconcerting and make a player nervous about where each character is on the screen at any given time.

Laggy connections with small spikes everywhere will look like they’re running in a kind of frustrating slow motion; rollback with small spikes gives a janky feel that to a veteran player isn’t really a big deal because they understand what to expect, but to a casual player, visually and flow-wise it looks horrible.

This was especially true in previous years when connection quality was much worse than it is now; it’s still bad in many places when it comes to real-time situations like fighting games, and rollback in particular performs in a very ugly manner on laggy connections from a casual perspective.

As such, game designers had to choose between somewhat ‘spiky’ looking games (lag), or janky-looking games (rollback), and for the casual market the latter wasn’t really a preferable feel, especially on the connections of say five to ten years ago but still now as well.

Difficulty of predicting network stability

This is certainly the bigger problem of the two (and it applies to both types of netcode).

One of the biggest problems fighting game developers have had to grapple with is the idea of having “adaptive” input latency: that is, if your connection seems to change throughout the course of the game, it would automatically adjust your input latency to keep the network as smooth as possible, allowing the game to lag as little as possible.

From the perspective of minimising lag freezes, this works pretty well and a casual player isn’t going to notice much change or care about it. For a serious player this is a nightmare; how on earth are you meant to time a difficult combo when your input delay can randomly change at any given moment throughout the match? It makes for an extremely frustrating experience, and this is the primary reason why purely delay-based netcode has a bad reputation. On top of that, when momentary lag spikes occur, it’s quite difficult for the game to know when it should revert back to a lower input latency (and the player has no notification to inform them about it), making slight connection problems turn into worse things than they ought to be.

As such, to make a pleasant gameplay experience when playing online is a bit of a tradeoff decision for the game designer: do you use adaptive latency to minimise lag freezes, or static latency to make inputs as comfortable as possible?

As the proportion of serious FG players to the total market increases, and as average connection quality improves, there is more and more reason for designers to choose the latter option: static input latency during matches. After all, there’s not much use in a lag-free game if your input latency is so hard to figure out that you can’t time anything, and with improved connection quality the issues that require adaptive latency are less prevalent.

The benefits of rollback

Much smoother play in most cases

One of the great benefits of rollback is that you end up with a much smoother game most of the time. When playing for fun, a rollback of a few frames (around 15–45 milliseconds) is very small and difficult to notice, whereas a sudden stop to the gameplay in pure delay-based netcode is much more noticeable.

On top of that, rollback tends to result in less such situations occurring, because of its prediction of inputs when it hasn’t received inputs from a player yet. Let’s say your opponent’s inputs didn’t arrive to your machine in time; instead of having to perform a game ‘rollback’ once they come in, your machine will predict what your opponent was doing, and only require a rollback if the prediction was incorrect. While the prediction is quite a naive one (it just assumes you’re pressing whatever you were last pressing), it has a high degree of accuracy for short prediction periods in fighting games. As a result, you can end up with a smoother game with less network-related events of any kind as the predictions wipe out the need to deal with many of them.

As such — to take an example figure — you might expect that in a game with 10 lag events, there might be say 1 or 2 rollback events that require an actual on-screen rollback. This is in many — but not all — cases, a preferable situation.

Lower input latency

Rollback itself doesn’t ‘enable’ lower input latency, but because of the way it functions as described above, you can usually get an acceptably smooth game using a lower input latency than you would need in a purely delay-based netcode solution on the same connection, as many situations that would cause a lag event may be rolled back without any game state changes. Lower latency is universally a good thing in and of itself, so this is definitely a big plus point.

Better at handling large numbers of small lag spikes

As explained before, when you are using rollback, many lag events that would result in a small freeze in a purely delay-based netcode will result in no visible change on a rollback system (as if the game’s predicted inputs for the laggy player are correct, no rollback is needed).

When the lag spikes are small, there are only a few frames that the game needs to predict. This tends to mean that the chance of a correct prediction is higher, thus meaning that for most small lag spikes an actual ‘rollback’ (change in the game state on either screen) won’t be needed.

This makes rollback excellent at dealing with connections where lag is limited to small spikes in network latency, which — while I can’t say I have data on the subject — I would assume to be a majority of modern connections.

The downsides of rollback

Cost and complexity of development

The first downside of rollback is cost; it’s more complex to develop than purely delay-based code. This is because purely delay-based code is basically just the normal offline play with an artificial input delay introduced, which is very easy to code — the state of play is always immutable (once rendered, there is no going ‘backwards’), and so when you render something on the screen you know it will stay where it is supposed to stay, and no additional development is required.

With rollback, the game state is never immutable — you need to be able to instantly re-draw or un-draw assets on screen, be able to deal with rolling back sounds and visual cues and a lot more, all of which is complicated and time consuming and thus adds extra expense to game development. The article linked above has some interviews with game developers and others, who give good examples of the extra development cost this can bring in — it’s a lot bigger than players might realise.

For indie games, and fighting games not using demanding graphics, the extra development costs are smaller — but for those using high-end graphics, rollback forces a developer to perform huge amounts of optimizations if they want their game to run at the proper frame rate. Whether they use demanding graphics or not, rollback requires a lot of extra work in terms of the flexibility of the game engine, maintaining a record of the game state, and so forth.

As a result, purely delay-based netcode is often much easier to implement, and with games studios usually working on very tight budgets and deadlines, this is undoubtedly a major factor in their decision making.

Unequal to each player

Unlike purely delay-based systems, rollback can give one player or the other a minor (or in unlucky or malicious situations, quite major) advantage. Not only this is problematic in terms of fairness — and in terms of the problems it can present in competitions — but it also creates a higher incentive to ‘cheat’ the system.

In a purely delay-based system, it’s comparatively easy to spot someone trying to cheat; you hit someone, start a combo while they’re unable to act, and the game mysteriously lags. While using lag switches to create lag at convenient moments has been done before, it’s often detectable and is difficult to abuse that easily, as it only benefits the player using it at very specific times (when being comboed).

In rollback, on the other hand, it’s easier to abuse this — to understand why, let’s go into how input latency works in rollback. Suppose that your average latency is, say, between 40–60ms — your inputs, on average, take that long to reach the other player (not ping, which is the time to get there and get back again).

If you set your input latency too low, your inputs will not reach the other player in time before they’re displayed on your screen. This doesn’t affect you — your game will run normally — but the other player will be seeing a fair few rollbacks, which effectively means you’ve given yourself a slight competitive advantage. This can also be exploited in two ways by a malicious player:

In a similar manner to the traditional ‘lag switch’ cheat, you can temporarily cause some lag on your side when you are about to begin an attack, meaning you will see a normal game but your opponent will see you suddenly zip across the screen and be unable to react. It’s important to note that this specific exploit is very difficult to utilise in practice — you’d have to have an advanced setup to both create said lag and start your combo at the same time — but it is possible.
A much easier exploit is simply to simulate a constant, random state of lag on your connection — as if your connection were genuinely a bit unreliable or laggy. It requires no active input from the cheating user, and will create unpredictable rollback issues on the other player’s PC — of course, this is not as big an effect as a traditional lag switch, but is still an advantage. This doesn’t work in purely delay-based systems, because simulating constant random lag through a match would cause as many problems for the cheating player as it would for the opponent, rendering it useless.

Unlike the lag situation, however, it’s far more difficult to pin this down. The player who creates lag in a purely delay-based netcode will never create it when they’re not being hit — it would only undermine themselves, and as such it will be easier to spot a pattern. On the other hand, in rollback the player with the dodgy connections suffers no problems on their side of the game no matter when they create the artificial lag, allowing them to make their game lag most or all of the time — thus, it’s hard to tell foul play apart from a genuinely bad connection.

Primitive lag switches that just turn off the connection momentarily are usually detectable — consoles are often able to tell if the voltage has gone for example — but in a rollback scenario, you don’t actually need to do that at all. You could just, for example, start some downloads — enough to put some pressure on your connection, but not in any way detectable as foul play. In a lag situation, your own side would lag too, making this a pointless idea — but in rollback, your game will still be fine, allowing it to be a viable cheating strategy of sorts.

Much worse at dealing with large lag spikes

This statement needs a bit of qualification. First of all, in both systems large lag spikes are naturally an undesirable state. Secondly, these are — I would assume — less common an issue than large numbers of small lag spikes, which rollback is better at handling.

However, this still remains important to note. The first reason rollback is bad at handling this scenario is because if a lag spike is long (let’s say, 500ms), it will have to predict many frames of one player’s input, in this case 30 frames for a 60fps game.

The naive prediction model of rollback netcode (assuming you were pressing whichever button you were last pressing before the lag began), is very good at correctly predicting your inputs for very short periods — but awful at predicting them for longer periods. It should logically be clear that if you ask a game to predict your inputs for 6 frames into the future, that prediction is a lot more likely to be right than if you ask it to predict your inputs for the next 60 frames.

As a result, the prediction model will frequently make an incorrect prediction for long time periods (say, 10–15+ frames as an example), which results in a very sudden janky rollback that catches one player completely by surprise. A single rollback of this nature will frequently be enough to change the course of a game, though they are of course not common.

The second reason is that while you might think purely delay-based systems are equally bad at handling this, they’re actually better at it. For long lag spikes, the game will freeze, and after some period (maybe 500ms-1000ms) the game will display a “waiting for connection” or “waiting for player” screen.

Because the game pauses, and then resumes exactly as it was before the lag, this is a far easier scenario for a player to deal with than the opponent teleporting across the screen and finishing half a combo on them in one frame. Additionally, this ‘caps’ the problem this situation can cause in a lag scenario: a 500ms lag spike won’t be much more disruptive than a 5000ms lag spike.

However, games haven’t always handled this well: you usually get a ‘waiting for player’ screen, then when the lag is resolved, the game immediately resumes without warning, catching both players off guard somewhat. It would, perhaps, have been better for there to be a 1 second countdown to resuming the game upon reconnection in lag events long enough to cause a waiting screen to appear, so that each player has a sufficient warning that the game is about to resume.

Nonetheless, I will say again that this is a less likely scenario than large numbers of small spikes which rollback is better at dealing with.

The problem of letting players decide input latency

In order to explain this, let’s look at how input latency works from a network perspective.

In purely delay-based systems, each player will generally have the same input latency. There’s no real reason to let users decide their own input latency, because a user who sets their input delay incorrectly (i.e. too low) will cause the game to lag for both players.

Meanwhile, in systems that use rollback, each player often *can* decide their own input delay (GGPO lets you do this for instance). The problem here is that rollback does not affect each player equally.

If you set your input latency too low, your inputs will not reach the other player in time before they’re displayed on your screen. This doesn’t affect you — your game will run normally — but the other player will be seeing a lot of rollbacks, which effectively means you’ve given yourself a slight competitive advantage.

In competitive situations, the problems with this are obvious: in casual situations, it’s also problematic, because most players will set their input latency too low (on purpose or out of ignorance, assuming that because they’ve set it low and their game is fine, that the netcode is awesome and no problems are happening) and thus both players will be playing a janky rollback-prone game, which is less fun for everyone than if it wasn’t that way.

While it’s possible to try and exploit lag to gain an advantage (lag switches of many types have been used for this in the past), this is comparatively easier to detect than exploiting rollback, where you don’t even need to think about it — you can simply let your network lag on purpose in random intervals, and while your game looks smooth, it’ll cause potential havoc on the other player’s end.

A common logical fallacy of rollback impacts

One thing that’s important to note about rollbacks that cause a change in the game state is that they have a bigger impact than they might seem. In order to understand this, let’s look at this excellent video from Ricky Pusch’s article, showing Jago’s overhead attack subjected to different amounts of rollback.

The video is here: https://cdn.arstechnica.net/wp-content/uploads/2019/10/CooperativeGentleBillygoat.mp4?_=2

For this, let’s look at the 3 frame rollback. I do not know how many frames Jago’s attack has in total here; let’s say it connects at frame 10, just as an example.

We normally would see Jago reach to his sword and begin drawing it; in the 3 frame rollback, we instead see his hand teleport straight to his sword and be partway through drawing it. When we look at this, instinctively we think “that’s quite a minor difference”; in a vacuum, yes. However, this fails to account for reaction time.

Imagine for a moment, you are playing offline — i.e. there is no input delay. An enemy Jago player throws this move at you; it connects on frame 10. You therefore have nine frames to react to his move and block it before it will hit you. However, you are not a machine: you will not instantly recognise this move, it will take you a moment to recognise he is attacking. As a result, you may —as an example — have a reaction time of 5 frames (you begin blocking him on frame 5).

As a result, you have 10–5 frames, i.e. 5 frames, of error to play with, the margin of error. If you’re being a bit slow, and you block three frames later than you usually would (i.e. 8 frames in) you’ll still block it. We need to think of the rollback in terms of this margin of error.

A rollback that lasts 3 frames, in this situation, would remove 3 frames of startup time, giving you a 2 frame margin of error to block this attack (as instead of seeing 10 frames of his attack, you are only seeing 7 frames — with a reaction time of 5 frames, you can only afford to be 2 frames slower than usual).

This makes rollback much more suited to games where the time between most attacks starting and ‘connecting’ is long — such as some slower-paced 3D fighters, amongst others. If on the other hand, your game has a lot of jabs and light moves that take say 5 frames to connect, rollback is going to present a lot more problematic situations, as even offline your margin of error to block a move on reaction is very low already — making even a slight rollback have a bigger impact.

Comparing this to purely delay-based systems

It’s important to note that the above problem must be seen in the perspective of the fact that input delay, in and of itself, also reduces the amount of time you have to react to enemy moves. For example, if an enemy attack takes 10 frames to connect and the input delay is 10 frames, you have no realistic way to block that attack by reacting to it; your only chance is to predict it was coming and begin blocking in advance.

Because purely delay-based systems usually require a higher input delay than rollback systems to maintain a smooth game, this means that the problem of “rollback causing you to get hit by something” must be balanced against the fact that higher input delay constantly causes a smaller version of the same problem throughout the match.

That said, it’s not a totally simple comparison:

Rollback is completely unpredictable for the player (you have no idea when or where the rollback will occur, and as such if an opponent’s move suddenly jumps forwards three frames, you will be completely unprepared for it). In addition, players often recognise an enemy move by the ‘signature’ startup frames associated with that move — and in some rollback scenarios, this can cause a player not to recognise an attack they would otherwise recognise and realise it too late.
Higher input delay, while making it harder to block on reaction, is a factor the player can account for when making decisions, meaning that the impact of it is mitigated slightly (though not by much).

Tournament considerations for rollback

Due to the fairness issues with rollback as described above, I think it is important that competitive tournaments have rules around rollback settings (and that games allow for players, or spectators, to see the settings of each player).

While it’s almost impossible to detect a player who has caused their connection to be bad on purpose for a particular match, in order to throw off their opponent (which you could e.g. do when facing a strong opponent in brackets), ensuring players aren’t unduly fiddling with their input delay settings between matches can help to ensure that a player isn’t exploiting the rollback system to get any advantage.

Survivorship bias, and its effect on players’ perception of rollback

Players of online games, in general, exhibit a lot of survivorship bias when blaming network issues for winning or losing an online game. This is particularly relevant when it comes to rollback for a few reasons:

If a combo drops because of lag, or an opponent hits you due to lag, it’s a very memorable event for the game. Rollbacks will often have an equivalent impact on the game but be almost impossible to discern visually: it’s a lot more likely that a player will assume they just didn’t react fast enough. This difference means that rollback will frequently not be blamed for problems while lag will be. In addition, players feel much more ‘cheated’ if their combo drops due to lag, versus if they got hit because a rollback reduced an enemy’s startup time on their screen, as it feels more like the player’s control of the game was denied to them even though both cases involved that.
Unlike lag, rollback doesn’t affect both players — so if you get screwed by an unfortunate rollback, the other player is not going to see it or know about it.

This has tended to give rollback a slightly better reputation than it necessarily deserves, as its downsides are better hidden from view.

COVID-19, and a rise in online tournaments

With the prevalence of COVID-19 in the last two years — even if it recedes — it’s likely more and more tournaments will be held online. If this is the case, the fairness property of netcode is likely to become a major factor; this doesn’t mean rollback is a bad idea there, but simply that rules will be needed to ensure that players aren’t exploiting dodgy input delay settings and the like to try and gain an advantage with it.

There could even be a case for things like kernel-level network monitoring in PC games to guard against this; it’s not perfect (you can’t guard against hardware lag with this), but it would go a long way to preventing malicious players making their connection laggy during important tournament rounds to gain the upper hand. A fair few PC games have already been implementing kernel-level protections to guard against cheating programs, so it’s not a new idea.

Recording games

Usually, when spectators watch a fighting game being played, they do not see a laggy or janky match even if the match is in fact that way. That is because they are coded to show spectators the game a few seconds behind the live game — this allows time for lag or other issues to resolve, meaning the spectators can see a nice smooth game, which is of course preferable the vast majority of the time.

For tournament purposes however, this can be a problem. Unlike laggy games, where it’s hard to claim one side had an upper hand (and where a lag of a few seconds e.g. for a lag switch is likely to be long enough even for spectators to see it), rollback is something only the person being afflicted by the rollbacks will see. I think it is important that developers ensure their games save a record of these events, such as the local non-smooth version of the replay (i.e. preserving network events) on each player’s machine, such that in dispute situations these can be used as evidence.

Conclusions

Rollback — implemented properly — is good overall, but needs to be done in the right way. In addition, players need to be aware of the problems that it can present in competitive play.

Additionally, rollback being an improvement requires a properly-set input delay. This is mostly the responsibility of game developers, but also partially the responsibility of fighting game players:

If a developer doesn’t allow users to set their own input delay, it’s on them to make sure that they set an appropriate delay so that it strikes a balance between input delay and janky matches.
If they do allow users to set it, it’s partially on the user to set a proper input delay, but it’s also on the developer to explain to the user how they should do this, give them the tools to measure it, etc.

If there is one thing in all this that can be unarguably said to be excellent, it is GGPO. It’s frankly fantastic that an open-source, standardised library for dealing with the networking aspect of rollbacks exists, and I think it would be excellent if more and more games adopted it so that netcode becomes more consistently implemented across titles.