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.