Client-Side Prediction Netcode: Warum wir sehen, что auf dem Server noch nicht passiert ist

Eine technische Analyse der Netzwerk-Synchronisation in Spielen. Funktionsweise von Client-Side Prediction, Interpolation, Extrapolation und Lag-Kompensation.

01.06.2026 Deutsch

Client-Side Prediction Netcode: Warum wir sehen, was auf dem Server noch nicht passiert ist

Jedes Mal, wenn Sie in einem modernen Online-Shooter oder einer Simulation eine Bewegungstaste drücken, macht Ihr Charakter sofort einen Schritt. Für Sie fühlt sich das Spiel unmittelbar und reaktionsschnell an. Aus der Perspektive der Physik und der Netzwerkarchitektur є dieses Gefühl jedoch nichts weiter als eine Illusion, die durch hochkomplexe mathematische Algorithmen erzeugt wird.

Wenn Ihr Client-Anwendung darauf warten würde, dass die Datenpakete zum Hosting-Server fliegen, dort verarbeitet werden und den gesamten Weg zurücklegen, würden Sie bei einem normalen Ping von 50–60 Millisekunden eine schwammige Verzögerung bei jeder Aktion spüren. Um ein flüssiges Gameplay zu gewährleisten, nutzen moderne Engines (Source, Unreal Engine, Unity) eine Netzwerkarchitektur mit Client-side Prediction (Client-seitige Vorhersage) und Lag-Kompensation. In diesem Artikel blicken wir unter die Haube des Game-Netcodes, um zu sehen, wie Spiele die Zeit austricksen und warum diese Täuschung gelegentlich zu Desynchronisation führt.

1. Client-Side Prediction — Leben in der Zukunft

In einer strikten Server-Authority-Netzwerkarchitektur bleibt der Server die einzige Quelle der Wahrheit. Er allein weiß genau, wo sich Ihr Charakter befindet. Um Ping-Verzögerungen zu kaschieren, zwingen Game-Engines Ihre Client-Anwendung dazu, der serverseitigen Validierung vorauszulaufen.

Wenn Sie die Taste W drücken, um vorwärtszugehen:

  1. Der Client verschiebt Ihr lokales Charaktermodell sofort auf Ihrem Monitor. Für Sie hat die Bewegung bereits begonnen.
  2. Gleichzeitig sendet der Client ein Netzwerkpaket an den Server: "Ich habe W in Tick #100 gedrückt".
  3. Etwa 30 Millisekunden später empfängt der Server dieses Paket, prüft, ob keine physische Geometrie den Pfad blockiert, und bestätigt die Aktion: "Bestätigt, du hast dich in Tick #100 vorwärtsbewegt".

Während dieser gesamten Round-Trip-Zeit haben Sie eine flüssige Bewegung gesehen, weil Ihr PC die serverseitige Validierung erfolgreich vorhergesagt hat. Sollte der Server die Aktion ablehnen (weil Sie beispielsweise betäubt wurden oder sich eine Tür vor Ihnen geschlossen hat), kommt es zu einem unschönen visuellen Artefakt namens Rubberbanding, bei dem der Server Ihren Client gewaltsam auf seine offizielle Version der Realität zurückwirft.


2. Andere Spieler tracken: Interpolation und Extrapolation

Während Ihr Computer Ihre eigenen Bewegungen problemlos vorhersagen kann, kann er die Aktionen der anderen 50 Spieler auf der Karte nicht erraten. Der Server sendet gegnerische Koordinatenvektoren in diskreten Schritten — zum Beispiel 30-mal pro Sekunde bei einer Tickrate von 30. Ohne spezifische Netcode-Logik würden gegnerische Avatare wie Marionetten über den Bildschirm ruckeln. Um dies zu verhindern, nutzen Engines zwei Methoden:

Interpolation — Der Blick in die Vergangenheit

Damit sich Gegner flüssig bewegen, rendert Ihre Client-Anwendung sie bewusst mit einer kleinen Verzögerung (normalerweise etwa 100 Millisekunden hinter der Echtzeit). Der Client wartet, bis er Paket #1 und Paket #2 mit den Koordinaten des Gegners abgefangen hat. Da der Computer nun zwei feste Punkte im Raum kennt, glättet (interpoliert) er die Position des Modells entlang des Pfades dazwischen.

Das Netzwerk-Paradoxon: Wenn Sie einen rennenden Gegner in CS2 oder Apex Legends verfolgen, betrachten Sie dessen Vergangenheit. Seine autoritative Position auf dem Server є bereits ein Stück далі auf seiner Bewegungstrajektorie.

Extrapolation — Ein gefährliches Ratespiel

Wenn Ihre Internetverbindung schwankt und Paket #2 vom Server aufgrund von Paketverlust (Packet Loss) verzögert wird, schlägt die Interpolation fehl, da der Client-Anwendung der Endpunkt für die Glättung fehlt. In diesem Moment greift die Extrapolation. Der Computer nimmt an: "Der Gegner wurde zuletzt gesehen, als er sich mit 5 m/s nach Norden bewegte. Das Paket fehlt, aber ich nehme an, dass er sich entlang desselben Vektors weiterbewegt", und rendert die Bewegung unabhängig.

Sobald das verlorene Paket schließlich eintrifft, stellt die Engine möglicherweise fest, dass der Gegner in Wirklichkeit angehalten hat. Die Extrapolation stoppt abrupt, was dazu führt, dass das Model des Gegners unnatürlich an seine valide Position teleportiert. Das є die Definition klassischer Netzwerk-Desynchronisation.


