Ping, Tickrate und Netcode: warum ein Treffer manchmal nicht zählt

Vom Klick bis zur Trefferbestätigung: die Ereigniskette

Ein Online-Shooter besteht aus mindestens zwei Simulationen: dem Client (dein PC/Konsole) und dem Server (autoritative Instanz). Beim Klick erzeugt der Client ein Input-Event (z. B. „Fire“ plus Blickrichtung, Zeitstempel, ggf. Spread-Seed) und simuliert sofort lokal, damit das Spiel reaktionsfähig wirkt. Parallel wird der Input als Netzwerkpaket an den Server gesendet.

Der Server sammelt eingehende Inputs aller Spieler, verarbeitet sie in seinem nächsten Tick, entscheidet über Treffer und Schaden und erzeugt daraus einen neuen autoritativen Spielzustand. Dieser Zustand (oder ein Delta davon) wird an die Clients zurückgeschickt. Erst wenn dein Client die Serverantwort erhält, ist klar, ob ein Treffer „zählt“ – alles davor ist visuelle und akustische Rückmeldung auf Verdacht.

Dass es sich manchmal wie ein registrierter Treffer anfühlt, aber keiner verbucht wird, liegt meist daran, dass Client und Server für kurze Zeit unterschiedliche „Wahrheiten“ simulieren. Diese Abweichungen werden später durch Korrekturen (Reconciliation) oder durch serverseitige Ablehnung deines Inputs sichtbar.

• Client: Input lesen → lokal simulieren → Effekte/Sounds → Paket senden
• Netzwerk: Laufzeit + Schwankungen (Jitter) + ggf. Paketverlust
• Server: Inputs im Tick verarbeiten → Hit-Test → Zustand/Events zurücksenden
• Client: Server-Update anwenden → ggf. korrigieren (Snap/Glätten)

Ping ist nicht die ganze Geschichte: RTT, Jitter, Paketverlust

Im Spiel wird „Ping“ meist als Round-Trip-Time (RTT) angezeigt: die Zeit, bis ein Paket zum Server und eine Antwort zurückkommt. Für die Frage „wann kommt mein Schuss beim Server an?“ ist grob die halbe RTT relevant, also RTT/2 – aber nur als Näherung. Routing kann asymmetrisch sein, und Spiele messen Ping oft über eigene Heartbeats, nicht über echte ICMP-Pings.

Wichtiger als ein stabiler Durchschnitt ist Jitter: die Schwankung der Paketlaufzeit. Hoher Jitter führt zu ungleichmäßigen Updates, wodurch Gegner „stottern“, Interpolation stärker arbeiten muss und Lag Compensation häufiger in Grenzbereiche gerät. Paketverlust verschärft das: Fehlt ein Input- oder State-Paket, muss neu gesendet oder extrapoliert werden; je nach Implementierung kann das zu „Schuss ging raus, aber Server hat ihn nie gesehen“ (oder zu verspäteten Ereignissen) führen.

• RTT (Ping): Gesamtzeit hin und zurück, häufig in ms
• One-way delay: grob RTT/2, praktisch variabel
• Jitter: Varianz der Laufzeit, oft spürbarer als +10 ms Durchschnitt
• Packet loss: fehlende Pakete → Retransmit (bei TCP) oder Lücken (bei UDP)

Warum UDP in Shootern üblich ist

Viele Shooter nutzen UDP für Positions- und Inputdaten, weil verlorene Pakete meist durch neuere Informationen überholt werden. TCP garantiert Zustellung, kann aber durch „Head-of-Line Blocking“ alte Pakete nachliefern und dadurch aktuelle Daten verzögern. Das ist für Echtzeit-Positionen oft schlechter als ein gelegentliches Loch, das Interpolation überbrückt.

Tickrate: Zeitauflösung des Servers und was sie wirklich bedeutet

Tickrate ist, wie oft pro Sekunde der Server seine Simulation fortschreibt und Inputs verarbeitet. 64 Tick bedeutet 64 Updates pro Sekunde, ein Tick dauert dann 1/64 s ≈ 15,6 ms. 128 Tick entspricht 1/128 s ≈ 7,8 ms. Diese Werte sind reine Zeitscheiben: Sie sagen nicht automatisch etwas über Netzwerkqualität aus, aber über die zeitliche Granularität von Entscheidungen. Welche Folgen das für den Wettkampfbetrieb hat, zeigt die Umstellung der ESL Pro League auf Gruppenphasen, die online auf europäischen Servern gespielt werden.

