Alpha 3.13 & Invictus Launch Week Postmortem

Alpha 3.13 & Invictus Launch Woche Postmortem
21.07.2021 - 9:00 UHR

Am 22. April 2021 starteten wir die Alpha 3.13: Underground Infamy, die eine Reihe von neuen Features und Änderungen einführte, darunter das Andocken von Schiff zu Schiff, zusätzliche Höhleneingänge und den Reputationsmanager. Der folgende Postmortem stammt von den leitenden Entwicklern selbst und beschreibt detailliert, was geliefert wurde und was sie darüber denken, wie es gelaufen ist. Nebenbei bemerkt, konzentriert sich dieser Postmortem sowohl auf den Alpha 3.13 Patch als auch auf das Invictus Launch Week Event.

Fahrzeug-Säule
John Crewe, Fahrzeug-Direktor

Für Star Citizen Alpha 3.13 lieferte die Vehicle Pillar eine Mischung aus neuen Features, der Grundlage für zukünftige Initiativen und unserem üblichen Content Drop.

Merlin/Constellation Docking
Was ist gut gelaufen?
Wir haben erfolgreich ein lang erwartetes Feature für eines der kultigsten Schiffe von Star Citizen geliefert. Obwohl wir das Ziel hatten, dies in Alpha 3.12 zu tun, hat sich die Entscheidung, ein zusätzliches Vierteljahr für den Feinschliff zu verwenden, bei der Veröffentlichung ausgezahlt, da es viel stabiler und umfangreicher war als ursprünglich geplant.

Was ist nicht so gut gelaufen?
Die Entscheidung, XenoThreat bis ins Jahr 2021 zu verschieben, bedeutete, dass wir länger als erwartet mit der Fehlerbehebung für das Event beschäftigt waren, was unsere Möglichkeiten einschränkte, auf Probleme mit dem Feature zu reagieren, bevor es an Evocati zum Testen ging.

Was wir in Zukunft anders machen werden
Im Großen und Ganzen verlief der Feature-Prozess gut, so dass es abgesehen von mehr Tests zu einem früheren Zeitpunkt nicht viel gibt, was wir in Zukunft verbessern werden.



Fahrzeugnamen/Seriennummern
Was ist gut gelaufen?
Die Möglichkeit, dein Schiff zu personalisieren, ist ein lang ersehntes Feature und etwas, das wir schon lange liefern wollten, aber wir hatten ein paar technische Probleme hinter den Kulissen, die wir in Bezug auf das Rendering und den Fluss von Plattform zu Spielberechtigung lösen mussten. Die Auslieferung einer kleinen Auswahl von Schiffen hat die Technik getestet und uns geholfen, die Grenzen des Systems besser zu verstehen.

Was ist nicht so gut gelaufen?
Das mit Abstand größte Problem war die Lesbarkeit, vor allem bei kürzeren Namen, bei denen die Schriftgröße die gleiche blieb wie bei einem maximal 32 Zeichen langen Namen. Ein kurzer Name in Kombination mit der nicht ganz so idealen Außenbeleuchtung des Schiffes und der Unmöglichkeit, die Textfarbe anzupassen, führte zu einigen großen Problemen bei der Lesbarkeit.

Was wir in Zukunft anders machen werden
Wir arbeiten mit den Grafik- und UI-Teams an einer besseren Implementierung über Building Blocks, damit wir die Schriftgröße dynamisch basierend auf der Länge des eingegebenen Strings ändern können. Ein optimiertes UV-Layout wird erstellt, um dies zu berücksichtigen. Auch das Farbsystem wird in Zukunft überarbeitet, um den Spielern die Möglichkeit zu geben, die Farbe des Namens zu wählen, um Überschneidungen zu vermeiden.


Visuelle Verschlechterung des Rumpfes
Was ist gut gelaufen?
Seit Star Citizen Alpha 3.6, als wir die Degradierung von Gegenständen und Fehlzündungen eingeführt haben, fehlte der große Teil, dass der Rumpf deines Schiffes zusammen mit den anderen Gegenständen visuell degradiert. Jetzt, wo wir dies vervollständigt haben, kannst du den Zustand deines Schiffes anhand der visuellen Darstellung des Rumpfes besser einschätzen, als wenn du auf MFD-Jagd gehen müsstest. Das System fügt sich in unsere bestehende Produktionspipeline für Fahrzeuge ein, sodass wir nicht zurückgehen und es zu allen Schiffen hinzufügen mussten, was die Implementierung viel schneller machte.

Was ist nicht so gut gelaufen?
Es gab eine ganze Reihe von Schiffen, die bei unseren internen Testdurchläufen übersehen wurden, was dazu führte, dass der Baldachin komplett "überkratzte" und die Sicht versperrte. Das war nicht unsere Absicht - das Ziel war es, die Abnutzung auf den Rand der Sicht zu beschränken.

Während die eigentliche Inhaltsseite Teil unserer Pipeline war, war es nicht leicht zu visualisieren, so dass das Content Team zurückgehen und die Abnutzungskarten und Einstellungen auf älteren Schiffen manuell anpassen musste.

Was wir in Zukunft anders machen werden
Wie bereits erwähnt, verschleißen einige Schiffe in Schlüsselbereichen dramatisch zu stark, was von Fall zu Fall behoben wird. In Zukunft wird der physische Schaden nicht mehr nur ein rein visuelles Feature sein, sondern auch strukturelle und spielerische Konsequenzen haben.



Schiff-an-Station-Andocken
Obwohl offiziell nicht Teil der Alpha 3.13, haben wir dieses Feature tatsächlich mit dem Patch eingeführt, wenn auch deaktiviert, um mit 3.13.1 (Invictus Launch Week) online zu gehen. Ursprünglich wollten wir beide Features mit demselben Patch ausliefern, aber wir haben uns entschieden, es offiziell zurückzuhalten, aus den gleichen Gründen, aus denen wir das Andocken von Connie und Merlin zurückgehalten haben - um die Qualität der Veröffentlichung zu verbessern.



Tumbril Cyclone MT
Der Cyclone MT war ein überraschendes Fahrzeug, an dem wir während der Downtime zwischen den Veröffentlichungen gearbeitet haben, um unser Angebot an Bodenfahrzeugen zu erweitern, insbesondere für Theaters of War.

Die Herausforderung, einen montierten Turm zu haben, der sowohl Raketen als auch Waffen steuert, verursachte einige Kopfkratzer in der Setup-Phase, aber der MT bietet eine interessante Feuerkraft-Ergänzung der Cyclone-Reihe auf Kosten des langsamsten Fahrzeugs der Familie.



Greycat ROC-DS
Der ROC-DS war ein Fahrzeug, das sowohl bei der Entwicklung als auch bei der Veröffentlichung zu kämpfen hatte, da er ursprünglich als primäres Fahrzeug der Familie konzipiert war. Aufgrund der Produktionszeiten mussten wir jedoch den ROC deutlich vor dem ROC-DS veröffentlichen. Das ursprüngliche Ziel war es, beide zusammen zu veröffentlichen, um den Spielern klarere Optionen zu bieten, aber der große zeitliche Abstand zwischen den beiden Fahrzeugen hat die Wahrnehmung der Rolle und des Nutzens des ROC nur noch verstärkt.

