Reverse the Verse – Object Container Streaming

Reverse the Verse ist zurück, gibt einen kleinen Rückblick auf die aktuelle Woche sowie speziell auf das Format AtV und beantwortet weitere Fragen zu diesen Themen. Der Stream kann jede Woche live auf dem CIG Twitch Channel angesehen und Fragen können direkt im Chat übermittelt werden.

Gastgeber dieser Episode ist Community Content Manager Jared Huckaby und als Gäste dabei sind unter anderem Gameplay Programmer Gordon McLean und Lead Network Programmer Clive Johnson und Lead Technical QA Chris.

Zusammenfassung

• Was wollten wir am Anfang mit Object Container Streaming (OCS) erreichen?
  • Das Ziel war und ist immer noch Star Citizen für viele PCs spielbar zu machen. Die Masse an Planeten und Systemen wäre sonst nicht zu händeln und alles ohne Ladebildschirme zu realisieren.

• Dabei muss man beachten, dass es einmal OCS für Server und für Clients (PCs/Spieler) gibt, richtig?
  • Korrekt, da der Server weiß, wo sich gerade der Client im Spiel befindet  und somit die Daten in den Speicher des Servers hinein lädt. Wenn der Spieler nun im System ankommt, gibt der Server dem Client an, welche Daten gestreamt werden müssen. Wenn der Spieler das System verlässt, wird der Speicher des Servers freigegeben, damit andere Daten hinein geladen werden können.

• Diese Art der Technologie, mit dem Laden und Freigeben von Daten, ist aber nicht neu bzw. extra für Star Citizen entwickelt worden?
  • Das ist richtig. Diese Technologie gibt es schon einige Jahre, nur wird sie eher bei kleineren Karten genutzt in Multiplayer-Spielen oder Singleplayer-Spielen. Damit kann der Client alle Daten vom Server laden und es kommt zu keinem Einbruch der Framerate oder ähnlichem und die Daten müssen nicht gestreamt werden. Aufgrund der Größe von Star Citizen muss man Anpassungen vornehmen.

• Nun geht aktuell um das Client OCS. Wie sieht es aus, wenn auch das Server OCS fertig ist?
  • Es sollte eine bessere Performance bringen, auch wenn es nicht das Allheilmittel ist. Der Client soll nur die Daten laden, die auch in seiner Umgebung relevant sind und den Speicher für die Daten dementsprechend wieder freigeben, wenn der Spieler selbst das System verlässt bzw. andere Spieler das System verlassen. Das von Serverseite aus zu registrieren und alles aufrechtzuerhalten ist dann die Sache des Servers, was dann auch nicht so rechenintensiv sein soll.

• Was sind die Kriterien für das Laden in bzw. aus dem Speicher?
  • Hauptsächlich die Nähe zum Spieler und die Größe des Objektes.

• Wird das dann vom Server oder vom Clients geregelt?
  • Das wird vom Server aus geregelt.

• Bitte eine kurze Erklärung was Bind Culling ist.
  • Die Idee hinter Bind Culling ist, dass Objekte, die zu weit weg sind, nicht vom Client komplett geladen werden, sondern dass ein Marker gesetzt wird, der weniger Performance kostet. Zusätzlich schickt der Server in größeren Abständen Updates über das Objekt an den Client, anstatt den Client in kurzen Intervallen zu informieren, was mit dem Objekt ist. Anpassungen müssen sie noch für die Scanner-Mechanik machen, da zwar das Objekt vom Spieler nicht zu sehen ist, aber vom Radar schon und damit die Daten beim Client geladen sein müssen.

• Was sind Serialized Variables?
  • Diese machen es möglich, dass die verschiedenen Technologien kommunizieren und effektiver zusammen arbeiten können. Dadurch ist es möglich, die Marker zu aktualisieren und an den Client zu senden. Dessen Serialized Variables werden dann entsprechend geändert. Marker, die sich nicht ändern, werden nicht an den Client gesendet. Da die Datenmenge dadurch gering gehalten wird, gibt es beim Spielen keine Einbrüche der Framerate.

• Was bedeutet Full Client Streaming?
  • Hier muss man unterscheiden zwischen Client OCS und Bind Culling. Client OCS ist auch wichtig für Squadron 42. Auf dem Server sind alle Objekte allgegenwärtig, deswegen brauchen sie die Berechnungen der Entfernung für die verschiedenen Objekte, die dann vom Client geladen werden. Bind Culling hat die Kontrolle über OCS von Server-Seite aus auf die Clients.