Trefferentscheidungen, Bewegungsupdates und Kollisionen passieren typischerweise „im Tick“. Kommt dein Fire-Input kurz nach Beginn eines Ticks an, wird er im nächsten Tick verarbeitet – im schlechtesten Fall wartest du fast eine Tickdauer, bis der Server ihn überhaupt berücksichtigt. Diese zusätzliche Wartezeit wird oft als Teil der gefühlten Latenz erlebt.

Wichtig: Viele Spiele entkoppeln Tickrate, Sendrate (wie oft der Server Snapshots verschickt) und Client-FPS. Du kannst also 240 FPS rendern, aber der Server entscheidet weiterhin nur alle 15,6 ms (bei 64 Tick). Umgekehrt kann ein Server hohe Tickrate haben, aber der Client bekommt nur reduzierte Snapshot-Rate, wenn Bandbreite oder Serverprofil das vorgibt.

• 64 Tick → 15,6 ms pro Tick; 128 Tick → 7,8 ms pro Tick
• Input-Verarbeitung ist meist tickbasiert → bis zu ~1 Tick zusätzliche Verzögerung
• Tickrate ≠ FPS ≠ Snapshot-Rate (Sendrate)

Client-Side Prediction: warum sich Movement sofort anfühlt

Ohne Prediction würdest du bei 50 ms RTT spürbar „nachlaufen“: Du drückst eine Taste, der Server verarbeitet, und erst dann siehst du die Bewegung. Deshalb simuliert der Client deine eigene Bewegung sofort anhand derselben Bewegungsregeln wie der Server (Beschleunigung, Reibung, Sprünge). Gleichzeitig schickt er Inputs mit Sequenznummern an den Server.

Wenn der Server später den autoritativen Zustand zurückschickt, vergleicht der Client: Stimmt meine lokale Vorhersage? Wenn nicht, korrigiert er (Reconciliation): Er setzt auf den Serverzustand zurück und spielt die noch nicht bestätigten Inputs erneut ab. Bei kleinen Abweichungen wird das geglättet; bei großen sieht man „Rubberbanding“ oder kurze Teleports.

Prediction hilft primär bei eigener Bewegung und Waffenhandling (z. B. Rückstoß-Animationen). Für Gegnerpositionen nutzt man meist keine Prediction, sondern Interpolation, weil du ihre Inputs nicht kennst und falsche Vorhersagen extrem auffallen würden.

Interpolation: warum Gegner oft „in der Vergangenheit“ gerendert werden

Damit gegnerische Bewegungen trotz Netzwerkjitter flüssig wirken, rendert der Client andere Spieler häufig zeitlich verzögert: Er hält einen kleinen Puffer aus vergangenen Server-Snapshots und interpoliert dazwischen. Dieser „Interpolation Delay“ liegt je nach Spiel und Netzbedingungen oft im Bereich einiger Dutzend Millisekunden, ist aber eine Designentscheidung und kann dynamisch sein.

Das hat eine Konsequenz: Du siehst den Gegner nicht exakt „jetzt“, sondern so, wie der Server ihn vor kurzer Zeit gemeldet hat. Das macht Bewegung glatt, verschiebt aber das visuelle Timing. Wenn du schießt, zielst du auf ein Bild, das bereits veraltet sein kann. Damit das trotzdem fair bleibt, kommt Lag Compensation ins Spiel.

Warum sich Peekers Advantage ergibt

Wer um eine Ecke peekt, sieht den Gegner auf dem eigenen Client früher, als der Gegner den Peeker sieht – wegen RTT, Interpolation und der Reihenfolge der Updates. Der Server versucht, beide Perspektiven über Lag Compensation zu berücksichtigen, aber komplett „wegdesignen“ lässt sich Peekers Advantage in einem Internet-basierten Modell nicht. In der Wettkampfszene ist genau das ein Dauerthema, wie der Überblick zu Counter-Strike 2 im E-Sport zeigt.

Lag Compensation: Server-Rewind für faire Hit-Registrierung

Lag Compensation bedeutet typischerweise: Der Server bewertet deinen Schuss nicht gegen die aktuelle Position des Gegners, sondern gegen eine rekonstruierte Vergangenheit. Dazu speichert der Server einen Verlauf (History) von Spieler-Hitboxen über eine kurze Zeitspanne und „rewindet“ beim Eintreffen deines Fire-Inputs auf den Zeitpunkt, zu dem du geschossen hast – geschätzt anhand von Zeitstempeln und/oder gemessener Latenz.

