Dev Blog - Netcode 2.0 & Next Beta

Since launch, desyncs, rollbacks and unstable network conditions have been at the top of your feedback. We have reduced these issues through many fixes, but some could not be solved without fundamentally reworking how the netcode works.

This 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. We believe this cost is worth it to make Rematch fair and reliable, and our internal testing is showing us massive improvements in the consistency of the online experience. However, we still need to put these improvements to the test, in a public online setting, which is why we will be holding a Beta next week for you to try these changes out. We'll be paying close attention to your feedback, as this is will inevitably affect how the game feels, so we can act accordingly and make adjustments before it hits the live servers.

More information about the Beta and how you can get that feedback to us can be found at the bottom of this post!

Once Netcode 2.0 is done, we will once again focus on improving the core gameplay.

Sit tight, because this is going to be a fairly lengthy one.

What is Netcode 2.0?

Netcode 2.0 introduces server-initiated hits. A hit is 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.

• Today, the player who makes a hit predicts on their own side that it will happen, shows the result of the hit on screen and informs the server afterwards. The server then acts as referee checking the hit that was sent. If the player predicted wrong, their view is corrected. This is what can be seen as a rollback or a desync.

  
  

• With Netcode 2.0, hits are predicted by the server, waiting for validation before showing you the result. Players actions are sent, the server then decides their outcome, and everyone sees contacts at the same moment and place.

  
  

The game will feel different:

• Outcomes are decided earlier. The server locks in a hit as soon as it receives your action, before you see the contact on your screen.

  
  

• Input delay. Your character's animations now start 50 milliseconds (3 frames when at 60fps) after you press, instead of instantly. Those 50 ms let your screen show what the server has actually decided, instead of a guess it might take back a moment later. 

  
  

• Your inputs are still sent to the server instantly, and from the next beta you will be able to adjust this delay through a simple setting.

Does input delay cost you reaction time? It depends: today you often miss the start of other players' actions, by the time a tackle or a dive reaches your screen, its first frames are skipped, or it gets rolled back. With Netcode 2.0, those animations play in full, so you can read and react to the whole action. In most situations, that makes up for the 50 ms.

Client-initiated Hits

Every online game has to deal with the time it takes information to travel. If your ping is 40 ms, it takes about 20 ms for your input to reach the server and 20 ms for the answer to come back. Ten players, each with their own ping, never see exactly the same thing at exactly the same moment.

Rematch handles this in three ways:

• Your character reacts instantly on your screen. Your game predicts what your inputs will do instead of waiting for the server.

• The server is the referee. It checks every move and action you send. If your game predicted something the server disagrees with, your screen is corrected. That correction is what you see as a rollback or a desync.

  
  

Today, hits with the ball are client-initiated, let’s use a tackle as an example:

1. You start a tackle. Your game sees the contact on your screen and starts the ball's new trajectory right away.

2. Your game then tells the server, which checks the hit from your point of view and starts the new trajectory on its side.

3. The server tells everyone else.

   
   

By the time the other players hear about it, the ball has already been travelling on its new path for a moment. Their game has to “teleport” the ball back to where it should be by now.

It also means that on everyone else's screen, the tackler is never really at the point of impact. The contact happens slightly away from where the animation shows it.

The most difficult cases to manage are contested moments, where two players act on the ball at almost the same time. Each game shows its own player's version. The server picks one, and the other player sees their action taken back. A save that looked clean on your screen and still concedes, or a tackle that clearly connected and was denied, usually comes from this.

Server-initiated Hits

With Netcode 2.0, hits become server-initiated:

1. You start a tackle. The server receives it shortly after the animation begins, before the contact.

2. The server works out when and where the hit will happen, and what the ball's new trajectory will be.

3. It sends that to you and to every other player while the animation is still winding up.

4. Each game adjusts the start of the animation very slightly, so the contact lands exactly when and where the server said it would.

Because everyone knows about the hit before it happens, the ball no longer needs to jump to catch up. The tackler is at the point of impact on every screen. And because the server decides once, for everyone, there are far fewer moments where two screens disagree about who got the ball first.

The animations themselves keep the same total length. Only the timing inside the wind-up is adjusted. This applies to every hit, including tackles, goalkeeper dives, catches and ball controls.

Fairness

Today, when two players contest the ball, the server judges each hit from the point of view of the player who made it. 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. 

With Netcode 2.0, the server decides each hit for everyone at once. Your connection no longer lets your version of the game override someone else's.

This also means the cost of a slow connection now stays with the player who has it. If you play with high ping, you may see more corrections on your own screen than before, especially on quick actions. We think this is the right trade: one player's connection should not decide the outcome for the other nine.

To help, in the next beta you will be able to change your input delay. A higher delay gives the server more time to confirm your actions before they are shown, which means fewer corrections on high ping. Choosing the server region closest to you also helps.

Logic Change and Input Delay

The logic behind every hit changes. Moving hits to the server means changing how every interaction is resolved: when a tackle connects, when the goalkeeper catches the ball, who gets control of a loose ball, etc. Some effects of this on how the game feels, and on the timings and techniques you have learned, can only be found by playing at scale, in real player’s conditions. The beta is here to see the real impact of this change.

We are also adding input delay. With input delay, the animations you see of your own character are shown 50 ms later. In that time, the server has already confirmed what happened, so most corrections are dealt with before they ever reach your screen. In this first beta the value is fixed for everyone; in the next beta you will be able to adjust it. We wanted this first beta to have similar conditions for all players to have more consistent reports.

Your inputs are sent to the server exactly as fast as before. Only what is displayed on your screen waits. 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.

A small, constant delay allows for much more reliable outcomes. Some games will have “adaptable delay”, where input delay changes depending on player ping and ping fluctuation: instead, we believe having the game react to your inputs in a consistent manner, that you can train with, is essential.

Network Conditions

Netcode 2.0 means far fewer rollbacks but not zero. Some situations stay hard to resolve for any online game:

• Packet loss. When data between you and the server is lost, the game has to correct what it guessed. No delay or netcode can make up for information that is completely missing.

• Unstable ping. A connection that jumps between 30 ms and 60 ms can cause more corrections than a steady 60 ms.

• Very high ping. When the wind-up of an action is shorter than the time needed to warn everyone, the server cannot warn everyone in time.

  
  

When these happen, they come from the connection between a player and the server, rather than the game itself. We will add more feedback in the game to make this more visible, so you can tell a connection issue apart from a game issue.

Feedback & Beta

The first Netcode 2.0 beta will take place next week, tentatively planned for October 13th. Your feedback is invaluable to make sure Netcode 2.0 arrives in the best state possible.

You can submit your feedback and bug reports on Feature Upvote, our dedicated feedback platform.

When sharing your thoughts with us, it would be very helpful to us if you could:

• provide specific examples of what feels right, or what feels wrong, and provide as much detail as you can

• have your inputs displayed on screen while recording videos

• add “reproduction steps” when reporting a bug (a quick description of how the bug was triggered)

• share how frequently it happens (does it happen every time ? Or is it 1 out of 5 times, 2 out of 5 ? Etc.)

• specify if you are using controller, or mouse and keyboard

Thank you for playing, testing and telling us what you see!