Alpha 3.12 Postmortem

Alpha 3.12 Postmortem
Am 17. Dezember 2020 haben wir die Alpha 3.12: Assault on Stanton veröffentlicht, die eine Reihe von neuen Features und Änderungen eingeführt hat, darunter Raffinerie-Decks, KI-Verbesserungen und Gaswolken. Der folgende Postmortem stammt von den leitenden Entwicklern selbst und beschreibt, was geliefert wurde und was sie darüber denken, wie es gelaufen ist. Nebenbei bemerkt konzentriert sich dieser Postmortem speziell auf den Alpha 3.12 Patch - wir werden einen separaten Postmortem Comm-Link veröffentlichen, der sich auf das dynamische Ereignis XenoThreat konzentriert.


Fahrzeug-Team

Was gut lief


Das Vehicle Pillar hat vor allem die Arbeit anderer Teams für Star Citizen Alpha 3.12 unterstützt, vor allem bei den Kämpfen mit Großkampfschiffen vor den Events Arlington Bounty, CS5 UEE Navy Idris und XenoThreat. Wir haben nicht nur daran gearbeitet, wie die Fahrzeuge funktionieren und sich verhalten (sie sind die größten Schiffe, die bisher auf den Servern eingesetzt wurden), sondern haben auch dabei geholfen, mit der erhöhten Tödlichkeit von Torpedos umzugehen, indem wir intelligentere und effektivere KI-Gegenmaßnahmen eingesetzt haben.
Die Spieler profitierten auch von dieser Arbeit mit der Möglichkeit, die Art der Gegenmaßnahme zu wählen und wie viele in einem Burst abgefeuert werden, was eine größere taktische Auswahl bei der Ablenkung von ankommenden Raketen und Torpedos ermöglicht. Wir haben auch weitere HUD-Elemente hinzugefügt, damit die Spieler sehen können, wie viele von jedem Typ sie übrig haben, zusammen mit der aktuellen Burst-Größe.
Die letzte Änderung an den Gegenmaßnahmen war eine Erweiterung der Änderungen aus Alpha 3.11. Dies führt dazu, dass jeder Gegenmaßnahmentyp gegen alle Raketensuchertypen funktioniert, aber die Effektivität in Abhängigkeit von der Art und Anzahl der ankommenden Raketen verändert. Täuschkörper ersetzten Leuchtraketen als zeitlich begrenzte, punktuelle Ablenkung, während Lärm, ehemals Düppel, zu einem flächendeckenden Signalblocker wurde (mehr abgeschossene Gegenmaßnahmen bieten eine höhere Chance auf Spoofing). Wir haben auch die Raketen selbst verändert, um eine kleine Varianz in ihrer Verfolgung zu ermöglichen, damit eine erfolgreiche Gegenmaßnahme nicht alle Raketen gleichermaßen ablenkt. Zusätzlich zur manuellen Steuerung der Burst-Größe fügten wir eine Panikfunktion hinzu, die 25% der verfügbaren Gegenmaßnahmen leert, um eine Flut von ankommenden Raketen zu überwältigen.
Was nicht so gut geklappt hat

Wir entdeckten eine Menge Probleme mit dem Raketen-Setup und der Balance, die zu seltsamen Verhaltensweisen führten. Wir haben uns jedoch entschieden, dies zu belassen, bis die Raketen in der Alpha 3.13 auf IFCS 2.0 umgestellt werden, da dies eine umfassende Überarbeitung aller Verhaltensweisen der Raketen von Grund auf erfordert. In der Zukunft wollen wir die Gegenmaßnahmen erweitern, indem wir den Spielern ein besseres Feedback zu ihren eigenen Signaturen und Raketenfähigkeiten geben, was mit dem Missile Operator Mode kommen wird.
Die Fahrzeug-Eingangs-Identifikation war ein viel gefordertes Quality-of-Life-Feature (aufbauend auf den ASOP-Hangar-Spawn-Benachrichtigungen der Alpha 3.11), das es den Spielern ermöglicht, die Einstiegspunkte in ein Schiff schnell zu identifizieren. Diese Markierungen aktualisieren sich je nachdem, ob das Schiff gelandet ist oder sich in der Schwerelosigkeit befindet, was eine häufige Beschwerde neuer Spieler beseitigt, die nicht herausfinden konnten, wie sie in ihr Schiff gelangen. Gelegentlich sind diese Anzeigen wild vom Fahrzeug abgewichen, was wir untersuchen, aber das war so ziemlich das einzige negative Problem mit dem Feature und es wurde allgemein gut angenommen.
Die Hauptinhalte der Alpha 3.12 waren die Esperia Talon und Talon Shrike, zwei leichte Jäger, die das Line-Up im Spiel erweitern. Im Allgemeinen liefen diese ziemlich gut und wir diskutierten ihre Entwicklung in mehreren ISC-Episoden, einschließlich unserer Arbeit am Hard Surface Shader und irisierenden Materialien.
Leider gab es bei der Veröffentlichung ein paar Probleme, die wir in zukünftigen Patches beheben wollen. Dazu gehören der Bildschirm, der im Arena Commander umgeschaltet werden muss (auch auf dem Prowler) und die Raketenwerfer der Talon Shrike, die manchmal nicht mehr funktionieren, nachdem eine große Anzahl von Raketen abgefeuert wurde.
John Crewe
Fahrzeug Direktor

USPU-Gameplay-Feature-Team
Das vierte Quartal ist für das USPU Team immer ein arbeitsreiches. Nicht nur für uns, sondern für das gesamte Unternehmen. Hier ist eine kurze Zusammenfassung unserer wichtigeren Initiativen, die wir während des Quartals in die Hände bekommen konnten. Zum Glück mussten wir dieses Jahr keine große CitizenCon-Demo vorbereiten, aber das hat uns nicht davon abgehalten, extrem beschäftigt zu sein.
Internationale Luft- und Raumfahrt-Ausstellung (IAE)
Was gut lief


Wir haben unseren IAE-Inhalt erfolgreich in den High-Tech-Art-Stil erweitert, der auf New Babbage auf dem Planeten microTech stattfand. Wir fügten der Veranstaltung in diesem Jahr einige neue Dinge hinzu, die versuchten, auf die Kommentare der Fans einzugehen. Erstens ließen wir die Ausstellungshalle jedes Herstellers an zwei aufeinanderfolgenden Tagen laufen, für den Fall, dass die Fans den ersten Tag verpasst hatten, und wir verlängerten die kostenlose Ausleihzeit von einem auf zwei Tage. Hoffentlich haben diese beiden Dinge jedem die Möglichkeit gegeben, die Schiffe zu mieten, die er unbedingt ausprobieren wollte. Wir hatten auch zwei Ausstellungshallen an einem Tag. Dies ermöglichte es den Spielern, mehr Dinge zu sehen, und im Sinne von "mehr Dinge zu sehen" haben wir beschlossen, viele unserer Schiffskomponenten und Waffen in der Haupthalle zu präsentieren. Mit zwei aktiven Hallen pro Tag und all den zusätzlichen Gegenständen war dies ein wahrer Beweis dafür, dass unsere Technik immer mehr optimiert wird, da wir in der Vergangenheit niemals in der Lage gewesen wären, dies zu tun. Um die Zugänglichkeit zu erhöhen, haben wir in der "Best In Show"-Halle, die vier Tage lang lief, eine Reihe von Verleihkiosken aufgestellt. In diesen Kiosken haben wir jedes Fahrzeug, das im Laufe der Show gezeigt wurde, untergebracht und die gleiche zweitägige Mietdauer gewährt. Wir denken, dass dies die ansprechendste Iteration war, die wir bis jetzt geschaffen haben.
Was nicht so gut gelaufen ist


Wir hatten zwei Fahrzeuge, die auf der IAE-Show vorgestellt wurden und deren Entwicklung wirklich auf der Kippe stand. Letztendlich konnten wir den Build erst ein paar Tage vor der Show fertigstellen. Da die Messe im November für die Öffentlichkeit zugänglich ist, musste der Build als Point-Patch zur Alpha 3.11 veröffentlicht werden. Die Tatsache, dass wir nicht in der Lage waren, den Build abzuschließen, bevor wir auf den Alpha 3.12 Build verzweigt haben, verursachte einige Kopfschmerzen bei der Dateiverwaltung. Kritische Korrekturen werden immer noch am Point-Release vorgenommen und die gleichen Korrekturen müssen auch im neu verzweigten Stream-Content enthalten sein. Das führt unweigerlich dazu, dass die Arbeit hier und da eingestampft wird und frisst am Ende des Tages wertvolle Zeit, die für die Behebung anderer Fehler oder die Entwicklung neuer Dinge genutzt werden könnte. Außerdem sickerten einige Dinge durch, die wir eigentlich bis kurz vor dem Event geheim halten wollten. Das war kein großes Problem, aber es ist immer schön, wenn man die Fans von Zeit zu Zeit überraschen kann.
Was wir in Zukunft anders machen werden


Ein paar Dinge, auf die ich mich wirklich konzentrieren möchte, wenn wir mit diesem Event weitermachen, sind: Modularität/Wiederverwendung von Assets aus früheren Events. Je schneller wir diese Events umsetzen können, desto mehr Zeit haben wir, um uns auf neue Content-Ideen oder andere Sonnensysteme zu konzentrieren. Vorproduktionsplanung. Wir wissen, dass das Event im nächsten November wieder stattfinden wird, also möchte ich Dinge wie das Farbschema, Eventlogos, die Location, etc. so früh wie möglich ausbügeln. Auf diese Weise muss niemand auf eine Entscheidung warten, wenn es Zeit ist, an den Inhalten zu arbeiten, und wir können einfach unsere Köpfe hinlegen und arbeiten. Bringe alle Inhalte für das Event in den Build, so dass wir eine Punktveröffentlichung vermeiden können. Wie bereits erwähnt, sind zwei parallel laufende Release-Streams/Abzweigungen einfach nur eine Einladung zum Ärger.
Reputationssystem
Was gut gelaufen ist


Ein weiteres wichtiges System, das in Q4 hinzugefügt wurde, war das Rufsystem, das wir schon immer haben wollten. Während es für die Spieler noch nicht sichtbar ist, können sie es durch unsere Missionsgeber und einige unserer Missionsketten erleben (die Kopfgeldjägerkette ist die bemerkenswerteste Serie, die derzeit durch Rufgewinne freigeschaltet wird). Noch sind nicht alle Missionen auf das neue System umgestellt, aber das wird ein fortlaufender Prozess in den nächsten ein bis zwei Quartalen sein. Dieses neue Rufsystem wird die Grundlage für eine beträchtliche Anzahl von Gameplay-Systemen sein, während wir vorankommen. Es wird nicht nur der Hauptweg sein, auf dem Inhalte für die Spieler freigegeben werden, sondern es wird auch mit Dingen wie den Reaktionen der NPCs (derzeit in den Missionsgebern zu sehen), den Vergünstigungen und Vorteilen, die durch die Teilnahme an Inhalten verdient werden können, für die Verfolgung des Spielerfortschritts durch die Karrierewege, für das Diktieren der Beziehungen zwischen den Organisationen innerhalb des Spiels und einer Reihe von anderen essentiellen Gameplay-Schleifen verbunden sein. Wir hatten das Gefühl, dass dies so wichtig für das Spiel war, dass wir uns dafür entschieden haben, es ohne eine dem Spieler zugewandte UI zu veröffentlichen (was für die Veröffentlichung in Q1/Q2 in Arbeit ist). Aber da dies in einer beträchtlichen Anzahl von Systemen in der Zukunft so tief verwurzelt sein wird, dachten wir, dass es das Opfer wert ist. Es wird nicht nur in einer eigenständigen Reputations-UI dargestellt, die es den Spielern erlaubt, ihre Karrierestrecken bei verschiedenen Organisationen einzusehen, sondern auch die wichtigsten NSCs, mit denen sie interagiert haben, zusammen mit ihrem aktuellen Stand bei jedem von ihnen zu verfolgen. Die Reputationen werden in diesem UI sichtbar sein, sobald sie im Universum auf sie stoßen, so dass es die Spieler dazu ermutigt, herumzureisen und sich mit den Inhalten zu beschäftigen, um sie freizulegen. Zusätzlich werden wir den Missionsmanager überarbeiten, um den Spielern die Möglichkeit zu geben, zu sehen, welche Art von Rufanforderungen sie benötigen, um Missionen zu erhalten. Der Ruf wird eine der größten Fortschrittsmechaniken in Star Citizen sein, abgesehen von der Wirtschaft, da wir ein fähigkeitsbasiertes Sandbox-Spiel sind, das nicht durch "Leveling"- oder "Talentbaum"-Systeme angetrieben wird. Die Reputation ist nun auch im Backend servicegesteuert. Das bedeutet, dass alle Rufgewinne zwischen den Patches erhalten bleiben, was eine großartige Sache für die Spieler sein wird.
Was nicht so gut gelaufen ist


