Around the Verse – Performance und Optimierung

Willkommen zu einer weiteren Episode von Around the Verse (AtV), dem wöchentlichen Format mit den aktuellsten Informationen zu Star Citizen. Jede Woche erhalten wir darin einen tieferen Einblick in ein Thema der Entwicklung des Spiels. Diese Woche geht es um den fortlaufenden Optimierungsprozess.


Einführung

  • Die Einführung startet bei Minute 0:15.
  • Gastgeber sind VP of Marketing Sandi Gardinerund Technical Director of Content Sean Tracy.

Projektupdate

  • Das Projektupdate startet bei Minute 0:42 und wird von Senior Producer Ricky Jutley moderiert.
  • Das UI-Team hat die Fahrzeugstatushologramme für die Visiere neu geschrieben, sodass sie RTT (Render-to-Texture) nutzen. Dadurch sind sie ein genaues Abbild des Schiffes, welches im Spiel angezeigt wird.
  • RTT wird auch verwendet, um Kommunikationsverbindungen zu rendern, sodass sie auf MFDs, dem mobiGlas oder in Visieren angezeigt werden können.
  • Bald wird man (aus einer vordefinierten Liste) einen Kamerawinkel auswählen können, aus dem das eigene Fahrzeug oder das eures Ziels angeschaut wird.
  • Ebenso wird man Hilfsanzeigen (Visier, 3D-Radar etc.) an die Instrumententafel von Fahrzeugen anschließen können, um sie als zusätzliche Bildschirme zu nutzen.
  • Auf Seiten der prozeduralen Planetentechnologie wurden die Multi-Channel-Unterstützung sowie Farbübergänge und -auflösungen verbessert.
  • Die bestehenden Tools wurden verbessert, sodass alle planetaren Außenposten automatisch repositioniert werden können.
  • Die letzten Außenteile des Truck-Stops werden fertiggestellt und neue, häufige Hangarelemente darin eingebunden.
  • Das ProceduralLayout-Tool generiert nun automatisch viele (bisher mehr als tausend) erfolgreiche Layouts für diese Raumstationen.
  • Die Anvil Terrapin, MISC Razor, Tumbril Cyclone und Aegis Reclaimer nähern sich dem flight-ready Status und erhalten noch visuelle Effekte.
  • Der Fokus liegt beim Waffenbalancing momentan darauf, dass der Kugeleinschlag der Gemini R97, PRAR Distortion Scattergun und Scourge Railgun überarbeitet wird.
  • Das Charakter-Anpassungsmenü von Star Marine wird in die gemeinsame Codebasis (mit Arena Commander und mobiGlas) migriert: Dies erlaubt Spielern, individuelle Rüstungsteile in Star Marine auszuwählen.
  • Das UI-Team arbeitet hart daran, visuelle Verbesserungen zu implementieren und einen Prototyp für ein neues mobiGlas-Layout zu erstellen.
  • Das TechArt-Team arbeitet an der Charakteranpassung: neue Inaktivitätsanimationen, mehr zufällige Gesichtsanimationen, WIP-Symbole, überarbeitete Spiegelungen, Hervorhebungen und Belechtung sowie ein verbessertes Kamerasystem.
  • Es wird für Alpha 3.1 an Service Beacons gearbeitet, mit denen Spieler sich gegenseitig für Dienstleistungen (Eskorte, Kampfunterstützung etc.) bezahlen können.
  • Fehler bei den Charaktermodellen wie ständig leuchtende Kopflampen und gleichzeitig getragene Mützen und Helme werden behoben.

