Die Implementierung von Multiplayer-Netzwerken in bahnbrechenden Spielen wie Half-Life und Counter-Strike erforderte die Lösung tiefer technischer Herausforderungen, die die Online-Spielentwicklung heute noch beeinflussen. Ursprünglich als Modifikation von Valves Quake-Engine entwickelt, hat sich Counter-Strike zu einem eigenständigen Titel entwickelt, der hohe Präzision, geringe Latenz und cheat-resistentes Gameplay erforderte. Die für diese Titel entwickelte Netzwerkarchitektur - basierend auf einem Client-Server-Modell, benutzerdefinierter Zuverlässigkeit gegenüber UDP und einer ausgeklügelten Verzögerungsvergütung - setzte einen Maßstab für Echtzeit-Multiplayer-Shooter. Dieser Artikel untersucht die wichtigsten technischen Komponenten hinter Half-Life und Counter-Strike's Netcode, die Protokolle und Algorithmen, die sie zum Funktionieren gebracht haben, und das Vermächtnis, das diese Entscheidungen für moderne Online-Spiele hinterlassen haben.

Das Client-Server-Modell im Detail

Half-Life und Counter-Strike haben eine strenge Client-Server-Architektur implementiert, bei der der Server die autoritative Kontrolle über den gesamten Spielzustand behält. Jede Spieleraktion - ob sie sich bewegt, schießt oder neu lädt - muss vom Server validiert werden, bevor sie die Simulation beeinflusst. Dieses Design verhindert Manipulationen und gewährleistet die Konsistenz aller verbundenen Clients.

Autoritativer Server

Auf Valves GoldSrc-Engine (und späterer Quelle) führt der Server die vollständige Physiksimulation, Kollisionserkennung, Spielregeln und KI-Logik aus. Clients senden rohe Eingabebefehle (z. B. Tastendrücke oder Mausbewegungen) an den Server, aber sie beeinflussen nie direkt die Welt. Der Server verarbeitet diese Eingaben, aktualisiert den Zustand und sendet die neuen Positionen, Gesundheit, Ereignisse und Entitäts-Schnappschüsse an alle Spieler zurück. Da der Server die einzige Quelle der Wahrheit ist, wird jeder Versuch eines Clients, den Zustand zu manipulieren - wie z. B. durch Wände zu bewegen oder den Zustand zu verändern - automatisch abgelehnt. Dieser autoritative Ansatz, der bandbreitenintensiver ist, bleibt die Grundlage für ein faires Multiplayer-Gameplay.

Client-Input-Verarbeitung

Jeder Client sammelt Spielereingaben jedes Frames und packt sie in eine Befehlsstruktur, die Bewegungsvektoren, Blickwinkel, Schaltflächenzustände und einen Zeitstempel enthält. Diese Befehle werden als UDP-Datagramme an den Server gesendet. Der Server stellt eingehende Befehle in Warteschlangen, führt sie in der richtigen Reihenfolge basierend auf der Tick-Reihenfolge aus und wendet sie auf die autoritative Simulation an. Um variable Latenz zu glätten, verarbeitet der Server Befehle von mehreren Clients gleichzeitig während jedes festen Zeitschritts. Jeder Befehl, der zu spät oder nicht in Ordnung ist, wird je nach Wichtigkeit verworfen oder neu interpretiert. Dieses Design stellt sicher, dass die Simulation des Servers deterministisch und cheat-resistent bleibt.

Netzwerk-Transport: Warum UDP und Custom Reliability

Half-Life und Counter-Strike verlassen sich beim Echtzeit-Datenaustausch in erster Linie auf UDP (User Datagram Protocol), das trotz der garantierten Liefer- und Bestellvorteile von TCP über TCP gewählt wurde.

UDP vs. TCP Trade-offs

TCP bietet zuverlässige Paketzustellung in Auftrag, führt aber einen erheblichen Overhead ein: Es erfordert Bestätigungen, die erneute Übertragung verlorener Pakete und ein Staufenster, das eine Head-of-Line-Blockierung verursachen kann. In einem schnelllebigen Shooter kann sogar eine kleine Verzögerung, die durch das Warten auf die erneute Übertragung eines verlorenen Pakets verursacht wird, das Spielerlebnis ruinieren. UDP bietet im Gegensatz dazu ein Best-Effort-Liefermodell ohne eingebaute Bestellung oder erneute Übertragung. Die sendende Anwendung steuert genau, welche Daten das Netzwerk verlassen und wann, was den Overhead minimiert. Der Nachteil - Pakete können ausfallen, dupliziert werden oder ganz verloren gehen - wird durch benutzerdefinierte Logik gemindert, die in die Netzwerkschicht des Spiels integriert ist.