Was die allgemeine Entwicklung dieses Features angeht, so lief es ziemlich reibungslos, sobald wir uns in die Arbeit gestürzt hatten. Wir hatten etwa ein Jahr zuvor mit der Arbeit daran begonnen, aber leider wurden wir zu dieser Zeit von einigen Dingen mit höherer Priorität abgehalten. Wenn ich noch einmal die Wahl hätte, würde ich das Team so lange daran arbeiten lassen, bis es fertig ist und die gewünschten UI/UX-Änderungen vorgenommen wurden. Das UI nicht mit dem Release fertig zu haben, ist zwar nicht spielentscheidend, aber ein kritischer Teil dieses Features. Um sicherzustellen, dass alle unsere Features intuitiv sind, sind wir oft auf diese Art von visuellem Feedback angewiesen.
Was wir in Zukunft anders machen werden


In Zukunft würde ich gerne versuchen, die nötige Zeit einzuplanen, um ein "kompletteres" Feature zu veröffentlichen. Es ist zwar nicht immer möglich, alle bestehenden Inhalte eines Spiels auf neue Systeme wie dieses umzustellen, aber ich würde gerne versuchen, sicherzustellen, dass wir mehr tun können, wenn große Änderungen wie diese in der Zukunft passieren. Ich war froh, dass wir mehr als die ursprüngliche Absicht umgesetzt haben, aber ich hätte gerne mehr Zeit mit dem Missionsteam gehabt, um noch mehr zu konvertieren, als wir es getan haben. Das nächste Mal, wenn so etwas Grundlegendes ansteht, würde ich persönlich gerne einen besseren Job machen, um das globale Bewusstsein im Unternehmen zu erhöhen, damit wir so viel wie möglich umwandeln können.
Front End Konvertierung zu Building Blocks
Was gut lief


Wir waren in der Lage, die ersten zwei Screens im Frontend auf unsere Building Blocks Technologie umzustellen. Im Allgemeinen denke ich, dass dieser Prozess ziemlich gut gelaufen ist. Es brauchte nicht viele Leute und war eine ziemlich eigenständige Arbeit. Wir hatten auch die Möglichkeit, ein paar Dinge zu beheben, die wir seit der Einführung des "Neue Freunde"-Services in Q1 2020 angehen wollten. Die Umstellung auf unser neues UI-System erlaubte es uns auch, alle UI-Elemente zusammen auszublenden. Dieser Prozess gab uns die Zeit, das Frontend kritisch zu durchdenken, da sich das Projekt in den letzten Jahren so sehr entwickelt hat. Wir haben es auch so eingerichtet, dass die aktuelle Lösung skaliert werden kann, wenn wir weitere Solarsysteme hinzufügen. Wir haben den Hauptbildschirm aufgeräumt, damit wir einen größeren Blick auf die Hintergrundbilder haben. Ich bin froh, dass wir in der Lage waren, jeder möglichen Landezone ein anderes Bild zuzuordnen; ich denke, es hilft neuen Spielern wirklich, ein Gefühl dafür zu bekommen, welche Art von Ort sie wählen.
Was nicht so gut gelaufen ist


Das Frontend ist sehr stark mit dem ursprünglichen CryEngine-Toolset verwurzelt, mit dem wir ursprünglich angefangen haben. Das Building Blocks System arbeitet auf Basis von Entitäten, was bedeutet, dass unsere Kerndaten geladen werden müssen, damit wir eine Entität haben, auf der wir den Canvas ausführen können. Außerdem erfordert das ursprüngliche System, dass ein Level geladen wird. Aus diesem Grund waren wir nicht in der Lage, irgendwelche Elemente zu ersetzen, bevor wir ausgewählt haben, welchen Spielmodus die Spieler spielen wollen (zumindest nicht mit der auf Building-Blocks basierenden Tech/Implementierung). Die ultimative Lösung wäre eine komplette Überarbeitung dieser Codebasis, aber das lag weit außerhalb des Rahmens dessen, was wir bewältigen konnten, und war auch nicht unsere Hauptdirektive hier.
Was wir in Zukunft anders machen werden


Die Quintessenz hier ist, dass das Spiel, auf dem unser ursprüngliches Frontend basierte, sich sehr von dem Spiel unterscheidet, auf das wir heute hinbauen. Ich bin mir nicht sicher, wie sehr das USPU Team das Frontend in der Zukunft verändern wird, aber wenn wir hier das nächste Mal Änderungen vornehmen, würde ich wirklich gerne auf die endgültige Vision hinarbeiten. Das würde uns erlauben, das neue Benutzererlebnis wirklich zu optimieren, so dass der Einstieg ins Spiel zum ersten Mal oder der Wiedereinstieg für zurückkehrende Spieler so einfach und intuitiv wie möglich ist. Da wir die neuen Features nach und nach eingebaut haben, hat dieser Teil des Spiels darunter gelitten. Wenn dies von Grund auf neu definiert werden kann, gibt es eine Menge, was wir anders machen würden, basierend darauf, wie sehr sich das Spiel entwickelt hat.
Rob Reininger
Lead System Designer und USPU Product Owner

Systemische Dienste & Tools Team
Was gut gelaufen ist


Das Systemic Services and Tools (SST) Team hat weiter an der Quantum Simulation gearbeitet und sie in die Services integriert, neben internen Präsentationen neuer Technologien, die wir bald mit der Community teilen werden.
Administrative Arbeit fand im letzten Quartal statt, um die internen CIG Ressourcen für SST umzuschichten. Das Team wird vergrößert, um dem wachsenden Bedarf an Dienstleistungen und Support für Quantum in vielen Aspekten des Spiels gerecht zu werden.
Außerhalb der Dienstleistungen und der Simulationsarbeit hat SST neue Tools entwickelt, um das kommende Reputationssystem zu unterstützen und die Art und Weise, wie Reputation im Spieluniversum verteilt wird. SST unterstützt weiterhin die Star Citizen Wirtschaft mit Data Tools, um die massive Datenmenge zu lindern, während wir uns darauf vorbereiten, dass Quantum die Zügel in die Hand nimmt.
Was nicht so gut gelaufen ist


Während wir zu einer größeren Abteilung werden, hatten wir einige Wachstumsschmerzen mit unseren Reaktionszeiten auf andere Teams. Features wie der Raffinerie-Service bekamen nicht die sofortige Aufmerksamkeit, die sie brauchten, während unsere Aufmerksamkeit woanders lag.
Was wir in Zukunft anders machen werden


Wir suchen nach Möglichkeiten, die Arbeit, die bei SST ankommt, für das wachsende Team besser zu rationalisieren und zu verteilen. Außerdem haben wir automatisierte Nachrichten eingerichtet, um die Kommunikation zwischen SST und den abhängigen Teams zu ergänzen.
Jake Mühle
Senior Technischer Designer

Design Team
KI fängt Torpedos ab
Was gut lief


Die Geschütztürme der Idris, die Torpedos abfangen, funktionieren gut und es gibt einige sehr coole Momente, wenn sie erfolgreich abfangen.
Was nicht so gut gelaufen ist


Die KI-Genauigkeit ist nicht gut genug, um ankommende Torpedos zuverlässig abzuschießen, abhängig von der Framerate des Servers.
Was wir in Zukunft anders machen werden


Wir werden uns bemühen, die KI-Genauigkeit zu verbessern, damit wir mehr Kontrolle darüber haben, wie viele Torpedos durch die Turmverteidigung schlüpfen.
KI-Feuermodus-Nutzung und Zielprioritäten
Was gut gelaufen ist


Die KI, die Burst-Feuer verwendet, verbessert das Aussehen des KI-Turmfeuers erheblich. Außerdem stellen die Zielprioritäten sicher, dass die KI ein vernünftiges Ziel für ihre Schiffsklasse und Geschützgröße angreift.
Was nicht so gut gelaufen ist


Im Moment benachteiligt die Verwendung von Burst-Fire die KI im Vergleich zu den Spielern, da vollautomatisches Feuern den Schaden erhöht.
Was wir in Zukunft anders machen werden


Wir werden die KI-Serienfeuer neu ausbalancieren, wenn Kondensatoren eingeführt werden, um die Effektivität des Gedrückthaltens der Feuertaste zu reduzieren.
KI-Genauigkeitskonvergenz
Was gut gelaufen ist


Das neue Genauigkeitssystem verhält sich glaubwürdiger, da es die Position des Ziels verfolgt und weiter auf diese Position feuert, bis sich das Ziel bewegt. Das ist besser als das alte System, bei dem das Ziel der KI wild hin und her schwankte, während sie versuchte, stationäre Ziele vor ihr zu verfehlen.
Was nicht so gut geklappt hat


Die KI ist noch nicht genau genug, um den Spieler ernsthaft zu bedrohen. Außerdem neigt das neue System dazu, hinter die Bewegung des Ziels zu schießen, anstatt davor, sodass die Spieler nicht so oft sehen, dass sie beschossen werden.
Was wir in Zukunft anders machen werden


Wir wollen die Genauigkeit insgesamt verbessern und es so gestalten, dass verschiedene NSCs einen deutlicheren Unterschied in der Genauigkeit zwischen geübter und ungeübter KI haben. Das Genauigkeitssystem wird auch dahingehend überarbeitet, dass es das Ziel öfter über- als unterschießt.
Kampfverhalten von Großkampfschiffen
Was gut gelaufen ist


Die Großkampfschiffe berücksichtigen nun die Entfernung und die relative Position, wenn sie andere Schiffe angreifen. Großkampfschiffe ohne Frontalgeschütze werden versuchen, nahe genug heranzukommen, um alle ihre Geschütztürme zu nutzen, während Schiffe mit großen Frontalgeschützen versuchen werden, sich aus der Reichweite des Feindes herauszuhalten und ihre mächtigen Fernwaffen zu nutzen.
Was nicht so gut gelaufen ist


Die Taktikauswahl berücksichtigt die Stärke des KI-Schiffs relativ zum Ziel nicht ausreichend. Wenn die Idris zum Beispiel gegen ein Kanonenschiff oder ein Großkampfschiff kämpft, wird sie versuchen, auf Distanz zu bleiben und ihre Railgun zu benutzen. Das macht oft Sinn, kann aber dazu führen, dass sie vor kleineren Kanonenschiffen wegläuft, die sie in einem Nahkampf leicht einnehmen könnte.
Was wir in Zukunft anders machen werden


Wir werden die Taktikauswahl überarbeiten, damit die KI das eigene Schiff und das Ziel detaillierter betrachtet als nur die Schiffsklasse. Außerdem werden wir den Charaktereigenschaften der Piloten erlauben, das Verhalten des Hauptschiffs zu beeinflussen.
Aufzugspaneele
Was gut gelaufen ist


Wir haben erfolgreich den Grundstein für zukünftige Aufzugspaneele (und andere umgestaltbare Bildschirme) gelegt, indem wir sie dazu gebracht haben, ihre Stile vom Transitsystem zu erben und auf jedem geformten Canvas verwendbar zu sein. Das bedeutet, dass alle zukünftigen Panels die gleichen zwei Dateien verwenden können und trotzdem unterschiedlich aussehen.
Was nicht so gut gelaufen ist


Das Transitsystem ist in seiner jetzigen Form sehr schwierig einzurichten und zu testen - das UI Team war nicht in der Lage, es richtig zum Laufen zu bringen und musste sich bei der Implementierung auf das Level Design verlassen. Allerdings haben UI und Level Design nicht gleichzeitig an dem Feature gearbeitet, was dazu führte, dass die Arbeit in unterschiedlichen Strömen begann und endete und Bugs übersehen wurden. Neue Building Blocks Styles sind extrem zeitaufwendig zu implementieren, da es an Werkzeugen mangelt und die Dateien nicht zusammengeführt werden können.
Was wir in Zukunft anders machen werden


Wir werden sicherstellen, dass das Feature in einem Rutsch in einem Feature Stream entwickelt, implementiert und getestet wird, so dass Bugs aufgegriffen und behoben werden, bevor es "fertig" ist. Wir werden auch sicherstellen, dass das Team, das für das Feature verantwortlich ist, Zeit hat, um Code-Probleme als Teil des Feature-Entwicklungszyklus zu beheben und dass das UI-Team sich auf die Benutzeroberfläche konzentriert.
Stationsbasiertes Refining
Was gut gelaufen ist