Performance und Optimierung

  • Das Thema dieser Episode startet bei Minute 13:40.
  • Das größte Problem an der Optimierung bei Spielen wie Star Citizen ist die bloße Anzahl an Instanzen.
  • Die Spielsimulation hängt von Eingaben ab; die Statusänderung der Spielwelt und das Rendern von Szenen in dieser Welt geschieht in einfachen, sich wiederholenden Schritten.
  • Die Performance zu optimieren heißt im Grunde, Wege zu finden, die weniger ressourcenintensiv sind, um diese Schritte durchzuführen, ohne dass die Qualität beim Spielfluss und der -erfahrung verloren geht.
  • GPUs und CPUs können entweder im Gleichschritt oder so parallel zusammenarbeiten, sodass sich ein Muster bildet, das Pipelining genannt wird.
  • Pipelining zu verwalten ist der wichtigste Weg, die Ressourceneffizienz zu verbessern und dabei Lag und Latenz zu reduzieren.
  • Da ein System immer an die langsamste Komponente gebunden ist, tragen CPUs, die Multithreading unterstützen, zur Komplexität bei.
  • Mehr Pipelining kann sogar die erkannte Latenz erhöhen, obwohl eine bessere Bildrate erreicht werden könnte.
  • Aufgrund der Latenzprobleme wird bei einem Spiel wie Star Citizen, gerade wenn man bedenkt, dass es über das Internet läuft, kein Gleichschritt verwendet.
  • Ein anderer Weg der Optimierung ist eine Verringerung der Distanz, über die eine Instanz im Spiel visualisiert wird (etwas was zu weit weg ist, muss nicht dargestellt/simuliert werden). Dadurch wird die Menge an Tracking reduziert.
  • Oft werden mehrere Ansätze im Einklang verwendet, um die Performance durch gutes Ressourcenmanagement zu steigern und zu optimieren.
  • Die Teams für Tech Art und Content tendieren dazu, sich auf ein Maximum von 2500 Drawcalls (Aufrufe der draw()-Funktion => Rechenzeit der GPU) zu fokussieren, und versuchen, LODs (Objekte mit variablem Detaillierungsgrad) zu verwenden, um die Anzahl an Drawcalls zu reduzieren.
  • Die Schadenstechnologie wird überarbeitet, sodass es weniger Trümerteile eines zerstörten Schiffes gibt, und dadurch weniger zusätzliche Geometrie. Dies reduziert die Anzahl der benötigten Drawcalls.
  • Ein weiterer Trick, um Drawcalls zu limitieren, ist, VisAreas (vordefinierte Innenbereiche) und Portals (Eingang zur VisArea) zu verwenden, um Culling (anfängliche Aussortierung von Objekten, die nicht zum Bild beitragen) zu optimieren. Somit rendert das Spiel nur, was der Spieler sehen kann. Momentan werden ein paar erhebliche Fehler bekämpft, wie z.B. bei der Caterpillar, durch deren Wände ihr häufig hindurchsehen könnt.
  • Eine weitere Verbesserung ist, nicht mehr Voxelobjekte, sondern vorzeichenbehaftete Felder für lokale Physikgitter zu nutzen. Diese sind viel präziser und die tatsächliche Form kann in viel höherer Auflösung dargestellt werden. Dadurch kann eine Schildtechnologie genutzt werden, die sich viel näher an die Schiffe anschmiegt.
    • Vorzeichenbehaftete Felder sind außerdem der erste Schritt dazu, Schiffswracks voll zugänglich und damit ausschlachtbar und erkundbar zu machen.
  • Der Netzwerkcode auf den Servern war ein großer Flaschenhals. Der Hauptthread wird verzögert, weil der Netzwerkthread zu beschäftigt damit ist, Aktualisierungen an alle Spieler im Spiel zu senden, was dazu führt, dass sich alles verlangsamt oder zum Stillstand kommt.
    • Alpha 3.0 enthielt viele Optimierungen für den Netzwerkcode, z.B. die Konvertierung in serialisierte Variablen und Remotemethoden.
  • Die Belastung eines einzelnen Threads durch Netzwerkanweisungen wurde nun parallel auf mehrere Threads verteilt, um die Überlastung zu vermeiden.
    • Der Netzwerkcode war nie wirklich ein Performanceproblem auf Clientseite – das Problem lag immer auf der Seite der Server.
  • Network Bind Culling soll diese Diskrepanz angehen.
    • Im Wesentlichen heißt Network Bind Culling, dass der Client keine Instanzen lädt, die nicht in der Reichweite des Spielers sind. Somit werden für sie keine Bearbeitungszeit verschwendet und keine Aktualisierungen vom Server geladen.
    • Das Problem war – und deswegen hat es solange gedauert, bis Network Bind Culling implementiert wurde-, was getan werden soll, wenn der Spieler in die Nähe einer Instanz kommt, die der Server nicht aktualisiert hat. Es stellte sich die Frage, wie Instanzen erstellt werden, ohne dass das Spiel massiv verlangsamt wird.
    • Object Container Streaming ist die Antwort auf das Network Bind Culling – Problem. Benötigte Instanzen werden vorausgesagt und in einem Hintergrundthread geladen, sodass der Hauptthread nicht aufgehalten wird.
    • Die vollständige Implementierung von Network Bind Culling wird den Spieler nicht erreichen, bis Object Container Streaming implementiert wurde, aber Network Bind Culling wird im Voraus von den Entwicklern benötigt, sodass sie daran arbeiten können, alle Probleme zu eliminieren, die es verursachen kann. Ein Beispiel wäre, wie ihr einem Spieler den Bestimmungsort für eine Mission zeigt, wenn dieser Ort momentan bedingt durch Culling nicht im Spiel existiert.
    • Ein großer Teil des Performancegewinns, der durch Network Bind Culling erwartet wurde, konnte schon mit normalem Culling, dass serialisierte Variablen nutzt, erreicht werden. Die teilt im Grunde dem Server nur mit, mit dem Senden von Aktualisierungen der Instanzen, die sich nicht in einem bestimmten Umkreis vom Spieler befinden, an den Client aufzuhören.
  • Wenn man ein Spiel wie Star Citizen entwickelt, wird es mit der Zeit schwieriger, die Performance zu optimieren und zu verbessern, da dies abhängig von der Komplexität und den Ambitionen ist, die das Spiel zu erreichen versucht.
  • Eines der Probleme, die die Entwickler eine Zeit lang hatten, war, nicht nur eine angemessene Auslastung der Server zu simulieren, sondern auch genug QA-Mitarbeiter und andere Entwickler für interne Spieltests zu gewinnen.
  • Mit Alpha 3.1 werden zwei neue Tools eingeführt, damit die Daten, die erfasst werden, verbessert werden, sodass die Entwickler besser nachvollziehen können, woher die Performanceeinbrüche kommen.
  • Es wurden kopflose Clients enwickelt, die die zufälligen Aktionen der Spieler auf den Servern simulieren und diese auf die maximale Spieleranzahl skalieren können. Dadurch können die Entwickler einen internen Server schnell bevölkern und eine genauere Vorstellung davon bekommen, wie die Serverauslastung im Livemodus sein wird.
  • Zweitens haben sie ein Tool entwickelt, das Daten genauer als zuvor sammeln kann und den Entwicklern detaillierte Informationen über die Einzelheiten gibt, die ein Spieler tut. Dadurch muss kein ewig langes Protokoll nach den gesuchten Daten durchsucht werden.
  • Wenn neue Funktionen online gehen, gibt es für gewöhnlich einen Performanceeinbruch, aber mit den neuen Tools sollten sie die Performance schnell zurück auf ein Level bringen, das die Spieler akzeptabel finden und worauf sie aufbauen können.
  • Würden sie Star Citizen als Spiel so entwickeln, wie dies andere Studios tun, sodass es keinen spielbaren Build während der Entwicklung gibt und das Spiel nur die letzen paar Monate vor der Veröffentlichung ausgefeilt wird, dann wäre die Produktion weitaus anders. Aber da sie diesen Ansatz gewählt haben, wird nochmal ein Level an Komplexität benötigt, damit die Builds spielbar werden, während die Entwicklung weitergeht.
  • Wie es Lead Gameplay Programmer Mark Abent ausdrückt, gibt es nicht die eine Lösung, um alle Probleme zu lösen; es gibt Milliarden an Möglichkeiten, die schrittweise die Performance und Stabilität mit der Zeit verbessern.

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

