Servereinblick – Die Macht des Schönen

Kapselpiloten,

Es ist an der Zeit, das Gespräch über Quasar fortzusetzen, das zugrunde liegende Ökosystem für die moderne Entwicklung in EVE Online. Seit seiner Einführung auf dem Fanfest 2022 wurde es zur Grundlage für mehrere wichtige Fortschritte, darunter:

Diese Reise, ein Teil von EVE Evolved, hat sich mit der Mengenlehre, der Graphentheorie und, äh … der Farbtheorie befasst. Heute liegt der Fokus jedoch auf der Technologie, die von Kapselpiloten erstellte Schiff-SKINs antreibt, da sie viel mehr ist als nur ein schicker Editor und Shader-Zauberei! Tatsächlich ist sie ein wesentlicher Bestandteil, um zukünftige Möglichkeiten für die Serverleistung zu eröffnen. Ihr solltet euch allerdings darauf gefasst machen, dass einige technische Crashkurse erforderlich sein werden, um die Feinheiten dessen zu verstehen, woran das Team gearbeitet hat.

Netzcode und Tickrate

Eine der häufigsten Herausforderungen in Mehrspielerspielen ist die Netzwerkarchitektur, die umgangssprachlich als „Netzcode“ bezeichnet wird. Egal, ob man ein einheitliches Erlebnis für alle Spieler gewährleisten oder Cheating verhindern möchte, die Art und Weise, wie Informationen an Spielclients übertragen werden, spielt eine entscheidende Rolle für die allgemeine Leistung und den Spielspaß. Ein wichtiger Faktor ist hier die Tickrate – die Frequenz, mit der der Spielserver Informationen aktualisiert und an verbundene Clients sendet.

Verschiedene Spiel-Engines gehen dieses Thema auf unterschiedliche Weise an. Unreal Engine legt zum Beispiel Wert auf Relevanzfilter, wobei nur die wichtigsten Updates an jeden Client gesendet werden, während Source Engine sich auf Eingabevorhersage konzentriert, um die Anzahl der Korrekturen zu reduzieren, die für reibungsloses Gameplay erforderlich sind.

Unabhängig vom Ansatz bleibt die Tickrate ein grundlegender Faktor für die Netzwerkleistung. Die meisten Spiele bewegen sich je nach Anzahl der Spieler, die aktuell online sind, zwischen 20 Hz und 120 Hz, was bedeutet, dass Updates zwischen 20 und 120-mal pro Sekunde pro Client gesendet werden. Beispielsweise muss der Server bei 60 Hz alle 16,6 Millisekunden Updates verarbeiten und senden, um sicherzustellen, dass 60 Updates innerhalb einer Sekunde erfolgen können, und das mit genug Spielraum, damit andere Spieler im selben Zeitraum dieselben Informationen erhalten können. Angenommen, es gäbe eine magische, latenzfreie Internetverbindung, die den Clients den Spielstatus direkt bei der Verbindung übermittelt (tun wir einfach mal so, als gäbe es das), würde ein Server bei 60 Hz Spielstatus-Updates wie folgt verarbeiten:

Zwei Ticks eines Servers bei 60 Hz

Eingabevorhersage und Motion-Interpolation können die Illusion einer nahezu Echtzeit-Interaktion schaffen, selbst ohne ein magisches Internet ohne Latenz. Aber wenn die Tickrate sinkt, werden Verzögerungen spürbarer. Das klingt schlecht, oder? Warum solltet ihr also jemals eine niedrigere Tickrate wollen?

Nun, EVE Online gibt es seit der Zeit der 56k-Modems. Um die Bandbreitenvoraussetzungen niedrig genug für gewaltige Weltraumschlachten zu halten, wurde die Server-Tickrate auf eine Sekunde eingestellt.

Genauer gesagt beträgt die Tickrate der Physiksimulation 1 Hz, was die Notwendigkeit, Updates an die Desktop-Clients zu senden, erheblich reduziert.