3. Lag-Kompensation: Eine Zeitmaschine für die Trefferregistrierung

Das komplexeste mathematische Rätsel im Multiplayer-Netcode є die Trefferregistrierung (Hitreg). Stellen Sie sich ein Duell vor: Ein Gegner sprintet mit 10 m/s. Aufgrund von Interpolationspuffern sehen Sie sein Modell auf Ihrem Bildschirm um 100 ms in der Vergangenheit verzögert. Sie zielen genau auf seinen Kopf auf Ihrem Monitor und schießen. Das Schuss-Paket benötigt weitere 30 ms, um den Server-Host zu erreichen.

Bis der Server Ihr Schuss-Paket empfängt, є dieser Gegner auf der autoritativen Zeitachse des Servers bereits einen ganzen Meter далі gesprintet! Ohne Lag-Kompensation würden Sie ein bewegliches Ziel niemals treffen.

Um dies zu beheben, nutzen moderne Engines die Lag-Kompensation (Lag Compensation) — eine serverseitige Zeitmaschine:

  1. Der Server speichert kontinuierlich einen fortlaufenden Verlauf der 3D-Koordinaten aller Spieler-Hitboxen in seinem RAM-Puffer für die letzten 1.000 Millisekunden.
  2. Wenn Ihr Schuss-Paket eintrifft, wertet der Server Ihre spezifischen Latenz- und Interpolationswerte aus und dreht die Zeit buchstäblich zurück — und zwar exakt auf die Millisekunde, in der Sie den Abzug auf Ihrem Monitor gedrückt haben.
  3. Der Server verifiziert: "Wo befand sich die Kopf-Hitbox von Gegner X in dieser spezifischen Millisekunde der Vergangenheit? Ah, genau dort, wohin Spieler Y geschossen hat." Der Treffer wird erfolgreich registriert.

4. Mathematische Abweichungen und der Preis der Täuschung

Das Maskieren von Netzwerkverzögerungen mit Vorhersage-Algorithmen erfordert mathematische Kompromisse, die Spieler häufig als Bugs interpretieren:

  • Sterben hinter der Wand (Dying behind cover): Das häufigste Symptom der serverseitigen Lag-Kompensation. Sie sprinten auf Ihrem Bildschirm erfolgreich hinter eine solide Betonwand, aber für einen Gegner mit hoher Latenz bewegen Sie sich noch durch den offenen Korridor. Er schießt auf Ihr „vergangenes“ Ich, der Server dreht die Zeit zurück, validiert den Treffer und liefert das Todespaket an Ihren Client — eine volle Sekunde, nachdem Sie die Sicherheit der Deckung erreicht haben.
  • Hitbox-Desynchronisation: Dies tritt auf stark belasteten Servern auf, die unter niedrigen TPS-Werten leiden. Wenn die Physik-Engine die strukturellen Hitboxen seltener aktualisiert, als der Netzwerk-Layer Positionskoordinaten repliziert, kann sich die zugrunde liegende Kollisions-Hitbox eines Spielers visuell von seinem Charaktermodell lösen. In diesem Zustand fliegen Kugeln glatt durch das Charaktermodell, ohne Schaden zu verursachen.
Spielmechanik Was der Client lokal sieht Was tatsächlich auf dem Server passiert
Lokale Spielerbewegung Sofortige Charakterreaktion ohne sichtbare Latenz. Virtuelle Verarbeitung eines hypothetischen Zukunftszustands. Der Server validiert diesen erst nach einer Round-Trip-Zeit.
Gegnerische Bewegungen Flüssige Bewegungen von Gegnern auf der Karte. Rendern eines expliziten vergangenen Zustands (50–100 ms zurück), um Animationen via Interpolation zu glätten.
Schussabgabe auf einen Gegner Zielen direkt auf das gerenderte Gegnermodell. Erzwungenes Zurückdrehen der Weltzeitachsen, um die Schussvektoren mit den alten Hitbox-Koordinaten abzugleichen.

Fazit

Der Netzwerkcode moderner Multiplayer-Spiele є weit mehr als eine einfache Pipeline zur Übertragung von Raumkoordinaten. Es є ein hochkomplexes mathematisches System, das permanent die Vorhersage der Zukunft mit der Verifikation der Vergangenheit ausbalanciert. Eine stabile CPU-Leistung aufseiten Ihrer Hosting-Infrastruktur є für das Gleichgewicht dieses Ökosystems unerlässlich — lässt die Hardware Ticks aus, bricht dieses sensible mathematische Modell zusammen und verwandelt High-Tech-Optimierung in chaotische Desynchronisations-Lags.

Ähnliche Artikel

Virtualisierung und Ressourcenlimits: Was passiert, wenn Ihr Server die Hosting-Limits überschreitet

Ein tiefgehender technischer Überblick über Containerisierung und Linux cgroups, der CPU-Throttling, den Completely Fair Scheduler (CFS) und den Noisy-Neighbor-Effekt auf Gameservern erklärt.

Weiterlesen

Synchron vs. Asynchron: Wie Datenbanken die TPS-Stabilität von Gameservern diktieren

Ein technischer Leitfaden über den Einfluss synchroner Datenbankabfragen auf I/O-Engpässe und TPS-Einbrüche bei Gameservern.

Weiterlesen

Speicherlecks unter dem Mikroskop: Was im RAM passiert, wenn ein Server zu lange läuft

Ein technischer Leitfaden zur Speicherverwaltung von Game-Servern, der den Unterschied zwischen Stack und Heap, die Grenzen der Garbage Collection und die Ursachen von OOM-Abstürzen erklärt.

Weiterlesen