TREPI

Via quamvis abstrusa sit, ita lux in extremo cuniculo est. // Referral Code: STAR-D33Q-XKRV

2 Kommentare zu “Around the Verse – Performance und Optimierung

  • 10. März 2018 um 22:04
    Permalink

    Einmal mehr vielen Dank für die Mühe, auch diese Episode zu übersetzen 😉

    Ich hab sie mir vorher selbst angesehen und muss sagen, dass man an der Art des Erzählens von Netzwerk-Programmierer Clive Johnson sehr gut merkt, wie komplex und anspruchsvoll das Netzwerk-Thema ist.

    Star Citizen ist eben mehr als nur Fleißarbeit – und starcitizenbase.de mehr als nur eine Webseite 🙂

    Danke, macht weiter so!

    Antwort
  • 12. März 2018 um 08:55
    Permalink

    Vielen Dank für die vielen zusammengefassten Fakten aus dem Video.

    Das war eine Menge Input für heute. Hoffentlich bekomme ich kein Input Lag. 😀
    Ich freue mich, dass CIG etwas mehr auf die Netcode Problematik eingeht. Das wird hoffentlich so einige Gemüter befriedigen.
    Es ist schon eine Mammut Aufgabe derer sich CIG angenommen hat. Ein Spiel entwickeln und für die Unterstützer eine Spielbare Testumgebung erschaffen, mit der die Spieler auch halbwegs zufrieden sein können.
    Hut ab für so viel Tatendrang.

    Antwort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert