Wer einen Game Server betreibt, stellt sich schnell eine Frage: Warum fühlt sich das Spiel bei 20 Spielern noch flüssig an – und bei 80 plötzlich nicht mehr? Die Antwort liegt selten an der rohen Rechenleistung, sondern an der Netzwerkarchitektur. Game Server haben besondere Anforderungen, die sie grundlegend von klassischen Web-Anwendungen unterscheiden. Während ein HTTP-Request einige Hundert Millisekunden toleriert, spürt ein Spieler jede Verzögerung über 80 ms sofort.
Was Game Server von klassischen Servern unterscheidet
Klassische Web-Server folgen einem Request-Response-Modell: Der Client sendet eine Anfrage, der Server antwortet, die Verbindung wird geschlossen oder wiederverwendet. Game Server hingegen arbeiten mit persistenten, bidirektionalen Verbindungen. Hunderte von Clients senden gleichzeitig Positions- und Aktionsdaten, während der Server den Spielzustand für alle Teilnehmer synchronisiert und in Echtzeit zurücksendet. Das geschieht bei modernen Multiplayer-Titeln 20 bis 128 Mal pro Sekunde – die sogenannte Tickrate des Servers.
Je höher die Tickrate, desto präziser das Spielgefühl – aber auch desto höher die CPU- und Bandbreitenbelastung. Counter-Strike 2 läuft etwa mit 64 Ticks pro Sekunde im Standardbetrieb, kompetitive Server verwenden 128. Das bedeutet: Pro Sekunde werden 128 vollständige Spielzustands-Updates berechnet und an alle verbundenen Clients verteilt.
UDP statt TCP: Warum Verlässlichkeit manchmal im Weg steht
Das erste überraschende Merkmal vieler Game-Networking-Implementierungen: Sie setzen auf UDP statt TCP. TCP garantiert Zustellung und Reihenfolge – klingt gut, ist aber für Echtzeit-Spiele problematisch. Wenn ein Paket verloren geht, wartet TCP auf die erneute Übertragung. Diese Verzögerung – auch Head-of-Line Blocking genannt – ist für Positionsupdates fatal: Veraltete Daten, die mit 50 ms Verspätung ankommen, sind schlechter als gar keine.
UDP liefert Pakete ohne Garantie, aber ohne Wartezeit. Der Nachteil: Verluste müssen auf Anwendungsebene behandelt werden. Moderne Game-Engines implementieren deshalb eigene Zuverlässigkeitsschichten, die selektiv Pakete bestätigen. Kritische Nachrichten wie Spieler-Tod oder Score-Update werden erneut übertragen, reine Positionsupdates nicht. Neue Protokolle wie QUIC kombinieren die Geschwindigkeit von UDP mit Zuverlässigkeitsmechanismen auf Anwendungsebene. Immer mehr Game-Engines experimentieren damit, besonders für Szenarien mit häufigem Paketverlust wie in mobilen Netzwerken.
Client-Side Prediction und Server-Side Reconciliation
Ein zentrales Konzept moderner Multiplayer-Architektur ist die Client-Side Prediction. Anstatt auf die Antwort des Servers zu warten, simuliert der Client lokal, was passiert, wenn der Spieler eine Taste drückt. Das Ergebnis wird sofort angezeigt – das Spiel fühlt sich reaktionsfähig an. Gleichzeitig sendet der Client seine Eingaben an den Server.
Der Server berechnet den autoritativen Zustand und sendet Korrekturen zurück. Falls Server und Client-Prognose abweichen, korrigiert der Client seinen Zustand – im Idealfall so sanft, dass der Spieler es kaum wahrnimmt. Dieses Muster nennt sich Server-Side Reconciliation. Der Game Server ist dabei immer die einzige Wahrheit: Er entscheidet, ob ein Treffer valide war, ob eine Aktion erlaubt ist und welchen Zustand die Spielwelt hat. Damit ist er auch die zentrale Instanz für Anti-Cheat-Maßnahmen.
Lag Compensation: Zeit zurückdrehen für faire Treffer
Netzwerklatenz erzeugt eine besondere Herausforderung bei der Treffererkennung. Spieler A sieht Spieler B aufgrund von Netzwerkverzögerung immer leicht in der Vergangenheit. Wenn A schießt und Spieler B laut Client-Darstellung trifft, befand sich B aus Sicht des Servers vielleicht schon an einer anderen Position.
Lag Compensation löst dieses Problem, indem der Server die vergangene Position von Spieler B zum Zeitpunkt des Schusses rekonstruiert. Dafür speichert der Server einen kurzen Positionsverlauf aller Spieler. Beim Treffer-Check dreht er die Zeit zurück auf den Zeitpunkt, an dem der Schuss beim Server ankam, und prüft dann die Kollision. Das Ergebnis wirkt fair für den Schützen, kann aber für das Opfer kontraintuitiv sein: Es stirbt scheinbar hinter einer Wand, weil der Server in der Vergangenheit sieht.
Monitoring von Game Servern: Was wirklich gemessen werden muss
Die klassischen Monitoring-Metriken wie CPU und RAM sind für Game Server notwendig, aber nicht ausreichend. Für stabilen Betrieb sind folgende Werte entscheidend:
- Tickrate-Stabilität: Fällt die Tickrate unter den Sollwert, merken Spieler es sofort als Ruckeln oder Rubber-Banding.
- Netzwerklatenz pro Spieler: Durchschnittliche und maximale RTT zeigen, ob ein einzelner Spieler oder der gesamte Server ein Problem hat.
- Paketverlustrate: Über 1–2 % Paketverlust werden Spielsessions spürbar schlechter.
- Entity Count: Wie viele aktive Objekte simuliert der Server? Zu viele Entities bei hoher Tickrate überlasten auch starke CPUs.
- Spieler-Verbindungszeit: Lange Join-Zeiten deuten auf Überlast oder Konfigurationsprobleme hin.
Einfaches Heartbeat-Monitoring reicht für Game Server nicht aus. Ein Server kann online sein und trotzdem mit einer Tickrate von 10 statt 64 laufen. Für tiefe Einblicke bieten sich spielspezifische Protokolle wie das Valve Source Query Protocol an, das Metriken wie aktive Spieler, aktuelle Map und Tickrate direkt abfragt.
Horizontale Skalierung: Regionen und dynamische Instanzierung
Wächst die Spielerbasis, wird horizontale Skalierung notwendig. Dabei gibt es zwei Hauptansätze: regionale Server-Cluster und dynamische Instanzierung. Regionale Cluster platzieren Server nahe den Spielern – EU-Spieler verbinden sich mit EU-Servern. Das reduziert Latenz strukturell, unabhängig von Netzwerkoptimierungen.
Dynamische Instanzierung bedeutet, dass für jedes Match eine eigene Server-Instanz gestartet wird. Cloud-Dienste wie AWS GameLift oder Azure PlayFab bieten genau das: automatisches Starten und Beenden von Game-Server-Instanzen basierend auf der Nachfrage. Das macht die Infrastruktur kosteneffizient – im Leerlauf laufen keine ungenutzten Instanzen. Für kleinere Teams und Community-Server ist Self-Hosting auf dedizierten Maschinen weiterhin beliebt. Hier sind regelmäßige Verfügbarkeitsprüfungen, automatische Neustarts nach Absturz und klare Alerting-Regeln beim Überschreiten von Latenzschwellenwerten entscheidend.
Fazit: Netzwerkarchitektur ist Spielqualität
Die Qualität eines Multiplayer-Spiels steht und fällt mit seiner Netzwerkarchitektur. UDP, Lag Compensation, Client-Side Prediction und stabile Tickrates sind keine akademischen Konzepte – sie entscheiden, ob ein Match fair, flüssig und angenehm ist. Game-Server-Betreiber sollten diese Mechanismen verstehen, um Monitoring-Metriken richtig zu interpretieren, Probleme schnell zu isolieren und Optimierungen gezielt umzusetzen.
Bildquelle: EFTA Free Library / Wikimedia Commons, CC0
Quellen
- Valve Developer Community: Source Multiplayer Networking (developer.valvesoftware.com)
- Gabriel Gambetta: Fast-Paced Multiplayer (gabrielgambetta.com)
- AWS Documentation: Amazon GameLift (docs.aws.amazon.com)