Das Ziel ist Fairness: Ein Spieler mit 60 ms RTT soll einen Treffer landen können, auch wenn der Gegner seitdem weitergelaufen ist. Ohne Lag Compensation würden hohe Pings systematisch benachteiligen. Mit Lag Compensation entstehen aber neue Artefakte: Du kannst „hinter einer Wand“ getroffen werden, weil der Server den Treffer gegen deine frühere Position prüft, die aus Sicht des Schützen noch sichtbar war.

Warum zählt ein Treffer trotzdem manchmal nicht? Weil Lag Compensation Grenzen hat: Der Server kann nur so weit zurückspulen, wie seine History reicht und wie er dem Zeitstempel vertraut. Außerdem können Abweichungen zwischen Client-Hit-Effekten und Server-Hit-Test auftreten (unterschiedliche Spread-Rekonstruktion, unterschiedliche Sichtlinien durch Desync, oder weil der Server eine Kollision/Line-of-Sight anders bewertet). In solchen Fällen siehst du eventuell Hitmarker durch clientseitige Effekte, der Server bestätigt aber keinen Schaden.

• Server speichert Hitbox-History über eine begrenzte Zeit (spielabhängig)
• Beim Schuss: Rewind auf Schusszeit → Raycast/Hit-Test in der Vergangenheit
• Artefakte: „um die Ecke getroffen“, „ich hab getroffen, aber zählt nicht“

Typische Ursachen für „Hit, aber zählt nicht“

Der häufigste Grund ist ein Konflikt zwischen lokaler Wahrnehmung und serverseitiger Autorität. Dein Client zeigt sofort Mündungsfeuer, Rückstoß und oft auch Trefferfeedback. Der Server kann den Schuss aber ablehnen, wenn er ihn zeitlich anders einordnet oder wenn die rekonstruierten Bedingungen nicht passen. Dazu kommen technische Limits wie Tickrate und History-Fenster.

Auch reine Performance kann reinspielen: Niedrige oder stark schwankende FPS verschlechtern Input Sampling und Frametimes, was den Zeitpunkt des Klicks relativ zu Render- und Netzwerkschritten verschiebt. Das ist kein Netcode-Fehler, fühlt sich aber ähnlich an, weil der Schuss „zu spät“ rausgeht oder du dein Crosshair nicht so präzise platzieren kannst, wie du glaubst.

• Du schießt auf eine interpolierte (verzögerte) Gegnerposition, der Server rewoundet aber anders als erwartet
• Jitter oder Packet loss: Fire-Input kommt verspätet oder in Burst-Form an
• Tick-Granularität: Timing landet im ungünstigen Teil des Tick-Fensters
• Server verwirft/limitiert Rewind (z. B. zu alt, außerhalb History, Anti-Cheat/Validity-Checks)
• Client zeigt vorauseilendes Feedback (Hitmarker/Sound), Server bestätigt keinen Schaden
• Frametimes/Input Lag lokal: Klick wird spät erfasst oder spät gesendet

Was du realistisch prüfen kannst (ohne Mythen)

Wenn Treffer inkonsistent wirken, lohnt sich eine Trennung in drei Ebenen: Netzwerk (RTT/Jitter/Loss), Serverparameter (Tickrate, Snapshot-Rate, Rewind-Regeln) und lokale Latenz (Input Lag, Frametimes). Viele Spiele zeigen zumindest Ping und Packet loss an; manche bieten Netzwerkgraphen mit Jitter oder „choke“-ähnlichen Werten. Das ist aussagekräftiger als ein einzelner Ping-Wert. Begriffe wie Choke, Jitter und Rollback, die dabei ständig fallen, sammeln wir im E-Sport-Glossar.

Praktisch hilft: Verbindung stabilisieren (WLAN-Probleme, Bufferbloat, Auslastung im Heimnetz), FPS stabil halten (Frametimes), und verstehen, dass ein Teil der Effekte systemimmanent ist. Selbst bei niedriger RTT bleiben Interpolation und serverseitige Autorität bestehen – sie sind notwendig, damit alle Spieler eine konsistente Welt teilen.

• Netzwerk: Ping + Jitter + Packet loss beobachten (sofern das Spiel es anzeigt)
• Lokal: stabile FPS und gleichmäßige Frametimes sind oft wichtiger als Max-FPS
• Erwartungsmanagement: „Instant Hit“ ist online fast immer eine Illusion des Clients

Häufige Fragen

Veröffentlicht am 18. September 2026 · Zuletzt aktualisiert am 30. September 2026