Guilty Gear Strive and the Importance of Rollback Netcode
Guilty Gear: Strive is a beautiful fighting game. It is the mastery of a character and its mechanics; it is the intense fights with other players with nothing but pride on the line; it is the community of dedicated and passionate individuals all here to celebrate, play, and win the game. And it would all be impossible without the ability to play the game online smoothly.
Guilty Gear (and most other modern fighting games) implements a netcode system called rollback netcode. Rollback has become such an integral part of fighting games that most people will refuse to play a game that does not have it. So what is rollback? How did it become so important and well-known? Let’s explore that.
From Arcades to Online: The Roots of the Fighting Game Community
First, a short history lesson provides good context. The first fighting game was released in the mid-’70s, but that is not when the genre became what it is. That happened with the release of Street Fighter 2; it defined the fundamentals of the genre that most games ended up following. It also created the fighting game community. This happened in a time when arcades were really big, and most matches between players happened by playing on the same machine. The players slowly started hosting tournaments of the game and discussing who was better. The community was rather small, but very dedicated.
Tournaments were one thing, but it was incredibly essential to be able to play the game consistently and get a lot of practice, and this always happened in the arcades. Even with the release of fighting games on home consoles and support for online play, finding opponents and subpar netcode were big issues, and arcades remained the popular choice. This kept going until the arcades started dying; the rise of home consoles and personal computers resulted in fewer and fewer visits to the arcade from the general population. While this was ultimately a good development for gaming as a whole, it was slowly becoming a big problem for fighting games. Locations to find opponents to fight were decreasing, while home consoles were still plagued with the same subpar netcode.
Why Fighting Games Are Uniquely Sensitive to Netcode?
So, what exactly was the issue with the netcode in fighting games, and why did this problem occur in fighting games but not in other video game genres? One reason is popularity. Genres like FPS (First-Person Shooter) and RTS (Real-Time Strategy) were really popular; this meant that a given region would often have more than enough players to support matchmaking. Those online games were also often on personal computers and would be played in internet cafes, which, unlike arcades, were going strong in the 2000s.
Other than external factors, there is also a big mechanical difference that fighting games need to deal with: the importance of timing in the genre. Most people are familiar with the term frames per second, or FPS for short; it measures how many frames are being displayed in a second. In more general gaming circles, the concept of frames is about the smoothness of the video game or how strong a computer is, but in fighting games, it is used as a unit of measurement. In this genre, every attack or move in the game is measured by how many frames it takes. Because FPS is always locked to be at 60, this ends up being a really consistent, logical measuring method. But why would the community even feel the need to put so much focus onto frames? In fighting games, timing moves to punish an opponent when they whiff, or knowing what move to use against a certain attack, all depends on the different timings that are measured in frames. So, excelling at this genre means knowing and exploiting timings, called frame data, of an opponent’s moves. This meant that even small delays or discrepancies caused by subpar netcode would ruin the game for most players. Stricter methods of keeping the game in sync for both players would be needed.
The Limitations of Delay-Based Netcode
The preferred method of netcode back then was called “delay-based netcode”. This basically meant that the game would implement a delay from the moment an input was pressed to the moment it executed. Normally this would not be a big problem if delays were kept short, like around 3 frames; however, most matches ended up requiring much higher delays.
Another problem was that the delays were not consistent and would change depending on the fluctuating connection quality. This made timings very inconsistent. Most players viewed the in-game character as an extension of their body; this meant that such delays ended up feeling incredibly uncomfortable and confusing. Imagine a physical hand moving only a moment after the brain commands it to move. It would create a lot of cognitive dissonance.
Tony Cannon and the Birth of Rollback Netcode
At some point in 2002, a player by the name of Tony Cannon set his sights on solving this problem. The solution he came up with was using rollback. In very basic terms, rollback is an idea that instead of delaying inputs, they can be predicted on the client side, and when the actual input arrives, the system recalculates it and rolls back the game to the state it should have been.
It sounds like it would have two major problems: rollbacks being disruptive, and the predictions being wrong the majority of the time. But the constraints and design fundamentals of fighting games make these issues negligible in most cases. Rollbacks do not end up being disruptive because of the way animations work in fighting games. The predictions work in a very primitive way: the game just predicts that the player will keep doing the same input as in the previous frame. This ends up working really well and actually predicts correctly 90%+ of the time. And when this prediction fails, then rollback is used to correct it.
How Rollback Netcode Works in Practice?
An example illustrates how rollback works. Assuming that the connection delay between players is 65 milliseconds (around 4 frames) in one direction. If one player uses a move that is 20 frames long, the other player would only receive that input 4 frames late. So instead of syncing these players’ games by delaying the game for 4 frames, rollback just accepts that the move that was used should currently be on its 4th frame and recalculates the game state based on the new information. Basically, the game ‘time travels’ 4 frames back and calculates how it should look currently, now knowing that a move was pressed 4 frames before. And if the game doesn’t roll back by too much, this ends up looking quite smooth, and it just results in a move starting a bit faster than it should. This is a really good trade-off for smoother online play.
Another interesting aspect to mention is that the rollback system still uses delay, but now the delay can be kept at a consistent and low amount of frames. If that’s not enough to receive the input from the other player, then rollback will pick up the slack.
From Experiment to Standard: GGPO and Community Testing
It’s important to mention that this did not become a success overnight, and the implementation was as important as the concept. It took Tony a long time and a lot of testing to perfect this system. He did this by creating a platform to play older fighting games online using the rollback system he designed. He used a lot of feedback and testing data from this platform to perfect the system. The feedback he got made him decrease the packet sizes. Even though he did not believe it would actually do anything, it ended up helping players immensely from regions with bad internet. All this resulted in a publicly available implementation of this netcode called GGPO (Good Game Peace Out), which is used in a lot of games, even some outside of fighting games.
While implementing rollback is much more complex than a simple delay-based system, it is extremely important to have in a fighting game to maintain any kind of playerbase.
Lessons Learned: Designing for the Constraints of a Genre
So, what can be learned from here? This might just be a story of how a video game genre adapted to the era of the internet, but there is a lot to learn from here. One of the biggest lessons here is the importance of creating domain-specific solutions. Rollback worked so well and solved a lot of the problems netcode had before because of the genre’s restraints. Working with those restraints and design fundamentals instead of against them is what helped this idea be so successful.
Another important lesson is that live testing and iteration are really important; rollback could not have been so successful without the amount of time it was being tested by a big community of players.