Wir haben den ersten Gameplay-Loop für das Raffinieren fertiggestellt, komplett mit Raffinerien, die ihre eigenen Materialspezialisierungen und Arbeitslasten haben, und der Möglichkeit, raffinierte Materialien an verschiedenen Orten in der Galaxie zu sammeln und zu verkaufen. Die Raffinerie-Decks selbst sehen spektakulär aus und die Benutzeroberfläche des Raffinerie-Terminals ist an einem großartigen Ort, um den Gameplay-Loop mit sehr wenig Nacharbeit zu erweitern, was eine schnellere Iteration in der Folge bedeuten sollte.
Was nicht so gut gelaufen ist


Unsere Planung für jeden Schritt war extrem gründlich, jedoch konnten wir aufgrund mehrerer Situationen, die außerhalb unserer Kontrolle lagen, nicht früh genug einen Punkt erreichen, an dem wir den Raffinerie-Loop so ausbalancieren konnten, wie wir es vorhatten. Daher haben wir ein weiteres, bereits geplantes Set von Änderungen in Form des ersten Bergbau-Rebalances vorgezogen, um so gut wie möglich zu kompensieren, bis wir die Raffinerie-Balance auf das Niveau bringen können, das wir ursprünglich wollten. Dieses Bergbau-Rebalance hatte den zusätzlichen Bonus, dass es den MISC-Prospector ein wenig attraktiver für Leute machte, die mit ihm anfangen oder ihn mieten wollten, und dass es mehr Spielerfahrung für die Argo MOLE oder mehrere Spieler mit Prospectors bot.
Was wir in Zukunft anders machen werden


Die UI-Kunst früher spielerisch testen lassen. Einige Spieler wussten nicht, mit welchen Teilen des Bildschirms sie interagieren können und das hätte uns mehr Zeit gegeben, um Änderungen vorzunehmen.
Bergbau UI Refactor
Was gut lief


Wir haben die gesamte Bergbau-UI überarbeitet, um mit Building Blocks zu arbeiten. Das ging viel reibungsloser, als wir es uns je erhofft hatten, da ein großer Teil des Mining-Gameplay-Loops direkt mit Building Blocks funktionierte, ohne dass wir viel nacharbeiten mussten. Das gab uns den Spielraum, mehr zur Mining UI hinzuzufügen, als wir ursprünglich vorhatten. Das bedeutet, dass wir nicht nur eine komplett neue UI bereitstellen konnten, die über drei verschiedene Mining-Fahrzeuge hinweg skalierbar ist, sondern wir haben diese Skalierbarkeit gezeigt, indem wir schnell UI-Canvas-Teile iteriert haben, um zuvor eingeführte Systeme zu unterstützen. Dazu gehörte auch die flüchtige Ladung und ein komplett neues Laderaumteil, das den Spielern weitere Informationen bietet, die wir schon immer bereitstellen wollten, aber nie die Möglichkeit hatten, dies zu tun.
Was nicht so gut gelaufen ist


Der erste Durchgang des UI-Refactors für den Bergbau war schwieriger zu implementieren als zu bauen, da verschiedene Fahrzeuge unterschiedliche Flächen für das UI zur Verfügung hatten, was bedeutete, dass eine Menge Tweaking hinter den Kulissen nötig war, um das UI tatsächlich auf eine komfortable Weise darzustellen. Wir arbeiten immer noch an der Feinabstimmung und hoffen, dass wir die Benutzeroberfläche in Zukunft auf eine visuell ansprechendere Art und Weise darstellen können, die besser funktioniert als die aktuelle Implementierung.
Was wir in Zukunft anders machen werden


Wir werden in Zukunft schneller iterieren, da wir jetzt ein besseres Verständnis von Building Blocks und seinen Vorteilen haben.
Todd Papy
Star Citizen Live Direktor

Kern Gameplay Säule
Multi-Tool Traktorstrahl
Der Multi-Tool Tractor Beam ist eine aufregende Ergänzung zum 'Verse' und ist ein Kernstück der Funktionalität, die mehrere Gameplay-Loops freischaltet, an denen wir arbeiten, wie z.B. Frachttransport und EVA-Traversalräume. Der Hauptanwendungsfall für den Tractor Beam in Alpha 3.12 ist das einfachere Einsammeln von Frachtkisten in EVAs, entweder während verlorener Weltraummissionen oder für das Einsammeln von Beute nach einem Schiffskampf. Oberflächlich betrachtet ist der Tractor Beam ein einfaches Werkzeug, aber unter der Haube passiert eine Menge und ich denke, das Team hat einen fantastischen Job gemacht, um ein wirklich systemisches Feature zu erschaffen, das zugänglich und einfach zu benutzen ist.
Die erste Herausforderung, mit der wir konfrontiert waren, war, dass wir wollten, dass es in verschiedenen Schwerkraft-Einstellungen funktioniert und das Gewicht eines Objekts ausnutzt. Dies führte zu mehreren Problemen, da in der Schwerelosigkeit alles schwerelos ist, was bedeutet, dass man potentiell etwas Riesiges bewegen kann, das sehr wenig wiegt. Zum Beispiel eine planetengroße Styroporkugel. Wir haben den Tractor Beam um zwei Kernkonzepte herum entworfen - Volumen und Kraft. Das Volumen diktiert die generelle Größe des Objekts, das du anheben kannst, während die Kraft die Menge an Anstrengung diktiert, die die Waffe aufbringen muss, um das Objekt anzuheben. Das bedeutet, dass für jeden Gegenstand, der eine Masse und einen Physikkollider hat (was jeder Gegenstand bereits haben sollte), die Kraft, die benötigt wird, um ihn anzuheben, automatisch anhand der Schwerkraft der Umgebung berechnet wird. Dies erlaubte uns, ein Feature zu bauen, das mit jedem Physik-Objekt im Spiel funktioniert, ohne dass wir eine Menge manueller Einstellungen vornehmen müssen.
Die zweite Herausforderung war, wie erklären wir dem Spieler, was er heben kann und was nicht, ohne alles mit ADS zu belegen oder, noch schlimmer, Versuch und Irrtum anzuwenden. Glücklicherweise hat das Multi-Tool bereits einen kleinen Bildschirm auf der Rückseite, der es uns ermöglichte, eine einfache Ikonographie zusammen mit einem Ampel-Farbcodierungssystem zu implementieren. Das bedeutet, dass wir in der Lage sind, alle fünf Zustände eines Objekts deutlich zu zeigen, indem wir es einfach anschauen:
Objekt kann angehoben werden Objekt kann angehoben werden, ist aber außer Reichweite Objekt ist zu schwer Objekt kann niemals angehoben werden Du wirst zu dem Objekt reisen
Obwohl wir zusätzliche Informationen in der ADS-Ansicht zur Verfügung gestellt haben, befindet sich alles, was du wissen musst, auf der Rückseite des Werkzeugs und ich war wirklich froh, dass wir so viele Informationen in einen so kleinen Bildschirm destillieren konnten.


Was nicht so gut gelaufen ist


Wenn du ein Feature planst, solltest du das Haupterlebnis identifizieren und dann alle sekundären Mechaniken skizzieren, die dieses Erlebnis verbessern würden. Zum Beispiel ist eine Sprungmechanik für sich genommen ein eigenständiges Feature, aber du könntest entscheiden, dass die Kontrolle in der Luft (eine sekundäre Mechanik) das Kernerlebnis verbessert. Mit dem Traktorstrahl haben wir uns hingesetzt und das Haupterlebnis identifiziert, nämlich die Möglichkeit, Objekte zu manipulieren und ihn als Greifhaken in EVA zu benutzen, und ich glaube, das haben wir geschafft. Aber es gab einige sekundäre Mechaniken, die ich gerne eingebaut hätte, für die uns aber die Zeit fehlte. Insbesondere die Möglichkeit, die Flugbahn mit den Triebwerken des Anzugs zu manipulieren, wenn man den Greifhaken in der Schwerelosigkeit benutzt.
Leider funktionierten die beiden Systeme nicht wirklich gut zusammen, da die Kraft, die zum Ziehen verwendet wurde, die Kraft der Anzugtriebwerke überlagerte. Es war auch nicht hilfreich, dass EVA zur gleichen Zeit auf IFCS umgestellt wurde, was dazu führte, dass wir uns auf die Kernfunktion konzentrieren mussten, um sicherzustellen, dass diese bis zur Veröffentlichung so gut wie möglich ausgefeilt war. Das passiert bei Features immer wieder und liegt in der Natur der Spieleentwicklung, aber es war eine Schande, dass es in der ersten Iteration fehlte. Wir werden diese Funktionalität in einer späteren Version hinzufügen.
Was wir in Zukunft anders machen werden


Um ein Feature zur Veröffentlichung zu bringen, müssen viele verschiedene Teams zusammenarbeiten, von VFX über Audio bis hin zum Feature-Team, das an der Funktionalität arbeitet. Eines der größten Dinge, die ich versuche zu verbessern, ist, den Missionsdesignern mehr Zeit zu geben, damit sie all diese verschiedenen Features sinnvoll in das Verse integrieren können. Wenn du meine vorherigen Postmortems gelesen hast, wirst du wahrscheinlich einen Trend erkennen, dass dies etwas ist, was ich aktiv versuche zu verbessern, aber da mehrere Teams und Zeitpläne involviert sind, braucht es ein wenig Zeit, um sich umzustellen. Wenn ich in der Zeit zurückgehen könnte, hätte ich wahrscheinlich versucht, eine einfache Version früher in die Hände der Missions-/Leveldesigner zu bekommen, damit sie ein bisschen mehr damit spielen konnten.
Waffennullstellung
Was gut lief


Das Weapon Zeroing, wie der Titel schon sagt, erlaubt es dir, deine Waffen auf verschiedene Entfernungen zu nullen, was dir erlaubt, auf viel weitere Entfernungen genau zu schießen. Das bedeutet, dass das Zielfernrohr den Abfall des Geschosses in einer bestimmten Entfernung berücksichtigt und dir erlaubt, die Visierung so einzustellen, dass du dein Fadenkreuz immer noch auf das Ziel richten kannst. D.h. du musst nicht über das Ziel hinaus zielen. Wir haben bereits viele Zielfernrohre zur Verfügung und die erste Herausforderung war zu entscheiden, welche Zielfernrohre überhaupt nullen sollten und dann zu entscheiden, ob sie automatisch oder manuell nullen sollten. Dies führte zu einer viel breiteren Diskussion über Hersteller und ihre spezifischen Eigenschaften, wie High-Tech oder Low-Tech. Während das Team sich nur auf das Feature hätte konzentrieren und es herausbringen können, haben sie auch einen langfristigen Plan für die Zielfernrohrbefestigungen geliefert, nicht nur für aktuelle Hersteller, sondern auch für zukünftige.
Das ist etwas, woran ich grundsätzlich glaube - dass wir, auch wenn wir an einem Live-Produkt arbeiten, Entscheidungen rund um die finale Erfahrung im veröffentlichten Spiel treffen sollten. Manchmal ist das schwer, da es bedeuten kann, dass bestimmte Features auf den ersten Blick nicht in ihrem besten Licht gesehen werden oder kurzfristig von den Spielern missverstanden werden. Aber es ist mein Job, sicherzustellen, dass wir auf die finale Vision hinarbeiten und das Team hat einen fantastischen Job gemacht, ein Feature bereitzustellen, das Spaß macht, aber in der Zukunft skalierbar ist.
Was nicht so gut gelaufen ist