Andere Wechselwirkungen mit Elementen, die die Physik nicht beeinflussen, werden so schnell verarbeitet, wie die Python-Hamster können. Das bedeutet, dass es sich sehr reaktionsschnell anfühlt, wenn eine Eingabe direkt vor einem Tick gesendet wird. Wenn sie direkt danach gesendet wird, kann es sich anfühlen, als würde es eine Sekunde oder noch länger dauern, bis ein Effekt sichtbar wird (wenn man die Latenz der realen Welt berücksichtigt – GG, Australien). Technisch gesehen könntet ihr mit dem Server perfekt auskommen, indem ihr genau einmal pro Sekunde eine Taste drückt, aber natürlich kann es für das mentale Wohlbefinden sehr wichtig sein, dreißig Mal pro Sekunde auf „Springen“ zu klicken.

Betrachtet man Tranquility im vergangenen Jahr ganzheitlich, wird deutlich, dass die Anzahl der Operationen pro Sekunde proportional zur Anzahl der aktiven Kapselpiloten im Cluster ist. Im Durchschnitt verarbeitet jede Sitzung etwa 0,7 Operationen pro Sekunde, was zeigt, wie effizient EVE Online nur die notwendigen Daten überträgt.

Die Zahlen schwanken natürlich, und das sind alles Mittelwerte. Wenn Flottenkämpfe die Verarbeitungsgrenzen erreichen, setzt die Zeitdilatation (TiDi) ein. Wenn ihr neugierig auf die Einzelheiten sind, könnt ihr im Archiv zur TiDi mehr erfahren.

Wo kommen also SKINs ins Spiel?

Fast alle kosmetischen Mechanismen in EVE Online werden über Simulationsframes, EVEs Version eines Ticks, versendet. Vor SKINR wurden Änderungen an Schiff-SKINs mit dem nächsten Simulationsframe geliefert, der an alle relevanten Clients gesendet wurde. Mit anderen Worten: SKIN-Updates konnten nur einmal pro Sekunde erfolgen. Auch ohne Begrenzungen der Benutzeroberfläche oder der Netzwerkanfragen war es egal, wie schnell ihr eure SKINs geändert habt – niemand konnte mehr als ein Update pro Sekunde sehen, denn das war das Limit für die Übertragung von Simulationsframes.

Außerdem gibt es noch ein weiteres Problem: die Ausgangsverzweigung. (Letzter Crashkurs, versprochen.)

Wenn ihr den SKIN eures Schiffes ändert, muss das Update an mehrere Empfänger gesendet werden – was als „Ausgangsverzweigung“ bezeichnet wird. Aber welche müssen die Informationen erhalten? Was passiert, wenn hundert andere Schiffe in der Nähe sind? Was bedeutet eigentlich „in der Nähe“ und wer sind die anderen hundert?

Simulationsframes handhaben beide Probleme, indem sie nur Updates für Schiffe in derselben Blase verarbeiten (umgangssprachlich Gitter – nicht zu verwechseln mit Warpstörungsblasen). Dieser Ansatz hat allerdings einen Haken, denn mehr Daten pro Simulationsframe bedeuten mehr Serialisierung und Ausgangsverzweigung für den Server, der dieses Sonnensystem simuliert. Vorher verfolgte Quasar nur, in welchem Sonnensystem sich ein Schiff befand, aber damit SKINR in Echtzeit funktionieren kann, musste es auch die Schiffsbewegung zwischen Blasen verfolgen.

Das war keine leichte Sache. Es waren tiefgreifende Änderungen an der Kernsimulations-Engine von EVE Online erforderlich, um Quasar in einer bisher nicht dagewesenen Weise den Zugriff auf seinen Zustand zu ermöglichen. Das Ergebnis war schockierend! Ein 27-facher Anstieg der weiterverarbeiteten Daten im Vergleich zu den einfachen Übergängen zwischen Sonnensystemen.

Hier ist ein Vergleich von Events pro Sekunde zwischen Reisen durch das Sonnensystem und Blasenreisen – man beachte hierbei, dass das Warpen mehrere Blasen durchquert, nicht nur „A nach B“.

Und das ist nur interner Verkehr, bevor man das Problem der Ausgangsverzweigung überhaupt bedenkt!

Die Lösung der Ausgangsverzweigung-Herausforderung

Gehen wir zurück zum Szenario „ein Schiff verändert in der Nähe von 100 anderen Schiffen seinen SKIN“. Da Quasar alle Schiffe in allen Blasen nachverfolgt, versteht es jetzt, was „in der Nähe“ bedeutet und welche Clients Updates erhalten müssen. Anstatt auf den nächsten Simulationsframe zu warten, sendet Quasar sofort SKIN-Änderungen an alle in einer bestimmten Blase.

Dies wird durch die Nachrichtenübermittlung des mächtigen NATS ermöglicht, das die ungefähr 10.000 Nachrichten, die jede Sekunde an EVE-Clients gesendet werden, effizient verarbeitet. Dienste wie die, die den kosmetischen Zustand verwalten, können jetzt ein einzelnes SKIN-Update serialisieren und senden, das dann an alle Schiffe in der Nähe verteilt wird, anstatt durch den 1Hz-Simulationstick verzögert zu werden.

Dies wird in diesem kurzen Clip von einem SKINR-Spieltest demonstriert:

Nun stellt sich folgende Frage: Warum ist es wichtig, dass Quasar die Standorte von Schiffen verfolgen und kosmetische Updates unabhängig versenden kann? Weil diese Technik es EVE Online erlaubt, eine rein kosmetische Funktion von der Hauptsimulations-Engine auszulagern.

Darüber hinaus hat es weitreichendere Konsequenzen, wenn man alle anderen kosmetischen Effekte berücksichtigt, die serialisiert und an Clients verteilt werden müssen. Sobald sich das Gespräch über kosmetische Dinge hinaus bewegt, stellt sich natürliche die Frage: Was könnte sonst noch auf Quasar ausgelagert werden?

Die Grenzen überschreiten

Um das System auf die Probe zu stellen, beinhaltete ein Teil des SKINR-Massentests das Entfernen des Benutzeroberflächenbegrenzers beim SKIN-Wechsel, um zu sehen, was passieren würde. Das Ergebnis? Ein ziemlich interessanter sichtbarer Effekt:

Der Spaß begann mit Beginn des echten Stresstests, mit 500 Spielern, die gleichzeitig massenweise SKIN-Änderungen in derselben Blase auf einem Kartoffel-Testserver durchführten. Das führte dazu, dass das System einen Spitzenwert von etwa 45.000 Nachrichten pro Sekunde erreichte!

Ein großes Dankeschön an alle, die an diesen Massentests teilnehmen. Es ist vielleicht nicht immer offensichtlich, wie wertvoll euer Beitrag ist, aber das hier verdeutlicht die Auswirkungen eurer Teilnahme.

Zurück zu dem chaotischen Beispiel oben – was wurde dadurch erreicht?

Tranquility verarbeitet typischerweise etwa 30.000 Nachrichten pro Sekunde auf dem gesamten Server, was einem Durchschnitt von etwa einer Operation pro Sekunde oder 1 Hz entspricht. Im Gegensatz dazu erreichte der SKINR-Test mit nur 500 Spielern 45.000 Nachrichten pro Sekunde, was bedeutet, dass Quasar in diesem Szenario effektiv Updates mit 90 Hz lieferte.

Wenn Quasar 90-Hz-Verkehr für 500 Spieler auf einem kleinen Testserver mit nur drei Knoten bieten kann, was könnte es schaffen, wenn es auf die volle Leistung von 230 Tranquility-Knoten mit 30.000 aktiven Spielern skaliert wird?

Was passiert, wenn Simulationsframes selbst demselben Paradigma folgen?

Was passiert, wenn die Simulationsframes nicht mehr eine volle Sekunde warten müssen, um gesendet zu werden?

Welche Auswirkungen hat das auf die Zeitdilatation? Verschiebt sich die Meta, wenn Kämpfe im großem Maßstab in Echtzeit ausgetragen werden?

Wenn die Zuverlässigkeit des Netzwerks um das 90-Fache erhöht werden kann, welche neuen Erfahrungen können die Designer den Piloten von New Eden dann bieten?

Das sind die Fragen, die die Entwicklung von EVE Online beeinflussen werden, und einige könnten am 20. Februar um 15:00 Uhr auf CCP TV beantwortet werden. Schaltet also ein!

o7