• Wenn wir bereits Bind Culling haben, warum dauert es dennoch so lange mit OCS?
  • Die Herausforderung ist, dass sobald Bind Culling dem Client die Daten senden will, da Objekte für den Spieler auftauchen, die Daten aktuell in den Main Thread geladen werden und alles andere geblockt wird. Da die Daten synchron übermittelt werden, werden erst alle Daten geladen, alles andere geblockt und dann auf dem Client dargestellt. Die Entwickler sind dabei, die Daten asynchron zu senden. Es wird also ein Teil an den Client gesendet und wenn dieser die Daten verarbeitet hat, folgen weitere Daten bis der Client alle Daten hat und dann das Objekt darstellt.

• Wie testet man im QA das OCS?
  • Man fliegt viel umher, da die verschiedenen Objekte hinein und hinaus geladen werden sollen. Als Beispiel geben sie an, man befindet sich im Dogfight und im Laderaum ist ein Spieler der eine Box in den Händen hält und diese hinter dem Schiff hinaus wirft. Zeitgleich wird das Raumschiff zerstört und es kommt ein dritter Spieler zurück, der einen vorher im Dogfight gesehen hat. Nun ist für ihn die Situation anders. Die Kollegen vom QA Team prüfen jetzt, ob der Client die Änderungen korrekt anzeigt, ob die Box im Weltraum schwebt, ob die Spieler am Leben sind etc. Komplizierter wird es wenn es größere Gruppen an Spielern sind, die sich zum Beispiel auf GrimHex oder Port Olisar aufhalten.

• Wie ist die Erfahrung mit Client OCS?
  • Ihnen ist bekannt, dass die Performance bisher nicht so gut war. Alle vom QA Team machen diese Erfahrung tagtäglich. Aber aktuell melden so gut wie alle Kollegen eine spürbare Verbesserung, manche sogar eine drastische Steigerung der Performance.

• Wird es durch OCS möglich sein, mehr Spieler auf den Servern zu haben?
  • Nein, mehr Spieler werden durch Client OCS nicht möglich sein. Erst mit dem Server OCS werden mehr Spieler pro Server möglich.

• Warum werden Server und Client OCS getrennt bearbeitet?
  • Für das Server OCS haben sie noch nicht die benötigten Technologien, deswegen arbeiten sie zuerst am Client OCS.

• Wird OCS die Sichtreichweite beeinflussen?
  • Nicht wirklich, es könnte zu leichten Pop-Up Effekten kommen.

• Welche Fortschritte kann man aus Entwicklersicht erkennen?
  • Im Allgemeinen lässt sich die aktuelle Version schneller laden und auch Stationen wie Port Olisar mit allen Objekten lassen sich schneller laden.

• Was war die größte Herausforderung bei der Entwicklung von OCS?
  • Einerseits die asynchrone Datenübertragung im Netzwerk. Auch die Kommunikation zwischen den vielen Teams, welche von OCS betroffen sind. Für das QA Team war die Herausforderung, auf so vielen PCs wie möglich die aktuellste Version zu testen, um so viele Bugs wie möglich zu finden.

• Werden Hardwarekomponenten wie CPU, GPU, RAM etc. von OCS profitieren?
  • Am meisten wird der RAM davon profitieren, ansonsten in Maßen die CPU und GPU. Dabei muss man sagen, dass noch viele Anpassungen gemacht werden müssen.

• Hat OCS einen Nachteil?
  • Für das QA Team ist es die Zeit, die es dauert, die Neuerungen beim OCS zu testen. Ansonsten muss bei mehr Objekten die in Spiel kommen die Wechselwirkungen immer mehr beachten und die Kommunikation zwischen Server und Client muss richtig funktionieren, damit der Client nur das an Daten bekommt, was notwendig ist.

• Kann man Bugs, die verursacht werden, durch OCS erkennen?
  • Allgemein soll man einfach weiter vermeintliche Bugs melden. OCS Bugs könnten sein, dass Objekte oder Personen hin und her springen.

• Was ist der Unterschied zwischen asynchronem Spawning und normalem Spawning?
  • Der Unterschied ist, dass asynchrones Spawning nicht im Main Thread passsiert, sondern secondary Thread.

Quelle: RSI
Übersetzung: StarCitizenBase
Social Media: FaceBook | Twitter | Community Hub