Dies war das erste Feature, an dem eines unserer neuesten Teammitglieder gearbeitet hat. Daher stellten wir sicher, dass er genug Zeit hatte, um es weit vor dem eigentlichen Release zu liefern. Tatsächlich wurde die Funktionalität (nicht die Optik) im Quartal davor geliefert und er hat einen tollen Job gemacht. In den meisten Fällen ist das fantastisch, da es bedeutet, dass wir uns auf das Erlebnis konzentrieren und sicherstellen können, dass es von höchster Qualität ist. In diesem Fall jedoch konnte sich das Testteam aufgrund anderer Prioritäten und der Tatsache, dass dies so weit vor der Veröffentlichung geschah, nicht voll und ganz darauf konzentrieren, da es (berechtigterweise) damit beschäftigt war, Dinge zu überprüfen, die kurz vor der Veröffentlichung standen. Unglücklicherweise bedeutete dies, dass ein grundlegender Edge Case bis kurz vor der Veröffentlichung übersehen wurde, nämlich dass das Zeroing nicht funktionierte, als die Physik-Patches für die Umgebung herauskamen.
Lass mich das erklären. Wenn ein Charakter auf einem Planeten spawnt, spawnen eine Reihe von Patches (Quadrate) um ihn herum in immer größer werdenden Größen. Diese Patches decken die Renderqualität (Grafik) und die Physikkollision ab, wobei weiter entfernte Patches weniger Details und schließlich keine Kollision mehr haben (da die Physik relativ teuer ist). Wenn du dich nun bewegst, werden die Patches dynamisch aktualisiert, aber nicht eins zu eins. So kann ein Patch, in dem du dich gerade befunden hast, immer noch seine Kollision haben, da du vielleicht dorthin zurückkehren möchtest und es performanter ist, ihn kurzfristig dort zu behalten, als ihn ständig zu laden und zu entladen. In diesem Fall bedeutete es jedoch, dass wenn ein Designer in den Editor geladen wurde, um das Feature zu testen, der Patch geladen war und er sich dann 2 km weg bewegte, um die Waffen-Nullstellung zu testen und es funktionierte. Wäre ein Spieler jedoch nie an die ursprüngliche Position gegangen, gäbe es keine Kollision und somit hätte das Zielfernrohr nichts, gegen das es testen könnte. Das bedeutete, dass es unter normalen Spielbedingungen nicht wie beabsichtigt funktionierte, also mussten wir den Code für die Waffennullstellung neu schreiben, um gegen die Rendergeometrie zu testen, anstatt gegen die Physikgeometrie. Obwohl diese Änderung nicht groß war, war sie nicht ideal, da wir geplant hatten, an anderen Features zu arbeiten.
Was wir in Zukunft anders machen werden


Wenn ich in der Zeit zurückgehen könnte, würde ich auf jeden Fall sicherstellen, dass das Feature gründlich getestet wurde, als es fertiggestellt wurde, anstatt auf das eher traditionelle Go/No Go zu warten. Obwohl es keinen Einfluss auf die Veröffentlichung des Features hatte Das hatte Auswirkungen auf die zukünftige Arbeit, da wir im Laufe des Quartals die Prioritäten neu setzen mussten.
Gemini A03 Scharfschützengewehr & Behring FS-9 LMG
Was gut lief


Wie bei jeder Waffe, die wir dem Spiel hinzufügen, müssen wir immer sicherstellen, dass sie in die bestehende Waffenmatrix passt und etwas Einzigartiges bietet, das es nicht schon gibt. Mit dem Gemini A03 Scharfschützengewehr war die Absicht, ein leichtes, reaktionsschnelles Scharfschützengewehr mit einem geringeren Kaliber als seine schwereren Gegenstücke, aber hoher Geschwindigkeit und Genauigkeit zu bauen. Ich denke, dass das Team diese Absicht wirklich umgesetzt hat und eine gute Balance zwischen den hochkalibrigen Scharfschützengewehren wie dem P6-LR und den eher angriffsorientierten Waffen wie dem Gemini S71 gefunden hat. Während das A03 eine einfache Ergänzung war, war das Behring FS-9 ein wenig kniffliger. LMGs als Waffenkategorie stehen momentan nicht gut da, da sie auf kurze Distanz von SMGs/Schrotflinten und auf mittlere bis lange Distanz von Sturmgewehren übertroffen werden. Wir sind uns dessen bewusst und haben hinter den Kulissen daran gearbeitet, dies zu verbessern. Der Behring FS-9 setzt den Standard für das, was wir uns von LMGs wünschen - Maschinengewehre mit hoher Kapazität, die es den Spielern erlauben, ein Gebiet ohne großen Verlust an Genauigkeit zu unterdrücken.
Was nicht so gut gelaufen ist


Während wir an der FS-9 gearbeitet haben, haben wir auch die Designabsichten für alle anderen LMGs ausgearbeitet, damit wir ein Update für alle in einem Release liefern konnten. Leider ist uns bei den bestehenden Waffen die Zeit ausgegangen, obwohl wir es geschafft haben, einige Tweaks zu machen, um ihre Effektivität zu erhöhen. Wir planen, die bestehenden LMGs zu aktualisieren, um sie auf die gleiche Qualitätsstufe wie die FS-9 zu heben, aber das bedeutet kurzfristig, dass sie den anderen Waffen der gleichen Kategorie weit überlegen ist. Aber wie ich bereits erwähnt habe, werde ich Entscheidungen immer danach ausrichten, was das Endziel sein soll, damit wir uns ständig weiterentwickeln.
Was wir in Zukunft anders machen werden


Wir haben den Plan, alle Waffenkategorien zu überarbeiten und ihr könnt hoffentlich sehen, dass jede Waffe, die wir veröffentlichen, die vorherigen leicht verbessert. Mit dieser Absicht hätte ich mehr Zeit für den Feinschliff der bestehenden LMGs eingeplant, denn ich hätte sie gerne alle zusammen veröffentlicht. Egal wie erfahren man ist, man lernt immer dazu und das ist etwas, das ich für zukünftige Waffen implementieren werde.
Richard Tyrer
Core Gameplay Direktor

Standorte
Raumstation Raffinerie Decks
Was gut lief


Für diese Veröffentlichung konnten wir Raffinerie-Decks an einigen speziellen Orten der Raumstation einführen. Diese Räume sind thematisch an die Bergbau- und Raffinerie-Spielschleifen angelehnt und dienen auch als Standort für zukünftige Spielmöglichkeiten. Innerhalb des Raffineriedecks haben wir einen Raum speziell für die Raffination und Verarbeitung geschaffen, zusammen mit einem Shop und einem Gildenraum darunter.
Nachdem wir die Reaktionen auf die Frachtdecks und die neuen Innenräume der Raumstation in Alpha 3.11 gesehen hatten, stimmten wir mit den Kommentaren überein, dass die Spieler mehr sichtbare Verbindungen mit dem Außenbereich sehen wollten, um physisch zu verstehen, wo sie sich in der Station befinden. Obwohl wir mit der Entwicklung des Innenraums des Raffineriedecks schon ziemlich weit waren, schwenkten wir um und passten den Raum an, um das Mini-Aussichtsdeck bei den Aufzug-Lobbys einzubeziehen. Visuell wollten wir schon seit einiger Zeit ein Raumstationserlebnis erkunden, das sich mehr auf industrielle Aktivitäten konzentriert.
Was nicht so gut gelaufen ist


Es war schade, dass keine spezifischen NPC-Loadsouts mit den Raffinerie-Decks veröffentlicht wurden oder dass einige der spezifischen Nutzgegenstände nicht erweitert werden konnten. Diese sind jedoch alle geplant, also werden wir sie hoffentlich bald online sehen.
Was wir in Zukunft anders machen werden


Wie bereits erwähnt, haben wir das Aussichtsdeck erst recht spät im Prozess eingeführt, so dass wir während des Konzepts und des Whiteboxings einen besseren Platz dafür hätten entwerfen können.
Stanton Planet Verbesserungen & Politur
Was gut gelaufen ist


Aufbauend auf den Planetenverbesserungen, die im Laufe von 2020 gemacht wurden, war dies die erste Gelegenheit für das Team, die neuen und verbesserten Arbeitsabläufe, die bei der Erstellung der Planeten und Monde von Pyro entwickelt wurden, in Stanton einzuführen.
Die Verbesserung des Workflows beinhaltete, dass wir die Zeit und den Fokus hatten, tiefer in den globalen Malprozess einzusteigen. Für Planeten wie Stanton I und IV wurde die globale Bemalung komplett überarbeitet, um sowohl die Temperaturparameter genauer einzuhalten als auch eine bessere Mischung und Verteilung der Farbtöne zu erreichen. Als zweiter Teil der Bemalung wurden alle Objektpräsentationen und Verteilungsregelsätze von Grund auf neu erstellt. Im Allgemeinen lag der Fokus darauf, mit weniger mehr zu erreichen. Anstatt also viele Arten von Geologie im gleichen Raum zu verwenden, wurden nur ein oder zwei verwendet, die wirklich gut zusammen funktionieren. Das Endergebnis ist viel realistischer und natürlicher. Ein gutes Beispiel dafür ist Daymar. Ein weiterer Bereich, den wir verbessern wollten, war der verstärkte Einsatz von Bodenstreuungsobjekten, um das Terrain komplexer zu lesen. Wir haben eine Mischung aus Geologie-Assets wie Platten, Geröll und kleinen Felsen mit der Verteilung der Geologie-Packs kombiniert, um der Szene eine viel integriertere Lesart zu geben.
Zusätzlich wurden einige herausragende Geologie-Packs konvertiert, um den organischen Shader zu verwenden und wurden als Teil unserer Pipeline korrekt durch Houdini verarbeitet.
Einige neue Tech-Features kamen in diesem Release online, die wir mit Begeisterung genutzt haben. Das erste ist Terrain Displacement, das POM ersetzt. Jetzt kannst du tatsächlich sehen, wie die Geometrie des Geländes tesseliert und verschoben wird, was eine echte Tiefe und komplexere Überschneidungen mit Objekten ermöglicht. Das zweite Feature ist Biome Accumulation, was bedeutet, dass Assets prozedural eine dünne Materialschicht auf ihrer Oberseite erhalten können, abhängig vom Biome. Zum Beispiel sammelt sich Sand auf der Oberseite der Felsen auf Daymar.
Was nicht so gut gelaufen ist


Als wir versuchten, das Jahr zu beenden und die Alpha 3.12 zu veröffentlichen, konnten einige Monde nicht auf das gewünschte Polishing-Niveau gebracht werden. Außerdem haben wir im Zuge der Einführung unserer neuen Arbeitsabläufe und Methoden in das Stanton-System festgestellt, dass die visuellen Stile zwischen einigen Monden zu eng beieinander liegen und wir dadurch etwas an Vielfalt verlieren.
Was wir in Zukunft anders machen werden


Mehr Assets werden helfen, die Kunstmüdigkeit zu reduzieren und die visuelle Vielfalt zu verbessern, daher werden wir in diesem Jahr Zeit und Energie in mehr Asset-Packs investieren.
Stanton System Spacescaping
Was gut lief


Wir waren alle sehr aufgeregt, die Gaswolkentechnologie als Teil des PU in Alpha 3.12 präsentieren zu können. Viele Teams haben hart daran gearbeitet, dieses neue Feature zu entwickeln. Es ging also darum, ein Team zu gründen, das sich der Erstellung von Inhalten für Stanton widmet, und dann zu schauen, was wir für die Lagrange-Punkte tun können.
Wenn man bedenkt, dass dies die erste Release-Version der Technologie war, denke ich, dass wir eine Vielzahl von visuellen Szenarien geschaffen haben, um das Potenzial der Technologie zu zeigen.
Was nicht so gut gelaufen ist


Da es sich um das erste Release handelte, gab es offensichtlich eine Menge herauszufinden, was die Performance angeht, und es gibt eine Menge, was wir in Bezug auf die Pipeline-Verfeinerung tun können. Außerdem gibt es in einigen Beleuchtungsszenarien sichtbares Rauschen, das wir in Zukunft gerne reduzieren würden, wenn es die Leistung zulässt.
Was wir in Zukunft anders machen werden


Wir sind bereits dabei, unseren Entwicklungsworkflow zu verbessern und suchen nach Möglichkeiten, den Prozess zu verbessern. Wir erforschen, wie wir die Hintergrund-Raumlandschaft in mehr Mini-System-basierte Formen zusammenbinden können, was dann zu kleineren, volumetrischen Gastaschen führt. Für zukünftige Gameplay-Möglichkeiten schauen wir uns an, wie wir das Risiko/Belohnungs-Gameplay innerhalb der Gastaschen mit Elementen wie Blitzen, Strahlung, Temperaturbereichen und Flughandling fördern können.
Ian Leyland
Star Citizen Art Director

Technologie
In der Alpha 3.12 konzentrierte sich das Grafikteam hauptsächlich auf die Verbesserung der Stabilität und die Behebung von Fehlern in den verschiedenen Grafikfeatures, die in der Version verwendet werden. Viele der Fehlerkorrekturen bezogen sich auf die Einführung von Gaswolken, wie z.B. das Beheben eines sichtbaren Dithermusters, wenn die Sonne von einer Wolke verdeckt wird und das Verhindern des Clippings von Gaswolken und Partikeln innerhalb von Raumschiffen durch die Verbesserung des volumetrischen Culling- und Partikel-Culling-Systems. Solche Probleme waren zu erwarten, aber größtenteils unvermeidbar, denn obwohl die Technik bei der Entwicklung von SQ42 ausgiebig genutzt wurde, sind die Grafik und die Szenarien in PU ganz anders. Außerdem bedeutete die Sandbox-Natur der PU und die ausgiebigen Tests, die sie erhält, dass viele zuvor unbekannte Probleme entdeckt oder in den Vordergrund gestellt wurden.
Das Team schaffte es auch, Dutzende anderer Bugs zu beheben, die von "popping shadows" bis hin zu einer zu hellen Kamerabelichtung reichen, wenn ein Planet hereingestreamt wird. Der Anteil der Zeit, die für die Behebung von Bugs im Vergleich zu neuen Features aufgewendet wurde, war höher, als wir es uns gewünscht hätten, aber am Ende des Jahres liegt der Schwerpunkt immer auf Stabilität und Qualität und die Arbeit an den Features wurde bereits wieder aufgenommen, also ist dies kein Grund zur Sorge. Trotz der Verlangsamung der Feature-Arbeiten haben wir es geschafft, gute Fortschritte beim neuen Gen12-Renderer zu machen, der Anfang 2021 unser Hauptaugenmerk sein wird.
Das Physics Team arbeitete an dem volumetrischen Soft Body Prototyp sowie dem damit verbundenen Rendering der volumetrischen Deformation. Außerdem wurden verschiedene Optimierungen in der Physik vorgenommen. Zum Beispiel verbesserten wir das Threading verschiedener Subsysteme, fügten schnellere Spatial Grid Queries hinzu, entfernten Contention beim Zugriff auf die lokale Kommando-Warteschlange und entfernten Contention für die Schrittfunktionen der Actor/Living Entities (Verbesserung der Living Entity Step Performance um einen Faktor von 2x - 5x). Wir haben auch eine bessere Methode zur Vorphysikalisierung der Terrain-Patches des Planeten implementiert, die für Kollisionsprüfungen verwendet werden. In Bezug auf die Kollisionserkennung haben wir auch ein langjähriges Problem behoben, das zusätzliche Geisterkontakte weit weg von den eigentlichen Kontakten einführen konnte. Außerdem wurden Verbesserungen an der Ereignis-Warteschlange vorgenommen. Der erste Entwurf zur Ausbreitung von physikalisierten Schockwellen wurde eingereicht und kastenförmige Physikgitter und Geschosswiderstand wurden hinzugefügt. Die SDF-Unterstützung wurde verbessert und die Forschung an Verbesserungen des Setups der Touch-Bending-Vegetation begann.
Beim Renderer haben wir mit der laufenden Gen12-Umstellung und dem damit verbundenen Refactoring weitergemacht. Zum Beispiel fügten wir ein parametrisierbares Feature-Set für die Deferred Pipeline hinzu, implementierten Updates pro Objekt-Ressourcenset (einschließlich RTT-Update für Pinsel) für das Gen12-Szenen-Rendering und Legacy-Pipeline-Status-Caching (um DX-API-Aufrufe zu sparen, während wir noch vollständig auf Gen12 umstellen). Im Shader-System haben wir den gesamten Code für das Nachladen von Shadern aufgeräumt, was die Shader-Bearbeitung während der Entwicklung verbessern wird und eine deutlich verbesserte Reaktion beim Ändern von System-Spezifikationseinstellungen (z.B. Grafikeinstellungen, die die Verwendung verschiedener Shader-Kombinationen erfordern) ermöglicht. Wir haben auch ein größeres Refactoring des Shader-Cache-Backend-Systems begonnen, da es ziemlich veraltet ist und eine ständige Quelle des Ärgers in Bezug auf Wartung und Gen12-Fitness ist. Mehrere Optimierungen wurden im Renderer Code durchgeführt. Zum Beispiel wurde die Art und Weise, wie Materialkonstanten auf die GPU hochgeladen werden, vereinfacht und optimiert.
Auf der Grafikseite wurden verschiedene Fixes für die Tiefenschärfe bereitgestellt. Der Haar-Shader erhielt mehrere Verbesserungen, wie die Möglichkeit, spiegelnde Highlights auf den Wimpern zu deaktivieren, verbesserte Boundary Occlusion an Haarlinien, Unterstützung für Umgebungslichter im Forward Shading sowie eine verbesserte Haarqualität bei Kameraschnitten. Die Duallobe-Approximation für den Skin-Shader wurde verbessert und der Eye-Shader erhielt ebenfalls ein paar Verbesserungen. Was Atmosphären, Wolken und den Unified Raymarcher angeht, so sind die im letzten Postmortem erwähnten Verbesserungen nun in Alpha 3.12 verfügbar. Nachdem das aus dem Weg geräumt ist, wurde die meiste Zeit auf das volumetrische Wolkenrendering verwendet. Der erste Entwurf des Wolkenrenderers wurde implementiert und die Arbeit an volumetrischen Wolkenschatten machte gute Fortschritte. Die Arbeit an den Verbesserungen für die lokale Wolkenformung wird beginnen. Beachte, dass es bis zur Veröffentlichung noch eine ganze Menge Arbeit zu erledigen gibt.
Für das Kern-Engine-System haben wir einen dynamischen Zonen-Culling-Pfad in das Zonensystem implementiert. Außerdem haben wir ein paar Culling-Fehler in Bezug auf die Sichtdistanz behoben, die mit pixelgroßen Objekten zu tun haben und in Alpha 3.11 auftraten. Die Leute haben bereits bemerkt, dass sie jetzt Spieler sehen können, die über 1000 Meter entfernt sind, anstatt nur ein paar hundert oder so. Eine Menge Bugfixes und Verbesserungen wurden für Vis-Flächen bereitgestellt, wie z.B. ein Fix für das Streaming von Meshes für animierte Vis-Flächen und die Möglichkeit, Vis-Flächen zu CGA-Joints hinzuzufügen. Das Entity-System erhielt mehrere Verbesserungen und Optimierungen, um unnötige Updates und Suchen zu vermeiden. Ebenso erhielt der Entity-Aggregate-Manager Low-Level-Optimierungen, um das Work-Balancing zu verbessern und den Speicherverbrauch und die Konkurrenzsituation bei der Arbeit mit Entity-Bubbles zu reduzieren. Es gab auch ein paar kleinere Verbesserungen am Entity Component Update Scheduler. Die Culling-Logik des Radix-Baums wurde verbessert, wobei die Threading-Logik angepasst wurde, um Konflikte zu reduzieren und SIMD-Culling implementiert wurde, um bis zu vier Bubbles vs. Objekte pro Knoten zu überprüfen. In Bezug auf die Performance wurde der Engine-Profiler weiter entwickelt, der viele Verbesserungen erfahren hat. Die Arbeit an einem Echtzeit-Sampling-Profiler basierend auf Event Traces wird bald beginnen. Verschiedene Optimierungen wurden im Entity System, den Komponenten-Updates und dem Zonensystem implementiert. Basierend auf der Telemetrie von der PU und PTU haben wir unsere laufenden Untersuchungen zur Speichernutzung fortgesetzt. So wurde der Engine-weite Memory Allocator und das Memory Tracking System, einschließlich der Toolchain, erheblich überarbeitet und verbessert. Um unseren Servern einen zusätzlichen Leistungsschub zu geben, wurde der Linux DGS auf ein monolithisches Executable umgestellt, um dem Compiler zu ermöglichen, besseren Code zu generieren (insbesondere für den Thread Local Storage Access). Als Teil unserer Initiative, ein Performance-Regressionssystem aufzubauen, haben wir auch einen Stresstest für Object Container Streaming hinzugefügt.
Was die Crash-Behandlung angeht, erfassen wir nun einen Hex-Stack des Render-Threads und betten ihn in Mini-Dumps ein, die du uns (optional) schickst, falls das Spiel abstürzt. Dies ermöglicht es uns, den kompletten Renderthread-Callstack während des Postmortem-Debugging wiederherzustellen, ohne dass Drittanbieter-Binaries (die Teil des Callstacks oder des Videotreibers sein könnten) den Stack vollständig abwickeln müssen. Das spart eine Menge Zeit, da wir die verschiedenen Treiber, die die Spieler verwenden, nicht herunterladen müssen.
Auf der Animationsseite haben wir den Code korrigiert, damit die Charakterüberblendungen und das dynamische Beleuchtungsrigg beim Rendern von Cutscenes nicht bei jedem Kameraschnitt zu spät umschalten.
Zu guter Letzt wurde die Unterstützung von C++ 14 für den gesamten Client-Server-Editor und die relevanten Tool-Projekte aktiviert.
Online Technik
Load Balancing Test Framework


Der Pestilence Warmer für Alpha 3.12 erhielt wichtige Updates. In erster Linie nutzt der Warmer nun das neue JWT-Identifikationssystem, das es ihm erlaubt, sehr schnell viele Token für Impersonationszwecke zu holen. Dies hat den 10-fachen Durchsatz an Warmer-Instanzen, die wir gleichzeitig laufen lassen können.
Ein wichtiges Subsystem wurde hinzugefügt, das es dem Warmer ermöglicht, sich als Service mit dem Diffusion Gateway zu verbinden, was die Ausführung von Lastszenarien ermöglicht, die sich sowohl als Client, der über den Hub verbunden ist, als auch als Service im Diffusion Netzwerk koordinieren.
Backend Gleichzeitigkeitsverbesserungen


Wir waren in der Lage, die Leistung des variablen Dienstes, der Loadouts und des Haupt-Persistenz-Cache-Dienstes zu erhöhen. Die Stabilität des Backends wurde stark erhöht und übertraf die Leistung und Zuverlässigkeit, die wir in früheren Versionen hatten. Unser Low-Level-Netzwerkcode wurde aktualisiert, um sowohl die Leistung als auch die Skalierbarkeit und Robustheit zu verbessern. Wir haben auch verschiedene Korrekturen und Optimierungen am Transaktionsdienst, den Vermietungen und unserem Entitlement-Prozessor vorgenommen.
Vereinheitlichtes und zentralisiertes Logging


Mit unserem neuen einheitlichen, zentralisierten Logging-System senden alle Dienste formatierte JSON-Nachrichten an eine zentralisierte Elasticsearch-Datenbank. Jedes Log-Ereignis wird getaggt und dynamische Daten wie Account-IDs, Spieler-IDs, etc. werden in benannte Felder extrahiert, was die Suche nach Ereignissen oder bestimmten Feldern - wie z.B. einer "AccountID" - sehr effizient macht. Dies ermöglicht den Entwicklern einen einfachen Zugriff auf die Logs von einem zentralen Ort aus und die Verfolgung komplexer Nachrichten und Ereignisse, die zwischen mehreren Diensten stattfinden.
Persistente Technik
Entity Erstellung & Spawn Entkopplung


In Vorbereitung auf das persistente Streaming wurde der Prozess der Entitätserstellung vom Spawnen der Entitäten entkoppelt. Dies erlaubt es uns, den Anfangszustand des Universums in die persistente Datenbank zu "seeden", indem wir alle dynamischen Entitäten vor der Simulation erzeugen. DGS-Prozesse werden dann während der Simulation persistente Entitäten aus dieser Datenbank streamen (spawn/despawn). Dies ist ein wichtiger Schritt auf dem Weg zu einem vollständig persistenten Universum.
Parallele Spawn-Warteschlangen


Als eine Optimierung haben wir mehrere parallele Spawn-Warteschlangen auf jedem Spielserver eingeführt. Dies erlaubt es uns, mehrere verschiedene Orte (wie Lorville und New Babbage) parallel in separaten Threads auf demselben Server zu spawnen. In früheren Versionen gab es nur eine einzige Warteschlange und daher würden wir (in diesem Beispiel) erst mit New Babbage beginnen, wenn Lorville vollständig gespawnt ist. Auf ausgelasteten Servern kann dies die Wartezeit in einigen Fällen wirklich reduzieren. Zum Beispiel beim Spawnen von Wellen von KI-Schiffen oder beim Respawn in einem Hab.
Netzwerk Tech
Zeit & De-Syncs


Die Art und Weise, wie die Engine den Ablauf der Zeit misst, wurde komplett überarbeitet. Die Genauigkeit wurde sowohl bei der Messung der Zeit als auch bei der Synchronisation zwischen Server und Clients verbessert. Die Art und Weise, wie die Engine die Zeit nutzt, um ihre Logik- und Physiksimulation zu aktualisieren, wurde geändert, um Fehler zu beseitigen, die dazu führen konnten, dass die Simulationszeit auf dem Server und den Clients unterschiedlich verlaufen konnte. Viele kleinere Bugs, die dazu führten, dass Zeitfehler auf lang laufenden Servern anwuchsen, wurden ebenfalls behoben. Die Netzwerksynchronisation von Fahrzeugen und Physikobjekten wurde aktualisiert, um den vollen Nutzen aus den Verbesserungen zu ziehen. Das akkumulierte Ergebnis all dieser Änderungen war eine signifikante Reduzierung von Latenz- und Desynchronisationsproblemen in vielen Bereichen, selbst unter harten Testbedingungen für Netzwerk- und Serverleistung. Neben der Verbesserung des allgemeinen Spielerlebnisses war diese Arbeit ein notwendiger Schritt in Richtung Server-Meshing, wo die Simulation des Spiels über mehrere Spielserver Desynchronisationsprobleme aufgrund von Timing-Fehlern verschlimmert hätte.
Autoritäts-API


In Vorbereitung auf das Server Meshing hat das Team die verbleibenden Aufgaben zur Konvertierung des Codes auf die Authority API durchgeführt. In den letzten 12 Monaten gab es eine koordinierte Anstrengung von allen Teams, um den Code der Game-End-Engine auf dieses neue System zu aktualisieren. Dank ihrer Arbeit konnte ein Großteil dieser Aufgaben abgeschlossen werden. Mit einem konzertierten Vorstoß haben wir die Anzahl der verbleibenden Aufgaben auf eine einstellige Zahl reduziert.
Verbindungsfluss


In einem Server Mesh kann sich ein Client während einer Spielsitzung mit vielen verschiedenen Servern verbinden. Ein Teil der Arbeit in Richtung Server Meshing erfordert es, den Prozess der Verbindung eines Clients mit einem Server in verschiedene Phasen zu unterteilen. Diese Phasen können dann unabhängig voneinander ausgeführt werden, ohne dass ein Client seine bestehende Spielsitzung komplett aufgeben muss. Es wurden bereits bedeutende Fortschritte in diese Richtung gemacht, obwohl es noch mehr Arbeit zu tun gibt.
Marco Corbetta
VP der Technologie


Wir sehen uns im 'Verse!
Wir glauben, dass es sehr wertvoll ist, diesen Einblick in unseren Entwicklungsprozess zu geben, vor allem, wenn du die Gedankengänge, Überlegungen und Lehren direkt von unseren Senior-Entwicklern lesen kannst. Wie schon beim letzten Mal erwähnt, haben wir uns zu einer transparenten Entwicklung verpflichtet und werden auch in Zukunft vierteljährliche Patch-Postmortems zur Verfügung stellen.

Alpha 3.12 Postmortem
On December 17, 2020, we launched Alpha 3.12: Assault on Stanton, which introduced a number of new features and changes, including refinery decks, AI improvements, and gas clouds. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. As a side-note, this postmortem specifically focuses on the Alpha 3.12 patch – we will release a separate postmortem Comm-Link focusing on the XenoThreat dynamic event separately. Vehicle Team

What went well
The Vehicle Pillar primarily supported a lot of other teams’ work for Star Citizen Alpha 3.12, particularly with capital ship combat ahead of the Arlington Bounty, CS5 UEE Navy Idris, and XenoThreat events. We worked not just on how the vehicles function and perform (being the largest ships deployed to the servers yet) but also helped deal with the increased lethality of torpedoes with smarter and more effective AI countermeasure usage.
Players also benefitted from this work with the ability to choose the type of countermeasure and how many are fired in a burst, adding greater tactical choice to the act of diverting incoming missiles and torpedoes. We also added further HUD elements to allow players to see how many of each type they have left along with the current burst size.
The last change to countermeasures was an expansion of the Alpha 3.11 changes. This makes each countermeasure type work against all missile seeker types but changes how effective they are depending on the type and number of incoming missiles. Decoys replaced flares as a time-limited point distraction while noise, formerly chaff, became an area-of-effect signal blocker (more countermeasures launched provides a higher chance of spoofing). We also changed the missiles themselves to provide minor variance in their tracking so a successful countermeasure would not divert all missiles equally. In addition to controlling the burst size manually, we added a panic function that empties 25% of available countermeasures in an attempt to overpower a surge of incoming missiles.
What didn’t go so well

We discovered a lot of issues with the missile setup and balance that caused odd behaviors. However, we decided to leave this until missiles are converted to IFCS 2.0 in Alpha 3.13 as it requires a comprehensive ground-up retune of all missile behaviors. In the future, we want to expand countermeasures by giving players better feedback on their own signatures and missile abilities, which will start coming online with Missile Operator Mode.
Vehicle Entry Identification was a much-requested quality-of-life feature (building upon the ASOP Hangar Spawn notifications of Alpha 3.11) that allows players to quickly identify the points of entrance into a ship. These markers update depending on whether the ship is landed or in zero-g, removing a common complaint new players had of being unable to figure out how to get into their ship. Occasionally these displays wildly offset from the vehicle, which we’re looking into, but that was pretty much the only negative issue with the feature and it was generally well-received.
The main content delivery in Alpha 3.12 was the Esperia Talon and Talon Shrike, which are a pair of light fighters that expand the line-up in-game. Generally, these went pretty well and we discussed their development in multiple ISC episodes, including our work on the Hard Surface Shader and iridescent materials.
Unfortunately, a few issues were present at release that we’re aiming to fix in future patches. These include the screen requiring toggling in Arena Commander (also present on the Prowler) and the Talon Shrike’s missile launchers sometimes stopping functioning after a large number have been fired.
John Crewe
Vehicle Director

USPU Gameplay Feature Team
Q4 for the USPU team is always a busy one. Not just for us, but for the entire company. Here’s a brief summary of our more important initiatives that we were able to get into your hands during the quarter. Thankfully, for better or for worse, we didn’t have a massive CitizenCon demo to prepare for this year, but that didn’t stop us from being extremely busy.
International Aerospace Exposition (IAE)
What went well We successfully extended our IAE content into the high-tech art style, which took place at New Babbage on planet microTech. We added several new things to the event this year that tried to cater to comments from the fans. Firstly, we had each manufacturer’s expo hall run for two consecutive days in case fans missed the first and extended the free rental period from one day to two. Hopefully these two things allowed everyone the opportunity to rent the ships they were eager to try. We also had two expo halls running on any given day. This obviously allowed for more things for the players to see and, in the spirit of “more things to see,” we decided to showcase many of our ship components and weapons in the main hall. Between two halls active each day and all the additional items, this was a true testament that our tech is getting more and more optimized as we would never have been able to do that in the past. Finally, to try and extend accessibility, we added a series of rental kiosks into the “Best In Show” hall, which ran for four days. In these kiosks, we put every vehicle that was shown throughout the course of the show and gave the same two-day rental period. Between all of this, we feel it was the most engaging iteration we’ve created to date.
What didn’t go so well We had two vehicles that were introduced to the game at the IAE show that really came down to the wire in terms of their development. Ultimately, this didn’t allow us to lock down the build until a few days before the show. Because this show is open to the public in November, it had to be released as a point-patch to the Alpha 3.11 build. Not being able to lock down the build before we branched to the Alpha 3.12 build caused some file-management headaches. Critical fixes are still being made to the point release and those same fixes also need to be in the newly branched stream content. This inevitably leads to work getting stomped here and there and, at the end of the day, eats valuable time that could be used to fix other bugs or make new things. Also, some things that we intended to keep secret until a bit closer to the time of the event leaked. This was hardly a major issue, but it’s always nice to be able to surprise the fans from time to time.
What we’ll do differently in the future A few things I really want to focus on as we move forward with this event are: Modularity/re-use of assets from previous events. The faster we can make these events happen, the more time we’ll have to focus on new content ideas or other solar systems.

Preproduction planning. We know the event will happen again next November, so I would like to iron out things like the color scheme, event logos, location, etc. as early as possible. This way, when it comes time to work on the content, nobody is waiting for anything to be decided and we can just put our heads down and work.

Get all content for the event into the build so we can avoid requiring a point release. As mentioned above, having two release streams/branches running in parallel is simply asking for trouble.


Reputation System
What went well Another important system that was added in Q4 was the reputation system that we’ve always intended to have. While this isn’t visible to players yet, they are able to experience it through our mission givers and some of our mission chains (the bounty hunter chain is the most notable series that is currently being unlocked by reputation gains). Not every mission has been converted to the new system, though it will be an ongoing process over the next quarter or two. This new reputation system will be the foundation for a significant number of gameplay systems as we move forward. Not only will this be the main way that content is released to players, it will also be tied to things like NPC responses (currently seen in mission givers), perks and benefits that can be earned by participating in content, for tracking player progress through career paths, for dictating relationships between the organizations within the game, and a number of other essential gameplay loops. We felt that this was so important to get into the game that we elected to release it without any player facing UI (which is in progress for Q1/Q2 release). But because this is going to be so ingrained in a significant number of systems moving forward, we felt it was worth the sacrifice. Not only will it be represented in a standalone reputation UI that will allow players to view their career tracks with various organizations, it will also track the key NPCs they have interacted with along with their current standing with each. Reputations will be exposed in this UI as they come across them in the universe so that it encourages players to travel around and engage with the content to expose them. Additionally, we will be revamping the Mission Manager to include player visibility as to what sort of reputation requirements they need to acquire missions. Reputation is going to be one of the largest progression mechanics that Star Citizen will have going for it outside of the economy since we are a skill-based sandbox game not driven by “leveling” or “talent tree” systems. Reputation is now service-driven on the backend as well. This means that all reputation gains can be preserved between patches, which will be a great thing for the players.
What didn’t go so well As far as general development of this feature, it went quite smoothly once we got to dig our heels into it. We had started work on it about a year prior to this but unfortunately got pulled onto some higher priority stuff at the time. If I had it to do over, I would have kept the team on this until it was done and had the desired UI/UX changes to go along with it. Not having the UI in place with its release, while not game-breaking, is a critical piece of this feature. Ensuring that all our features are intuitive often relies on this type of visual feedback.
What we’ll do differently in the future Moving forward, I would like to try and budget the required time to release a more “complete” feature. While it’s not always possible to convert all of a game’s existing content over to new systems like this, I would like to try and make sure we can do more when big changes like these happen in the future. I was happy that we got more than the original intention into place but would have loved to get more time with the Mission Team to help convert even more than we did. The next time something as foundational as this comes up, I would like to personally do a better job of raising global awareness across the company so we can convert as much of it as possible. Front End Conversion to Building Blocks
What went well We were able to convert the initial two screens in the frontend to utilize our Building Blocks tech. In general, I think this process went fairly well. It didn’t require a ton of people and was a fairly self-contained bit of work. We also got the opportunity to fix a few things that we wanted to address since adding the “new friends” service back in Q1 2020. Switching this over to our new UI system also allowed us to fade all of the UI elements together. Going through this process gave us some time to critically think through the frontend since the project has evolved so much over the last few years. We also set it up so that the current solution can scale up as we add more solar systems. We cleaned up the main screen so that we can have a greater view of the background images. I’m happy that we were able to attribute a different image for each possible landing zone; I think it really helps give new players a sense of what type of location they’re choosing.
What didn’t go so well The frontend is very ingrained with the original CryEngine toolset that we originally started with. The Building Blocks system works based on entities, which means that our core data needs to be loaded so that we have an entity to run the canvas on. On top of that, the original system requires a level to be loaded. Because of this, we were not able to replace any elements prior to selecting what game mode players want to play (at least not with Building-Blocks-based tech/implementation). The ultimate solution is to completely rework this code base but that was way outside the scope of what we were able to deal with, nor was it our main directive here.
What we’ll do differently in the future The bottom line here is that the game that we based our original frontend on is much different from the game that we are building towards today. I’m not sure how much the USPU Team will be changing the frontend in the future, but the next time we make changes here I’d really like to be working towards the final vision. This would allow us to really streamline the new user experience so that getting into the game for the first time, or back into the game for returning players, is as simple and intuitive as possible. Because we have been bolting on new features one at a time, this part of the game has suffered as a result. If this can be redefined from the ground up, there’s a lot that we’d do differently based on how much the game has evolved.
Rob Reininger
Lead System Designer and USPU Product Owner

Systemic Services & Tools Team
What went well The Systemic Services and Tools (SST) Team continued working on the Quantum simulation and integrating it into services alongside internal presentations of new technology that we’re excited to share with the community soon.
Administrative work occurred last quarter to shift around internal CIG resources for SST. The team will be increasing in size to accommodate the growing need for services and support for Quantum across many aspects of the game.
Outside of services and simulation work, SST created new tools to support the upcoming reputation system and the way reputation is distributed across the game universe. SST continues to support the Star Citizen economy with Data Tools to help alleviate the massive amount of data while we prepare for Quantum to take the reins.
What didn’t go so well As we transition into a larger department, we had some growing pains with our response times to other teams. Features like the refinery service didn’t get the immediate attention they needed while our attention was elsewhere.
What we’ll do differently in the future We’re looking for ways to better streamline and distribute the work coming into SST for the growing team. In addition, we’ve set up automated messaging to supplement the communication coming out of SST to dependent teams.
Jake Muehle
Senior Technical Designer

Design Team
AI Intercepting Torpedoes
What went well Turrets on the Idris intercepting torpedoes works well, and it creates some very cool moments when they successfully intercept.
What didn’t go so well AI accuracy is not good enough to reliably shoot down incoming torpedoes depending on server framerate.
What we’ll do differently in the future We will look to improve the AI accuracy so we can have greater control over how many torpedoes slip through turret defenses.
AI Fire Mode Usage and Targeting Priorities
What went well The AI using burst-fire greatly improves the look of AI turret fire. Plus, the targeting priorities ensure that the AI are attacking a sensible target for their ship class/turret size.
What didn’t go so well At the minute, using burst-fire puts the AI at a disadvantage compared to the players as fully automatic firing increases damage.
What we’ll do differently in the future We will rebalance AI burst-firing when capacitors are introduced to reduce the effectiveness of holding down the fire button.
AI Accuracy Convergence
What went well The new accuracy system acts in a more believable manner as it tracks the target’s position and continues to fire at that position until the target moves. This is preferable to the old system where the AI’s aim would swing wildly as it attempted to miss stationary targets in front of it.
What didn’t go so well The AI is not accurate enough to pose a decent level of threat to the player at the minute. And, the new system tends to miss behind the target’s movement instead of in front, so the players don’t see that they are being shot at as much.
What we’ll do differently in the future We want to improve the accuracy overall and make it so different NPCs have a more noticeable accuracy difference between skilled and unskilled AI. The accuracy system will also be iterated upon to make it overshoot as opposed to undershoot the target more often.
Capital Ship Combat Behavior
What went well The capital ships now put a good amount of consideration into distance and relative position when engaging other ships. Capital ships without frontal guns will attempt to get in close enough to utilize all of their turrets, while those with large frontal guns will attempt to keep out of the enemy’s range and utilize their powerful long-ranged weapons.
What didn’t go so well The tactic selection doesn’t consider the AI ship’s strength relative to the target enough. For example, when the Idris is fighting a gunship or capital ship, it will attempt to stay at a distance and use its railgun. This often makes sense but can lead to it running away from smaller gunships that it could easily take in a close-range slap fight.
What we’ll do differently in the future We will iterate on the tactic selection so the AI consider their own ship and target in more detail than just the ship class. Also, we will want to allow pilot character traits to affect the capital ship behavior as well.
Elevator Panels
What went well We successfully laid the groundwork for future elevator panels (and other re-styleable screens), making them inherit their styles from the transit system and be usable on any shaped canvas. This means all future panels can use the same two files but still look different.
What didn’t go so well The transit system is very difficult to set up and test in its current form – the UI Team were unable to get it working properly and had to rely on Level Design to implement. However, UI and Level Design didn’t work on the feature at the same time, resulting in work starting and stopping in different streams and bugs getting missed. New Building Blocks styles are extremely time-consuming to implement due to a lack of tools and an inability to merge files.
What we’ll do differently in the future We’ll make sure that the feature is developed, implemented, and tested in one go in a feature stream so that bugs are picked up and fixed before it’s “finished.” We’ll also make sure the team that owns the feature has time to fix code issues as part of the feature development cycle and have the UI Team focus on the UI.
Station Based Refining
What went well We finished the initial gameplay loop for refining, complete with refineries having their own material specializations, workloads, and the ability to refine, collect, and sell refined materials at various places across the galaxy. The refinery decks themselves look spectacular and the UI for the refinery terminal itself is in a great place to expand upon the gameplay loop with very little in the way of reworking things, which should mean quicker iteration down the line.
What didn’t go so well Our planning for every step was extremely thorough, however, due to several situations out of our control, we were unable to reach a point early enough where we could balance the refinery loop the way we intended to. So, we brought forward another already-intended set of changes in the form of the initial mining rebalance to compensate as best we could until we can get the refinery balance to the level we originally wanted. This mining rebalance had the added bonus that it made the MISC Prospector a bit more appealing for people to start out with or rent as well as providing more gameplay experiences for the Argo MOLE or multiple players with Prospectors.
What we’ll do differently in the future Get the UI art play-tested earlier. Some players didn’t know what parts of the screen they could interact with and this would have allowed us to have more time to make changes.
Mining UI Refactor
What went well We reworked the entire mining UI to work with Building Blocks. This went a lot smoother than any of us could have ever hoped as a lot of the mining gameplay loop setup actually worked with Building Blocks straight out of the box without much reworking at all. This gave us leeway to add more to the mining UI than we originally intended to, meaning we were able to not only provide an entirely new UI that’s scalable across three different mining vehicles, but we showed off that scalability by quickly iterating on UI canvas pieces to support previously introduced systems. This included volatile cargo and added an entirely new cargo hold piece that further provides players with information we always wanted to provide but never had the ability to do so.

What didn’t go so well The initial pass of the mining UI refactor was trickier to implement than it was to build, with different vehicles having different spaces available to them for the UI, meaning that a lot of behind-the-scenes tweaking was required to actually display the UI in a comfortable way. This is still being fine-tuned and, with future tech coming soon, we hope to broadcast the UI in a slightly more visually appealing way that works better than the current implementation.
What we’ll do differently in the future We’ll iterate more quickly in the future on things like this as we now have a firmer understanding of Building Blocks and its benefits.
Todd Papy
Star Citizen Live Director

Core Gameplay Pillar
Multi-Tool Tractor Beam
The Multi-Tool Tractor Beam is an exciting addition to the ‘verse and is a core piece of functionality that unlocks several gameplay loops that we are working on, such as cargo hauling and EVA traversal spaces. The main use-case for the Tractor Beam in Alpha 3.12 is to allow for easier collection of cargo boxes in EVA either during lost in space missions or for the collection of post-ship-combat loot. While on the surface the Tractor Beam is a point-and-shoot tool, under the hood a lot is going on, and I think the team did a fantastic job of creating a truly systemic feature that is accessible and easy to use.
The first challenge that we faced is that we wanted it to work in several different gravity settings and to utilize the weight of an object. This led to several issues, as in zero-g everything is weightless, so it meant that you could potentially move something huge that weighed very little. For example, a planet-sized polystyrene ball. We designed the Tractor Beam around two core concepts – volume and force. Volume dictates the general size of the object you can lift while force dictates the amount of effort the gun needs to apply to lift the object. This means that for any item that has a mass and physics collider (which every item should already have), the force required to lift it is automatically calculated using the environment’s gravity. This allowed us to build a feature that works with any physics object in the game without having to do lots of manual set up.
The second challenge was how do we explain to the player what they can and cannot lift without having to ADS on everything or even worse, use trial and error. Fortunately, the Multi-Tool already has a small screen on the back that allowed us to implement some simple iconography alongside a traffic light color-coding system. This means that we’re able to clearly show all five states of an object by just looking at it: Object can be lifted

Object can be lifted but is out of range

Object is too heavy

Object can never be lifted

You will travel to the object

While we did provide additional information in the ADS view, everything that you need to know is on the back of the tool and I was really pleased we were able to distill so much information into such a small screen.
What didn’t go so well When planning any feature, you want to identify the core experience and then outline any secondary mechanics that would enhance that experience. For example, a jump mechanic by itself is a standalone feature, but you may decide that in-air control (a secondary mechanic) enhances that core experience. With the Tractor Beam, we sat down and identified the core experience of being able to manipulate objects and use it as a grapple hook in EVA, and I feel we delivered on this. But there were some secondary mechanics that I would have liked to ship that we ran out of time to deliver. Specifically, allowing the manipulation of your trajectory using your suit thrusters when using the grapple hook functionality in zero-G.
Unfortunately, the two systems did not really work well together, with the force used to pull you along overriding any force used by the suit thrusters. It also didn’t help that EVA was also being moved over to using IFCS at the same time and this led to us having to make a priority call to focus on the core experience and make sure that was as polished as can be for release. This happens all the time with features and is the nature of game development, but it was a shame it missed the first iteration. We will add this functionality in a later release.
What we’ll do differently in the future Delivering a feature for release requires lots of different teams coordinating together, from VFX to Audio to the feature team working on the functionality. One of the biggest things I am trying to improve upon is to give the mission designers more time to allow them to integrate all of these different features into the ‘verse in a meaningful way. If you have read my previous postmortems, you will probably see a trend that this is something I am actively trying to improve, but as multiple teams and schedules are involved, it takes a little bit of time to readjust. If I could go back in time, I would probably have tried to get a simple version into the hands of the mission/level designers sooner so they could have played with it a little bit more.
Weapon Zeroing
What went well Weapon zeroing, as the title suggests, allows you to zero weapons to different ranges, allowing you to shoot accurately at much further distances. This means the scope considers the fall-off of the bullet at a specific range and allows you to adjust the sight so you can still aim your reticule at the target. I.e. you don’t have to aim above the target. We already have lots of scopes available and the first challenge was deciding which scopes should zero at all and then deciding whether they should auto-zero or manually-zero. This led to a much wider discussion surrounding manufacturers and their specific traits, such as high-tech or low-tech. While the team could have just focussed on the feature and pushed it out, they have also delivered a long-term plan for the scope attachments for not just current manufacturers but future ones as well.
This is something that I fundamentally believe in – that even though we are working on a live product, we should be making decisions around the final experience in the released game. Sometimes that’s hard as it can mean that certain features are not seen in their best light on first inspection or misunderstood in the short-term by the players. But it’s my job to make sure we are working towards the final vision and the team did a fantastic job of providing a feature that is fun to use but scalable in the future.
What didn’t go so well This was the first feature one of our newest team members worked on. As such, we made sure he had plenty of time to deliver it way before the actual release. In fact, the functionality (not the visuals) was delivered the quarter before and he did a great job. Now, in most cases, this is fantastic as it means we can focus on the experience and make sure it’s of the highest quality. In this case though, due to other priorities and this being done so far ahead of the release, it did not get the full focus of the testing team as they were (rightfully) busy checking things going imminently live. Unfortunately, this meant a fundamental edge case was missed until just before the release, which was that zeroing did not work when the physics patches for the environment streamed out.
Let me explain. When a character spawns on a planet a series of patches (squares) spawn around them in ever-increasing sizes. These patches cover the render (graphics) quality and the physics collision, with patches further away having less detail and eventually no collision (as physics is relatively expensive). Now, when you move around, the patches dynamically update but it’s not one-to-one. So, a patch you might have just been in may still have its collision as you may want to go back there and it’s more performant to keep it there in the short-term than to keep loading and unloading it. In this case though, it meant when a designer loaded into the editor to test the feature, the patch was loaded and then they moved 2 km away to test weapon zeroing and it worked. Though if a player had never gone to the original position there would be no collision and so the scope would have nothing to test against. This meant in normal game conditions it didn’t work as intended, so we had to reauthor the weapon zeroing code to test against the render geometry instead of the physics one. While this change was not major, it was not ideal as we had planned to work on other features.
What we’ll do differently in the future If I could go back in time, I would most definitely make sure that the feature had been thoroughly tested when it was completed rather than wait for the more traditional go/no go. While it didn’t affect the feature’s release, it did have knock-on effects for future work as we had to reprioritize during the quarter.
Gemini A03 Sniper Rifle & Behring FS-9 LMG
What went well As with every weapon we add to the game, we must always make sure it fits into the existing weapons’ matrix and offers something unique that doesn’t already exist. With the Gemini A03 sniper rifle, the intention was to make a lightweight, responsive marksman rifle with a lower caliber than its heavier counterparts but high speed and accuracy. I think the team really delivered on that intention and struck a good balance between the high-caliber sniper rifles like the P6-LR and the more assault-orientated weapons like the Gemini S71. While the A03 was a simple addition, the Behring FS-9 was a bit trickier. LMGs as a weapon category are not in a great place right now as they are outgunned by SMG/shotguns at close range and outmatched by assault rifles at mid-to-long range. This is something we are acutely aware of and have been working behind the scenes to improve. The Behring FS-9 sets the standard for what we want LMGs to be – high-capacity machineguns that allow players to suppress an area without a huge loss of accuracy.
What didn’t go so well While we were working on the FS-9, we were also working out the design intentions for all the other LMGs so we could deliver an update across the board in one release. Unfortunately, we ran out of time on the existing weapons, although we did manage to do some tweaks to raise their effectiveness. We do plan on updating the existing LMGs to raise them to the same quality bar as the FS-9, but it does mean in the short term it’s vastly superior to the other weapons in the same category. But as I mentioned above, I will always prioritize decisions around what we want the end goal to be so that we are constantly moving forward.
What we’ll do differently in the future We have a plan to overhaul all the weapon categories and hopefully you can see that each weapon we release slightly improves on those that came before it. With this intention, I would have added more time to polish the existing LMGs as I would have liked to release them all together. No matter how experienced you are, you are always learning and this is something I will be implementing for future weapons.
Richard Tyrer
Core Gameplay Director