Packet Loss Handling und Sequenzierung

Der GoldSrc-Netcode implementiert seine eigene Zuverlässigkeitsschicht auf UDP. Kritische Nachrichten (wie Waffenschüsse oder Spielertode) werden über einen zuverlässigen Kanal gesendet, der Pakete sequenziert und eine erneute Übertragung anfordert, wenn Bestätigungen nicht innerhalb einer Timeout-Periode empfangen werden. Weniger kritische Updates - wie Positionsänderungen oder Animationszustand - werden unzuverlässig gesendet, so dass das System ältere Snapshots zugunsten neuerer abwerfen kann. Sequenznummern werden an jedes Paket angehängt, so dass der Empfänger verlorene oder nicht geordnete Datagramme erkennen und entweder veraltete Daten ablegen oder einen erneuten Versand anfordern kann. Dieser hybride Ansatz ermöglichte es Half-Life und Counter-Strike, ein responsives Gameplay auch auf der begrenzten Bandbreite und den Verbindungen mit hoher Latenz der späten 1990er und frühen 2000er Jahre beizubehalten.

Für einen tieferen Einblick in die Entwicklung der Echtzeit-Netzwerke bietet Valves eigene GDC-Präsentation 2001 von Yahn Bernier einen umfassenden Überblick über die Techniken, die in Half-Life verwendet werden: Latenzkompensierungsmethoden im Client / Server-Protokolldesign und -optimierung.

Glättendes Gameplay über unzuverlässige Netzwerke

Selbst mit UDP und benutzerdefinierter Zuverlässigkeit erleben die Spieler variable Latenz, Paketverlust und Jitter. Um die Illusion einer sofortigen Reaktion und konsistenter Weltanschauungen aufrechtzuerhalten, implementierten Half-Life und Counter-Strike drei kritische Techniken: clientseitige Vorhersage, Serverabgleich und Entitätsinterpolation.

Client-Side-Vorhersage und Server-Abgleich

Ohne clientseitige Vorhersage würde jede Spieleraktion einer Roundtrip-Latenz unterliegen: Sie klicken mit der Maus, der Befehl fährt zum Server, der Server verarbeitet ihn und das Ergebnis reist zurück. Bei einem Spiel wie Counter-Strike, bei dem Reaktionszeiten in Millisekunden gemessen werden, wäre diese Verzögerung inakzeptabel. Clientseitige Vorhersage ermöglicht es dem lokalen Client, sofort die Wirkung seiner eigenen Eingabe zu simulieren (z. B. Vorwärtsbewegung oder Feuern), bevor der Server sie bestätigt. Der Client führt eine Kopie der Spielwelt aus und aktualisiert sie mit den gleichen Bewegungs- und Physikregeln wie der Server. Dies gibt dem Spieler sofortiges visuelles Feedback.

Die Vorhersage des Clients kann jedoch vom autoritativen Zustand des Servers abweichen, weil es zu Verzögerungen, Paketverlusten oder Differenzen in der Simulation kommt. Die Serverabgleichung korrigiert diese Abweichungen. Jedes Mal, wenn der Server eine Momentaufnahme des Spielzustands sendet, vergleicht der Client die Positionen des Servers mit seinem eigenen vorhergesagten Zustand. Wenn es zu einer Diskrepanz kommt, bewegt der Client seine lokalen Einheiten reibungslos zu den Positionen des Servers und korrigiert Fehler, ohne dass es zu einer störenden Teleportation kommt. Diese Kombination von Vorhersage und Abgleich macht Counter-Strike selbst bei einem hohen Ping reagierend.

Interpolation von Unternehmen

Da der Server Updates nur mit einer festen Frequenz (Tickrate) sendet, erhält der Client diskrete Snapshots. Entity-Interpolation füllt die Lücken, indem Objektpositionen zu einem Zeitpunkt zwischen den letzten beiden empfangenen Snapshots dargestellt werden, wobei gewichtete Durchschnittswerte auf der Grundlage der Zeitstempel verwendet werden. Dies erzeugt eine reibungslose, kontinuierliche Bewegung, selbst wenn der Server nur 20 oder 66 Mal pro Sekunde aktualisiert. In Counter-Strike ist Interpolation sichtbar in der Art und Weise, wie sich die Spieler bewegen: Sie scheinen nicht zwischen den Positionen zu "snapen", weil die Engine die Animation und den räumlichen Zustand zwischen den Updates reibungslos verbindet.

Lag-Entschädigung für Hitscan-Waffen