Während der Evocati- und der PTU-Phase erhielt der ROC-DS zwar einige kräftige Upgrades, die sowohl seine Kapazität als auch seine Reichweite erhöhten, aber diese Ziele wurden zu Beginn des Release-Zyklus nicht gut genug kommuniziert, sodass der ROC-DS mehr leiden musste als erwartet. Der ROC-DS sollte nie ein klares Upgrade des ROC sein, sondern ein Begleiter, der es zwei Spielern ermöglicht, an anspruchsvolleren Orten, die weiter von der Basis entfernt sind, zusammenzuarbeiten.

Es befindet sich derzeit in einer schlechten Position, aber zukünftige Änderungen am Inventarverhalten, dem Frachtsystem und den Höhlen-Setups werden es vielleicht wieder in die Position bringen, die wir ihm zugedacht haben. Sollte dies nicht der Fall sein, werden wir weitere Änderungen vornehmen, um seine Akzeptanz zu verbessern.

Live Säule
Todd Papy, Star Citizen Live Direktor

EUPU: Bergbau Sub-Komponenten
Was ist gut gelaufen?
Wir haben das Mining-Gameplay weiter vertieft und erweitert und die Sub-Komponenten ziemlich reibungslos zum Laufen gebracht. Der Quality Assurance Test Request (QATR) Prozess verlief ebenfalls gut, mit einer großartigen Kommunikation im Team.

Was ist nicht so gut gelaufen?
Die Stabilität der Spielentwicklung war schlecht, was zu Verzögerungen bei der Erstellung aktueller Builds mit Integrationen führte.

Was wir in Zukunft anders machen werden
Das Team erstellt QATRs, um ihre Arbeit in die Spielentwicklung zu integrieren, was ein normaler Prozess ist. Unglücklicherweise war die QA mit den beiden großen Releases Alpha 3.13 und 3.13.1 super beschäftigt. Dies beeinträchtigt derzeit die Effizienz des QATR-Prozesses, was dazu führt, dass Sprint-Integrationen von nicht kommenden Releases stark verzögert werden.



Live Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries
Was lief gut?
Die Mission verlief reibungslos, da sie auf bestehende Technologien zurückgriff, von denen ein Großteil für die XenoThreat-Mission entwickelt wurde.

Was ist nicht so gut gelaufen?
Einige der Kisten verhielten sich nicht wie erwartet, was auf ein Problem mit dem Verhalten der Entitäten zurückzuführen war. Die Timer zeigten nicht die richtige Zeit an und die Kiste explodierte zwei Minuten vor Schluss.

Hurston ist nicht der beste Ort für lange Flugmissionen aufgrund der Ortsverteilung. Wir haben die Auszahlung erhöht, aber wir werden uns weitere Verfeinerungen ansehen.

Was wir in Zukunft anders machen werden
Wir müssen die Übergabe der Verhaltensweisen der Entitäten verbessern und die Verantwortung zwischen den Teams klären.

Kern-Gameplay-Pfeiler
Richard Tyrer, S42 FPS Game Director

Montierte Waffen
Was ist gut gelaufen?
Star Citizen ist von Natur aus ein Spiel mit gemischten Waffen, das Kämpfe zu Fuß, mit Fahrzeugen und Schiffen kombiniert. Die Mounted Guns fügen sich direkt in dieses Dreiergespann ein, indem sie den Spielern zu Fuß erlauben, Fahrzeuge und kleinere Schiffe herauszufordern. Wir haben bereits den Animus-Raketenwerfer und die Scourge-Railgun, aber sie bieten nur eine kleine Menge an Widerstand, bevor dir die Munition ausgeht. Mit der langfristigen Absicht, Gehöfte und Außenposten zu errichten, wollten wir dem Spieler und der KI zusätzliche Möglichkeiten geben, diese Gebiete zu verteidigen.

Wir standen vor zwei großen Herausforderungen mit dem montierten Geschütz: seine Größe und das Steuerungsschema. Die Adleraugen unter euch werden wahrscheinlich bemerkt haben, dass das montierte Geschütz eine Schiffswaffe der Größe 1 ist, da wir diese Art von Feuerkraft benötigten. Während diese auf einem Schiff klein sind, sind sie in den Händen der Spieler riesig, was uns mehrere Probleme bereitete. Erstens nahm sie in der Ego-Perspektive den ganzen Bildschirm ein, so dass die Sichtlinie schrecklich war, und zweitens war der Drehpunkt für Schiffswaffen nicht ideal für einen Charakter, der versucht, auf das Visier zu zielen und sich vertikal zu drehen. Da wir bereits eine Schiffswaffe hatten, konnten wir sie schnell in den Editor einfügen, was es uns ermöglichte, die Ego-Perspektive schon sehr früh zu verbessern, ohne uns zu viele Gedanken über die Metriken machen zu müssen. Das war ein echter Segen, denn so konnten wir den Drehpunkt der Waffe, ihre Blickwinkel und ADS-Ansichten ausarbeiten, ohne dabei die Glaubwürdigkeit zu verlieren, dass es sich um eine Waffe handelt, die ein Schiff zerstören kann.

Die andere Herausforderung, der wir gegenüberstanden, war das Kontrollschema. Wir haben lange darüber debattiert, ob wir ein eher FPS-zentriertes Kontrollschema verwenden sollten oder etwas, das eher einem Schiffsturm ähnelt. Glücklicherweise hatten wir genug Zeit eingeplant, um beide Systeme zu implementieren und zu spielen, um zu sehen, welches sich am besten anfühlt. Das erlaubte uns, die Erfahrung zu verfeinern und eine gute erste Iteration zu liefern. Wir haben auch langfristig geplant, die zusätzlichen Steuerungsoptionen in die Menübildschirme einzubauen, damit die Spieler wählen können, was sie bevorzugen.

Was ist nicht so gut gelaufen?
Die Verwendung einer bereits existierenden Schiffswaffe erlaubte es uns, früh zu iterieren und die Metriken einzustellen, ohne eine ganze Reihe neuer Kunstwerke erstellen zu müssen. Das hatte auch den Vorteil, dass in Zukunft theoretisch jede Schiffswaffe der Größe 1 auf ein Reittier montiert werden konnte. Leider verlief dies nicht so reibungslos wie erhofft, da Schiffswaffen von oben und nicht von unten montiert werden. Das bedeutete, dass die Waffe verkehrt herum montiert wurde und eine Menge zusätzlicher Geometrie hatte, die die Hauptansicht blockierte. Das ist zwar relativ einfach zu beheben, aber es bedeutet, dass jede neue Waffe, die wir in Zukunft verwenden wollen, weitere künstlerische Anpassungen und zusätzliche Daten benötigt, um sie zu unterstützen.

Was wir in Zukunft anders machen werden
Berittene Waffen sind ein Feature, das ein Content-Team benötigt, um es in das Verse zu implementieren (es ist kein systemisches Feature wie Sprung oder Schauspieler-Status). Obwohl wir Features immer so schnell wie möglich zu Testzwecken in die Hände der Spieler geben wollen, denke ich, dass die aktuelle Implementierung im PU nicht wirklich einen Zweck erfüllt. Im Nachhinein denke ich, dass es besser gewesen wäre, es zu implementieren, nach spezifischem PTU/Evocati-Feedback zu fragen und es dann in einem späteren Patch zu veröffentlichen, wenn die Content-Teams genug Gelegenheit hatten, etwas darum herum zu bauen.



