Client-Side Prediction, Server-Reconciliation und Rubberbanding: Die Netcode-Physik-Pipeline in modernen Multiplayer-Spielen

Einleitung: Die mathematische Illusion sofortiger Reaktionszeiten

In modernen kompetitiven Multiplayer-Spielen fühlt sich die eigene Bewegung vollkommen unmittelbar an. Wer die Taste W drückt, um loszulaufen, oder die Leertaste betätigt, um über ein Hindernis zu springen, sieht seinen Charakter ohne wahrnehmbare Verzögerung auf dem Bildschirm beschleunigen.

Aus der Perspektive der Computernetzwerktechnik ist diese unmittelbare Reaktionsfähigkeit jedoch eine hochentwickelte mathematische Illusion.

In einem gewöhnlichen Online-Match kommuniziert der heimische PC mit einem dedizierten Server, der hunderte oder tausende Kilometer entfernt steht. Liegt die Netzwerklatenz (Ping / RTT) bei 60 Millisekunden, benötigt jedes Datenpaket physikalisch 60 Millisekunden für den Hin- und Rückweg durch Glasfaserkabel und Router. Müsste der Client des Spiels warten, bis der Server den Tastendruck empfangen, die physikalische Kollision berechnet und die neue Koordinate bestätigt hat, wäre jede Bewegung von einer trägen, unspielbaren Eingabeverzögerung gelähmt.

Um die Grenzen der Lichtgeschwindigkeit zu überwinden, nutzen moderne Multiplayer-Engines eine synchronisierte Triade aus drei Netzwerktechniken: Client-Side Prediction (Client-Vorhersage), Server Authority (Server-Autorität) und Server Reconciliation (Server-Abgleich).

Sobald jedoch Netzwerkpakete verloren gehen, die Tickrate des Servers einbricht oder Kollisionsmodelle asynchron laufen, gerät dieses System aus dem Takt. Der Client wird abrupt auf eine zurückliegende Koordinate zurückgeworfen – das allseits gefürchtete Phänomen des Rubberbandings.

Die Netcode-Triade: Vorhersage, Autorität und Abgleich

Um die Entstehung von Rubberbanding nachzuvollziehen, muss die zeitliche Pipeline betrachtet werden, die jeden Millimeter Bewegung in einem Multiplayer-Spiel steuert:

[Client-Zeitstrahl]                                              [Server-Zeitstrahl]
Spieler drückt 'W' (Tick 100)                                   
  │                                                               
  ├── Wendet lokale Physik sofort an (Prediction)                 
  ├── Speichert {Tick 100, Input: Vor, Pos: (10, 0, 0)} im FIFO   
  └── Sendet UDP-Paket {Tick 100, Input: Vor} ──(Latenz)────────> Server empfängt Paket
                                                                    │
                                                                    ├── Simuliert Physik bei Tick 100 (Autorität)
                                                                    ├── Berechnet autoritative Position: (10, 0, 0)
Empfängt Snapshot {Tick 100, (10, 0, 0)} <──────(Latenz)────────────└── Sendet Snapshot an Client
  │
  ├── Vergleicht vorhergesagte Position mit Server (Delta < Toleranz)
  └── Löscht Tick 100 aus dem Puffer (Vorhersage bestätigt!)

1. Client-Side Prediction (Client-Vorhersage)

Erfasst der Client eine Eingabe, leitet er diese ohne Wartezeit direkt an die lokale Physik-Engine weiter. Auf dem Bildschirm wird die Bewegung unverzüglich mit 144 Hz, 240 Hz oder mehr dargestellt. Zeitgleich legt der Client diesen Befehl samt der berechneten Position in einer internen FIFO-Warteschlange ab: dem Puffer unbestätigter Eingaben (Unacknowledged Input Buffer).

2. Server Authority (Absolute Server-Autorität)

In einer soliden Netzwerkarchitektur gilt der Client stets als ungesicherte und potenziell manipulierte Umgebung. Würde der Server die vom Client gesendeten Positionsdaten unbesehen übernehmen, könnten Cheater durch Speicheränderungen unbegrenzt Wände durchdringen oder sich teleportieren.

Aus diesem Grund sendet der Client ausschließlich nummerierte Roh-Eingaben (Blickwinkel, Bewegungsrichtungen). Der Server führt auf einem unabhängigen Headless-Prozess seine eigene deterministische Physikberechnung gegen die Geometrie der Spielwelt durch und legt den einzigen wahrhaftigen Spielzustand (Ground Truth) fest.

3. Server Reconciliation (Abgleich und Korrektur)

In festen Abständen (meist 60 bis 128 Mal pro Sekunde, entsprechend der Tickrate) sendet der Server Snapshots mit den echten Koordinaten aller Spieler an die Clients. Sobald der Client einen Snapshot für einen vergangenen Tick erhält, geschieht folgendes:

1. Positionsprüfung: Er ermittelt die Differenz zwischen der autoritativen Serverkoordinate und der für diesen Tick im Puffer gespeicherten lokalen Vorhersage.
2. Bestätigung (Keine Abweichung): Liegt die Differenz unterhalb einer minimalen Toleranzschwelle (Epsilon, meist wenige Millimeter), war die Vorhersage korrekt. Der Client entfernt den Tick und alle früheren Eingaben geräuschlos aus dem Puffer.
3. Korrektur (Reconciliation): Weicht die Position zu stark ab (etwa durch eine unerwartete Kollision oder Paketverlust), überschreibt der Server die Client-Daten. Der Client setzt die Spielfigur hart auf die vom Server gemeldete Koordinate zurück und simuliert in einem einzigen Rechenschritt alle seither im Puffer aufgelaufenen Eingaben erneut durch.

Die Ursachen des Rubberbandings: Warum schnellt die Figur zurück?

Bei geringen Positionsabweichungen glätten Client-Algorithmen (Smoothing) die Differenz über mehrere Frames hinweg, sodass der Spieler nichts bemerkt. Ist die Diskrepanz jedoch gravierend, versagt die Glättung und die Kamera wird abrupt zurückgerissen: Das ist Rubberbanding.

[Mechanik des Rubberband-Rücksprungs]
Client sagt voraus: Sprint durch offene Tür ──> Position: (25, 0, 0) [Tick 105]
                      VS
Server urteilt: Tür schloss bereits bei Tick 102! Blockiert bei: (12, 0, 0) [Autorität]
                      │
                      ▼
Server sendet Korrektur: „Bei Tick 102 war deine tatsächliche Position (12, 0, 0).“
                      │
                      ▼
[Harter Reset im Client]: Die Spielfigur springt in 1 Frame von (25, 0, 0) zurück auf (12, 0, 0)!

1. Kollisionen mit dynamischen Objekten und anderen Spielern

Der häufigste Auslöser während des Spielens sind Kollisionen mit Mitspielern (Body Blocking) oder beweglichen Objekten (Türen, Fahrstühle):

• Da der Client die künftigen Eingaben fremder Spieler nicht kennen kann, rendert er deren Positionen per Interpolation leicht zeitverzögert.
• Versucht ein Spieler, eng um eine Ecke zu rennen, meldet der lokale Client freie Bahn. Auf dem Server hat der Gegner diese Koordinate jedoch Millisekunden früher besetzt.
• Der Server registriert eine Kollision und stoppt die Vorwärtsbewegung. Trifft der Korrektur-Snapshot ein, wird die Figur aus dem blockierten Bereich nach hinten gerissen.

2. UDP-Paketverlust-Bursts und Puffer-Leerlauf

Multiplayer-Titel setzen auf das UDP-Protokoll, um Latenzen zu minimieren. UDP garantiert weder die Auslieferung noch die Reihenfolge von Paketen:

• Gehen durch WLAN-Störungen oder Router-Pufferüberläufe (Bufferbloat) 3 bis 5 aufeinanderfolgende Upstream-Pakete verloren;
• Empfängt der Server keine Eingaben mehr und geht davon aus, dass der Spieler die Tasten losgelassen hat, wodurch die Figur abgebremst wird.
• Sobald die Verbindung wieder steht, meldet der Server, dass die Figur stehen geblieben ist. Der Client muss den in der Zwischenzeit lokal gelaufenen Weg komplett annullieren und reißt die Figur zurück.

3. Server-Überlastung und Einbruch der Tickrate

Rubberbanding entsteht nicht zwingend auf der Seite des Spielers. Wenn der Prozessor des dedizierten Servers durch zu viele Physikobjekte oder unoptimierte Skripte überlastet ist:

• Bricht die reale Tickrate von 64 Ticks pro Sekunde beispielsweise auf 30 Ticks ein, wodurch sich die Abstände zwischen den Physikschritten unberechenbar verlängern.
• Die verzögerten Snapshots überlasten den Puffer der Clients, was dazu führt, dass alle Spieler auf dem Server gleichzeitig synchron zurückgeworfen werden.

4. Geschwindigkeitsbegrenzungen durch Anti-Cheat-Systeme

Serverbasierte Anti-Cheat-Routinen prüfen kontinuierlich, ob die Geschwindigkeit einer Spielfigur physikalische Höchstwerte (Sprinttempo, Beschleunigungskurven) überschreitet:

• Führen komplexe Manöver (wie präzises Bunnyhopping oder Slide-Cancels) durch Rundungsdifferenzen der Framerate zu kurzen Beschleunigungsspitzen, stuft der Server dies mitunter fälschlich als Speedhack ein.
• Die Bewegung wird auf null geklemmt und die Spielfigur auf den Ausgangspunkt zurückgesetzt.

Entity-Interpolation: Wie Mitspieler dargestellt werden

Während der eigene Charakter durch Client-Vorhersage gesteuert wird, werden alle anderen Spieler, Fahrzeuge und Projektile über Entity-Interpolation visualisiert:

[Interpolations-Puffer: Glatte Darstellung der Vergangenheit]
Snapshot N - 2               Snapshot N - 1               Snapshot N (Neuester Stand)
      │                            │                            │
      ├────────────────────────────┼────────────────────────────┤
                                   ▲
                             Render-Zeitpunkt
               (Client interpoliert glatt zwischen N-2 und N-1)

1. Interpolationsverzögerung (Interp Delay): Da gegnerische Eingaben unvorhersehbar sind, puffert der Client eintreffende Daten und stellt andere Einheiten bewusst 50 bis 100 Millisekunden in der Vergangenheit dar, um Ruckler zu vermeiden.
2. Lineare Kurvenüberblendung (lerp): Der Client überblendet die Positionen und Animationen zwischen zwei empfangenen Snapshots mathematisch nahtlos.
3. Zusammenbruch der Extrapolation (Dead Reckoning): Bleiben Pakete aus und der Puffer leert sich, versucht der Client, die Position anhand des letzten Geschwindigkeitsvektors vorauszuberechnen. Sobald neue Pakete eintreffen, weicht die Realität fast immer ab – der Gegner teleportiert über den Bildschirm.

Diagnose- und Lösungsmatrix bei Rubberbanding

Die Architektur moderner Netzwerkcodes zählt zu den anspruchsvollsten Errungenschaften verteilter Systeme. Indem Client-Vorhersage, kompromisslose Server-Autorität und verzögerungsfreier Abgleich ineinandergreifen, schaffen Entwickler die Basis für weltweiten fairen Wettbewerb. Anhand der detaillierten Netzwerkstudien auf 365Finds können Enthusiasten und Entwickler Übertragungsprobleme präzise lokalisieren, Puffergrößen optimal abstimmen und störendes Rubberbanding dauerhaft unterbinden.

Referenzen

• Steam Networking Sockets Overview - Steamworks Documentation
• Windows Sockets 2 (Winsock) Architecture - Microsoft Learn
• RFC 5405: Unicast UDP Usage Guidelines for Application Designers - IETF
• Linux Networking Documentation for /proc/sys/net/* - The Linux Kernel Archives