Locations
Space Station Refinery Decks
What went well For this release, we were able to introduce refinery decks to some specific space station locations. These spaces are themed around the mining and refining gameplay loops and also serve as a location for future gameplay opportunities. Inside the refinery deck, we created a space specific for refining and processing along with a shop and guild space below.
After seeing the response to the cargo decks and the new space station interiors in Alpha 3.11, we agreed with the comments about players wanting to see more of a visible connection with the exterior to physically understand where they are in the station. Even though we were quite far through developing the refinery deck interior, we pivoted and adapted the space to include the mini viewing deck by the elevator lobbies. Visually, we had wanted to explore a space station experience more focused towards industrial activity for some time, including the global composition of the station to the hot and noisy interior.
What didn’t go so well It was a shame not to see specific NPC loadouts release with the refinery decks or be able to expand some of the specific usables. However, these are all planned so hopefully we will see them come online soon.
What we’ll do differently in the future As mentioned above, we introduced the viewing deck quite late in the process, so we could have designed a superior space with this in mind during concept and whiteboxing.
Stanton Planet Improvements & Polish
What went well Continuing to build on the planetary improvements made throughout 2020, this was the first opportunity the team had to introduce the new and improved workflows developed when creating Pyro’s planets and moons to Stanton.
Improvement to the workflow included having the time and focus to go deeper on the global painting process. For planets like Stanton I and IV, the global painting was completely redone to be both more accurate to temperature parameters and to have a better blend and distribution of hues. As a second part to the painting, all object presents and distribution rulesets were done from scratch. In general, the focus was to do more with less. So, rather than use many types of geology all in the same space, just use one or two that work really well together. The end result is something much more realistic and natural. A good example of this is on Daymar. Another area we wanted to improve was the increased use of ground scatter objects to complexify the terrain read. We combined a mixture of geology assets like plates, scree, and small rocks with the distribution of the geology packs to give a much more integrated read to the scene.
Additionally, some outstanding geology packs were converted to use the organics shader and were processed correctly through Houdini as part of our pipeline.
Some new tech features came online during this release that we were excited to take advantage of, the first being terrain displacement which replaces POM. So, now you can actually see the terrain geometry get tessellated and displaced giving actual depth and more complex intersections with objects. The second feature is biome accumulation, which means assets can procedurally receive a thin layer of material on their top surface depending on the biome. For example, sand gathering on the top of the rocks on Daymar.
What didn’t go so well As we were trying to close out the year and hit the Alpha 3.12 release, some moons were not able to be taken to the polish level we wanted. Also, as part of introducing our new workflows and methodology to the Stanton system, we noticed the visual styles between some moons are becoming too close together and we’re losing some diversity.
What we’ll do differently in the future More assets will help reduce art fatigue and improve visual diversity, so moving into this year, we’re investing time and energy into more asset packs.
Stanton System Spacescaping
What went well We were all really excited to be able to showcase the gas cloud tech as part of the PU in Alpha 3.12. Lots of hard work was done by many teams to create this new feature, so the process was about establishing a team dedicated to creating content for Stanton, and then starting to look at what we could do for the Lagrange points.
Considering this was the first release version of the tech, I feel we created a variety of visual scenarios to show the potential of the tech.
What didn’t go so well As this was the first release, there was obviously a lot to figure out in terms of performance, and there is a great deal we can do in terms of pipeline refinement. There is also some visible noise in some lighting scenarios that we would like to reduce in the future as performance allows.
What we’ll do differently in the future We are already improving our development workflow and looking at ways to improve the process. We are exploring how we can tie together the background spacescape into more mini-system-based forms, which then leads to smaller, volumetric gas pockets. For future gameplay opportunities, we’re looking at encouraging risk/reward gameplay inside the gas pockets with elements like lightning, radiation, temperature ranges, and flight handling.
Ian Leyland
Star Citizen Art Director

Technology
For Alpha 3.12, the Graphics Team mainly focussed on improving stability and fixing bugs with the various graphics features utilized in the release. Many of the bug fixes related to the introduction of gas clouds, such as fixing a visible dither pattern when the sun is obscured by a cloud and preventing gas clouds and particles from clipping inside spaceships by improving both the volumetric culling and particle culling systems. Such issues were expected but largely unavoidable because, although the tech has been used extensively in the development of SQ42, the artwork and scenarios are quite different in the PU. Plus, the sandbox nature of the PU and extensive testing it receives meant many previously unknown issues were discovered or raised in priority.
The team also managed to resolve dozens of other bugs ranging from popping shadows to over-bright camera exposure when a planet is streamed in. The proportion of time spent bug-fixing compared to new features was higher than we’d have ideally liked, but there’s always an emphasis on stability and quality at the end of the year and feature work has already resumed, so this is not of concern. Despite the slowdown in feature work, we did manage to maintain good progress on the new Gen12 renderer, which will be our primary focus for early 2021.
The Physics Team worked on the volumetric soft body prototype as well as the related rendering of volumetric deformation. Moreover, various optimizations were done in physics. For example, we improved the threading of various subsystems, added faster spatial grid queries, removed contention accessing local command queue, and removed contention for actor/living entities step functions (improving the living entity step performance by a factor of 2x – 5x). We also implemented a better way to pre-physicalize the planet terrain patches used for collision checks. With regard to collision detection, we also fixed a longstanding issue that could introduce additional ghost contacts far off from where the actual contacts were being processed. Furthermore, improvements were made to event queueing. The first draft of propagating physicalized shockwaves was submitted and box-shaped physics grids and bullet drag were added. SDF support was improved and research started on improvements to the setup of touch bending vegetation.
On the renderer, we continued with our ongoing Gen12 transition and related refactoring. For instance, we added a parameterizable feature set for the deferred pipeline, implemented per-object resource set updates (including RTT update for brushes) for Gen12 scene-rendering and legacy pipeline state caching (to save DX API calls while we’re still fully transitioning to Gen12). In the shader system, we cleaned up all shader reloading code, which will improve shader editing during development and give a much-improved response when changing system spec settings (e.g. graphics settings that require the use of different shader combinations). We also started a larger refactor of the shader cache backend system as it’s quite outdated and a constant source of grief with regards to maintenance and Gen12 fitness. Several optimizations were done in the renderer code. For instance, the way material constants are uploaded to the GPU was simplified and optimized.
On the graphics side, various fixes for depth-of-field were provided. The hair shader received several improvements, such as the ability to disable specular highlights on eyelashes, improved boundary occlusion at hairlines, support for ambient lights in forward shading, as well as improved hair quality during camera cuts. Dual lobe approximation for the skin shader was improved and the eye shader received a couple of improvements as well. As far as atmospheres, clouds, and the unified raymarcher go, the improvements mentioned in the previous postmortem are now available in Alpha 3.12. With that out of the way, most of the time was focused on volumetric cloud rendering. The initial draft of the cloud renderer was implemented and work on volumetric cloud shadows made good progress. Work will commence on improvements to local cloud shaping. Note that there’s still quite a lot of work to be done before release.
For the core engine system, we implemented a dynamic zone culling path in the zone system. We also fixed a few view distance-related culling bugs to do with pixel-sized objects that went into Alpha 3.11. People have already noticed that they can now see players over 1000 meters away instead of just a few hundred or so. A lot of bug fixes and improvements were provided for vis-areas, such as a fix for streaming meshes for animated vis-areas and the ability to add vis areas to CGA joints. The entity system received several improvements and optimizations to avoid unnecessary updates and searches. Similarly, the entity aggregate manager received low-level optimizations to improve work balancing and reduce memory use and contention when working with entity bubbles. There were also a few smaller improvements made to the entity component update scheduler. Radix tree culling logic has been improved, with its threading logic adjusted to reduce contention and SIMD culling implemented to check up to four bubbles vs objects per node. With regards to performance, progress continues on the engine profiler, which saw a lot of enhancements. Work on a real-time sampling profiler based on event traces will commence soon. Various optimizations were implemented in the entity system, component updates, and zone system. Based on telemetry from the PU and PTU, we continued our ongoing investigations into memory usage. As such, the engine-wide memory allocator and memory tracking system, including its toolchain, was substantially refactored and improved. To provide an additional performance boost to our servers, the Linux DGS was switched to a monolithic executable to allow the compiler to generate better code (thread local storage access in particular). As part of our initiative to build a performance regression system, we added a stress test for object container streaming too.
Regarding crash-handling, we now capture a hex stack of the render thread and embed it in mini-dumps that you (optionally) send to us in case the game crashes. This allows us to recover the full render thread call stack during postmortem debugging without the need for third-party binaries (that might be part of call stack or the video driver) to fully unwind the stack. This saves quite a bit of time as we don’t have to download the various drivers that players use.
On the animation side, we fixed code so that character blend shapes and the dynamic lighting rig don’t switch too late at every camera cut when rendering cutscenes.
Lastly, C++ 14 support was enabled for the entirety of the client server editor and relevant tool projects.
Online Tech
Load Balancing Test Framework The pestilence warmer for Alpha 3.12 received major updates. First and foremost, the warmer now uses the new JWT identification system that allows it to fetch many tokens for impersonation purposes very rapidly. This has 10x the throughput of warmer instances we can run at the same time.
A major subsystem was added that enables the warmer to connect as a service to the diffusion gateway allowing for executing load scenarios that coordinate both as a client connected through the hub and as a service on the diffusion network.
Backend Concurrency Improvements We were able to increase the performance of the variable service, loadouts, and the main persistence cache service. The stability of the backend increased greatly, surpassing the performance and reliability that we had in previous releases. Our low-level networking code was updated to improve both performance, scalability, and robustness. We also made several fixes and optimizations to the transaction service, rentals, and our entitlement processor.
Unified and Centralized Logging With our new unified centralized logging system, all services send formatted JSON messages to a centralized Elasticsearch database. Each log event is tagged and dynamic data such as account IDs, player IDs, etc. are extracted into named fields, which makes searching for events or specific fields – such as an “AccountID” – very efficient. This allows the devs to easily access logs from a centralized place and track complex messages and events happening between multiple services.
Persistent Tech
Entity Creation & Spawn Decoupling In preparation for persistent streaming, the entity creation process was decoupled from entity spawning. This allows us to “seed” the initial state of the universe into the persistent database by creating all dynamic entities prior to simulation. DGS processes will then stream persistent entities (spawn/despawn) from that database during simulation. This is an important steppingstone for a fully persistent universe.
Parallel Spawn Queues As an optimization, we introduced multiple parallel spawn queues on each game server. This allows us to spawn multiple distinct locations (such as Lorville and New Babbage) in parallel on separate threads on the same server. Previous releases had a single queue and therefore (in this example) we wouldn’t start on New Babbage until Lorville was fully spawned. On busy servers, this can really reduce the wait time in some cases. For example, when spawning waves of AI ships or respawning in a hab.
Network Tech
Time & De-Syncs How the engine measures the passage of time underwent a complete overhaul. Accuracy was improved both in the measurement of time and in its synchronization between server and clients. How the engine uses time to update its logic and physics simulation was changed to eliminate errors that could result in simulation time passing differently on the server and clients. Many smaller bugs that had caused timing errors to grow on long-running servers were also fixed. The network synchronization of vehicles and physics objects were updated to take full advantage of the improvements. The accumulated result of all these changes was a significant reduction in latency and desynchronization issues in many areas, even under harsh test conditions for network and server performance. Besides improving the overall player experience, this work was a necessary step towards server meshing, where simulating the game across multiple game servers would have made desynchronization issues due to timing errors worse.
Authority API In preparation for server meshing, the team performed a sweep on the remaining tasks to convert code to the Authority API. Over the last 12 months, there has been a coordinated effort by all teams to update the game-end engine code to this new system. Thanks to their work, a large majority of these tasks have been completed. With a concerted push, we’ve reduced the number of remaining tasks into single digits.
Connection Flow In a server mesh, a client may connect to many different servers during a game session. Part of the work towards server meshing requires separating the process of connecting a client to a server into distinct stages. These stages can then be executed independently without requiring a client to completely abandon its existing game session. Significant progress has been made towards this although there is more work to be done.
Marco Corbetta
VP of Technology


See you in the ‘Verse!
We believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we’re committed to transparent development and will continue to provide quarterly patch postmortems going forward.