Trolley Push/Pull
Was ist gut gelaufen?
Trolley Push/Pull ist eine Funktion, die es den Spielern erlaubt, mit einem Objekt zu interagieren, wie z.B. einem Trolley oder einem Block, und ihn in die Richtung ihrer Wahl zu schieben oder zu ziehen (vorausgesetzt, sie haben Grip). Da Star Citizen ein Sandbox-Spiel ist, das verschiedene Schwerkräfte und Planeten hat, mussten wir sicherstellen, dass das Feature systemisch ist, damit es mit verschiedenen Gewichten und Umgebungen funktioniert und skaliert. Wir wollten auch, dass sich der Wagen physikalisch korrekt anfühlt, wobei schwerere Lasten schwieriger zu kontrollieren sind. Das Team arbeitete direkt mit den Physikprogrammierern zusammen, um ein physikalisch korrektes Modell zu liefern, das sich wirklich so anfühlt, als würde man einen Wagen oder Block schieben. Der Charakter lehnt sich an schwerere Lasten an und die Steuerung fühlt sich gewichtig und geerdet an.

Was ist nicht so gut gelaufen?
Das Team war sehr darauf fokussiert, dass sich der Wagen in der Welt geerdet anfühlt und sie bauten eine aufwendige Testkarte, die mehrere Facetten des Features testete, einschließlich des Ladens auf ein Schiff. Dabei wurde ein großes Problem deutlich. Viele der Trolleys, die im Laufe der Jahre gebaut wurden, waren auf eine Charakter-Metrik mit relativ kleinen Rädern ausgelegt. Leider haben die Schiffe alle unterschiedliche Rampen, wobei einige sehr harte, eckige Kanten haben und andere sich gar nicht bis zum Boden absenken. Das bedeutete, dass viele der Trolleys Schwierigkeiten hatten, die Schiffsrampen hinaufzufahren und in einigen Fällen nicht über die Kante der Rampe kommen konnten, da diese zu groß war (man denke an das Verseuch, einen Einkaufswagen einen Bordstein hinaufzuschieben). Da das Fahrzeugteam bereits für das Quartal eingeplant war, konnten wir nicht das volle Trolley-Erlebnis liefern.

Was wir in Zukunft anders machen werden
Trolley Push/Pull wurde immer so konzipiert, dass es zwei Zwecke erfüllt: eine Rätselmechanik und zum Beladen der Ladung. Als Rätselmechanik funktioniert das Feature gut und erlaubt es den Designern, neue und interessante Missionen/Räume zu erschaffen, in denen Spieler Trolleys und Blöcke benutzen können, um höhere Aussichtspunkte zu erreichen. Als Frachtlademechanik fällt es aufgrund der Einschränkungen der Räder und der Größe der Schiffsrampen zu kurz. In Zukunft werden wir einen Schwebetrolley entwickeln, der viele unserer Probleme lindern wird und sich auf die traditionelleren Trolleys für Landezonen und spezielle Missionen verlassen wird.

Systemisches Gameplay & Dienstleistungen
Tony Zurovec, PU Spielleiter

Reputation UI
Was ist gut gelaufen?
In der Alpha 3.13 konnten wir das Reputations-UI veröffentlichen, das den Spielern eine visuelle Darstellung und einen Kontext für unser erstes T0-Release des Reputationssystems im vierten Quartal 2020 bietet. Für diese Veröffentlichung hatten wir den Ruf an die Kopfgeldjägermissionen (und ein paar andere) gekoppelt, aber die Spieler hatten keinerlei Einblick, warum sich ihr Missionsfortschritt veränderte. Wir haben auch den ersten Durchgang der Belohnung von Spielern basierend auf ihrem Ruffortschritt eingeleitet. Mit der neuen Benutzeroberfläche haben die Spieler nun viel mehr Klarheit über ihren Status bei Organisationen und Missionsgebern.

Die gesamte Entwicklung und Veröffentlichung dieses Features verlief für das Team reibungslos. Die Analyseberichte, die wir erhalten haben, zeigten unglaublich positive Ergebnisse bei den Spielern in der Alpha 3.13, was zu einer höheren Engagement-Rate der Kopfgeldjagdmissionen führte.

Was ist nicht so gut gelaufen?
Es gab einen unerwarteten Schluckauf mit einigen Änderungen am Reputation Service, die dem Feature Team nicht gut kommuniziert wurden. Dies führte zu einigen dringenden Korrekturen, die sehr kurz vor der Veröffentlichung der Alpha 3.13 durchgeführt werden mussten.

Außerdem haben wir noch nicht den gesamten Missionsinhalt auf das neue System umgestellt und hatten auch noch keine Zeit, das Verhalten der Missionsgeber so zu überarbeiten, dass sie auf die Affinitäts- und Zuverlässigkeitsanzeigen reagieren können. Dies ist zwar ein fortlaufender Prozess und die Spieler sollten sich auf weitere Fortschritte freuen, aber es wird leider einige Zeit dauern, bis wir alle Missionen umgestellt haben und das Verhalten der Missionsgeber überarbeitet haben.

Was wir in Zukunft anders machen werden?
Wir werden uns bemühen, unsere globale Kommunikation zu den Features zu verbessern, vor allem, wenn es sich um Dienstleistungen oder externe Unterstützung handelt. Es hat sich gezeigt, dass es bei teamübergreifenden Initiativen aufgrund unserer globalen Verteilung immer wieder zu Kommunikationsproblemen kommt, daher suchen wir immer nach Möglichkeiten, diese Pipeline zu verbessern. Insbesondere versuchen wir, mehr technische Designdokumente (TDD) zu erstellen, bevor wir diese größeren Initiativen starten. Dies sollte helfen, ein globales Bewusstsein zu schaffen, da alle betroffenen Gruppen während dieses Prozesses Feedback zu den TDDs geben müssen.

Da das System nun steht und unser zweites Sternensystem am Horizont auftaucht, sobald die Serververmaschung online ist, führen wir außerdem fortlaufende Designgespräche darüber, wie wir die Organisationen innerhalb des Universums für die ersten fünf Systeme strukturieren werden. Diese Gespräche beinhalten alles, von der Erfahrung eines neuen Spielers und seinem Startort, wie Spieler innerhalb eines einzelnen Systems vorankommen und wie große Organisationen den Inhalt über mehrere Systeme hinweg beeinflussen werden. Dies erlaubt uns auch, das Gameplay für jeden der Hauptmissionstypen zu definieren, wobei der aktuelle Plan vorsieht, jeden Missionstyp mit den Rufspuren innerhalb der Organisationen zu verknüpfen. Während dieses Prozesses haben wir bedeutende Fortschritte gemacht, die uns zu einer ersten Version/Vision geführt haben, wie diese wichtige Fortschrittsmechanik das gesamte Spielerlebnis beeinflussen wird. Auch wenn wir noch die endgültige Freigabe benötigen, glauben wir, dass dies mit der Art und Weise übereinstimmt, wie der Ruf der Öffentlichkeit bisher präsentiert wurde und freuen uns darauf, dies voranzutreiben.



