Server Meshing und Persistent Streaming Q&A Auf der CitizenCon 2951 haben wir mit Paul Reindell (Director of Engineering, Online Technology) und Benoit Beausejour (Chief Technology Officer bei Turbulent) einen tiefen Einblick in die transformativen Technologien des Server Meshing und Persistent Streaming gegeben. Nach der Podiumsdiskussion haben wir festgestellt, dass viele Leute Fragen an unsere Podiumsteilnehmer hatten, die wir gerne beantworten möchten. Lies weiter für unsere Fragen und Antworten an Paul, Benoit, Roger Godfrey (Lead Producer) und Clive Johnson (Lead Network Programmer).
Wann werden wir Persistent Streaming und Server Meshing in der PU sehen? Unser derzeitiges Ziel ist es, Persistent Streaming und die erste Version der Replikationsschicht im Idealfall zwischen dem ersten und zweiten Quartal nächsten Jahres zu veröffentlichen. Wenn keine unvorhergesehenen technischen Komplikationen auftreten, werden wir zwischen dem dritten und vierten Quartal nächsten Jahres die erste Version eines statischen Server-Meshes veröffentlichen.
Wie ist der aktuelle Stand der Server-Meshing-Technologie und was sind die größten Probleme, die sie behindern? Die meisten Leute denken beim Thema Server Meshing an den letzten Schritt dieser Technologie, bei dem wir "Server miteinander vermaschen". Die Wahrheit ist, dass vor diesem letzten Schritt eine lange Kette von Vorbedingungen und grundlegenden technologischen Änderungen an unserer Spiel-Engine vorgenommen werden müssen. Deshalb werde ich versuchen, diese Frage im Zusammenhang mit dem Gesamtbild zu beantworten.
Die kurze Antwort ist, dass der Stand der Dinge bereits sehr fortgeschritten ist.
Jetzt die lange Version. Der Weg zum Server Meshing begann bereits 2017/2018:
Object Container Streaming
Damit Server Meshing funktioniert, brauchten wir zunächst eine Technologie, die es uns ermöglicht, Entitäten über das Streaming-System dynamisch zu binden und zu lösen, da die Engine dies zu Beginn nicht unterstützte. Als wir 2018 das "Client Side Object Container Streaming" (OCS) veröffentlichten, haben wir damit auch den ersten Schritt zum Server Meshing gemacht!
Nachdem dieser erste Schritt getan war, musste die Technologie, die es uns ermöglicht, Objekte auf dem Client dynamisch zu binden und zu lösen, auch auf dem Server aktiviert werden (denn schließlich müssen die Serverknoten im Mesh Objekte dynamisch ein- und ausströmen). Diese Technologie wird "Server Side Object Container Streaming" (S-OCS) genannt und die erste Version von S-OCS wurde Ende 2019 veröffentlicht. Das war der nächste große Schritt in Richtung Server Meshing.
Entity Authority & Authority Transfer
Obwohl wir die Technologie hatten, die es uns ermöglichte, Entitäten dynamisch auf dem Server zu streamen, gibt es immer noch nur einen einzigen Server, dem alle simulierten Entitäten "gehören". In einem Netz, in dem sich mehrere Serverknoten die Simulation teilen, brauchten wir das Konzept der "Entity Authority". Das bedeutet, dass eine bestimmte Entität nicht mehr einem einzelnen Spielserver gehört, sondern dass es mehrere Serverknoten im Mesh gibt. Es gibt also einen Serverknoten, der die Entität kontrolliert, und mehrere andere Serverknoten, die eine Client-Ansicht dieser Entität haben. Diese Autorität muss auch die Möglichkeit haben, zwischen den Serverknoten zu wechseln. In der ersten Hälfte des Jahres 2020 wurde viel Entwicklungszeit auf das Konzept der "Entity Authority" und der "Authority Transfer" verwendet. Dies war das erste Mal, dass das gesamte Unternehmen am Server Meshing arbeiten musste, da ein großer Teil des Spielcodes geändert werden musste, um mit dem neuen Entity-Authority-Konzept zu arbeiten. Ende 2020 war der Großteil des (Spiel-)Codes so verändert, dass er das Konzept unterstützte, ein weiterer großer Schritt war also getan, doch ein tatsächliches Mesh ist noch nicht in Sicht.
Replikationsschicht und persistentes Streaming
Der nächste Schritt bestand darin, die Replikation von Entitäten an eine zentrale Stelle zu verlagern, von der aus wir die Streaming- und Netzwerkbindungslogik steuern können. Dies ermöglicht es uns, den Netzwerkstatus auf mehrere Serverknoten zu replizieren. Um dies zu erreichen, mussten wir die Streaming- und Replikationslogik aus dem dedizierten Server in die "Replication"-Schicht verlagern, die nun den Netzwerkreplikations- und Entity-Streaming-Code enthält.
Gleichzeitig haben wir Persistent Streaming implementiert, das es der Replikationsschicht ermöglicht, den Zustand der Entitäten in einer Graphdatenbank zu speichern, in der der Zustand jeder einzelnen im Netzwerk replizierten Entität gespeichert wird. 2021 arbeiteten wir an der Replikationsschicht und dem EntityGraph, der es uns ermöglicht, das Streaming und die Replikation von Entitäten von einem separaten Prozess aus zu steuern (getrennt vom traditionellen Spielserver). Diese Arbeit ist fast abgeschlossen und befindet sich in der Endphase.
Statische und dynamische Server-Meshes
Dies ist jedoch noch kein "Mesh". Die Arbeit an dem eigentlichen Netz hat begonnen und wird uns bis weit ins nächste Jahr hinein beschäftigen. Die erste Version dieser Technologie wird ein statisches Server-Mesh sein und ist der nächste große Schritt. Es wird aber auch nicht die letzte sein! Mit dem statischen Netz werden wir die erste Version eines echten Netzes haben, aber wie der Name "statisch" schon sagt, ist die Skalierbarkeit dieses Netzes sehr begrenzt.
Bevor wir diese Funktion wirklich als vollständig bezeichnen können, müssen wir einen weiteren großen Schritt machen, den wir "dynamisches Mesh" nennen. Dieser Schritt wird es uns ermöglichen, Serverknoten dynamisch miteinander zu vernetzen und das Netz je nach Bedarf dynamisch zu skalieren. Ein großer Teil der Arbeit an diesem Teil geschieht parallel. Der Flottenmanager, der den dynamischen Bedarf des Meshs steuert, ist zum Beispiel bereits in der Entwicklung, ebenso wie die Anforderungen an das Matchmaking, die mit der neuen Einbeziehung von "Shards" einhergehen.
In der Zwischenzeit müssen auch viele Spielcode-Teams daran arbeiten, den bestehenden Spielcode so anzupassen, dass er vollständig mit einem Server-Mesh funktioniert (und, was noch wichtiger ist, alle Randfälle zu finden, die erst auftauchen werden, wenn wir ein echtes Mesh haben). Während die Arbeit an der Entitätsautorität 2020 abgeschlossen wurde, wird die Entitätsautorität derzeit nur zwischen dem Client und einem einzigen Server übertragen, sodass einige Codes noch angepasst werden müssen.
Wie planst du, ein großes Schiff zu verwalten, z.B. eine Javelin? Wäre das eine eigene Ressource mit Schiffen um sie herum? Mit Dynamic Server Meshing ist es möglich, dass große Schiffe wie eine Javelin einen eigenen Server haben, auf dem die maßgebliche Simulation für das Schiff und alles, was sich darauf befindet, läuft. Wir versuchen jedoch, starre Regeln zu vermeiden, die festlegen, wie die Einheiten den Verarbeitungsressourcen zugewiesen werden, daher wird das nicht immer der Fall sein. Es geht um Effizienz, sowohl in Bezug auf die Verarbeitungsgeschwindigkeit als auch auf die Serverkosten. Wenn wir eine feste Regel hätten, dass jeder Javelin und alles, was darin ist, einen eigenen Server bekommt, dann wäre es nicht sehr kosteneffizient, wenn ein Javelin nur eine Handvoll Spieler hat. Die gleiche Regel wäre auch nicht effizient in Bezug auf die Verarbeitungsgeschwindigkeit der Server, wenn sich Hunderte von Spielern auf einer Speerbrücke drängen, da die Regel uns daran hindern würde, die Verarbeitungslast auf mehrere Server zu verteilen.
Das Dynamic Server Meshing wird ein wenig anders sein, da es ständig neu bewertet, wie die Simulation am besten verteilt wird, um den optimalen Punkt zu finden, damit kein einzelner Server überlastet oder unterausgelastet ist. Wenn sich die Spieler/innen im Verse bewegen, wird sich die ideale Verteilung der Verarbeitungsressourcen ändern. Um auf diese Veränderungen reagieren zu können, müssen wir die Möglichkeit haben, die Autorität über Entitäten von einem Server auf einen anderen zu übertragen sowie neue Server online zu bringen und alte abzuschalten. So können wir die Verarbeitungslast von einem Server, der Gefahr läuft, überlastet zu werden, auf einen Server verlagern, der derzeit nicht ausgelastet ist. Wenn keiner der vorhandenen Server über genügend freie Kapazitäten verfügt, um einen Anstieg der Last zu bewältigen, können wir einfach weitere Server von unserem Cloud-Plattformanbieter mieten. Und wenn einige Server nicht genug Last haben, um sie kosteneffizient zu machen, können einige von ihnen ihre Teile der Simulation auf die anderen übertragen und wir können die, die wir nicht mehr brauchen, abschalten.
Wie viele Spieler/innen werden sich in einem Raum sehen können? Was ist das Maximum, das ihr plant? Das ist eine schwer zu beantwortende Frage. Die beste Antwort, die wir im Moment geben können, ist, dass es darauf ankommt.
Angenommen, die Frage bezieht sich darauf, wie viele Spieler/innen sich aus der Sicht des Clients sehen können, so wird dies hauptsächlich durch den Spielclient bestimmt. Das liegt an clientseitigen Simulationen wie Physik und Spielcode sowie an den Renderingkosten.
Außerdem hängt es stark vom Szenario ab: 100 Spieler/innen in FPS-Kämpfen sind billiger zu simulieren und auf dem Client zu rendern als 100 Spieler/innen, die in einsitzigen Raumschiffen kämpfen und sich gegenseitig mit Raketen und Lasern beschießen.
Das Grafikteam arbeitet aktiv an Vulkan, um die Anzahl der Draw Calls zu erhöhen und die Anzahl der Spieler/innen/Schiffe, die wir gleichzeitig rendern können, zu verbessern, während sich das Engine-Team auf die Optimierung des Game-Codes konzentriert, um die Anzahl der Spielobjekte, die wir gleichzeitig simulieren können, zu erhöhen.
Unser Ziel ist es, die Anzahl der Spieler/innen zu erhöhen und wir erwarten, dass wir Szenarien unterstützen, in denen sich 100 Spieler/innen bei vernünftigen Frameraten sehen können. Wenn wir jedoch unsere Shards skalieren, um höhere Spielerzahlen zu unterstützen, wird die Wahrscheinlichkeit abnehmen, dass sich jeder einzelne Spieler innerhalb eines Shards an denselben physischen Ort begeben und einander ohne Leistungsprobleme sehen kann.
An dieser Stelle müssen wir Spielmechaniken einführen, die verhindern, dass diese Szenarien zu häufig auftreten.
Die absolute Grenze ist schwer vorherzusagen, bis einige der neuen Technologien online gehen und wir anfangen können, die Leistung zu messen.
Wenn ich eine Basis auf einem Mond baue, wird meine Basis dann auch auf den anderen Scherben, auf denen ich nicht bin, zu sehen sein? Das Planet Tech-Team plant, den Bau von Basen mit Blick auf die Server-Splits zu implementieren. Wenn du Land für deine Basis beanspruchst, wird dieses Land auf allen Shards beansprucht, und wir planen, deine Basis auf alle Shards zu replizieren.
Allerdings wird es nur auf einem Shard eine "aktive" Version der Basis geben, während auf den anderen Shards eine Version mit eingeschränktem Zugang bzw. Lesezugriff auf dieselbe Basis entsteht. Zum Beispiel wird eine Basis auf dem Shard, auf dem der Besitzer gerade spielt, vollen Zugang und die Möglichkeit zur Erweiterung bieten, während auf allen anderen Shards diese Basis mit verschlossenen Türen in einem unveränderlichen Zustand spawnen kann. Das vollständige Design ist noch nicht zu 100% festgelegt und kann sich noch ändern.
Ist das wahre Endziel ein einziger Shard für alle Spieler? Das ist unser Ziel, aber eine endgültige Antwort ist zum jetzigen Zeitpunkt noch nicht möglich.
Wir werden mit vielen kleinen Shards pro Region beginnen und die Anzahl der Shards langsam reduzieren. Das erste große Ziel ist, dass wir nur noch einen einzigen Shard pro Region brauchen. Um dieses Ziel zu erreichen, wollen wir die Spielerzahl pro Shard schrittweise erhöhen und das Backend und die Client-Technologie ständig verbessern, um mehr und mehr Spieler zu unterstützen.
Um dieses Ziel zu erreichen, sind nicht nur technische Änderungen erforderlich, sondern auch ein neues Spieldesign und neue Spielmechaniken. Ohne Mechanismen, die verhindern, dass jeder einzelne Spieler denselben Ort aufsucht, wird ein großer Mega-Shard nur schwer zu erreichen sein, vor allem auf dem Client. Es könnte zum Beispiel eine Mechanik geben, mit der Sprungpunkte zu überfüllten Orten vorübergehend geschlossen werden können, oder es könnten neue Ebenen für bestimmte Orte geschaffen werden.
Während das Backend für eine horizontale Skalierung ausgelegt ist, läuft der Spielclient auf einem einzigen Rechner und ist auf eine bestimmte Anzahl von CPU/GPU-Kernen und Speicher beschränkt.
Erst wenn wir diese Hürden überwunden und einen Mega-Splitter pro Region erreicht haben, können wir es mit dem Endboss aufnehmen: Die Verschmelzung der regionalen Shards zu einem globalen Mega-Shard.
Das bringt eine ganze Reihe von Problemen mit sich, denn die Lokalität spielt eine große Rolle für das Spielerlebnis. So ist zum Beispiel die Latenz zwischen Diensten innerhalb desselben Rechenzentrums viel geringer als die Latenz zwischen Diensten, die in zwei regional getrennten Rechenzentren gehostet werden. Und obwohl wir das Backend so konzipiert haben, dass es einen globalen Shard unterstützt, ist es eine operative Herausforderung, das Backend so einzusetzen, dass eine Gruppe von Spielern nicht gegenüber einer anderen bevorzugt wird.
Wird die Wirtschaft des Universums in jedem Shard unabhängig oder verbunden sein? Die Wirtschaft wird global sein und sich in jedem Shard widerspiegeln.
Schauen wir uns zum Beispiel die Läden an. Während jeder Laden ein lokales Inventar hat (Gegenstände, die gerade ausgestellt sind), werden die Läden aus einem globalen Inventar aufgefüllt, das auf allen Shards vorhanden ist. Wenn viele Spieler/innen eine bestimmte Waffe im Waffenladen von Port Olisar kaufen, steigt der Preis für diese Waffe in diesem Laden auf allen Shards. Irgendwann ist das Inventar für diese Waffe erschöpft, so dass die Läden auf allen Shards diese Waffe nicht mehr aufstocken können.
Wie wird verhindert, dass große Gruppen von "Blauen" und große Gruppen von "Roten" in den Echokammern landen? Die soziale Dynamik würde große Konzentrationen von Menschen bedeuten, die Freunde haben und in Orgs sind, die die gleichen Interessen haben. Wird es eine Lösung geben, die eine gute Durchmischung von Guten, Bösen und Dazwischen gewährleistet? Die Spieler/innen werden nicht dauerhaft einem Shard zugewiesen, da das Matchmaking-System bei jedem Einloggen einen neuen Shard für die gewählte Region zuweist. Am Anfang wird dies zu einer natürlichen Verteilung führen, da wir mit vielen kleineren Shards parallel starten.
Wenn wir anfangen, unsere Shards zu skalieren (und damit die Anzahl der parallelen Shards zu verringern), wird diese Frage immer wichtiger werden. Wir planen, dieses Problem mit unserem neuen Matchmaking-System zu lösen.
Das neue Matchmaking-System, das derzeit zusammen mit dem Server Meshing entwickelt wird, ermöglicht es uns, Spieler/innen anhand mehrerer Eingabeparameter den Shards zuzuordnen. Diese werden verwendet, um Spieler/innen den Shards zuzuordnen, auf denen sie mit ihren Freunden spielen oder auf denen sie die meisten ihrer Gegenstände in der offenen Welt zurückgelassen haben. Es ermöglicht uns aber auch die Verwendung von fortgeschritteneren Parametern, wie z. B. dem Ruf und anderen versteckten Spielerdaten, die wir verfolgen.
So können wir sicherstellen, dass jeder Shard eine halbwegs vielfältige Ansammlung von Individuen hat. So können wir zum Beispiel sicherstellen, dass wir einen Shard nicht versehentlich nur mit gesetzestreuen Spielerinnen und Spielern beladen, was vielleicht nicht so viel Spaß macht, wenn sie unter anderem kriminelle Spielerinnen und Spieler jagen wollen.
Werden dein Charakter und dein Schiff immer im Spiel sein, wenn du es verlassen hast; d.h. wenn ich mich von meinem Schiffsbett auf einem Planeten ausgeloggt habe, wird mein Schiff immer noch dort sein, was bedeutet, dass Leute versuchen könnten, in mein Schiff einzubrechen oder es zu zerstören? Wenn eine Entität in einem Shard "ausgeladen" wird (d. h. sie existiert physisch in dem Shard), existiert sie dauerhaft in diesem Shard, bis der Spieler die Entität in ein Inventar "einlagert". Dies kann geschehen, indem du eine Waffe aufnimmst und sie in deinen Rucksack steckst oder indem du ein Schiff auf einem Landeplatz landest, wodurch das Schiff in einem bestimmten Inventar des Landeplatzes verstaut wird. Sobald sich ein Gegenstand in einem Inventar befindet, wird er in der globalen Datenbank gespeichert und kann in einem beliebigen Shard verstaut werden. So können Spieler/innen Gegenstände zwischen Shards verschieben.
Wir planen außerdem eine Mechanik namens "Helden-Gegenstand verstauen/entstauen". Damit werden alle im Besitz des Spielers befindlichen Heldengegenstände automatisch in ein spielerspezifisches Shard-Übergangsinventar verstaut. Das automatische Verstauen geschieht in der Regel, wenn keine anderen Spieler/innen in der Nähe sind und die Entität herausgestreamt wird. Die Gegenstände in diesem Shard-Übergangsinventar folgen dem Spieler automatisch. Wenn sich ein Spieler also auf einem anderen Shard einloggt, nehmen wir die Gegenstände und verstauen sie auf dem neuen Shard wieder an der Stelle, an der der Spieler sie zurückgelassen hat.
Wenn du mit deinem Schiff auf einem Mond landest und dich ausloggst, wird das Schiff ausfliegen und automatisch verstaut, wenn zu diesem Zeitpunkt keine anderen Spieler/innen in der Nähe sind. Wenn du dich nun auf einem anderen Shard einloggst, wird dein Schiff auf dem neuen Shard wieder freigegeben. Wenn das Schiff aus irgendeinem Grund länger auf dem alten Shard geblieben ist und zerstört wurde, während du ausgeloggt warst, kann es sein, dass du in einem Krankenbett aufwachst.
Wie sehr sind neue Inhalte jetzt vom Server Meshing abhängig? Das Server Meshing wird es uns ermöglichen, die Anzahl der Spieler, die gemeinsam in Star Citizen spielen können, zu erhöhen und neue Inhalte zu schaffen. Im Moment konzentrieren wir uns darauf, neue Sternensysteme hinzuzufügen. Server Meshing ist eine der Schlüsseltechnologien, die es ermöglichen, dass die Sprungpunkte im Spiel funktionieren und die Sternensysteme ohne Ladebildschirme nahtlos in den Speicher hinein- und wieder herausbewegt werden können. Die Spieler/innen werden dies nächstes Jahr zum ersten Mal sehen, wenn die erste Version des Server Meshing mit der Einführung des Pyro-Systems live geht.
Wenn wir die Technologie verfeinern und vom statischen Server Meshing zum dynamischen Server Meshing übergehen, können Designer/innen diese Technologie nutzen, um größere, interessantere Gebiete (wie größere Siedlungen oder große Schiffsinnenräume) mit einer dichteren Anzahl von KI- und Spielercharakteren zu gestalten. Server Meshing könnte die Türen zu Spielerlebnissen öffnen, an die unsere Designer/innen noch gar nicht gedacht haben!
Wie viel Leistungssteigerung können wir erwarten? Die größte Verbesserung wird die Serverleistung sein. Im Moment ist unsere Serverleistung aufgrund der schieren Anzahl von Entitäten, die wir auf einem Server simulieren müssen, ziemlich begrenzt. Das führt zu einer sehr niedrigen Framerate und zu einer Verschlechterung der Serverleistung, was wiederum zu Netzwerkverzögerungen und anderen Problemen mit der Netzwerksynchronisation führt. Sobald wir auch das statische Netz eingerichtet haben, erwarten wir, dass die Framerate des Servers deutlich höher ist und weniger dieser Symptome auftritt.
Auf die FPS des Clients hat das Server-Meshing eigentlich kaum Auswirkungen. Der Client streamt ohnehin nur Objekte, die sich in Sichtweite befinden. Es kann zu leichten Verbesserungen kommen, da wir die Reichweite auf dem Client etwas aggressiver einschränken können, da einige Objekte im Moment einen zu großen Streaming-Radius haben, damit Funktionen wie Radar oder Raketen richtig funktionieren. Mit Server Meshing können wir den Client- und Server-Streaming-Radius entkoppeln. Allerdings werden die Verbesserungen auf dem Client nur minimal sein. Dennoch werden die schnelleren FPS des Servers das Gesamterlebnis verbessern, da der Netzwerk-Lag deutlich reduziert wird.
Ich weiß, dass es darauf vielleicht noch keine Antwort gibt, aber wie viele Shards wirst du bei der ersten Veröffentlichung von Server Meshing voraussichtlich benötigen? 10, 100, 1000 oder mehr? Wir wissen, dass die Abkehr von DGS mehr Spieler pro Spielgebiet bedeutet, aber ich weiß nicht, mit wie vielen ihr rechnet. Die kurze Antwort ist, dass wir keine Zahl nennen können.
Das Konzept des Scherbens ist der "formbare" Teil der Meshing-Architektur, und wir können die Anzahl der benötigten Scherben erst sagen, wenn alle Komponenten vorhanden sind und wir planen, iterativ dorthin zu gelangen.
Bei der ersten Version von Persistent Streaming (nicht Meshing) wollen wir zunächst das aktuelle Verhalten, das du online siehst, nachahmen, indem wir einen Shard pro Serverinstanz und einen Replikanten (Hybrid genannt) haben. Der einzige Unterschied ist, dass alle Entitäten in diesen Shards persistent sind. So können wir mit dem Worst-Case-Szenario umgehen, indem wir eine wirklich große Anzahl von persistenten Scherben und sehr großen Replikanten haben, um die Mechanismen der Erstellung/Saat, der Simulation mit aktiven Spielern und des Recyclings oder der Zerstörung zu testen. Wir wollen, dass die Erstellung und Zerstörung von Scherben in dieser ersten Phase optimal, schnell und kostenneutral ist.
Dieser Ansatz hat mehrere Vorteile, denn wir können die Persistenz von Scherben früher testen und, was noch wichtiger ist, aktive Metriken über viele Scherben hinweg messen.
Zum Beispiel (nicht abschließend!):
Wie viele Entitäten verbleiben im Laufe der Zeit in einem persistenten Shard (Shard-Wachstumsrate)
Größe des globalen Graphen (globale Wachstumsrate)
Wie viele Spieler eine einzelne Shard-Datenbank verarbeiten kann (Spielernutzung)
Auswirkung verschiedener Spielmechanismen auf die Aktualisierung der Splitterdatenbank (Auswirkungen auf das Spiel)
Leistungsprofil der Schreibwarteschlangen, durchschnittliche Abfragezeiten von Shard-DB-Clustern (Shard-Datenbank-Metriken)
Leistungsprofil der Schreibwarteschlangen, mittlere Abfragezeiten des globalen DB-Clusters (Metriken der globalen Datenbank)
Effizienz des Datenbank-Shardings (eine weitere Sharding-Ebene!) des Graphen
Wir haben zwar gute Schätzungen und interne Messungen, aber nichts ersetzt echte Spieler, die das System repräsentativ belasten.
Wenn wir die anderen Komponenten des Meshings ins Spiel bringen, vor allem das statische Mesh, planen wir, die Anzahl der Shards schrittweise zu reduzieren und die Spieler in immer größeren Shards zu gruppieren, bis wir uns mit der Leistung von Replikanten, DGSs und dem Entity-Graphen wohl fühlen. Natürlich wird das statische Mesh unter Problemen bei der Zusammenlegung leiden und wir werden erst dann wieder zu größeren Shards übergehen können, wenn das dynamische Mesh eingerichtet ist.
Letztendlich wollen wir mit dem dynamischen Netz sehr große Shards unterstützen.
Kann ein Gegenstand, der so klein wie eine Kugel ist, über Server-Shards hinweg reisen? Die kurze Antwort lautet: Nein.
Du kannst Shards als eine komplett isolierte Instanz des simulierten Universums betrachten, ähnlich wie wir derzeit verschiedene isolierte Instanzen pro dediziertem Server haben. Damit Gegenstände zwischen den Instanzen übertragen werden können, müssen diese Gegenstände in ein Inventar verstaut werden, bevor sie in einem anderen Shard ausgepackt werden können. Wenn ein Spieler zum Beispiel eine Waffe in einem Shard aufhebt und sie in seinen Rucksack legt. Wenn der Spieler/die Spielerin sich nun mit einem anderen Shard verbindet, kann er/sie die Waffe aus seinem/ihrem Rucksack nehmen und sie im neuen Shard auspacken.
Innerhalb eines Shards kann ein Objekt wie eine Rakete über mehrere Serverknoten hinweg reisen, wenn diese Serverknoten die Rakete im Streaming-Bereich des Servers haben. Nur ein Serverknoten hat die Kontrolle über den Flugkörper, während die anderen Serverknoten nur eine Client-Ansicht desselben Flugkörpers sehen.
Geschosse werden tatsächlich clientseitig erzeugt. Auf jedem Client- und Serverknoten wird also eine eigene Version des Geschosses erzeugt, weshalb ich im obigen Beispiel eine netzwerkreplizierte Entität wie eine Rakete verwendet habe.
Wenn du verschiedene Regionen der Welt behandelst, planst du dann, vier Hauptserverfarmen zu hosten, z. B. USA, EU, China, Ozeanien? Oder wollt ihr ein "One-Global-Universe" schaffen? Wenn global, wie würde das die Balance der Spieler mit extremen Ping-Schwankungen regeln? Wir planen, die regionale Verteilung von netzwerksensitiven Diensten beizubehalten. Beim ersten Einsatz von Persistent Streaming wird die globale Datenbank wirklich global sein. Die Shards selbst werden regional verteilt sein, so dass ein Spielclient, der sich mit der EU-Region verbindet, vorzugsweise mit einem EU-Shard verbunden wird. Wenn die Shards größer werden (sowohl für Spieler/innen als auch für Entitäten), planen wir, dieses Modell zu überdenken und auch Dienste auf regionaler Ebene einzuführen, um Daten näher an der Lokalität bereitzustellen.
Ich lebe in Osteuropa. Werde ich nach dem Start von Server Meshing mit Freunden aus den USA spielen können? Wir haben nicht vor, die Wahl des Shards und der Region einzuschränken, die ein Spieler wählen kann.
Ein Spieler kann eine beliebige Region zum Spielen wählen und innerhalb dieser Region werden wir eine begrenzte Auswahl an Shards erlauben. Zum Beispiel den Shard mit deinen Freunden oder den Shard, auf dem du zuletzt gespielt hast.
Da alle Spielerdaten in der globalen Datenbank gespeichert werden, können die Spieler/innen zwischen Shards wechseln, ähnlich wie sie heute zwischen Instanzen wechseln können. Verstaute Gegenstände werden mit dem Spieler übertragen und sind unabhängig von der Shard immer zugänglich.
Sterben der Replikationsschicht: Was werden die Spieler/innen erleben, wenn eine Replikationsschicht abgeschaltet wird/"stirbt"? Wir wissen, dass der Entitätsgraph die gesäten Informationen sammelt und in einen neuen Replikationslayer einspeist, aber werden wir zum Hauptmenü zurückkehren, wenn der Replikationslayer stirbt, verglichen mit dem Tod eines Serverknotens, oder werden wir eine Art Ladebildschirm haben, der uns automatisch an einen neuen Layer anpasst? Um diese Frage richtig zu beantworten, muss ich erst einmal genauer beschreiben, wie unsere endgültige Architektur aussehen wird. Letztendlich wird die Replikationsschicht nicht aus einem einzigen Serverknoten bestehen. Stattdessen wird er aus mehreren Instanzen einer Reihe von Microservices mit Namen wie Replicant, Atlas und Scribe bestehen. Ein Vorteil davon ist, dass die Replikationsschicht selbst skalierbar ist. Ein weiterer Vorteil, der für diese Frage wichtiger ist, besteht darin, dass zwar ein einzelner Knoten/Instanz in der Replikationsschicht ausfallen kann, es aber sehr unwahrscheinlich ist, dass die gesamte Replikationsschicht auf einmal ausfällt. Aus Sicht des Kunden sind die Replikationsknoten am wichtigsten, da sie für das vernetzte Entity Steaming und die Statusreplikation zwischen Kunden und dem Spiel zuständig sind. Der Replikant ist so konzipiert, dass er keine Spiellogik ausführt, sondern nur sehr wenig Code: keine Animationen, keine Physik, nur Netzwerkcode. Da er auf einer so kleinen Codebasis aufbaut, sollten insgesamt weniger Fehler auftreten. Wir gehen also davon aus, dass Replicants nach einigen unvermeidlichen Anlaufschwierigkeiten ziemlich stabil sein wird. Es ist auch wichtig zu wissen, dass ein einzelner Kunde zu einem bestimmten Zeitpunkt von mehreren Replikanten bedient werden kann (aber diese Replikanten bedienen auch gleichzeitig andere Kunden). Das letzte Teil des Puzzles ist die Gateway-Schicht: Die Kunden verbinden sich nicht direkt mit den Replikanten, sondern mit einem Gateway-Knoten in der Gateway-Schicht. Der Gateway-Dienst ist nur dazu da, Pakete zwischen den Kunden und den verschiedenen Replikanten, mit denen sie sprechen, weiterzuleiten. Der Gateway-Dienst verwendet eine noch kleinere Codebasis als der Replikant und sollte daher noch weniger absturzgefährdet sein.
Was erlebt ein Kunde, wenn einer der Replikanten, die ihn bedienen, plötzlich ausfällt?
Der Kunde bleibt mit dem Shard verbunden, aber ein Teil oder die gesamte Simulation wird vorübergehend eingefroren. Die Replikationsschicht wird einen neuen Replikantenknoten erstellen, der den abgestürzten Knoten ersetzt, und den verlorenen Entitätsstatus über EntityGraph aus der Persistenz wiederherstellen. Die Client-Gateways und DGS-Knoten, die mit dem alten Replikanten verbunden waren, stellen die Verbindung mit dem neuen Knoten wieder her. Sobald alles wieder verbunden ist, wird das Spiel für die betroffenen Clients wieder freigegeben. Zu diesem Zeitpunkt kann es auf dem Client zu einem Einrasten/Teleportieren von Einheiten kommen. Wir hoffen, dass der gesamte Prozess weniger als eine Minute dauert.
Was passiert, wenn das Gateway, das den Client bedient, plötzlich abstürzt?
Der Gateway-Dienst speichert keinen Spielstatus und hat seine eigene Form der Wiederherstellung nach einem Absturz. Da es sich um einen viel einfacheren Dienst als einen Replikanten handelt, sollte die Wiederherstellungszeit viel kürzer sein und eher im Bereich von Sekunden liegen. Während der Wiederherstellung wird der Client vorübergehend einfrieren, gefolgt von einem Einfrieren/Teleportieren.
Was ist mit dem Hybrid-Dienst?
Während ihrer CitizenCon-Präsentation über Persistent Streaming und Server Meshing sprachen Paul und Benoit über die Replikationsschicht im Zusammenhang mit dem Hybrid-Dienst. Der Hybrid-Dienst ist, wie der Name schon sagt, eine Mischung aus den oben erwähnten Diensten Replicant, Atlas, Scribe und Gateway (aber nicht EntityGraph) sowie einer Handvoll anderer Dienste, die noch nicht erwähnt wurden. Wir haben uns dafür entschieden, diesen Dienst zuerst zu entwickeln, bevor wir ihn in seine einzelnen Komponenten aufteilen, da wir so weniger bewegliche Teile auf einmal benötigen. Außerdem können wir uns so auf die Erprobung der großen Konzepte konzentrieren und müssen uns nicht mit der korrekten Kommunikation der einzelnen Dienste herumschlagen. In dieser ersten Implementierung besteht die Replikationsschicht aus einem einzigen Hybrid-Serverknoten. Wenn dieser Hybridknoten abstürzt, ist die Situation ähnlich wie die, die Kunden erleben, wenn ein dedizierter Spieleserver abstürzt. Alle Kunden werden mit der berüchtigten 30k-Fehlermeldung zum Frontend-Menü zurückgeschickt. Sobald der Ersatz-Hybrid gestartet ist, können die Kunden den Shard wieder betreten und dort weitermachen, wo sie aufgehört haben. Wir hoffen, dass wir es so einrichten können, dass die Clients eine Benachrichtigung auf dem Bildschirm erhalten, dass der Shard wieder verfügbar ist, und ein einziger Tastendruck sie wieder mit dem Shard verbindet (ähnlich wie es bei der Wiederherstellung von Client-Abstürzen funktioniert).
In der Diskussionsrunde wurde viel darüber gesprochen, welche Knotenpunkte innerhalb eines Shards Schreibrechte haben, aber wie sieht es mit den Schreibrechten zwischen verschiedenen Shards aus? Werden getrennte Persistenzdatenbanken für die einzelnen Shards unterhalten oder werden die Zustände der Weltobjekte irgendwann zwischen den Shards synchronisiert, auch wenn sie in unterschiedlichen Zuständen belassen wurden (z.B. eine Tür wird auf einem Shard offen und auf einem anderen geschlossen gelassen - wird ein Shard irgendwann seinen Zustand in die Datenbank schreiben und den Zustand der Tür auf dem anderen Shard aktualisieren)? Im Allgemeinen ist jeder Shard eine eigene, einzigartige Kopie des Universums und jeder Gegenstand innerhalb des Shards teilt seinen Zustand nicht mit einem Gegenstand von einem anderen Shard, da jeder Shard seine eigene Datenbank hat. Andererseits haben wir eine globale Datenbank für die Inventardaten der Spieler/innen. In dieser Datenbank werden alle Gegenstände im Inventar eines Spielers gespeichert, und Gegenstände können zwischen Shards übertragen werden, wenn sie zuerst von einer Shard in ein Inventar und dann in eine andere Shard verstaut werden.
Einige Funktionen, wie z. B. Spieler-Außenposten oder abbaubare Ressourcen, implementieren einen speziellen Code, der einen globalen Status auf allen Shards repliziert. So kann ein Außenposten auf mehreren Shards parallel existieren und seinen Status langsam (relativ zur Geschwindigkeit des Echtzeitspiels) zwischen den Shards replizieren. Dabei handelt es sich nicht um eine sofortige Replikation (eine sich öffnende/schließende Tür wird nicht repliziert), aber ein dauerhafter Zustand wie eine verschlossene oder unverschlossene Tür kann zwischen Shards repliziert werden.
Ähnlich verhält es sich mit abbaubaren Ressourcen: Während jeder Shard eine eigene Version eines abbaubaren Gesteins hat, wird die Gesamtmenge zwischen den Shards repliziert. Wenn Spieler/innen also beginnen, ein bestimmtes Gebiet abzubauen, wird die globale Ressourcenkarte für dieses Gebiet geändert und die Anzahl der abbaubaren Gesteine an diesem Ort wird auf allen Shards beeinflusst.
Wenn sich eine Gruppe von einem Objekt zu einem anderen bewegt (z.B. durch Quantenreisen) und ein anderer DGS-Knoten, ein Objekt oder eine Instanz voll ist, wird T0 / Static Meshing dann präventiv einen anderen DGS-Knoten erstellen? Oder wie wird dies gehandhabt? Beim Static Server Meshing wird alles im Voraus festgelegt, auch die Anzahl der Serverknoten pro Shard und welcher Spielserver für die Simulation welcher Orte zuständig ist. Das bedeutet, dass, wenn sich alle Spieler des Shards zum selben Ort begeben, sie alle von demselben Serverknoten simuliert werden.
Im schlimmsten Fall entscheiden sich alle Spieler/innen dafür, sich auf alle Orte zu verteilen, die einem einzigen Serverknoten zugewiesen sind. In diesem Fall muss sich der arme Server nicht nur um alle Spieler/innen kümmern, sondern auch um die Streams an allen seinen Standorten. Die offensichtliche Antwort ist, mehr Server pro Shard zuzulassen, damit jeder Serverknoten weniger Standorte hat, in die er streamen muss. Da es sich jedoch um ein statisches Netz handelt und alles im Voraus festgelegt ist, sind mehr Serverknoten pro Shard ard erhöht auch die laufenden Kosten. Aber irgendwo müssen wir ja anfangen. Deshalb ist der Plan für die erste Version von Static Server Meshing, mit so wenigen Serverknoten pro Shard wie möglich zu starten und gleichzeitig zu testen, ob die Technik tatsächlich funktioniert. Das wird natürlich ein Problem sein, wenn wir es zulassen, dass die Shards mehr als die 50 Spieler/innen haben, die wir jetzt in unseren Single-Server-"Shards" haben.
Erwarte also nicht, dass die Spielerzahlen in der ersten Version stark ansteigen werden. So vermeiden wir das Problem, dass ein einzelner Serverknoten voll ist, bevor die Spieler dort ankommen, da wir die maximale Spielerzahl pro Shard auf den schlimmsten Fall begrenzen werden. Sobald wir das hinbekommen haben, werden wir uns ansehen, wie sich die Leistung und die Wirtschaftlichkeit entwickeln und sehen, wie weit wir es treiben können. Damit eine weitere Expansion wirtschaftlich sinnvoll ist, müssen wir das Server Meshing so bald wie möglich dynamischer gestalten.
Kannst du angesichts der riesigen Datenmengen, die zwischen den Clients und den Serverknoten übertragen werden, und der Notwendigkeit extrem niedriger Latenzzeiten beschreiben, wie ihr das handhabt und welche Technologien ihr einsetzt, um die Dinge zu beschleunigen bzw. zu verhindern, dass sie langsamer werden? Die größten Faktoren, die sich derzeit auf die Latenz auswirken, sind die Tickrate des Servers, der Ping der Clients, das Spawnen von Entitäten und die Latenz der persistenten Dienste.
Die Server-Tickrate hat den größten Einfluss und hängt mit der Anzahl der Orte zusammen, die ein Spielserver simuliert. Das Server-Meshing sollte hier helfen, indem es die Anzahl der Orte reduziert, die jeder Spieleserver ansteuern und simulieren muss. Weniger Standorte bedeuten eine viel geringere durchschnittliche Anzahl von Entitäten pro Server und die Einsparungen können genutzt werden, um die Anzahl der Spieler pro Server zu erhöhen.
Der Ping der Clients wird von der Entfernung zum Server bestimmt. Wir beobachten, dass viele Spieler auf Regionen in ganz anderen Kontinenten spielen wollen. Ein Teil unseres Spielcodes ist immer noch Client-autoritär, was bedeutet, dass Spieler/innen mit hohem Ping das Spielerlebnis für alle anderen beeinträchtigen können. Kurzfristig können wir nicht viel dagegen tun, aber wir wollen das verbessern, sobald das Server Meshing funktioniert.
Langsames Spawnen von Entitäten kann zu Latenzzeiten führen, da sich das Einströmen von Entitäten auf den Clients verzögert. Das kann zu unerwünschten Effekten führen, z. B. dass Orte erst Minuten nach der Reise der Quanten zu einem Ort vollständig erscheinen, dass man durch die Etagen fällt, nachdem man an einem Ort respawnt, dass Schiffe lange brauchen, um an ASOP-Terminals zu erscheinen, dass sich die Ausrüstung der Spieler ändert usw. Die Engpässe liegen dabei hauptsächlich auf dem Server. Erstens werden Entitäten erst dann an die Clients repliziert, wenn sie vollständig auf dem Server gespawnt wurden. Zweitens hat der Server eine einzige Spawn-Warteschlange, die er der Reihe nach abarbeiten muss. Drittens: Je mehr Orte ein Server ansteuern muss, desto mehr Spawns muss er durchführen. Um die Situation zu verbessern, haben wir den Code für den Server-Spawn geändert, um parallele Spawn-Warteschlangen zu nutzen. Das Meshing von Servern ist ebenfalls hilfreich, nicht nur, weil es die Spawn-Warteschlangen entlastet, indem es die Anzahl der Orte reduziert, an denen ein Server spawnen muss, sondern auch, weil die Replikationsschicht Entitäten gleichzeitig an Clients und Server repliziert, so dass sie parallel spawnen können.
Wir verwenden immer noch einige unserer alten persistenten Dienste, die zwar geeignet sind, aber unter unseren Anforderungen Probleme mit der Leistung und Skalierbarkeit haben. Das kann zu langen Wartezeiten führen, wenn wir persistente Daten von den Diensten abrufen, um zu wissen, was gespawnt werden soll, z. B. wenn wir ein Schiff von einem ASOP-Terminal spawnen, ein Inventar untersuchen, die Spielerauslastung ändern usw. Da sowohl das persistente Streaming als auch das Server Meshing die Menge der zu speichernden Daten drastisch erhöhen, war uns klar, dass wir etwas dagegen tun mussten. Deshalb haben Benoit und sein Team bei Turbulent die Art und Weise, wie wir Daten aufbewahren, völlig neu erfunden: EntityGraph ist ein hoch skalierbarer Dienst, der auf einer hoch skalierbaren Datenbank aufbaut, die für genau die Art von Datenoperationen optimiert ist, die wir durchführen. Darüber hinaus entwickeln wir die Replikationsschicht, die wie ein hoch skalierbarer In-Memory-Cache für den aktuellen Zustand aller Entitäten in einem Shard funktioniert und die meisten Abfragen an die alten persistenten Dienste überflüssig macht. Richtig, es werden durchgängig hoch skalierbare Dienste sein!
Um zusätzliche Latenzzeiten, die durch die Replikationsschicht entstehen können, zu verringern, bauen wir sie ereignisgesteuert auf und nicht mit einer Tickrate wie ein herkömmlicher Spieleserver. Das heißt, wenn Pakete eingehen, werden sie sofort verarbeitet und die Antwort gesendet und/oder die Informationen an die entsprechenden Clients und Spielserver weitergeleitet. Sobald die Arbeit an der ersten Version der Replikationsschicht (dem Hybriddienst) abgeschlossen ist, werden wir sie optimieren, um sicherzustellen, dass sie so reaktionsschnell wie möglich ist. Auch wenn dies letztendlich eine Entscheidung für DevOps ist, werden wir sie in denselben Rechenzentren wie die Spieleserver selbst bereitstellen, sodass die Netzwerklatenz aufgrund des zusätzlichen Sprungs zwischen der Replikationsschicht und dem Spieleserver weniger als eine Millisekunde betragen sollte. Oh, und habe ich schon erwähnt, dass die Replikationsschicht hoch skalierbar sein wird? Das heißt, wenn wir feststellen, dass die Replikationsschicht in bestimmten Teilen des Verses Latenz-Hotspots verursacht, können wir sie neu konfigurieren, um das Problem zu beheben.
Haftungsausschluss Die Antworten spiegeln die Absichten der Entwickler zum Zeitpunkt des Verfassens dieses Artikels wider. Das Unternehmen und das Entwicklungsteam behalten sich jedoch das Recht vor, Funktionen und Designs aufgrund von Feedback, Spieltests, Designüberarbeitungen oder anderen Erwägungen anzupassen, zu verbessern oder zu ändern, um die Balance oder die Qualität des Spiels insgesamt zu verbessern.