#rollback netcode

If you knock on your router three times, and make a wish with all your heart, Rollback Netcode-chan may appear and bless you with a good connection.

A patreon reward for Haru.

From a high level perspective, what rollback does is hide the lag time between when a remote player (my opponent) presses a button and the local player (me) gets that button press notification by skipping animation frames. It will probably help if you read [this old post about delay-based netcode] first in order to understand the kind of problem we're trying to solve first and how a delay-based system works to solve it.

Let's take a look at some sprites from Street Fighter 2 in order to illustrate how different types of netcode work. First, we'll look at the animation frames that a game with zero delay plays starting from when the fierce button is pressed during Ryu's idle animation to the first active frame (when the fierce punch can hit). Let's assume that each of these animation frames takes the exact same amount of time to play (1/60th of a second or roughly 16.66 milliseconds each).

When the button is pressed, it shows the first startup animation frame for 50 milliseconds (3 frames worth of time), then the second 33 milliseconds, finally reaching the first frame that the fierce punch can actually hit an opponent.

A delay-based netcode approach would build in a few frames of input delay in order to give the remote player time to receive the notification. A three-frame input delay would look like this:

The important thing to note here is that the button press info from the remote player can arrive on any of the "DELAY" frames and still fully play the animation on time because the game can figure out what button was pressed on which frame so it knows when to start the animation. The longer the input delay, the more time the game has to make sure everything is synchronized between players. Unfortunately, it also makes things feel bad because it makes the controls feel sluggish to players.

What rollback does is save the entire game state over the last few frames and then insert the remote button press info to retroactively figure out what the world would look like if that button press had arrived on time. So, as an example, if my opponent presses Ryu's fierce punch on frame 0 and it arrives to my game on frame 3, the game would skip the first three frames of startup animation for the fierce punch and jump directly to frame four so that the fierce punch will have its first active frame at the same time on both games, like so:

This guarantees that both players will see the important event (when the fierce punch can actually hit and do damage) at the exact same time without needing to delay the game. However, this is not perfect. Observe how several frames of the startup animation have been skipped entirely for player 2 in this case. Instead of seeing the full fierce animation, player 2 instead sees that Ryu was idling for a few frames and then he throws a fierce punch with a visible two frame startup instead of its usual five frame startup. The larger the rollback window, the weirder it can get. If the button input doesn't arrive until frame 5, for example, there's no startup animation at all and the fierce punch can hit with zero visible startup:

If we have longer rollback windows and animations with short startup times, we can have significant troubles because it means that players can retroactively get hit without ever seeing what hit them until it is too late. Ryu's jab animation has only two frames of startup. If we have a rollback window of three frames or more, it means that I can be retroactively hit by a jab I never saw coming.

Rollback is very good at keeping important events happening at the same time across two different remote games as long as the window isn’t too long. Most of the time, going more than three rollback frames starts causing weird timing issues. However, rollback is not a perfect solution. There are significant gameplay issues that must be accounted for if a game runs with rollback. The biggest issue with being able to retroactively change the game state is that false positive events can trigger. If the game thought that the round was over because I hit my opponent with a killing blow, it normally does something like play a sound and visual effects - the announcer can yell KNOCK OUT, the opponent’s character groans in defeat, the game slows down to show the animation, visual effects play, etc. What do you think happens if that round-ending event gets retroactively changed three frames after it started because my opponent actually hit me during the rollback window and my game didn’t know it? The game has to handle this weird case when it thinks somebody has won the game/round/match and actually hasn’t.

Furthermore, rollback requires significant processing resources. The game must be able to remember the entire state of the game in order to retroactively simulate everything that would have happened if a particular input arrived at a certain time. This isn’t just hit and animation frame data, but the visual effects, lighting, and other details that might affect the game - a retroactive attack might trigger a trap placed by their opponent, which might cause other effects to trigger in order for the game state to be correct. This gets significantly more difficult as you add more players, which is probably the reason that Smash Bros could not add feasibly rollback online play. When there are three remote players that can all potentially cause a visually-intense game to roll back at any time and a huge number of additional permutations that can happen as a result of those retroactive rollbacks, you’re looking at some major potential performance issues (especially on a Switch). As such, rollback really is only important for precision input timing for games that have startup animations within which the lag can be hidden. That’s basically limited to fighting games (that allow two players at most) and not much else.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

@heroicsoftworks​ Godot’s workflow for online play is pretty straight forward and I think it is one of the better implementations I’ve seen, it can be pretty simple to implement but a lot of unexpected things can happen when doing online gameplay which isn’t really godot’s fault in this case.

For this project in particular it isn’t using the default stuff for godot, instead I’m using the rollback netcode plugin following this tutorial: https://www.snopekgames.com/course/rollback-netcode-godot

Setting it up is as simple as changing a few functions on a regular godot node, the problem comes with trying to keep things predictable so it doesn’t generate desynchronization across players.

If you’re thinking about making a online game with or without rollback, your main challenge is getting the 2 players connected which is outside of the godot scope, godot itself will handle things pretty well. To get 2 players connected on the other hand you will need to set up a server to create lobbies and then figure out who is actually simulating the gameplay. You can even set up a godot game as a server and let other people connect to it, it isn’t a bad choice either.

En una entrevista con la revista Famitsu, Kazuhisa Wada comentó que se considera implementar Rollback Netcode vía parche post lanzamiento para Persona 4 Arena Ultimax.

GUILTY GEAR STRIVE IS GONNA GET ROLLBACK!!