Invictus Startwoche
Was ist gut gelaufen?
Das Expo-Event, das mit der Invictus Launch Week verbunden war, verlief sehr reibungslos. Das ist ein Prozess, den wir schon mehrfach gemacht haben, also ist das Einrichten eines neuen Expo-Events eine bekannte Größe.

Auf der anderen Seite des Spektrums hat das USPU Team dazu beigetragen, einige zusätzliche Features mit Invictus herauszubringen, die unsere Dynamic Mission Service Toolbox erweitern. Es war das erste Mal, dass wir in der Lage waren, das Inventar eines Shops dynamisch zu verändern, basierend auf In-Game-Events (etwas, das wir als Dynamic Shop Modifiers bezeichnen). Dies wird letztendlich mit dem Quanta-Tooling verknüpft/kontrolliert werden, das wir in unserer letzten Videopräsentation besprochen haben. Wir können damit nicht nur neue ereignisspezifische Gegenstände hinzufügen, sondern auch ändern, ob ein Shop diese Waren verbraucht oder wieder auffüllt, was letztendlich den Gesamtpreis des Gegenstandes verändert. Diese Änderungen sind für eine begrenzte Zeit während des Events, so dass es uns erlaubt, das wirtschaftliche Klima von so vielen Läden zu verändern, wie wir wollen, um die gewünschten Ergebnisse zu erzielen.

Wir haben auch etwas hinzugefügt, das damit zusammenhängt und uns schließlich dabei helfen wird, den Beruf des Ladens zu erweitern. Wir nennen sie "Preisschwellenauslöser". Diese sollen es uns ermöglichen, Missionen auszulösen, die darauf basieren, dass die Vorräte der Läden ein bestimmtes Niveau erreichen. Als ersten Schritt zur Erstellung von Missionen haben wir sie jedoch genutzt, um den Spielern einen wertvollen Einblick zu geben, was an einem bestimmten Ort für die Dauer des Events gerade gefragt ist (zum Kaufen oder Verkaufen). Dies geschah vorübergehend über die Journaleinträge, die durch das Missionssystem generiert werden. Jetzt, wo diese drin sind, wird der nächste Schritt sein, spielweite Anfragen zu verschicken (jede beliebige Distanz, die wir über ein Sonnensystem oder zwischen Systemen wählen), während wir uns in Richtung eines Quanta-gesteuerten Universums bewegen. Während die Arbeit an der Visualisierung der Shop-Informationen im Journal eine temporäre Lösung ist, ist die gesamte zugrundeliegende Funktionalität wie beabsichtigt implementiert, so dass es nur sehr wenig wegwerfbare Arbeit geben wird, sobald wir die Missionsmanager-UI überarbeiten oder ein gewisses Maß an Wirtschaftsinformationen an anderer Stelle im Spiel hinzufügen (der Zeitrahmen für diese Ergänzung ist noch offen).

Abschließend sei gesagt, dass die Spieler die Tatsache genossen haben, dass die Läden während des Events Gegenstände freilegen und/oder die Preise dynamisch ändern. Wir freuen uns darauf, dieses System weiter auszubauen, da es wirklich eine der wichtigsten Grundlagen für das Wirtschafts- und Frachtsystem ist.

Was ist nicht so gut gelaufen?
Wir hatten einige Änderungen am Fahrwerkssystem der Schiffe, die Unregelmäßigkeiten mit den Standard-/Spawned-Kompressionswerten verursachten. Dies führte zu einer Menge langwieriger Tests auf unserer Seite, um sicherzustellen, dass alles wie vorgesehen platziert wurde, so dass wir bestätigen konnten, dass alles, was wir sahen, ein legitimes Problem war und nicht nur ein Platzierungsproblem.

Bei den Dynamic Shop Modifiern war der größte Stressfaktor, dass einige der Funktionen erst sehr spät in den Prozess kamen, was sehr wenig Zeit für das Testen des Features in der PTU ließ. Hätte dieses Feature nicht sehr gut funktioniert, als wir es endlich bekamen, wäre dies ein größeres Problem gewesen. Das Ninetails Lockdown Event (das mit Alpha 3.13, dann mit Invictus und schließlich mit Alpha 3.14 veröffentlicht werden sollte) konkurrierte in dieser Zeit ebenfalls um die QA-Bandbreite, was einer der Hauptgründe war, warum es auf Alpha 3.14 verschoben wurde. Da die Priorität auf Invictus liegen musste, hatten wir keine andere Wahl, als Ninetails zu opfern, was intern eine Enttäuschung war.

Der Workflow für die Einrichtung der Shop-Modifikatoren und der Preisschwellenauslöser war auch nicht gerade förderlich, um schnell große Änderungen vorzunehmen. Außerdem ist es momentan etwas verwirrend, weil wir historisch gesehen den Kontext von 'Kaufen' und 'Verkaufen' aus der Perspektive des Spielers verwenden, aber das wurde im Kontext der Schwellenwertauslöser irgendwie umgekehrt. Das führt offensichtlich zu einer Menge Verwirrung beim Einrichten dieser und muss unbedingt behoben werden, bevor man dieses Feature in die Breite trägt.

Während wir die Schwellenwert-Trigger einstellten, hatten wir außerdem den starken Wunsch, Shop-Einträge zu ändern, die wir nicht über die Shop-Modifikator-UI innerhalb von Subsumption bearbeiten konnten, wie z.B. den Grundpreis-Offset, den aktuellen Bestand und einige andere. Wir umgingen dies, indem wir Gegenstände zum Inventar hinzufügten, um sie einzurichten, DANN änderten wir ihren Kontext von Kaufen zu Verkaufen, wenn Waren verfügbar waren, um anderswo im Universum gesammelt/gekauft zu werden. Das ist zwar eine übliche Taktik für Designer, wenn Werkzeuge nicht das tun, was sie wollen, aber es ist im Allgemeinen verpönt, weil es letztendlich Schuld bedeutet, die man später wieder beheben muss.

Was wir in Zukunft anders machen werden
Ich würde gerne zusätzliches Debugging in die Engine einbauen, um die Unstimmigkeiten bei der Fahrwerkskompression schnell beheben zu können. Allerdings haben wir seit unserem letzten Expo-Event bereits einige neue Debugging-Methoden in das Spiel eingebaut. Allerdings könnten diese Unstimmigkeiten mit zusätzlichem Debugging-Feedback leichter zu erkennen sein. Während wir uns dem nächsten Expo-Event nähern, würde ich gerne Zeit darauf verwenden, sicherzustellen, dass diese Probleme leicht identifiziert und durch datengesteuerte Lösungen gelöst werden können.

Wir würden gerne eine bessere Koordination zwischen QA und den Entwicklerteams sehen, die eine größere QA-Beteiligung benötigen, wie z.B. Invictus und Ninetails. Wir haben sicherlich einige der Schmerzpunkte, die dies verursacht hat, gesehen und anerkannt, aber dies wird weiterhin auftauchen, wenn wir mehr dieser Events machen, also werden wir diesen Workflow in Zukunft straffen müssen. Idealerweise würden wir versuchen, die Lieferung aller Gameplay-Features und der dazugehörigen Services lange vor einem möglichen Liefertermin zu bekommen. Zum Beispiel, lange bevor wir den nächsten Release-Stream abzweigen und sicherlich bevor wir zum PTU gehen. Ich würde auch gerne weniger Feature-Entwicklung im Release-Stream sehen, wenn wir vorankommen.