Eine der innovativsten Eigenschaften im Netcode von Counter-Strike ist die Verzögerungsentschädigung für Hitscan-Waffen (Gewehre, Pistolen, Scharfschützengewehre). Da Kugeln sich in der Hitscan-Mechanik sofort bewegen, muss der Server entscheiden, ob ein Schuss auf der Grundlage der Position des Ziels zum Zeitpunkt des Schusses getroffen wird - nicht, wenn der Server ihn verarbeitet hat. Wenn ein Spieler eine Latenz von 100 ms hat und auf einen Feind zielt, hat der Feind sich bis zum Zeitpunkt des Erhalts des Befehls möglicherweise an einen anderen Ort bewegt. Ohne Entschädigung würde der Schuss verfehlen.

Die Lösung von Valve speichert eine kurze Historie der Position jedes Spielers für die letzten paar hundert Millisekunden auf dem Server. Wenn der Server einen Schussbefehl erhält, schaut er die Position des Ziels zu dem Zeitpunkt, an dem der Client des Schützen sie sah (entspricht dem Zeitstempel im Befehl). Der Server führt dann die Treffererkennung gegen diese historische Position aus, anstatt den aktuellen Zustand. Diese Methode - die sogenannte Verzögerungskompensation - reduziert den Nachteil eines höheren Pings drastisch.

Eine detaillierte Aufschlüsselung dieser Technik findet sich in Gaffer on Games, wo Glenn Fiedler ähnliche Methoden erklärt, die in Multiplayer-Shootern verwendet werden.

Tick Rate und Update-Frequenz

Die Tick-Rate des Servers bestimmt, wie oft er Eingaben verarbeitet und Snapshots sendet. In frühen Counter-Strike 1.6 betrug die Standard-Server-Tick-Rate etwa 20 Hz (20 Updates pro Sekunde) auf offiziellen Servern, während konkurrierende Server oft mit benutzerdefinierten Einstellungen auf 33 oder sogar 100 Hz erhöht wurden. Höhere Tick-Raten reduzieren die Verzögerung zwischen der Aktion eines Spielers und der Reaktion des Servers, erhöhen aber auch die Bandbreite und die CPU-Auslastung.

Server Tick Rate (sv tickrate)

Die Tickrate ist direkt an die Simulationsschrittgröße des Servers gebunden. Bei 33 Hz entspricht jeder Tick etwa 30 ms Spielzeit. Der Server führt alle anstehenden Befehle aus, führt Physik aus, verarbeitet Schäden und sendet an alle Clients eine vollständige Momentaufnahme. Eine höhere Tickrate bedeutet eine präzisere Treffererkennung und reibungslosere Bewegung, erhöht aber auch die Belastung der CPU und des Netzwerks des Servers. In der modernen Counter-Strike: Global Offensive sind Tickraten von 64 und 128 Hz Standard, aber die zugrunde liegenden Prinzipien bleiben gleich.

Client-Interpolationseinstellungen (lerp)

Auf der Clientseite steuert ein Interpolationsparameter namens (oder ), wie weit zurück in der Zeit der Client das Spiel macht, um die Netzwerkverzögerung zu kompensieren. Clients müssen einen lerp-Wert wählen, der die Glätte mit der Reaktionsfähigkeit ausgleicht. Ein niedriger lerp reduziert die visuelle Latenz, kann aber Jitter verursachen, wenn Pakete verloren gehen; ein hoher lerp glättet Netzwerkunregelmäßigkeiten aus, fügt aber eine konstante Verzögerung hinzu, was der Spieler sieht. Im kompetitiven Spiel optimieren die Spieler diese Einstellungen oft, um das beste Gefühl für ihre Verbindung zu erzielen.

Bandbreite und Datenoptimierung

Half-Life und Counter-Strike wurden für die Internetverbindungen ihrer Zeit (56k Modems bis frühes Breitband) entwickelt, um die Bandbreite überschaubar zu halten, verwendete der Netcode mehrere Optimierungstechniken.

Deltakompression

Der Server sendet nicht mit jedem Snapshot den vollen Spielzustand, sondern nach der Verbindung mit einem Spieler einen Basis-Snapshot, und nachfolgende Snapshots werden deltakomprimiert: Es werden nur die Änderungen (Deltas) seit dem letzten bestätigten Snapshot übertragen. Dies reduziert die Größe jedes Updates drastisch. Wenn ein Spieler stillsteht, kann der Server nur ein winziges Update senden, das keine Positionsänderung anzeigt. Wenn ein Spieler eine Waffe abfeuert, enthält das Delta den neuen Munitions- und Mündungs-Flash-Status, aber nicht den gesamten Waffen-Array. Die Delta-Komprimierung ist unerlässlich, um große Spielerzahlen zu unterstützen (bis zu 32 bei Counter-Strike), ohne das Netzwerk zu sättigen.

