Rematch is adding 50ms of input delay so your ping stops deciding other players' duels

Sloclap is rebuilding how Rematch decides who touched the ball, and the bill comes to 50 milliseconds. Every hit will be worked out by the server instead of by the player who threw it, and to make that possible your own character's animations will start three frames late.

Contested moments are where the old model breaks down, and where Netcode 2.0 is aimed. Image: Sloclap

The studio set it out in a dev blog posted at 14:00 UTC on October 9, re-read at 21:48 UTC on October 10. "Netcode 2.0 introduces server-initiated hits," it says, defining a hit as "any action where your character reaches out to make contact with another player or with the ball: tackles, dives, catches, ball controls and so on." The delay is given exactly: "Your character's animations now start 50 milliseconds (3 frames when at 60fps) after you press, instead of instantly."

Only the picture waits. Inputs still leave for the server at the same speed, and Sloclap says the server "knows how much delay you have and takes it into account when it checks your hits, so your actions are judged from what you actually saw". In the first beta the figure is fixed for everyone; a later one makes it a setting.

The fairness argument names who pays

The current model rewinds the world to suit whoever swung first. "The server judges each hit from the point of view of the player who made it," Sloclap writes. "The higher that player's ping, the older their view of the game, and the more the server rewinds everyone else to match it. In practice, a player with high ping can win duels that a player with low ping saw themselves winning."

Moving the decision to the server reverses who absorbs a bad line. "This also means the cost of a slow connection now stays with the player who has it," the post says, and warns those players directly that they "may see more corrections on your own screen than before, especially on quick actions". Sloclap then defends the choice: "We think this is the right trade: one player's connection should not decide the outcome for the other nine."

Sloclap also argues against the obvious alternative. Some games vary input delay with a player's ping, it notes, "instead, we believe having the game react to your inputs in a consistent manner, that you can train with, is essential".

What the rework does not fix

Sloclap is blunt about the ceiling. Netcode 2.0 means "far fewer rollbacks but not zero". Three cases are named and left standing. Packet loss, because "no delay or netcode can make up for information that is completely missing". Unstable ping, where "a connection that jumps between 30 ms and 60 ms can cause more corrections than a steady 60 ms". And very high ping, "when the wind-up of an action is shorter than the time needed to warn everyone". Sloclap says it will add in-game feedback so players can tell a connection problem from a game problem.

Animation lengths stay as they are, with only the timing inside a wind-up adjusted, and the change applies to every hit including goalkeeper dives and ball controls.

A beta, tentatively October 13

None of this is live. The first Netcode 2.0 beta is "tentatively planned for October 13th", with feedback going to the studio's Feature Upvote board. The rework "mobilised a large part of the team, and put on hold many core gameplay improvements that we want to make and that you have been asking for", with normal work resuming once it is done.

Trading latency for something else is a familiar bargain on PC this autumn. Valve's beta Steam client now allows Remote Play up to 1 Gbit/s while warning that the higher bitrate costs latency. Sloclap is making the opposite deal: spend 50ms up front, and buy a game where ten screens finally agree on what happened.