Die Evolution der Tickrate: Wie die Server-Aktualisierungsrate Trefferregistrierung und Physik beeinflusst
Im Sprachgebrauch von Gamern und Server-Administratoren ist der Begriff „Tickrate“ längst zum Synonym für die Qualität der Netzwerk-Rückmeldung geworden. Es herrscht die einfache Meinung: Je höher diese Zahl є, desto besser werden Treffer registriert, desto flüssiger bewegen sich die Charaktere und desto präziser є das gesamte Gameplay. In der Realität kann die blinde Jagd nach maximalen Tickrate-Werten einen komplexen Multiplayer-Server jedoch schnell in eine unspielbare Diashow verwandeln.
Die Tickrate є keine abstrakte Netzwerk-Metrik, sondern ein fundamentaler Begrenzungsfaktor. Sie bestimmt, wie die Hosting-CPU ihre Rechenleistung zwischen Physikberechnungen, KI-Updates und Netzwerksynchronisation aufteilt. In diesem Artikel analysieren wir die Anatomie eines Server-Frames und verstehen, warum die architektonischen Anforderungen von kompetitiven Shootern und riesigen Open-World-Survival-Simulatoren grundlegend gegensätzlich sind.
Was ist die Tickrate auf der Ebene der Engine-Architektur?
Jeder Spielserver arbeitet zyklisch. Er simuliert die virtuelle Welt nicht kontinuierlich; stattdessen unterteilt er die Zeit in mikroskopisch kleine Intervalle – sogenannte Ticks oder Server-Frames. Der Tickrate-Wert (z. B. 20, 30, 64 oder 128) gibt an, wie viele dieser Rechenzyklen der Server in genau einer Sekunde ausführt.
Innerhalb eines einzigen Ticks muss die Server-Engine eine feste Sequenz von Aufgaben abarbeiten. Dieser Prozess bildet die Anatomie eines Server-Frames:
- Paket-Erfassung (Input Processing): Der Server liest eingehende Client-Pakete aus dem Netzwerkpuffer (Tastendrücke, Bewegungsvektoren, Fadenkreuz-Koordinaten).
- Welt-Aktualisierung (World Update): Die Engine berechnet die Kern-Spiellogik: Spielerpositionen auflösen, Fabrikknoten aktualisieren und Gegenstands-Entitäten tracken.
- Physik & Kollisionen (Physics & Collisions): Der Physik-Integrator (wie PhysX oder spezifische Unreal-/Unity-Module) prüft Kollisionen und berechnet Raycasts, um zu verifizieren, ob Projektilbahnen die Hitboxen der Spieler kreuzen.
- Künstliche Intelligenz (AI Update): Der Server berechnet die Pfadfindung (NavMesh), Sichtfelder und Verhaltensbäume aller aktiven Bots.
- Zustands-Replikation (State Broadcasting): Die Engine bündelt sämtliche Zustandsänderungen der Welt in neue Paket-Payloads und sendet diese an die Clients zurück.
Wenn ein dedizierter Server mit einer Tickrate von 30 läuft, verbleibt der Hosting-CPU ein Zeitfenster von exakt 33,3 Millisekunden, um diese gesamte Kette abzuarbeiten. Bei einer Konfiguration von 128 Ticks schrumpft dieses Budget auf extreme 7,8 Millisekunden zusammen.
Das Genre-Dilemma: Taktische Shooter vs. Survival-Sandboxes
Das serverseitige Frame-Budget erklärt, warum verschiedene Genres fundamentale Unterschiede bei der optimalen Netzwerkfrequenz aufweisen.
CS2, Valorant, Apex Legends: Der Kampf um Millisekunden
In kompetitiven taktischen Shootern є die Spielwelt statisch und berechenbar. Die Map-Geometrie verändert sich nie, es liegen keine Tausenden von Gegenständen auf dem Boden, Umgebungsphysik wird minimiert und die Anzahl dynamischer Entitäten beschränkt sich streng auf eine Handvoll Spieler und wenige Granaten.
Da die physikalische und skriptbasierte Auslastung dieser Welten nur einen winzigen Bruchteil des Frame-Budgets beansprucht (meist unter 1 ms), bleibt die CPU weitgehend ungenutzt. Entwickler können die Tickrate problemlos auf 64 Hz oder 128 Hz erhöhen. Dies є notwendig, um die Latenz zwischen Client-Klick und serverseitiger Trefferbestätigung zu minimieren. In einem kompetitiven Umfeld, in dem Duelle innerhalb von 10–20 Millisekunden entschieden werden, є diese hohe Frequenz überlebenswichtig.
Rust, DayZ, ARK, Palworld: Der Fluch der offenen Welt
In Survival-Simulatoren є das Szenario genau umgekehrt. Hier є die Welt völlig dynamisch, persistent und gigantisch. Ein aktiver Rust- oder DayZ-Server muss gleichzeitig Folgendes verarbeiten:
- Bis zu 150.000 — 300.000 Baublöcke, Tore und Geschütztürme, die kontinuierliche Stabilitäts- und Verfallsberechnungen erfordern.
- Tausende Loot-Gegenstände, Wildtiere und Zombie-Assets, die jeweils eigene KI-Schleifen durchlaufen.
- Komplexe ballistische Berechnungen für Projektile (Schwerkraft, Luftwiderstand) sowie modulare Fahrzeugphysik.
Unter diesen Bedingungen kann allein das Berechnen der Physik- und Kollisionsmatrizen 15–20 Millisekunden pro Frame beanspruchen. Versucht ein Administrator, eine Tickrate von 64 Hz oder 100 Hz zu erzwingen, überschreitet der Server sofort sein Frame-Budget. Es kommt zu einem Server Tick Rate Drop. Der Prozessor kann die Simulation zeitlich nicht mehr bewältigen, Pakete stauen sich in den Warteschlangen und die Spieler erleben extremes Rubberbanding und teleportierende Objekte.
Was passiert, wenn der Server das Frame-Budget überschreitet?
Wenn die mathematische Berechnung der Welt länger dauert, als das Zeitfenster der Tickrate erlaubt, erzwingt die Game-Engine drastische Kompromisse, um den Thread am Leben zu erhalten:
- Tick-Skipping (Frame-Dehnung): Die Engine dehnt den aktuellen Server-Frame künstlich aus. Statt 33 ms dauert ein Frame plötzlich 50 ms oder 100 ms. Dem Spieler wird dies als Latenzspitze (Ping) angezeigt, obwohl die physische Route zum Hoster fehlerfrei є. Es handelt sich um eine „interne Serverlatenz“ aufgrund eines überlasteten CPU-Threads.
- Verschlechterung der Trefferregistrierung: Wenn die Physik-Engine die Server-Hitboxen (die Kollisionsmodelle der Spieler zur Schadensberechnung) nicht schnell genug aktualisiert, kommt es zur Desynchronisation. Ein Spieler landet einen präzisen Kopfschuss auf ein laufendes Ziel, und der Client rendert Bluteffekte, aber da der Server die Hitbox-Ausrichtung verzögert hat, ging der Schuss ins Leere.
- Drosselung der KI (Notfall-Modus): Um die Netcode-Stabilität zu retten, reduziert der Server die Aktualisierungszyklen von Nicht-Spieler-Entitäten. Bots reagieren erst nach Sekunden, frieren ein oder bewegen sich in Sprüngen über die Karte.
| Genre / Architektur-Vorlage | Optimale Tickrate | Primäre CPU-Frame-Budget-Zuweisung |
|---|---|---|
| Kompetitive Shooter (CS2, Valorant) | 64 — 128 Hz | 90% — Netzwerksynchronisation und sofortige Trefferregistrierung (Hitreg). Physik є minimal. |
| Survival-Sandboxes / MMOs (Rust, DayZ) | 20 — 30 Hz | 70% — Entitäten-Simulation, Kollisionsprüfungen für Gebäude, KI von Monstern/Bots. 30% — Netzwerk-Broadcasting. |
| Automatisierungs-Simulatoren (Satisfactory, Factorio) | 10 — 20 Hz | 95% — Logik- und Graphberechnungen von Fabriken und Förderbändern. Netcode є sekundär. |
Fazit
Die Tickrate є kein magischer Schalter für mehr Performance, sondern ein mathematischer Balanceakt. Das Erhöhen dieses Parameters є nur dann sinnvoll, wenn die Spielwelt simpel strukturiert є und die Server-CPU über ausreichend ungenutzte Frame-Zeit verfügt.
Bei riesigen persistenten Welten liegt die Kunst der Optimierung darin, eine absolut stabile, monolithische Rate (z. B. konstante 30.0 UPS) ohne Mikrosekunden-Schwankungen zu halten. Die Flüssigkeit eines Spiels wird nicht durch einen abstrakten Config-Wert definiert, sondern durch die Fähigkeit des Servers, sämtliche Berechnungen innerhalb seines zeitlichen Frame-Budgets abzuschließen.