Variable Rate Updates

Kritische Ereignisse wie Schäden, Kills und Waffenfeuer werden sofort über den zuverlässigen Kanal gesendet, während routinemäßige Positionsaktualisierungen mit der Tick-Rate über den unzuverlässigen Kanal gesendet werden. Der Server passt die Aktualisierungsrate auch dynamisch an, basierend auf der verfügbaren Bandbreite und der Clientverbindungsqualität. Wenn ein Client Paketverlust erfährt, kann der Server die Häufigkeit von nicht wesentlichen Updates reduzieren oder zu einem zuverlässigeren Kanal für kritische Daten wechseln. Dieser adaptive Ansatz half, die Spielbarkeit über einen breiten Bereich von Netzwerkbedingungen hinweg aufrechtzuerhalten.

Anti-Cheat-Architektur (VAC und darüber hinaus)

Die Halbwertszeit und Counter-Strike-Netzwerke sind nicht vollständig, ohne Valve Anti-Cheat (VAC) zu erwähnen. Obwohl VAC in erster Linie ein clientseitiges Scan- und serverseitiges Erkennungssystem ist, beruht sein Design auf dem autoritativen Netcode des Servers. Cheats, die Clientspeicher ändern oder Pakete einfügen, müssen die Validierungsprüfungen des Servers umgehen. VAC arbeitet zusammen mit dem Netcode durch:

  • Überprüfen, ob die ausführbaren und DLLs des Clients mit bekannten guten Versionen übereinstimmen.
  • Erkennung von Mustern wie der Aimbot-Nutzung durch Analyse von Schussgenauigkeitsstatistiken, die an den Server gesendet werden.
  • Konten zu verbieten, die mit bekannten Cheat-Signaturen erwischt werden.

Kritischerweise verhindert die Autorität des Servers viele gängige Cheats: Ein Wallhack kann nur enthüllen, was bereits an den Client gesendet wird (der Server sendet alle Entitätspositionen, so dass Wallhacks durch die "Sichtbarkeit" -Logik des Servers und durch die Begrenzung der Daten, die Clients über entfernte Feinde erhalten, gemildert werden).

Mehr über die Geschichte und die Fähigkeiten von VAC finden Sie auf der offiziellen Anti-Cheat-Seite von Valve.

Vermächtnis und Einfluss auf modernen Netcode

Die in Half-Life und Counter-Strike Pionierarbeit geleisteten Netzwerktechniken schufen eine Vorlage, die immer noch von fast jedem großen Online-Shooter verfolgt wird. Moderne Spiele wie Overwatch, Valorant und Call of Duty verwenden clientseitige Vorhersage, Serverabgleich, Verzögerungsvergütung, Delta-Komprimierung und Tick-basierte Updates. Valves Open-Source-Dokumentation und GDC-Gespräche halfen dabei, eine ganze Generation von Spieleentwicklern zu erziehen. Die Entscheidungen für GoldSrc und Source Netcode - autoritative Server, UDP mit benutzerdefinierter Zuverlässigkeit und ausgefeilte Interpolation - bewiesen, dass schnelle, faire Multiplayer über das Internet erreichbar waren, nicht nur über ein LAN.

Der Einfluss geht über Shooter hinaus. Kampfspiele, Echtzeit-Strategietitel und sogar Rennspiele haben ähnliche Client-Server- oder Peer-to-Peer-Architekturen mit Vorhersage und Rollback angenommen. Die Kernprobleme (Latenz, Paketverlust, Betrug) bleiben die gleichen, und die für Half-Life und Counter-Strike entwickelten Lösungen bieten einen robusten Ausgangspunkt für jedes vernetzte Spiel.

Einen technischen Überblick darüber, wie Source Netcode heute mit der Replikation und Vorhersage von Entitäten umgeht, finden Sie in der Dokumentation zum Source Multiplayer Networking von Valve.

Zusammenfassend war das Multiplayer-Networking in Half-Life und Counter-Strike nicht nur ein Produkt seiner Zeit, sondern eine grundlegende Errungenschaft, die zeigte, wie man reaktionsschnelles, faires und skalierbares Online-Gameplay liefert. Durch die Balance zwischen Leistungsoptimierungen und strenger Serverautorität hat Valve ein Erlebnis geschaffen, das Millionen von Spielern heute noch genießen - und das wird auch weiterhin darüber informieren, wie Spiele Menschen über das Internet verbinden.