Während dies noch geplant werden muss, würde ich gerne die UI-Präsentation der Journaleinträge in zukünftigen Revisionen aufgeräumt sehen, da sie sich auf nachgefragte Waren beziehen. Sie müssen nach Landezone geordnet werden und dann innerhalb jeder Landezone zeigen, was man kaufen und was man verkaufen kann. Die ideale Lösung wäre es, eine Art von Wirtschaftsinformationen irgendwo auf der Sternenkarte oder in einer separaten App zur Verfügung zu haben, aber wie oben erwähnt, muss diese Arbeit derzeit geplant werden, daher sind alle Ergänzungen TBD.



Mission Features
Was ist gut gelaufen?
XenoThreat und Fleet Week waren zwei große Ereignisse, an denen das Mission Feature Team im ersten Quartal 2021 gearbeitet hat. Die Zusammenarbeit zwischen uns und anderen Abteilungen bei beiden Initiativen, insbesondere der QA, war stärker als je zuvor, und wir denken, dass man das im fertigen Produkt sehen kann.

XenoThreat brauchte etwas mehr Zeit, um die verbleibenden Fehler auszubalancieren und auszubügeln und zum Glück wurde uns diese Zeit zugestanden, auch wenn die ursprüngliche Erwartung war, dass es zur Weihnachtszeit veröffentlicht werden würde.

Glücklicherweise waren wir in der Lage, Inhalte zu den Höhlen hinzuzufügen. Dies stand nicht einmal auf unserer geplanten Lieferliste für das Quartal, aber es schien eine Schande zu sein, neue Höhleneingänge zu veröffentlichen, ohne dass dort etwas vorhanden ist. Wir haben auch eine Menge weiterer Missionsorte im Yela-Asteroidenring hinzugefügt.

Unser Team war in der Lage, eine neue Debug-GUI hinzuzufügen, die sich nun als unschätzbar erweist, um Probleme viel schneller zu identifizieren. Und die Erstellung neuer Liefermissionen ging schnell und reibungslos vonstatten, vor allem dank gut etablierter Missionsmodule und der Wiederverwendung von Entitäten aus XenoThreat.

Was ist nicht so gut gelaufen?
XenoThreat hat, wie bereits erwähnt, sein geplantes Veröffentlichungsdatum nicht erreicht. Das war natürlich unglücklich, aber in Anbetracht des Umfangs dessen, was wir mit dem Event erreichen wollten, war das verständlich und zum Glück konnten wir ihm die nötige Zeit geben, um es weiter zu polieren, bis es fertig war.

Die Erstellung und Pflege einzigartiger Entitäten war ebenfalls ein Thema. Zum Beispiel waren die Quantenreise-empfindlichen Boxen eine Mischung aus der Arbeit mehrerer Teams, so dass es bei Bugs oft schwierig war, diese in den Griff zu bekommen. Die fortlaufende Wartung dieser könnte nun auch ein Problem sein, da es nicht wirklich einen definierten Entwickler gibt, der sie besitzt und aufrechterhält.

Parasitenschiffe verursachten auch Probleme mit dem Rechtssystem, die erst nach der Veröffentlichung der Alpha 3.13 entdeckt wurden.

Was wir in Zukunft anders machen werden
Wir werden darauf drängen, dass das Team bei allen Features, die das Gesetzessystem betreffen oder Unterstützung benötigen, mit einbezogen wird, um unvorhergesehene Probleme für zukünftige Initiativen zu vermeiden und hoffentlich zu minimieren.



Systemische Dienste & Tools
Was ist gut gelaufen?
Zusätzliche Ressourcen aus den Backend-Teams sorgten für eine sofortige Entlastung des Systemic Services & Tools (SST) Teams. Der SuperCache wurde implementiert und die Arbeit an mehreren längerfristigen Initiativen zur Integration von Quantum in weitere Dienste konnte beginnen. Die öffentliche Präsentation kam gut zusammen und wurde sehr positiv aufgenommen. Die Technologie, die wir in die Präsentationsdisplays investiert haben, wird in Zukunft für die Demonstration anderer High-Level-Konzepte verwendet werden.

Quasar wurde eingesetzt, das dynamische Missionstool, das während des SST Update Videos im April gezeigt wurde. Die Entwicklung von Quasar war aufgrund der vorangegangenen Arbeit mit Odin im letzten Jahr, die die meisten der grundlegenden Arbeiten, die für die Anbindung an Live-Services und DGS-Instanzen erforderlich sind, in Angriff genommen hat, sehr einfach. In Zukunft wird das Quasar-Tool eine Plattform bieten, über die dynamische Missionsinhalte über Quantum instanziiert werden können.

Die Arbeit am ATC Service wurde fortgesetzt und SST verbrachte Zeit mit der Entwicklung eines eigenständigen Objektcontainer-Dekompressors, der es ermöglicht, spezifische Datenpunkte in Assets zu injizieren, ohne jeden Objektcontainer manuell durch den Editor neu exportieren zu müssen. Diese Arbeit wird mehrere andere kritische Bereiche für die Datenmanipulation freischalten, die für zukünftige SST Projekte benötigt werden.

Was ist nicht so gut gelaufen?
Ein neuer Hochgeschwindigkeits-KI-Dienst wurde benötigt, um die Live-Positionen der in den Missionen gespawnten NPCs zu kartieren, was sich als äußerst komplex herausstellte. Dieser neue Dienst erforderte Arbeit von verschiedenen Teams und Säulen, was zu Verzögerungen und Schwierigkeiten beim Testen führte. Viele unserer Team-Ressourcen sind weiterhin damit beschäftigt, Fehler zu beheben, die am Ende nicht in unserem Verantwortungsbereich liegen.

Was wir in Zukunft anders machen werden
Zukünftige Präsentationen werden deutlich geradliniger sein, was die Inhalte angeht, die wir zeigen, und wir haben in Visualisierungswerkzeuge investiert, um High-Level-Konzepte auf der Starmap schnell und einfach zeigen zu können.

Wir haben Probleme identifiziert, die zu Verzögerungen bei neuen Diensten wie dem Hochgeschwindigkeits-KI-Service geführt haben und sind nun besser in der Lage, teamübergreifende Initiativen wie diese in Zukunft zu bewältigen. Da die Grundlagen für Quantum gelegt sind, können wir uns auf die Integration anderer Dienste konzentrieren.

Wir sind nun besser in der Lage, Probleme zu identifizieren, die nicht in den Verantwortungsbereich unseres Teams fallen und planen, diese Probleme an die entsprechenden Teams weiterzuleiten, was unseren Teammitgliedern dringend benötigte Zeit für die Entwicklung der Dienste spart.

Standorte
Ian Leyland, Star Citizen Art Director

Wann lief es gut?
Die Invictus Launch Week im Tobin Convention Centre war fantastisch, ebenso wie die neuen Raumstations-Andockmodule und Militärdocks für das Event. Abgesehen von dem, was wir in der Alpha 3.13 veröffentlicht haben, erlaubte es dem Team, sich darauf zu konzentrieren, solide Fortschritte bei zukünftigen Locations für das Spiel zu machen.

Was ist nicht so gut gelaufen?
Das Docking-Feature verursachte einige Hin- und Herbewegungen zwischen den verschiedenen beteiligten Teams, was die Effizienz reduzierte. Das Trolley Push/Pull Feature verursachte eine Menge Bugs für die Teams, die ebenfalls hätten reduziert werden können.

Was wir in Zukunft anders machen werden
Intern folgen wir einem Prozess, bei dem Features und Standorte ein 'Go/No Go' haben. In Bezug auf ein Feature wie das Andocken waren die Teams sehr komprimiert, wenn es darum ging, das Feature zu bauen und gleichzeitig die Standorte zu erstellen. Um die Ineffizienz, die dadurch entsteht, zu reduzieren, werden wir in Zukunft versuchen, einen größeren Puffer zwischen der Erstellung eines Features und der Erstellung des Ortes, der es nutzt, zu haben.

Alpha 3.13 & Invictus Launch Week Postmortem
07/21/2021 - 9:00 PM

On April 22, 2021, we launched Alpha 3.13: Underground Infamy, which introduced a number of new features and changes, including ship-to-ship docking, additional cave entrances, and the Reputation Manager. 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 focuses on both the Alpha 3.13 patch and the Invictus Launch Week event.

Vehicle Pillar
John Crewe, Vehicle Director

For Star Citizen Alpha 3.13, the Vehicle Pillar delivered a mixture of new features, the groundwork for future initiatives, and our usual content drop.

Merlin/Constellation Docking
What went well?
We successfully delivered a long-awaited feature to one of Star Citizen’s most iconic ships. Although we had aimed to do this in Alpha 3.12, the decision to spend an extra quarter polishing it paid dividends upon release as it was much more stable and expansive than originally planned.

What didn’t go so well?
The decision to delay XenoThreat into 2021 meant we were caught up longer than expected in bug fixing for the event, which reduced our ability to react to issues with the feature before it went to Evocati for testing.

What we’ll do differently in the future
Generally, the feature process went well, so aside from more testing sooner, there isn’t a huge amount we’ll improve on in the future.

Vehicle Names/Serials
What went well?
The ability to personalize your ship has been a long-requested feature, and it’s something we’ve wanted to deliver for a long time, but we’ve had a few behind-the-scenes technical issues we had to solve regarding the rendering and platform-to-game entitlement flow. The delivery for a small selection of ships proved out the tech and helped us better understand the limitations of the system.

What didn’t go so well?
By far the biggest issue was readability, particularly for shorter names where the font size stayed the same as a maximum-length 32-character name. A short name combined with less-than-ideal exterior ship lighting and the inability to customize text color lead to some major readability problems.

What we’ll do differently in the future
We’re working with the Graphics and UI teams on better implementation via Building Blocks to allow us to dynamically change the font size based on the input string length. An optimized UV layout will be created to accommodate this. The paint system will also have work done in the future to allow players to pick the name color to avoid clashing.


Hull Visual Degradation
What went well?
Since Star Citizen Alpha 3.6 when we introduced item degradation and misfires, the big part missing was having your ship’s hull visually degrade alongside the other items. Now we’ve completed this, you get a much-improved read on the state of your ship based on the hull’s visuals rather than having to go MFD hunting. The system ties into our existing production pipeline for vehicles so we didn’t have to go back and add it to any ships, making the implementation much quicker.

What didn’t go so well?
There were quite a few ships that were missed in our internal testing sweeps, leading to the canopy entirely ‘scratching’ over, blocking the view. This was not our intention - restricting wear to the edge of the view was the goal.

While the actual content side has been part of our pipeline, it wasn’t easily visualized, so the Content Team have to go back and manually adjust the wear maps and settings on older ships.

What we’ll do differently in the future
As mentioned, a few ships are dramatically wearing too much in key areas, which will be fixed case-by-case. In the future, with physical damage, this will move from being a purely visual feature to it having structural and gameplay consequences.

Ship-to-Station Docking
While officially not part of the Alpha 3.13 release, we did in fact launch this feature with the patch, albeit disabled ready to come online with 3.13.1 (Invictus Launch Week). We had originally aimed to deliver both features in the same patch but made the decision to officially hold it back, much for the same reasons we held back Connie/Merlin docking - to improve the quality of the release.

Tumbril Cyclone MT
The Cyclone MT was a surprise straight-to-release vehicle that we worked on during downtime between releases that helped expand our ground vehicle line up, particularly for Theaters of War.

The challenge of having a mounted turret controlling both missiles and weapons caused some head scratching in the setup phase, but the MT provides an interesting firepower addition to the Cyclone lineup at the expense of being the slowest in the family.

Greycat ROC-DS
The ROC-DS was a vehicle that struggled both through its development and public release, having originally been designed to be the primary vehicle in the family. However, due to production timelines, we had to release the ROC well in advance of the ROC-DS. The original aim was to have them both release together to provide clearer options for players but having the significant time gap between them just increased the perception issues surrounding its role and usefulness.

While it did get some hefty upgrades during the Evocati and PTU phases increasing both its capacity and range, these goals were not communicated well enough at the start of the release cycle, leaving it to suffer more than expected. The ROC-DS was never supposed to be a clear upgrade from the ROC; it’s a companion allowing two players to work together in more demanding locations further away from base.

It currently sits in a poor position, however future changes to inventory behavior, the cargo system, and cave setups will perhaps let it regain the position we had intended for it. If it doesn’t, we’ll investigate further changes to improve its reception.

Live Pillar
Todd Papy, Star Citizen Live Director

EUPU: Mining Sub-Components
What went well?
We continued to add depth and expand on the mining gameplay and got the sub-components up and running fairly smoothly. The Quality Assurance Test Request (QATR) process went well too, with great communication among the team

What didn’t go so well?
Game-dev stability was poor, which caused delays in getting up-to-date builds with integrations.

What we’ll do differently in the future
The team is creating QATRs to integrate their work to game dev as a usual process. Unfortunately, QA were super busy with the Alpha 3.13 and 3.13.1 releases, both of which were big ones. This is currently affecting the efficiency of the QATR process, leading to sprint integrations of non-upcoming releases being heavily delayed.

Live Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries
What went well?
It went smoothly because it was using existing tech, a lot of which was created for the XenoThreat mission.

What didn’t go so well?
Some of the boxes didn't behave as expected, which ended up being an issue with the entity behavior. The timers were not showing the correct time and the box would explode with two mins left.

Hurston isn't the best location for long-flight missions because of the location distribution. We did increase the payout but will look at continued refinements.

What we’ll do differently in the future
We need to improve the handoff of the entity behaviors and clear up responsibility between the teams.

Core Gameplay Pillar
Richard Tyrer, S42 FPS Game Director

Mounted Guns
What went well?
Star Citizen by its very nature is a mixed arms game combining on-foot, vehicle, and ship combat. Mounted guns slot directly into that trifecta by allowing on-foot players to challenge vehicles and smaller ships. We already have the Animus missile launcher and Scourge railgun, but they only provide a small amount of resistance before you would run out of ammo. With the long-term intention of homesteads and outposts, we wanted to provide the player and AI with additional options for defending these areas.

We faced two main challenges with the mounted gun: its size and the control scheme. The eagle-eyed among you will probably have noticed that the mounted gun is a Size 1 ship weapon as we needed that sort of firepower. While these are small on a ship, they are huge in the players’ hands, and this provided us with several issues. Firstly, it took up the whole screen in first-person, so the line of sight was terrible and, secondly, the pivot point for ship weapons was not ideal for a character trying to aim down the sights and pivot vertically. As we already had a ship weapon, we were able to get it into the editor quickly, and this allowed us to iterate on the first-person experience very early on without having to worry too much about metrics. This was a real boon as we were able to work out the pivot of the weapon, its viewing angles, and ADS views while still retaining a believability that this was a weapon that could take down a ship.

The other challenge we faced was the control scheme. We debated for a long time over whether we should use a more FPS-centric control scheme or have something more akin to a ship turret. Fortunately, we had scheduled enough time for us to implement both schemes and play them to see which felt the best. This allowed us to hone in on the experience and deliver a good first iteration. We have also planned long-term to try and add the additional control options to the menu screens so players can choose which they prefer.

What didn’t go so well?
Using a pre-existing ship weapon allowed us to iterate early on and dial in the metrics without having to create a whole suite of new art. This also had the advantage that, going forward, any Size 1 ship weapon could theoretically be mounted onto a mount. Unfortunately, this didn’t go as smoothly as we hoped, because ship weapons mount from the top rather than the bottom. This meant that the weapon was mounted upside down and had lots of additional geometry that blocked the main view. While this is a relatively easy fix, it does mean that any new weapon we want to use in the future will require further art tweaks and additional data to support it.

What we’ll do differently in the future
Mounted guns are a feature that requires a content team to implement it into the ‘verse (it’s not a systemic feature like jump or actor status). While we always want to get features into the hands of players as soon as possible for testing purposes, I think its current implementation in the PU doesn’t really serve a purpose. In hindsight, I think it would have been better to implement it, ask for specific PTU/Evocati feedback, and then release it in a later patch once the content teams had had enough chance to build something around it.

Trolley Push/Pull
What went well?
Trolley Push/Pull is a feature that allows players to interact with an object, such as a trolley or block, and push or pull it in the direction of their choosing (providing they have grip). As Star Citizen is a sandbox game that has multiple gravities and planets, we needed to make sure the feature was systemic so that it could work and scale with different weights and environments. We also wanted the trolley to feel physically correct, with heavier loads being harder to control. The team worked directly with the physics programmers in delivering a physically correct model that really feels like you are pushing a trolley or block. The character leans into heavier loads and the controls feel weighty and grounded.

What didn’t go so well?
The team were highly focused on making sure the trolley felt grounded in the world and they built an elaborate test map that tested multiple facets of the feature including loading onto a ship. This highlighted a significant problem. A lot of the trolleys built over the years had been designed to a character metric with relatively small wheels. Unfortunately, the ships all have different ramps, with some having very hard angular edges and others not lowering to touch the floor at all. This meant that a lot of the trolleys struggled to go up ship ramps and, in some cases, could not get over the edge of the ramp as it was too large (think trying to push a shopping trolley up a curb). As the Vehicle Team was already scheduled for the quarter, we were not able to deliver the full trolley experience.

What we’ll do differently in the future
Trolley Push/Pull was always designed to serve two purposes: a puzzle mechanic and for cargo loading. As a puzzle mechanic, the feature works well and allows the designers to start creating new and interesting missions/spaces where players can use trolleys and blocks to access higher vantage points. As a cargo-loading mechanic, it falls short due to the limitations of the wheels and the sizes of ship ramps. Going forward, we will be developing a hover trolley that will alleviate a lot of our issues and rely on the more traditional trolleys for landing zones and specific missions.

Systemic Gameplay & Services
Tony Zurovec, PU Game Director

Reputation UI
What went well?
For Alpha 3.13, we were able to release the Reputation UI, giving players a visual representation and context for our initial T0 release of the Reputation System in Q4 2020. For that release, we had hooked up reputation to the bounty hunting missions (and a few others), but players had zero visibility on why their mission progression changed. We have also instituted the first pass of rewarding players based on their reputation progress. With the UI now in place, players have much more clarity on their status with both organizations and mission givers.

The overall development and release for this feature went smoothly for the team. The analytics reports we received showed incredibly positive results with players in the Alpha 3.13 release, which resulted in a higher engagement rate of the bounty hunting missions.

What didn’t go so well?
There was an unexpected hiccup with some changes to the Reputation Service that were not communicated well to the Feature Team. This resulted in a few urgent fixes that needed to be done awfully close to Alpha 3.13’s release.

Additionally, we have not converted the entirety of our mission content over to the new system yet, nor have we had time to refactor the mission giver behaviors to be as reactive to the Affinity and Reliability meters. While this is an ongoing effort, and players should look for continued progress, this will unfortunately take time to churn through the entirety of our missions and refactor the mission-giver behaviors.

What we’ll do differently in the future?
We’ll be aiming to improve our global communication on features going forward, notably for any that involve services or external feature team support. Cross-team initiatives have consistently proven to have some level of communication breakdown due to our global distribution, so we’re always looking for ways to improve this pipeline. Specifically, we are trying to create more technical design documents (TDD) prior to starting these larger initiatives. This should help create global awareness since all applicable groups are required to provide feedback on the TDDs during this process.

Also, with the system now in place and our second star system on the horizon once server meshing comes online, we are having ongoing design discussions about how we will structure organizations within the universe for the first five systems. These talks include everything from the new-player experience and their starting location, how players progress within a single system, and how major organizations will influence content across multiple systems. This also allows us to define what gameplay will be involved for each of the major mission types, with the current plan to associate each mission type with the reputation tracks within organizations. Throughout this process, we have made significant strides towards (what we feel) will be the initial version/vision of how this major progression mechanic will affect the overall player experience. While we still need to get final signoff, we feel this falls in line with how reputation has been previously pitched to the public and look forward to driving this forward.

Invictus Launch Week
What went well?
The expo event associated with Invictus Launch Week went very smoothly. This is a process that we’ve done multiple times to date, so setting up a new expo event is a known quantity.

On the other side of the spectrum, the USPU Team did help to get some additional features out with Invictus that expand our Dynamic Mission Service toolbox. This was the first time we have been able to change the inventory of a shop dynamically based on in-game events (something we refer to as Dynamic Shop Modifiers). This will ultimately be tied/controlled by the Quanta tooling that you may have seen us discuss in our most recent video presentation. We can also use it to not only add new event-specific items, but we can also change whether a shop consumes or replenishes these commodities, which ultimately changes the overall price of the item. These changes are for a limited time during the event, so it allows us to change the economic climate of as many shops as we like to achieve the desired results.

We also added something related to this that will eventually help us expand the cargo profession. We call them “Price Threshold Triggers.” These are intended to allow us to trigger missions based on the shop inventories hitting designated levels. However, as a first step towards the creation of missions, we used it to give the players valuable insight into what is currently in demand (to purchase or to sell) at a given location for the duration of the event. This was temporarily done via the journal entries that are generated by the mission system. Now that these are in, the next step will be to send out game-wide requests (any distance we choose across a solar system or between systems) as we move towards a Quanta-driven universe. While the work towards visualizing the shop info within the journal is a temporary solution, all of the underlying functionality is implemented as intended, so there will be very little throw away work once we redo the mission manager UI or add some level of economy info elsewhere within the game (the timeframe on that addition is still TBD).

Finally, with all that said, the players enjoyed the fact that the shops were exposing items and/or changing the prices dynamically during the event. We are looking forward to expanding on this system as it is really one of the major underpinnings of the economic and cargo systems.

What didn’t go so well?
We had some changes to the ships’ landing gear system that caused irregularities with their default/spawned compression values. This ultimately caused a lot of tedious testing on our side to ensure that everything was placed as intended so that we could confirm that anything we DID see was a legitimate problem and not just a placement problem.

For Dynamic Shop Modifiers, the biggest stressor was that some of the functionality came in quite late in the process, which left very little time for testing the feature in the PTU. Had this feature not worked very well when we finally did get it, this would have been a larger problem. The Ninetails Lockdown event (supposed to go out with Alpha 3.13, then Invictus, and now ultimately Alpha 3.14), was also competing for QA bandwidth during this time, which was one of the main reasons it was pushed to Alpha 3.14. With the priority needing to stay on Invictus, we had no choice but to sacrifice Ninetails as a result, which was a letdown internally.

The workflow for setting up the shop modifiers and the price threshold triggers was also not conducive to making largescale changes quickly. Additionally, it is currently a bit confusing because, historically, we use the context of ‘buy’ and ‘sell’ from the perspective of the player, but this was somehow reversed in the context of threshold triggers. This obviously leads to a lot of confusion when setting these up and absolutely needs to be fixed before going wide with this feature.

Additionally, while tuning the threshold triggers, we had a strong desire to change shop entries that we didn’t have the ability to edit from the shop modifier UI within Subsumption, including base price offset, current inventory, and a couple of others. We hacked around this by adding items to the inventory to set them up, THEN changing their context from buy to sell when commodities were available to be gathered/purchased elsewhere within the universe. While this is a common tactic for designers when tools don’t do what they want, it’s generally frowned upon because it’s ultimately adding debt that you need to go back and fix later.

What we’ll do differently in the future
I would like to get additional debugging into the engine that would allow us to quickly debug the landing gear compression discrepancies. To this point though, we’ve already added some new debugging methods into the game since our last expo event. However, these discrepancies could potentially be easier to spot with additional debugging feedback. As we approach the next expo event, I would like to dedicate time to ensuring these issues are easily identified and are easily solved by data-driven solutions.

We would like to see some better coordination between QA and the dev teams that require larger-scale QA involvement, such as Invictus and Ninetails. We’ve certainly seen and acknowledged several of the pain points that this has caused, but this will continue to come up as we make more of these events, so we will need to tighten up this workflow moving forward. Ideally, we would try and get the delivery of all gameplay features and related services well in advance of any potential delivery date. For example, well before we branch the next release stream and certainly before going to the PTU. I would also like to see less feature development in the release stream as we move forward.

While this still needs to be scheduled, I would like to see the UI presentation of the journal entries cleaned up in any future revisions, as they relate to commodities that are in demand. It needs to order them by landing zone and then, within each landing zone, show things you can buy and what you can sell. The ideal solution is to have some type of economic info available someplace like the star map, or a separate app, but as mentioned above, this work currently needs to be scheduled so any additions are TBD.

Mission Features
What went well?
XenoThreat and Fleet Week were two major events worked on by the Mission Feature Team in the first quarter of 2021. The collaboration between us and other departments on both initiatives, especially QA, was stronger than it has ever been previously, and we think you can see that in the finished product.

XenoThreat needed a bit more time to balance and iron out the remaining bugs and thankfully we were allowed that time, even though the initial expectation was that it would be released for the holiday season.

Luckily, we were able to add content to the caves. This was not even on our planned deliverables list for the quarter, but it seemed a shame to release new cave entrances without something present there. We also added a lot more mission locations in the Yela asteroid ring.

Our team was able to add a new debug GUI, which is now proving invaluable for identifying issues at a far more rapid pace. And the creation of new delivery missions went quickly and smoothly, notably due to well-established mission modules and the reuse of entities from XenoThreat.

What didn’t go so well?
XenoThreat, as mentioned, didn’t hit its intended release date. This was obviously unfortunate but, given the scope of what we were trying to achieve with the event, we felt this was understandable and thankfully we were able to give it the proper amount of time to further polish it until it was ready.

Creating and maintaining unique entities was also an issue. For example, the quantum-travel-sensitive boxes were a mixture of several teams' work, so when it comes to bugs it was often difficult to get traction. Continued maintenance of these could now also be an issue as there isn't really a defined developer to own and sustain them.

Parasite ships also caused issues for the law system that weren’t spotted until after the initial release of Alpha 3.13.

What we’ll do differently in the future
We’ll aim to push for the team to be included on any feature that may affect or require support from the law system to try, and get ahead of, and hopefully minimize, any unforeseen issues for future initiatives.

Systemic Services & Tools
What went well?
Additional resources from the backend teams provided immediate relief for workload for the Systemic Services & Tools (SST) Team. The SuperCache was deployed and work was able to start on several longer-term initiatives to integrate Quantum into more services. The public presentation came together well and was received very positively. The technology that we invested into presentation displays will be used to demonstrate other high-level concepts in the future.

Quasar was deployed, which is the dynamic mission tool demonstrated during the SST update video released in April. Development of Quasar was straightforward due to the previous work done with Odin last year, which tackled most of the foundational work required to hook into live services and DGS instances. Going forward, the Quasar tool will provide a platform through which dynamic mission content can be instantiated via Quantum.

Work on the ATC service continued, and SST spent time developing a standalone object container decompressor to allow the injection of specific data points to assets without needing to manually re-export each object container through the editor. This work will unlock several other critical areas for data manipulation required for future SST projects.

What didn’t go so well?
A new high-speed AI service was needed to map live positions of mission-spawned NPCs, which ended up being deceptively complex. This new service required work from various teams and pillars, which caused delays and difficulties in testing. Many of our team resources continue to be absorbed addressing bugs that don’t end up being in our sphere of responsibility.

What we’ll do differently in the future
Future presentations will be significantly more straightforward in terms of the content we demonstrate, and we invested in visualization tools to be able to show high-level concepts on the Starmap quickly and easily.

We identified issues causing delays on new services like the high-speed AI service and are now more capable of dealing with cross-team initiatives like this going forward. With the groundwork of Quantum laid, we will be able to focus on the integration of other services.

We’re now better able to identify issues that don’t fall under the responsibility of our team and plan to re-route these issues to the appropriate teams, saving our team members much-needed time to develop services work.

Locations
Ian Leyland, Star Citizen Art Director

When went well?
Invictus Launch Week at the Tobin Convention Centre was fantastic to see, as were the new space-station docking modules and military docks for the event. Outside of what we released in Alpha 3.13, it allowed the team to focus on making solid progress on future locations for the game.

What didn’t go so well?
The docking feature caused some back and forth among the various teams involved, reducing efficiency. The trolley push/pull feature created a lot of bugs for the teams that could have been reduced too.

What we’ll do differently in the future
Internally, we follow a process of features and locations having a ‘go/no go.’ With regards to a feature like docking, the teams were very compressed in building the feature and creating the locations at the same time. In the future, to reduce the inefficiency this creates, we will look to have more of a buffer between a feature being made and the location being made that utilizes it.