This is not how rollback works.

The predictive algorithm just creates a visual placeholder until the game receives what your opponent’s inputs ACTUALLY were in the time period it had not yet received them. Then it “rolls back” the game and resimulates that gap using both players actual inputs, and updates the gamestate to match the resimulation if the prediction turns out to have been innacurate.

And note: if the player doesn’t press anything, that is an input. Pressing no buttons is a signal sent to game. If the computer receives that signal, it doesn’t need to predict anything. The computer only makes predictions when it isn’t recieving *any* signal for the non local player (i.e. when it would normally lag), and does so *only* for a limited frams window, and then will *undo* anything it predicted that was inaccurate.

For example, (note: This is massively oversimplified) if player A starts an uncancelable punch towards player B, there will be a window 3 frames long where the game has not yet received information regarding whether player B blocked or not - due to connectivity delay. Let’s say in that 3 frame window, player B did block - on the second frame of the 3 frame window.

In a traditional lag based setup, both instances of the game will wait 3 frames until the information that B blocked has been received by player A.

On rollback, player B’s netcode knows the punch is mid animation (for simplicity of example the startup began before the 3 frame window and will connect on the third frame if not blocked). It doesn’t need to predict anything - player B blocks the punch on his end. Player A’s netcode does not know what player B’s inputs are yet. So it makes a prediction and displays it visually.

After the 3 frame window, player A’s netcode has received the information regarding all of Player B’s *actual* inputs in that 3 frame window, and vice versa.

Player A’s netcode will then “roll back” the game state by 3 frames, and from there simulate - based on the inputs it now knows to have occurred in that time window - what the current game state SHOULD be. This resimulation isnt shown visually in its entirety, it’s done in the background.

If its prediction matched matches what was resimulated, or has the same end state, then nothing needs to be done and the game plays out normally. If it doesn’t match, then it just replaces it’s predicted game state with the simulated one.

If A’s netcode originally predicted player B blocked on the first or second frame of the window, the predicted endstate should match the resimulated one (chip damage, in blockstun). If it predicted B tried to block on the third frame or not at all, and got hit, this does NOT match the end state it simulated knowing that B blocked on the second frame. So B’s hit stun is turned into block stun, and the full damage is reduced to chip damage. ALL CONSEQUENCES OF PREDICTED PLAYER INPUTS WITHIN THE GAME ARE ESSENTIALLY OVERWRITTEN. Animations, hitsparks, etc. will usually subtly change to show this rather than disjointedly having the elements on screen snap to their correct states immediately.

And in theory this rollback and correction process will happen on B’s end as well, but I imagine in scenarios where the prediction is already known to be accurate by the reasoning stated above, the algorithm will skip that step.

This all causes slight visual inconsistency at times, but it DOES NOT aid player inputs. If it did, the “rollback” step would be unnecessary and the name would make no sense. Every single action in rollback netcode that has lasting effect past the rollback point is exactly what both players input in the preceding few frame window. And if lag extends beyond that window the game will just use regular delay so the two game states never desync too much.

Granted, this isn’t perfect. The visual inconsistencies can throw off someone’s reactions occasionally. But it’s the opposite of the issue you described. Rollback PRIORITIZES registering each players given inputs 100% accurately and precisely. It does so at the expense of immediate visual updates of these inputs, by using predicted placeholders until it’s certain it knows exactly what inputs happened at exactly what time on BOTH ends.

But in theory if you recorded every single button press that happened over rollback, and then played them all back exactly on one single console - no netcode, no predictive algorithm - the game should play out exactly the same, just with no visual artifacts. THERE IS NO ASSISTANCE.

The article you linked explains all this. Read past the step where it says the computer predicts players actions.

I think you interpreted the articles saying that the computer’s predictions were sometimes wrong as like a failure or drawback, and not explicitly intended as the “rollback” part of the netcode.

Also Consider:

If rollback worked the way you seem to think it does, then jn the time frames where neither instance of the game/netcode can communicate with the other, each computer must predict what the other player will do and then treat these predictions as if they were actual inputs. I.e. input reading, auto combo, etc. What if both players have multiple options and both predictions are wrong in ways that are inconsistent with one another?

At least one player would then have to have their inputs in that time window undone and replaced with the inputs that the other player’s computer predicted they would make - otherwise the game states would completely desync over time. And that input overwrite wouldn’t be just “autocombo”; at least one player would see themselves forcibly teleport in a different direction or block/unblock/attack when they didn’t make the input to. Visibly.

Someone might assume that this does happen, just to the player with the bad connection. But that’s not how connections work - both players share the same connection, regardless of how good their respective internet services are.

In reality, on rollback code the teleportation and seemingly force changed inputs will ONLY appear to happen to the non-local player, no matter which machine you look at. This is something you can observe by looking carefully at a match on rollback from both players’ perspectives. Hence only the predicted inputs are being overwritten, not the players’.