Alpha 3.12 Postmortem Am 17. Dezember 2020 haben wir die Alpha 3.12: Assault on Stanton veröffentlicht, die eine Reihe von neuen Features und Änderungen eingeführt hat, darunter Raffinerie-Decks, KI-Verbesserungen und Gaswolken. Der folgende Postmortem stammt von den leitenden Entwicklern selbst und beschreibt, was geliefert wurde und was sie darüber denken, wie es gelaufen ist. Nebenbei bemerkt konzentriert sich dieser Postmortem speziell auf den Alpha 3.12 Patch - wir werden einen separaten Postmortem Comm-Link veröffentlichen, der sich auf das dynamische Ereignis XenoThreat konzentriert.
Fahrzeug-Team
Was gut lief
Das Vehicle Pillar hat vor allem die Arbeit anderer Teams für Star Citizen Alpha 3.12 unterstützt, vor allem bei den Kämpfen mit Großkampfschiffen vor den Events Arlington Bounty, CS5 UEE Navy Idris und XenoThreat. Wir haben nicht nur daran gearbeitet, wie die Fahrzeuge funktionieren und sich verhalten (sie sind die größten Schiffe, die bisher auf den Servern eingesetzt wurden), sondern haben auch dabei geholfen, mit der erhöhten Tödlichkeit von Torpedos umzugehen, indem wir intelligentere und effektivere KI-Gegenmaßnahmen eingesetzt haben.
Die Spieler profitierten auch von dieser Arbeit mit der Möglichkeit, die Art der Gegenmaßnahme zu wählen und wie viele in einem Burst abgefeuert werden, was eine größere taktische Auswahl bei der Ablenkung von ankommenden Raketen und Torpedos ermöglicht. Wir haben auch weitere HUD-Elemente hinzugefügt, damit die Spieler sehen können, wie viele von jedem Typ sie übrig haben, zusammen mit der aktuellen Burst-Größe.
Die letzte Änderung an den Gegenmaßnahmen war eine Erweiterung der Änderungen aus Alpha 3.11. Dies führt dazu, dass jeder Gegenmaßnahmentyp gegen alle Raketensuchertypen funktioniert, aber die Effektivität in Abhängigkeit von der Art und Anzahl der ankommenden Raketen verändert. Täuschkörper ersetzten Leuchtraketen als zeitlich begrenzte, punktuelle Ablenkung, während Lärm, ehemals Düppel, zu einem flächendeckenden Signalblocker wurde (mehr abgeschossene Gegenmaßnahmen bieten eine höhere Chance auf Spoofing). Wir haben auch die Raketen selbst verändert, um eine kleine Varianz in ihrer Verfolgung zu ermöglichen, damit eine erfolgreiche Gegenmaßnahme nicht alle Raketen gleichermaßen ablenkt. Zusätzlich zur manuellen Steuerung der Burst-Größe fügten wir eine Panikfunktion hinzu, die 25% der verfügbaren Gegenmaßnahmen leert, um eine Flut von ankommenden Raketen zu überwältigen.
Was nicht so gut geklappt hat
Wir entdeckten eine Menge Probleme mit dem Raketen-Setup und der Balance, die zu seltsamen Verhaltensweisen führten. Wir haben uns jedoch entschieden, dies zu belassen, bis die Raketen in der Alpha 3.13 auf IFCS 2.0 umgestellt werden, da dies eine umfassende Überarbeitung aller Verhaltensweisen der Raketen von Grund auf erfordert. In der Zukunft wollen wir die Gegenmaßnahmen erweitern, indem wir den Spielern ein besseres Feedback zu ihren eigenen Signaturen und Raketenfähigkeiten geben, was mit dem Missile Operator Mode kommen wird. Die Fahrzeug-Eingangs-Identifikation war ein viel gefordertes Quality-of-Life-Feature (aufbauend auf den ASOP-Hangar-Spawn-Benachrichtigungen der Alpha 3.11), das es den Spielern ermöglicht, die Einstiegspunkte in ein Schiff schnell zu identifizieren. Diese Markierungen aktualisieren sich je nachdem, ob das Schiff gelandet ist oder sich in der Schwerelosigkeit befindet, was eine häufige Beschwerde neuer Spieler beseitigt, die nicht herausfinden konnten, wie sie in ihr Schiff gelangen. Gelegentlich sind diese Anzeigen wild vom Fahrzeug abgewichen, was wir untersuchen, aber das war so ziemlich das einzige negative Problem mit dem Feature und es wurde allgemein gut angenommen. Die Hauptinhalte der Alpha 3.12 waren die Esperia Talon und Talon Shrike, zwei leichte Jäger, die das Line-Up im Spiel erweitern. Im Allgemeinen liefen diese ziemlich gut und wir diskutierten ihre Entwicklung in mehreren ISC-Episoden, einschließlich unserer Arbeit am Hard Surface Shader und irisierenden Materialien. Leider gab es bei der Veröffentlichung ein paar Probleme, die wir in zukünftigen Patches beheben wollen. Dazu gehören der Bildschirm, der im Arena Commander umgeschaltet werden muss (auch auf dem Prowler) und die Raketenwerfer der Talon Shrike, die manchmal nicht mehr funktionieren, nachdem eine große Anzahl von Raketen abgefeuert wurde. John Crewe Fahrzeug Direktor
USPU-Gameplay-Feature-Team Das vierte Quartal ist für das USPU Team immer ein arbeitsreiches. Nicht nur für uns, sondern für das gesamte Unternehmen. Hier ist eine kurze Zusammenfassung unserer wichtigeren Initiativen, die wir während des Quartals in die Hände bekommen konnten. Zum Glück mussten wir dieses Jahr keine große CitizenCon-Demo vorbereiten, aber das hat uns nicht davon abgehalten, extrem beschäftigt zu sein. Internationale Luft- und Raumfahrt-Ausstellung (IAE) Was gut lief
Wir haben unseren IAE-Inhalt erfolgreich in den High-Tech-Art-Stil erweitert, der auf New Babbage auf dem Planeten microTech stattfand. Wir fügten der Veranstaltung in diesem Jahr einige neue Dinge hinzu, die versuchten, auf die Kommentare der Fans einzugehen. Erstens ließen wir die Ausstellungshalle jedes Herstellers an zwei aufeinanderfolgenden Tagen laufen, für den Fall, dass die Fans den ersten Tag verpasst hatten, und wir verlängerten die kostenlose Ausleihzeit von einem auf zwei Tage. Hoffentlich haben diese beiden Dinge jedem die Möglichkeit gegeben, die Schiffe zu mieten, die er unbedingt ausprobieren wollte. Wir hatten auch zwei Ausstellungshallen an einem Tag. Dies ermöglichte es den Spielern, mehr Dinge zu sehen, und im Sinne von "mehr Dinge zu sehen" haben wir beschlossen, viele unserer Schiffskomponenten und Waffen in der Haupthalle zu präsentieren. Mit zwei aktiven Hallen pro Tag und all den zusätzlichen Gegenständen war dies ein wahrer Beweis dafür, dass unsere Technik immer mehr optimiert wird, da wir in der Vergangenheit niemals in der Lage gewesen wären, dies zu tun. Um die Zugänglichkeit zu erhöhen, haben wir in der "Best In Show"-Halle, die vier Tage lang lief, eine Reihe von Verleihkiosken aufgestellt. In diesen Kiosken haben wir jedes Fahrzeug, das im Laufe der Show gezeigt wurde, untergebracht und die gleiche zweitägige Mietdauer gewährt. Wir denken, dass dies die ansprechendste Iteration war, die wir bis jetzt geschaffen haben.
Was nicht so gut gelaufen ist
Wir hatten zwei Fahrzeuge, die auf der IAE-Show vorgestellt wurden und deren Entwicklung wirklich auf der Kippe stand. Letztendlich konnten wir den Build erst ein paar Tage vor der Show fertigstellen. Da die Messe im November für die Öffentlichkeit zugänglich ist, musste der Build als Point-Patch zur Alpha 3.11 veröffentlicht werden. Die Tatsache, dass wir nicht in der Lage waren, den Build abzuschließen, bevor wir auf den Alpha 3.12 Build verzweigt haben, verursachte einige Kopfschmerzen bei der Dateiverwaltung. Kritische Korrekturen werden immer noch am Point-Release vorgenommen und die gleichen Korrekturen müssen auch im neu verzweigten Stream-Content enthalten sein. Das führt unweigerlich dazu, dass die Arbeit hier und da eingestampft wird und frisst am Ende des Tages wertvolle Zeit, die für die Behebung anderer Fehler oder die Entwicklung neuer Dinge genutzt werden könnte. Außerdem sickerten einige Dinge durch, die wir eigentlich bis kurz vor dem Event geheim halten wollten. Das war kein großes Problem, aber es ist immer schön, wenn man die Fans von Zeit zu Zeit überraschen kann.
Was wir in Zukunft anders machen werden
Ein paar Dinge, auf die ich mich wirklich konzentrieren möchte, wenn wir mit diesem Event weitermachen, sind: Modularität/Wiederverwendung von Assets aus früheren Events. Je schneller wir diese Events umsetzen können, desto mehr Zeit haben wir, um uns auf neue Content-Ideen oder andere Sonnensysteme zu konzentrieren. Vorproduktionsplanung. Wir wissen, dass das Event im nächsten November wieder stattfinden wird, also möchte ich Dinge wie das Farbschema, Eventlogos, die Location, etc. so früh wie möglich ausbügeln. Auf diese Weise muss niemand auf eine Entscheidung warten, wenn es Zeit ist, an den Inhalten zu arbeiten, und wir können einfach unsere Köpfe hinlegen und arbeiten. Bringe alle Inhalte für das Event in den Build, so dass wir eine Punktveröffentlichung vermeiden können. Wie bereits erwähnt, sind zwei parallel laufende Release-Streams/Abzweigungen einfach nur eine Einladung zum Ärger.
Reputationssystem
Was gut gelaufen ist
Ein weiteres wichtiges System, das in Q4 hinzugefügt wurde, war das Rufsystem, das wir schon immer haben wollten. Während es für die Spieler noch nicht sichtbar ist, können sie es durch unsere Missionsgeber und einige unserer Missionsketten erleben (die Kopfgeldjägerkette ist die bemerkenswerteste Serie, die derzeit durch Rufgewinne freigeschaltet wird). Noch sind nicht alle Missionen auf das neue System umgestellt, aber das wird ein fortlaufender Prozess in den nächsten ein bis zwei Quartalen sein. Dieses neue Rufsystem wird die Grundlage für eine beträchtliche Anzahl von Gameplay-Systemen sein, während wir vorankommen. Es wird nicht nur der Hauptweg sein, auf dem Inhalte für die Spieler freigegeben werden, sondern es wird auch mit Dingen wie den Reaktionen der NPCs (derzeit in den Missionsgebern zu sehen), den Vergünstigungen und Vorteilen, die durch die Teilnahme an Inhalten verdient werden können, für die Verfolgung des Spielerfortschritts durch die Karrierewege, für das Diktieren der Beziehungen zwischen den Organisationen innerhalb des Spiels und einer Reihe von anderen essentiellen Gameplay-Schleifen verbunden sein. Wir hatten das Gefühl, dass dies so wichtig für das Spiel war, dass wir uns dafür entschieden haben, es ohne eine dem Spieler zugewandte UI zu veröffentlichen (was für die Veröffentlichung in Q1/Q2 in Arbeit ist). Aber da dies in einer beträchtlichen Anzahl von Systemen in der Zukunft so tief verwurzelt sein wird, dachten wir, dass es das Opfer wert ist. Es wird nicht nur in einer eigenständigen Reputations-UI dargestellt, die es den Spielern erlaubt, ihre Karrierestrecken bei verschiedenen Organisationen einzusehen, sondern auch die wichtigsten NSCs, mit denen sie interagiert haben, zusammen mit ihrem aktuellen Stand bei jedem von ihnen zu verfolgen. Die Reputationen werden in diesem UI sichtbar sein, sobald sie im Universum auf sie stoßen, so dass es die Spieler dazu ermutigt, herumzureisen und sich mit den Inhalten zu beschäftigen, um sie freizulegen. Zusätzlich werden wir den Missionsmanager überarbeiten, um den Spielern die Möglichkeit zu geben, zu sehen, welche Art von Rufanforderungen sie benötigen, um Missionen zu erhalten. Der Ruf wird eine der größten Fortschrittsmechaniken in Star Citizen sein, abgesehen von der Wirtschaft, da wir ein fähigkeitsbasiertes Sandbox-Spiel sind, das nicht durch "Leveling"- oder "Talentbaum"-Systeme angetrieben wird. Die Reputation ist nun auch im Backend servicegesteuert. Das bedeutet, dass alle Rufgewinne zwischen den Patches erhalten bleiben, was eine großartige Sache für die Spieler sein wird.
Was nicht so gut gelaufen ist
Was die allgemeine Entwicklung dieses Features angeht, so lief es ziemlich reibungslos, sobald wir uns in die Arbeit gestürzt hatten. Wir hatten etwa ein Jahr zuvor mit der Arbeit daran begonnen, aber leider wurden wir zu dieser Zeit von einigen Dingen mit höherer Priorität abgehalten. Wenn ich noch einmal die Wahl hätte, würde ich das Team so lange daran arbeiten lassen, bis es fertig ist und die gewünschten UI/UX-Änderungen vorgenommen wurden. Das UI nicht mit dem Release fertig zu haben, ist zwar nicht spielentscheidend, aber ein kritischer Teil dieses Features. Um sicherzustellen, dass alle unsere Features intuitiv sind, sind wir oft auf diese Art von visuellem Feedback angewiesen.
Was wir in Zukunft anders machen werden
In Zukunft würde ich gerne versuchen, die nötige Zeit einzuplanen, um ein "kompletteres" Feature zu veröffentlichen. Es ist zwar nicht immer möglich, alle bestehenden Inhalte eines Spiels auf neue Systeme wie dieses umzustellen, aber ich würde gerne versuchen, sicherzustellen, dass wir mehr tun können, wenn große Änderungen wie diese in der Zukunft passieren. Ich war froh, dass wir mehr als die ursprüngliche Absicht umgesetzt haben, aber ich hätte gerne mehr Zeit mit dem Missionsteam gehabt, um noch mehr zu konvertieren, als wir es getan haben. Das nächste Mal, wenn so etwas Grundlegendes ansteht, würde ich persönlich gerne einen besseren Job machen, um das globale Bewusstsein im Unternehmen zu erhöhen, damit wir so viel wie möglich umwandeln können.
Front End Konvertierung zu Building Blocks
Was gut lief
Wir waren in der Lage, die ersten zwei Screens im Frontend auf unsere Building Blocks Technologie umzustellen. Im Allgemeinen denke ich, dass dieser Prozess ziemlich gut gelaufen ist. Es brauchte nicht viele Leute und war eine ziemlich eigenständige Arbeit. Wir hatten auch die Möglichkeit, ein paar Dinge zu beheben, die wir seit der Einführung des "Neue Freunde"-Services in Q1 2020 angehen wollten. Die Umstellung auf unser neues UI-System erlaubte es uns auch, alle UI-Elemente zusammen auszublenden. Dieser Prozess gab uns die Zeit, das Frontend kritisch zu durchdenken, da sich das Projekt in den letzten Jahren so sehr entwickelt hat. Wir haben es auch so eingerichtet, dass die aktuelle Lösung skaliert werden kann, wenn wir weitere Solarsysteme hinzufügen. Wir haben den Hauptbildschirm aufgeräumt, damit wir einen größeren Blick auf die Hintergrundbilder haben. Ich bin froh, dass wir in der Lage waren, jeder möglichen Landezone ein anderes Bild zuzuordnen; ich denke, es hilft neuen Spielern wirklich, ein Gefühl dafür zu bekommen, welche Art von Ort sie wählen.
Was nicht so gut gelaufen ist
Das Frontend ist sehr stark mit dem ursprünglichen CryEngine-Toolset verwurzelt, mit dem wir ursprünglich angefangen haben. Das Building Blocks System arbeitet auf Basis von Entitäten, was bedeutet, dass unsere Kerndaten geladen werden müssen, damit wir eine Entität haben, auf der wir den Canvas ausführen können. Außerdem erfordert das ursprüngliche System, dass ein Level geladen wird. Aus diesem Grund waren wir nicht in der Lage, irgendwelche Elemente zu ersetzen, bevor wir ausgewählt haben, welchen Spielmodus die Spieler spielen wollen (zumindest nicht mit der auf Building-Blocks basierenden Tech/Implementierung). Die ultimative Lösung wäre eine komplette Überarbeitung dieser Codebasis, aber das lag weit außerhalb des Rahmens dessen, was wir bewältigen konnten, und war auch nicht unsere Hauptdirektive hier.
Was wir in Zukunft anders machen werden
Die Quintessenz hier ist, dass das Spiel, auf dem unser ursprüngliches Frontend basierte, sich sehr von dem Spiel unterscheidet, auf das wir heute hinbauen. Ich bin mir nicht sicher, wie sehr das USPU Team das Frontend in der Zukunft verändern wird, aber wenn wir hier das nächste Mal Änderungen vornehmen, würde ich wirklich gerne auf die endgültige Vision hinarbeiten. Das würde uns erlauben, das neue Benutzererlebnis wirklich zu optimieren, so dass der Einstieg ins Spiel zum ersten Mal oder der Wiedereinstieg für zurückkehrende Spieler so einfach und intuitiv wie möglich ist. Da wir die neuen Features nach und nach eingebaut haben, hat dieser Teil des Spiels darunter gelitten. Wenn dies von Grund auf neu definiert werden kann, gibt es eine Menge, was wir anders machen würden, basierend darauf, wie sehr sich das Spiel entwickelt hat.
Rob Reininger
Lead System Designer und USPU Product Owner
Systemische Dienste & Tools Team Was gut gelaufen ist
Das Systemic Services and Tools (SST) Team hat weiter an der Quantum Simulation gearbeitet und sie in die Services integriert, neben internen Präsentationen neuer Technologien, die wir bald mit der Community teilen werden.
Administrative Arbeit fand im letzten Quartal statt, um die internen CIG Ressourcen für SST umzuschichten. Das Team wird vergrößert, um dem wachsenden Bedarf an Dienstleistungen und Support für Quantum in vielen Aspekten des Spiels gerecht zu werden.
Außerhalb der Dienstleistungen und der Simulationsarbeit hat SST neue Tools entwickelt, um das kommende Reputationssystem zu unterstützen und die Art und Weise, wie Reputation im Spieluniversum verteilt wird. SST unterstützt weiterhin die Star Citizen Wirtschaft mit Data Tools, um die massive Datenmenge zu lindern, während wir uns darauf vorbereiten, dass Quantum die Zügel in die Hand nimmt.
Was nicht so gut gelaufen ist
Während wir zu einer größeren Abteilung werden, hatten wir einige Wachstumsschmerzen mit unseren Reaktionszeiten auf andere Teams. Features wie der Raffinerie-Service bekamen nicht die sofortige Aufmerksamkeit, die sie brauchten, während unsere Aufmerksamkeit woanders lag.
Was wir in Zukunft anders machen werden
Wir suchen nach Möglichkeiten, die Arbeit, die bei SST ankommt, für das wachsende Team besser zu rationalisieren und zu verteilen. Außerdem haben wir automatisierte Nachrichten eingerichtet, um die Kommunikation zwischen SST und den abhängigen Teams zu ergänzen.
Jake Mühle
Senior Technischer Designer
Design Team KI fängt Torpedos ab Was gut lief
Die Geschütztürme der Idris, die Torpedos abfangen, funktionieren gut und es gibt einige sehr coole Momente, wenn sie erfolgreich abfangen.
Was nicht so gut gelaufen ist
Die KI-Genauigkeit ist nicht gut genug, um ankommende Torpedos zuverlässig abzuschießen, abhängig von der Framerate des Servers.
Was wir in Zukunft anders machen werden
Wir werden uns bemühen, die KI-Genauigkeit zu verbessern, damit wir mehr Kontrolle darüber haben, wie viele Torpedos durch die Turmverteidigung schlüpfen.
KI-Feuermodus-Nutzung und Zielprioritäten
Was gut gelaufen ist
Die KI, die Burst-Feuer verwendet, verbessert das Aussehen des KI-Turmfeuers erheblich. Außerdem stellen die Zielprioritäten sicher, dass die KI ein vernünftiges Ziel für ihre Schiffsklasse und Geschützgröße angreift.
Was nicht so gut gelaufen ist
Im Moment benachteiligt die Verwendung von Burst-Fire die KI im Vergleich zu den Spielern, da vollautomatisches Feuern den Schaden erhöht.
Was wir in Zukunft anders machen werden
Wir werden die KI-Serienfeuer neu ausbalancieren, wenn Kondensatoren eingeführt werden, um die Effektivität des Gedrückthaltens der Feuertaste zu reduzieren.
KI-Genauigkeitskonvergenz
Was gut gelaufen ist
Das neue Genauigkeitssystem verhält sich glaubwürdiger, da es die Position des Ziels verfolgt und weiter auf diese Position feuert, bis sich das Ziel bewegt. Das ist besser als das alte System, bei dem das Ziel der KI wild hin und her schwankte, während sie versuchte, stationäre Ziele vor ihr zu verfehlen.
Was nicht so gut geklappt hat
Die KI ist noch nicht genau genug, um den Spieler ernsthaft zu bedrohen. Außerdem neigt das neue System dazu, hinter die Bewegung des Ziels zu schießen, anstatt davor, sodass die Spieler nicht so oft sehen, dass sie beschossen werden.
Was wir in Zukunft anders machen werden
Wir wollen die Genauigkeit insgesamt verbessern und es so gestalten, dass verschiedene NSCs einen deutlicheren Unterschied in der Genauigkeit zwischen geübter und ungeübter KI haben. Das Genauigkeitssystem wird auch dahingehend überarbeitet, dass es das Ziel öfter über- als unterschießt.
Kampfverhalten von Großkampfschiffen
Was gut gelaufen ist
Die Großkampfschiffe berücksichtigen nun die Entfernung und die relative Position, wenn sie andere Schiffe angreifen. Großkampfschiffe ohne Frontalgeschütze werden versuchen, nahe genug heranzukommen, um alle ihre Geschütztürme zu nutzen, während Schiffe mit großen Frontalgeschützen versuchen werden, sich aus der Reichweite des Feindes herauszuhalten und ihre mächtigen Fernwaffen zu nutzen.
Was nicht so gut gelaufen ist
Die Taktikauswahl berücksichtigt die Stärke des KI-Schiffs relativ zum Ziel nicht ausreichend. Wenn die Idris zum Beispiel gegen ein Kanonenschiff oder ein Großkampfschiff kämpft, wird sie versuchen, auf Distanz zu bleiben und ihre Railgun zu benutzen. Das macht oft Sinn, kann aber dazu führen, dass sie vor kleineren Kanonenschiffen wegläuft, die sie in einem Nahkampf leicht einnehmen könnte.
Was wir in Zukunft anders machen werden
Wir werden die Taktikauswahl überarbeiten, damit die KI das eigene Schiff und das Ziel detaillierter betrachtet als nur die Schiffsklasse. Außerdem werden wir den Charaktereigenschaften der Piloten erlauben, das Verhalten des Hauptschiffs zu beeinflussen.
Aufzugspaneele
Was gut gelaufen ist
Wir haben erfolgreich den Grundstein für zukünftige Aufzugspaneele (und andere umgestaltbare Bildschirme) gelegt, indem wir sie dazu gebracht haben, ihre Stile vom Transitsystem zu erben und auf jedem geformten Canvas verwendbar zu sein. Das bedeutet, dass alle zukünftigen Panels die gleichen zwei Dateien verwenden können und trotzdem unterschiedlich aussehen.
Was nicht so gut gelaufen ist
Das Transitsystem ist in seiner jetzigen Form sehr schwierig einzurichten und zu testen - das UI Team war nicht in der Lage, es richtig zum Laufen zu bringen und musste sich bei der Implementierung auf das Level Design verlassen. Allerdings haben UI und Level Design nicht gleichzeitig an dem Feature gearbeitet, was dazu führte, dass die Arbeit in unterschiedlichen Strömen begann und endete und Bugs übersehen wurden. Neue Building Blocks Styles sind extrem zeitaufwendig zu implementieren, da es an Werkzeugen mangelt und die Dateien nicht zusammengeführt werden können.
Was wir in Zukunft anders machen werden
Wir werden sicherstellen, dass das Feature in einem Rutsch in einem Feature Stream entwickelt, implementiert und getestet wird, so dass Bugs aufgegriffen und behoben werden, bevor es "fertig" ist. Wir werden auch sicherstellen, dass das Team, das für das Feature verantwortlich ist, Zeit hat, um Code-Probleme als Teil des Feature-Entwicklungszyklus zu beheben und dass das UI-Team sich auf die Benutzeroberfläche konzentriert.
Stationsbasiertes Refining
Was gut gelaufen ist
Wir haben den ersten Gameplay-Loop für das Raffinieren fertiggestellt, komplett mit Raffinerien, die ihre eigenen Materialspezialisierungen und Arbeitslasten haben, und der Möglichkeit, raffinierte Materialien an verschiedenen Orten in der Galaxie zu sammeln und zu verkaufen. Die Raffinerie-Decks selbst sehen spektakulär aus und die Benutzeroberfläche des Raffinerie-Terminals ist an einem großartigen Ort, um den Gameplay-Loop mit sehr wenig Nacharbeit zu erweitern, was eine schnellere Iteration in der Folge bedeuten sollte.
Was nicht so gut gelaufen ist
Unsere Planung für jeden Schritt war extrem gründlich, jedoch konnten wir aufgrund mehrerer Situationen, die außerhalb unserer Kontrolle lagen, nicht früh genug einen Punkt erreichen, an dem wir den Raffinerie-Loop so ausbalancieren konnten, wie wir es vorhatten. Daher haben wir ein weiteres, bereits geplantes Set von Änderungen in Form des ersten Bergbau-Rebalances vorgezogen, um so gut wie möglich zu kompensieren, bis wir die Raffinerie-Balance auf das Niveau bringen können, das wir ursprünglich wollten. Dieses Bergbau-Rebalance hatte den zusätzlichen Bonus, dass es den MISC-Prospector ein wenig attraktiver für Leute machte, die mit ihm anfangen oder ihn mieten wollten, und dass es mehr Spielerfahrung für die Argo MOLE oder mehrere Spieler mit Prospectors bot.
Was wir in Zukunft anders machen werden
Die UI-Kunst früher spielerisch testen lassen. Einige Spieler wussten nicht, mit welchen Teilen des Bildschirms sie interagieren können und das hätte uns mehr Zeit gegeben, um Änderungen vorzunehmen.
Bergbau UI Refactor
Was gut lief
Wir haben die gesamte Bergbau-UI überarbeitet, um mit Building Blocks zu arbeiten. Das ging viel reibungsloser, als wir es uns je erhofft hatten, da ein großer Teil des Mining-Gameplay-Loops direkt mit Building Blocks funktionierte, ohne dass wir viel nacharbeiten mussten. Das gab uns den Spielraum, mehr zur Mining UI hinzuzufügen, als wir ursprünglich vorhatten. Das bedeutet, dass wir nicht nur eine komplett neue UI bereitstellen konnten, die über drei verschiedene Mining-Fahrzeuge hinweg skalierbar ist, sondern wir haben diese Skalierbarkeit gezeigt, indem wir schnell UI-Canvas-Teile iteriert haben, um zuvor eingeführte Systeme zu unterstützen. Dazu gehörte auch die flüchtige Ladung und ein komplett neues Laderaumteil, das den Spielern weitere Informationen bietet, die wir schon immer bereitstellen wollten, aber nie die Möglichkeit hatten, dies zu tun.
Was nicht so gut gelaufen ist
Der erste Durchgang des UI-Refactors für den Bergbau war schwieriger zu implementieren als zu bauen, da verschiedene Fahrzeuge unterschiedliche Flächen für das UI zur Verfügung hatten, was bedeutete, dass eine Menge Tweaking hinter den Kulissen nötig war, um das UI tatsächlich auf eine komfortable Weise darzustellen. Wir arbeiten immer noch an der Feinabstimmung und hoffen, dass wir die Benutzeroberfläche in Zukunft auf eine visuell ansprechendere Art und Weise darstellen können, die besser funktioniert als die aktuelle Implementierung.
Was wir in Zukunft anders machen werden
Wir werden in Zukunft schneller iterieren, da wir jetzt ein besseres Verständnis von Building Blocks und seinen Vorteilen haben.
Todd Papy
Star Citizen Live Direktor
Kern Gameplay Säule Multi-Tool Traktorstrahl Der Multi-Tool Tractor Beam ist eine aufregende Ergänzung zum 'Verse' und ist ein Kernstück der Funktionalität, die mehrere Gameplay-Loops freischaltet, an denen wir arbeiten, wie z.B. Frachttransport und EVA-Traversalräume. Der Hauptanwendungsfall für den Tractor Beam in Alpha 3.12 ist das einfachere Einsammeln von Frachtkisten in EVAs, entweder während verlorener Weltraummissionen oder für das Einsammeln von Beute nach einem Schiffskampf. Oberflächlich betrachtet ist der Tractor Beam ein einfaches Werkzeug, aber unter der Haube passiert eine Menge und ich denke, das Team hat einen fantastischen Job gemacht, um ein wirklich systemisches Feature zu erschaffen, das zugänglich und einfach zu benutzen ist. Die erste Herausforderung, mit der wir konfrontiert waren, war, dass wir wollten, dass es in verschiedenen Schwerkraft-Einstellungen funktioniert und das Gewicht eines Objekts ausnutzt. Dies führte zu mehreren Problemen, da in der Schwerelosigkeit alles schwerelos ist, was bedeutet, dass man potentiell etwas Riesiges bewegen kann, das sehr wenig wiegt. Zum Beispiel eine planetengroße Styroporkugel. Wir haben den Tractor Beam um zwei Kernkonzepte herum entworfen - Volumen und Kraft. Das Volumen diktiert die generelle Größe des Objekts, das du anheben kannst, während die Kraft die Menge an Anstrengung diktiert, die die Waffe aufbringen muss, um das Objekt anzuheben. Das bedeutet, dass für jeden Gegenstand, der eine Masse und einen Physikkollider hat (was jeder Gegenstand bereits haben sollte), die Kraft, die benötigt wird, um ihn anzuheben, automatisch anhand der Schwerkraft der Umgebung berechnet wird. Dies erlaubte uns, ein Feature zu bauen, das mit jedem Physik-Objekt im Spiel funktioniert, ohne dass wir eine Menge manueller Einstellungen vornehmen müssen. Die zweite Herausforderung war, wie erklären wir dem Spieler, was er heben kann und was nicht, ohne alles mit ADS zu belegen oder, noch schlimmer, Versuch und Irrtum anzuwenden. Glücklicherweise hat das Multi-Tool bereits einen kleinen Bildschirm auf der Rückseite, der es uns ermöglichte, eine einfache Ikonographie zusammen mit einem Ampel-Farbcodierungssystem zu implementieren. Das bedeutet, dass wir in der Lage sind, alle fünf Zustände eines Objekts deutlich zu zeigen, indem wir es einfach anschauen: Objekt kann angehoben werden Objekt kann angehoben werden, ist aber außer Reichweite Objekt ist zu schwer Objekt kann niemals angehoben werden Du wirst zu dem Objekt reisen Obwohl wir zusätzliche Informationen in der ADS-Ansicht zur Verfügung gestellt haben, befindet sich alles, was du wissen musst, auf der Rückseite des Werkzeugs und ich war wirklich froh, dass wir so viele Informationen in einen so kleinen Bildschirm destillieren konnten.
Was nicht so gut gelaufen ist
Wenn du ein Feature planst, solltest du das Haupterlebnis identifizieren und dann alle sekundären Mechaniken skizzieren, die dieses Erlebnis verbessern würden. Zum Beispiel ist eine Sprungmechanik für sich genommen ein eigenständiges Feature, aber du könntest entscheiden, dass die Kontrolle in der Luft (eine sekundäre Mechanik) das Kernerlebnis verbessert. Mit dem Traktorstrahl haben wir uns hingesetzt und das Haupterlebnis identifiziert, nämlich die Möglichkeit, Objekte zu manipulieren und ihn als Greifhaken in EVA zu benutzen, und ich glaube, das haben wir geschafft. Aber es gab einige sekundäre Mechaniken, die ich gerne eingebaut hätte, für die uns aber die Zeit fehlte. Insbesondere die Möglichkeit, die Flugbahn mit den Triebwerken des Anzugs zu manipulieren, wenn man den Greifhaken in der Schwerelosigkeit benutzt.
Leider funktionierten die beiden Systeme nicht wirklich gut zusammen, da die Kraft, die zum Ziehen verwendet wurde, die Kraft der Anzugtriebwerke überlagerte. Es war auch nicht hilfreich, dass EVA zur gleichen Zeit auf IFCS umgestellt wurde, was dazu führte, dass wir uns auf die Kernfunktion konzentrieren mussten, um sicherzustellen, dass diese bis zur Veröffentlichung so gut wie möglich ausgefeilt war. Das passiert bei Features immer wieder und liegt in der Natur der Spieleentwicklung, aber es war eine Schande, dass es in der ersten Iteration fehlte. Wir werden diese Funktionalität in einer späteren Version hinzufügen.
Was wir in Zukunft anders machen werden
Um ein Feature zur Veröffentlichung zu bringen, müssen viele verschiedene Teams zusammenarbeiten, von VFX über Audio bis hin zum Feature-Team, das an der Funktionalität arbeitet. Eines der größten Dinge, die ich versuche zu verbessern, ist, den Missionsdesignern mehr Zeit zu geben, damit sie all diese verschiedenen Features sinnvoll in das Verse integrieren können. Wenn du meine vorherigen Postmortems gelesen hast, wirst du wahrscheinlich einen Trend erkennen, dass dies etwas ist, was ich aktiv versuche zu verbessern, aber da mehrere Teams und Zeitpläne involviert sind, braucht es ein wenig Zeit, um sich umzustellen. Wenn ich in der Zeit zurückgehen könnte, hätte ich wahrscheinlich versucht, eine einfache Version früher in die Hände der Missions-/Leveldesigner zu bekommen, damit sie ein bisschen mehr damit spielen konnten.
Waffennullstellung
Was gut lief
Das Weapon Zeroing, wie der Titel schon sagt, erlaubt es dir, deine Waffen auf verschiedene Entfernungen zu nullen, was dir erlaubt, auf viel weitere Entfernungen genau zu schießen. Das bedeutet, dass das Zielfernrohr den Abfall des Geschosses in einer bestimmten Entfernung berücksichtigt und dir erlaubt, die Visierung so einzustellen, dass du dein Fadenkreuz immer noch auf das Ziel richten kannst. D.h. du musst nicht über das Ziel hinaus zielen. Wir haben bereits viele Zielfernrohre zur Verfügung und die erste Herausforderung war zu entscheiden, welche Zielfernrohre überhaupt nullen sollten und dann zu entscheiden, ob sie automatisch oder manuell nullen sollten. Dies führte zu einer viel breiteren Diskussion über Hersteller und ihre spezifischen Eigenschaften, wie High-Tech oder Low-Tech. Während das Team sich nur auf das Feature hätte konzentrieren und es herausbringen können, haben sie auch einen langfristigen Plan für die Zielfernrohrbefestigungen geliefert, nicht nur für aktuelle Hersteller, sondern auch für zukünftige.
Das ist etwas, woran ich grundsätzlich glaube - dass wir, auch wenn wir an einem Live-Produkt arbeiten, Entscheidungen rund um die finale Erfahrung im veröffentlichten Spiel treffen sollten. Manchmal ist das schwer, da es bedeuten kann, dass bestimmte Features auf den ersten Blick nicht in ihrem besten Licht gesehen werden oder kurzfristig von den Spielern missverstanden werden. Aber es ist mein Job, sicherzustellen, dass wir auf die finale Vision hinarbeiten und das Team hat einen fantastischen Job gemacht, ein Feature bereitzustellen, das Spaß macht, aber in der Zukunft skalierbar ist.
Was nicht so gut gelaufen ist
Dies war das erste Feature, an dem eines unserer neuesten Teammitglieder gearbeitet hat. Daher stellten wir sicher, dass er genug Zeit hatte, um es weit vor dem eigentlichen Release zu liefern. Tatsächlich wurde die Funktionalität (nicht die Optik) im Quartal davor geliefert und er hat einen tollen Job gemacht. In den meisten Fällen ist das fantastisch, da es bedeutet, dass wir uns auf das Erlebnis konzentrieren und sicherstellen können, dass es von höchster Qualität ist. In diesem Fall jedoch konnte sich das Testteam aufgrund anderer Prioritäten und der Tatsache, dass dies so weit vor der Veröffentlichung geschah, nicht voll und ganz darauf konzentrieren, da es (berechtigterweise) damit beschäftigt war, Dinge zu überprüfen, die kurz vor der Veröffentlichung standen. Unglücklicherweise bedeutete dies, dass ein grundlegender Edge Case bis kurz vor der Veröffentlichung übersehen wurde, nämlich dass das Zeroing nicht funktionierte, als die Physik-Patches für die Umgebung herauskamen.
Lass mich das erklären. Wenn ein Charakter auf einem Planeten spawnt, spawnen eine Reihe von Patches (Quadrate) um ihn herum in immer größer werdenden Größen. Diese Patches decken die Renderqualität (Grafik) und die Physikkollision ab, wobei weiter entfernte Patches weniger Details und schließlich keine Kollision mehr haben (da die Physik relativ teuer ist). Wenn du dich nun bewegst, werden die Patches dynamisch aktualisiert, aber nicht eins zu eins. So kann ein Patch, in dem du dich gerade befunden hast, immer noch seine Kollision haben, da du vielleicht dorthin zurückkehren möchtest und es performanter ist, ihn kurzfristig dort zu behalten, als ihn ständig zu laden und zu entladen. In diesem Fall bedeutete es jedoch, dass wenn ein Designer in den Editor geladen wurde, um das Feature zu testen, der Patch geladen war und er sich dann 2 km weg bewegte, um die Waffen-Nullstellung zu testen und es funktionierte. Wäre ein Spieler jedoch nie an die ursprüngliche Position gegangen, gäbe es keine Kollision und somit hätte das Zielfernrohr nichts, gegen das es testen könnte. Das bedeutete, dass es unter normalen Spielbedingungen nicht wie beabsichtigt funktionierte, also mussten wir den Code für die Waffennullstellung neu schreiben, um gegen die Rendergeometrie zu testen, anstatt gegen die Physikgeometrie. Obwohl diese Änderung nicht groß war, war sie nicht ideal, da wir geplant hatten, an anderen Features zu arbeiten.
Was wir in Zukunft anders machen werden
Wenn ich in der Zeit zurückgehen könnte, würde ich auf jeden Fall sicherstellen, dass das Feature gründlich getestet wurde, als es fertiggestellt wurde, anstatt auf das eher traditionelle Go/No Go zu warten. Obwohl es keinen Einfluss auf die Veröffentlichung des Features hatte Das hatte Auswirkungen auf die zukünftige Arbeit, da wir im Laufe des Quartals die Prioritäten neu setzen mussten.
Gemini A03 Scharfschützengewehr & Behring FS-9 LMG
Was gut lief
Wie bei jeder Waffe, die wir dem Spiel hinzufügen, müssen wir immer sicherstellen, dass sie in die bestehende Waffenmatrix passt und etwas Einzigartiges bietet, das es nicht schon gibt. Mit dem Gemini A03 Scharfschützengewehr war die Absicht, ein leichtes, reaktionsschnelles Scharfschützengewehr mit einem geringeren Kaliber als seine schwereren Gegenstücke, aber hoher Geschwindigkeit und Genauigkeit zu bauen. Ich denke, dass das Team diese Absicht wirklich umgesetzt hat und eine gute Balance zwischen den hochkalibrigen Scharfschützengewehren wie dem P6-LR und den eher angriffsorientierten Waffen wie dem Gemini S71 gefunden hat. Während das A03 eine einfache Ergänzung war, war das Behring FS-9 ein wenig kniffliger. LMGs als Waffenkategorie stehen momentan nicht gut da, da sie auf kurze Distanz von SMGs/Schrotflinten und auf mittlere bis lange Distanz von Sturmgewehren übertroffen werden. Wir sind uns dessen bewusst und haben hinter den Kulissen daran gearbeitet, dies zu verbessern. Der Behring FS-9 setzt den Standard für das, was wir uns von LMGs wünschen - Maschinengewehre mit hoher Kapazität, die es den Spielern erlauben, ein Gebiet ohne großen Verlust an Genauigkeit zu unterdrücken.
Was nicht so gut gelaufen ist
Während wir an der FS-9 gearbeitet haben, haben wir auch die Designabsichten für alle anderen LMGs ausgearbeitet, damit wir ein Update für alle in einem Release liefern konnten. Leider ist uns bei den bestehenden Waffen die Zeit ausgegangen, obwohl wir es geschafft haben, einige Tweaks zu machen, um ihre Effektivität zu erhöhen. Wir planen, die bestehenden LMGs zu aktualisieren, um sie auf die gleiche Qualitätsstufe wie die FS-9 zu heben, aber das bedeutet kurzfristig, dass sie den anderen Waffen der gleichen Kategorie weit überlegen ist. Aber wie ich bereits erwähnt habe, werde ich Entscheidungen immer danach ausrichten, was das Endziel sein soll, damit wir uns ständig weiterentwickeln.
Was wir in Zukunft anders machen werden
Wir haben den Plan, alle Waffenkategorien zu überarbeiten und ihr könnt hoffentlich sehen, dass jede Waffe, die wir veröffentlichen, die vorherigen leicht verbessert. Mit dieser Absicht hätte ich mehr Zeit für den Feinschliff der bestehenden LMGs eingeplant, denn ich hätte sie gerne alle zusammen veröffentlicht. Egal wie erfahren man ist, man lernt immer dazu und das ist etwas, das ich für zukünftige Waffen implementieren werde.
Richard Tyrer
Core Gameplay Direktor
Standorte Raumstation Raffinerie Decks Was gut lief
Für diese Veröffentlichung konnten wir Raffinerie-Decks an einigen speziellen Orten der Raumstation einführen. Diese Räume sind thematisch an die Bergbau- und Raffinerie-Spielschleifen angelehnt und dienen auch als Standort für zukünftige Spielmöglichkeiten. Innerhalb des Raffineriedecks haben wir einen Raum speziell für die Raffination und Verarbeitung geschaffen, zusammen mit einem Shop und einem Gildenraum darunter.
Nachdem wir die Reaktionen auf die Frachtdecks und die neuen Innenräume der Raumstation in Alpha 3.11 gesehen hatten, stimmten wir mit den Kommentaren überein, dass die Spieler mehr sichtbare Verbindungen mit dem Außenbereich sehen wollten, um physisch zu verstehen, wo sie sich in der Station befinden. Obwohl wir mit der Entwicklung des Innenraums des Raffineriedecks schon ziemlich weit waren, schwenkten wir um und passten den Raum an, um das Mini-Aussichtsdeck bei den Aufzug-Lobbys einzubeziehen. Visuell wollten wir schon seit einiger Zeit ein Raumstationserlebnis erkunden, das sich mehr auf industrielle Aktivitäten konzentriert.
Was nicht so gut gelaufen ist
Es war schade, dass keine spezifischen NPC-Loadsouts mit den Raffinerie-Decks veröffentlicht wurden oder dass einige der spezifischen Nutzgegenstände nicht erweitert werden konnten. Diese sind jedoch alle geplant, also werden wir sie hoffentlich bald online sehen.
Was wir in Zukunft anders machen werden
Wie bereits erwähnt, haben wir das Aussichtsdeck erst recht spät im Prozess eingeführt, so dass wir während des Konzepts und des Whiteboxings einen besseren Platz dafür hätten entwerfen können.
Stanton Planet Verbesserungen & Politur
Was gut gelaufen ist
Aufbauend auf den Planetenverbesserungen, die im Laufe von 2020 gemacht wurden, war dies die erste Gelegenheit für das Team, die neuen und verbesserten Arbeitsabläufe, die bei der Erstellung der Planeten und Monde von Pyro entwickelt wurden, in Stanton einzuführen.
Die Verbesserung des Workflows beinhaltete, dass wir die Zeit und den Fokus hatten, tiefer in den globalen Malprozess einzusteigen. Für Planeten wie Stanton I und IV wurde die globale Bemalung komplett überarbeitet, um sowohl die Temperaturparameter genauer einzuhalten als auch eine bessere Mischung und Verteilung der Farbtöne zu erreichen. Als zweiter Teil der Bemalung wurden alle Objektpräsentationen und Verteilungsregelsätze von Grund auf neu erstellt. Im Allgemeinen lag der Fokus darauf, mit weniger mehr zu erreichen. Anstatt also viele Arten von Geologie im gleichen Raum zu verwenden, wurden nur ein oder zwei verwendet, die wirklich gut zusammen funktionieren. Das Endergebnis ist viel realistischer und natürlicher. Ein gutes Beispiel dafür ist Daymar. Ein weiterer Bereich, den wir verbessern wollten, war der verstärkte Einsatz von Bodenstreuungsobjekten, um das Terrain komplexer zu lesen. Wir haben eine Mischung aus Geologie-Assets wie Platten, Geröll und kleinen Felsen mit der Verteilung der Geologie-Packs kombiniert, um der Szene eine viel integriertere Lesart zu geben.
Zusätzlich wurden einige herausragende Geologie-Packs konvertiert, um den organischen Shader zu verwenden und wurden als Teil unserer Pipeline korrekt durch Houdini verarbeitet.
Einige neue Tech-Features kamen in diesem Release online, die wir mit Begeisterung genutzt haben. Das erste ist Terrain Displacement, das POM ersetzt. Jetzt kannst du tatsächlich sehen, wie die Geometrie des Geländes tesseliert und verschoben wird, was eine echte Tiefe und komplexere Überschneidungen mit Objekten ermöglicht. Das zweite Feature ist Biome Accumulation, was bedeutet, dass Assets prozedural eine dünne Materialschicht auf ihrer Oberseite erhalten können, abhängig vom Biome. Zum Beispiel sammelt sich Sand auf der Oberseite der Felsen auf Daymar.
Was nicht so gut gelaufen ist
Als wir versuchten, das Jahr zu beenden und die Alpha 3.12 zu veröffentlichen, konnten einige Monde nicht auf das gewünschte Polishing-Niveau gebracht werden. Außerdem haben wir im Zuge der Einführung unserer neuen Arbeitsabläufe und Methoden in das Stanton-System festgestellt, dass die visuellen Stile zwischen einigen Monden zu eng beieinander liegen und wir dadurch etwas an Vielfalt verlieren.
Was wir in Zukunft anders machen werden
Mehr Assets werden helfen, die Kunstmüdigkeit zu reduzieren und die visuelle Vielfalt zu verbessern, daher werden wir in diesem Jahr Zeit und Energie in mehr Asset-Packs investieren.
Stanton System Spacescaping
Was gut lief
Wir waren alle sehr aufgeregt, die Gaswolkentechnologie als Teil des PU in Alpha 3.12 präsentieren zu können. Viele Teams haben hart daran gearbeitet, dieses neue Feature zu entwickeln. Es ging also darum, ein Team zu gründen, das sich der Erstellung von Inhalten für Stanton widmet, und dann zu schauen, was wir für die Lagrange-Punkte tun können.
Wenn man bedenkt, dass dies die erste Release-Version der Technologie war, denke ich, dass wir eine Vielzahl von visuellen Szenarien geschaffen haben, um das Potenzial der Technologie zu zeigen.
Was nicht so gut gelaufen ist
Da es sich um das erste Release handelte, gab es offensichtlich eine Menge herauszufinden, was die Performance angeht, und es gibt eine Menge, was wir in Bezug auf die Pipeline-Verfeinerung tun können. Außerdem gibt es in einigen Beleuchtungsszenarien sichtbares Rauschen, das wir in Zukunft gerne reduzieren würden, wenn es die Leistung zulässt.
Was wir in Zukunft anders machen werden
Wir sind bereits dabei, unseren Entwicklungsworkflow zu verbessern und suchen nach Möglichkeiten, den Prozess zu verbessern. Wir erforschen, wie wir die Hintergrund-Raumlandschaft in mehr Mini-System-basierte Formen zusammenbinden können, was dann zu kleineren, volumetrischen Gastaschen führt. Für zukünftige Gameplay-Möglichkeiten schauen wir uns an, wie wir das Risiko/Belohnungs-Gameplay innerhalb der Gastaschen mit Elementen wie Blitzen, Strahlung, Temperaturbereichen und Flughandling fördern können.
Ian Leyland
Star Citizen Art Director
Technologie In der Alpha 3.12 konzentrierte sich das Grafikteam hauptsächlich auf die Verbesserung der Stabilität und die Behebung von Fehlern in den verschiedenen Grafikfeatures, die in der Version verwendet werden. Viele der Fehlerkorrekturen bezogen sich auf die Einführung von Gaswolken, wie z.B. das Beheben eines sichtbaren Dithermusters, wenn die Sonne von einer Wolke verdeckt wird und das Verhindern des Clippings von Gaswolken und Partikeln innerhalb von Raumschiffen durch die Verbesserung des volumetrischen Culling- und Partikel-Culling-Systems. Solche Probleme waren zu erwarten, aber größtenteils unvermeidbar, denn obwohl die Technik bei der Entwicklung von SQ42 ausgiebig genutzt wurde, sind die Grafik und die Szenarien in PU ganz anders. Außerdem bedeutete die Sandbox-Natur der PU und die ausgiebigen Tests, die sie erhält, dass viele zuvor unbekannte Probleme entdeckt oder in den Vordergrund gestellt wurden. Das Team schaffte es auch, Dutzende anderer Bugs zu beheben, die von "popping shadows" bis hin zu einer zu hellen Kamerabelichtung reichen, wenn ein Planet hereingestreamt wird. Der Anteil der Zeit, die für die Behebung von Bugs im Vergleich zu neuen Features aufgewendet wurde, war höher, als wir es uns gewünscht hätten, aber am Ende des Jahres liegt der Schwerpunkt immer auf Stabilität und Qualität und die Arbeit an den Features wurde bereits wieder aufgenommen, also ist dies kein Grund zur Sorge. Trotz der Verlangsamung der Feature-Arbeiten haben wir es geschafft, gute Fortschritte beim neuen Gen12-Renderer zu machen, der Anfang 2021 unser Hauptaugenmerk sein wird. Das Physics Team arbeitete an dem volumetrischen Soft Body Prototyp sowie dem damit verbundenen Rendering der volumetrischen Deformation. Außerdem wurden verschiedene Optimierungen in der Physik vorgenommen. Zum Beispiel verbesserten wir das Threading verschiedener Subsysteme, fügten schnellere Spatial Grid Queries hinzu, entfernten Contention beim Zugriff auf die lokale Kommando-Warteschlange und entfernten Contention für die Schrittfunktionen der Actor/Living Entities (Verbesserung der Living Entity Step Performance um einen Faktor von 2x - 5x). Wir haben auch eine bessere Methode zur Vorphysikalisierung der Terrain-Patches des Planeten implementiert, die für Kollisionsprüfungen verwendet werden. In Bezug auf die Kollisionserkennung haben wir auch ein langjähriges Problem behoben, das zusätzliche Geisterkontakte weit weg von den eigentlichen Kontakten einführen konnte. Außerdem wurden Verbesserungen an der Ereignis-Warteschlange vorgenommen. Der erste Entwurf zur Ausbreitung von physikalisierten Schockwellen wurde eingereicht und kastenförmige Physikgitter und Geschosswiderstand wurden hinzugefügt. Die SDF-Unterstützung wurde verbessert und die Forschung an Verbesserungen des Setups der Touch-Bending-Vegetation begann. Beim Renderer haben wir mit der laufenden Gen12-Umstellung und dem damit verbundenen Refactoring weitergemacht. Zum Beispiel fügten wir ein parametrisierbares Feature-Set für die Deferred Pipeline hinzu, implementierten Updates pro Objekt-Ressourcenset (einschließlich RTT-Update für Pinsel) für das Gen12-Szenen-Rendering und Legacy-Pipeline-Status-Caching (um DX-API-Aufrufe zu sparen, während wir noch vollständig auf Gen12 umstellen). Im Shader-System haben wir den gesamten Code für das Nachladen von Shadern aufgeräumt, was die Shader-Bearbeitung während der Entwicklung verbessern wird und eine deutlich verbesserte Reaktion beim Ändern von System-Spezifikationseinstellungen (z.B. Grafikeinstellungen, die die Verwendung verschiedener Shader-Kombinationen erfordern) ermöglicht. Wir haben auch ein größeres Refactoring des Shader-Cache-Backend-Systems begonnen, da es ziemlich veraltet ist und eine ständige Quelle des Ärgers in Bezug auf Wartung und Gen12-Fitness ist. Mehrere Optimierungen wurden im Renderer Code durchgeführt. Zum Beispiel wurde die Art und Weise, wie Materialkonstanten auf die GPU hochgeladen werden, vereinfacht und optimiert. Auf der Grafikseite wurden verschiedene Fixes für die Tiefenschärfe bereitgestellt. Der Haar-Shader erhielt mehrere Verbesserungen, wie die Möglichkeit, spiegelnde Highlights auf den Wimpern zu deaktivieren, verbesserte Boundary Occlusion an Haarlinien, Unterstützung für Umgebungslichter im Forward Shading sowie eine verbesserte Haarqualität bei Kameraschnitten. Die Duallobe-Approximation für den Skin-Shader wurde verbessert und der Eye-Shader erhielt ebenfalls ein paar Verbesserungen. Was Atmosphären, Wolken und den Unified Raymarcher angeht, so sind die im letzten Postmortem erwähnten Verbesserungen nun in Alpha 3.12 verfügbar. Nachdem das aus dem Weg geräumt ist, wurde die meiste Zeit auf das volumetrische Wolkenrendering verwendet. Der erste Entwurf des Wolkenrenderers wurde implementiert und die Arbeit an volumetrischen Wolkenschatten machte gute Fortschritte. Die Arbeit an den Verbesserungen für die lokale Wolkenformung wird beginnen. Beachte, dass es bis zur Veröffentlichung noch eine ganze Menge Arbeit zu erledigen gibt. Für das Kern-Engine-System haben wir einen dynamischen Zonen-Culling-Pfad in das Zonensystem implementiert. Außerdem haben wir ein paar Culling-Fehler in Bezug auf die Sichtdistanz behoben, die mit pixelgroßen Objekten zu tun haben und in Alpha 3.11 auftraten. Die Leute haben bereits bemerkt, dass sie jetzt Spieler sehen können, die über 1000 Meter entfernt sind, anstatt nur ein paar hundert oder so. Eine Menge Bugfixes und Verbesserungen wurden für Vis-Flächen bereitgestellt, wie z.B. ein Fix für das Streaming von Meshes für animierte Vis-Flächen und die Möglichkeit, Vis-Flächen zu CGA-Joints hinzuzufügen. Das Entity-System erhielt mehrere Verbesserungen und Optimierungen, um unnötige Updates und Suchen zu vermeiden. Ebenso erhielt der Entity-Aggregate-Manager Low-Level-Optimierungen, um das Work-Balancing zu verbessern und den Speicherverbrauch und die Konkurrenzsituation bei der Arbeit mit Entity-Bubbles zu reduzieren. Es gab auch ein paar kleinere Verbesserungen am Entity Component Update Scheduler. Die Culling-Logik des Radix-Baums wurde verbessert, wobei die Threading-Logik angepasst wurde, um Konflikte zu reduzieren und SIMD-Culling implementiert wurde, um bis zu vier Bubbles vs. Objekte pro Knoten zu überprüfen. In Bezug auf die Performance wurde der Engine-Profiler weiter entwickelt, der viele Verbesserungen erfahren hat. Die Arbeit an einem Echtzeit-Sampling-Profiler basierend auf Event Traces wird bald beginnen. Verschiedene Optimierungen wurden im Entity System, den Komponenten-Updates und dem Zonensystem implementiert. Basierend auf der Telemetrie von der PU und PTU haben wir unsere laufenden Untersuchungen zur Speichernutzung fortgesetzt. So wurde der Engine-weite Memory Allocator und das Memory Tracking System, einschließlich der Toolchain, erheblich überarbeitet und verbessert. Um unseren Servern einen zusätzlichen Leistungsschub zu geben, wurde der Linux DGS auf ein monolithisches Executable umgestellt, um dem Compiler zu ermöglichen, besseren Code zu generieren (insbesondere für den Thread Local Storage Access). Als Teil unserer Initiative, ein Performance-Regressionssystem aufzubauen, haben wir auch einen Stresstest für Object Container Streaming hinzugefügt. Was die Crash-Behandlung angeht, erfassen wir nun einen Hex-Stack des Render-Threads und betten ihn in Mini-Dumps ein, die du uns (optional) schickst, falls das Spiel abstürzt. Dies ermöglicht es uns, den kompletten Renderthread-Callstack während des Postmortem-Debugging wiederherzustellen, ohne dass Drittanbieter-Binaries (die Teil des Callstacks oder des Videotreibers sein könnten) den Stack vollständig abwickeln müssen. Das spart eine Menge Zeit, da wir die verschiedenen Treiber, die die Spieler verwenden, nicht herunterladen müssen. Auf der Animationsseite haben wir den Code korrigiert, damit die Charakterüberblendungen und das dynamische Beleuchtungsrigg beim Rendern von Cutscenes nicht bei jedem Kameraschnitt zu spät umschalten. Zu guter Letzt wurde die Unterstützung von C++ 14 für den gesamten Client-Server-Editor und die relevanten Tool-Projekte aktiviert. Online Technik Load Balancing Test Framework
Der Pestilence Warmer für Alpha 3.12 erhielt wichtige Updates. In erster Linie nutzt der Warmer nun das neue JWT-Identifikationssystem, das es ihm erlaubt, sehr schnell viele Token für Impersonationszwecke zu holen. Dies hat den 10-fachen Durchsatz an Warmer-Instanzen, die wir gleichzeitig laufen lassen können.
Ein wichtiges Subsystem wurde hinzugefügt, das es dem Warmer ermöglicht, sich als Service mit dem Diffusion Gateway zu verbinden, was die Ausführung von Lastszenarien ermöglicht, die sich sowohl als Client, der über den Hub verbunden ist, als auch als Service im Diffusion Netzwerk koordinieren.
Backend Gleichzeitigkeitsverbesserungen
Wir waren in der Lage, die Leistung des variablen Dienstes, der Loadouts und des Haupt-Persistenz-Cache-Dienstes zu erhöhen. Die Stabilität des Backends wurde stark erhöht und übertraf die Leistung und Zuverlässigkeit, die wir in früheren Versionen hatten. Unser Low-Level-Netzwerkcode wurde aktualisiert, um sowohl die Leistung als auch die Skalierbarkeit und Robustheit zu verbessern. Wir haben auch verschiedene Korrekturen und Optimierungen am Transaktionsdienst, den Vermietungen und unserem Entitlement-Prozessor vorgenommen.
Vereinheitlichtes und zentralisiertes Logging
Mit unserem neuen einheitlichen, zentralisierten Logging-System senden alle Dienste formatierte JSON-Nachrichten an eine zentralisierte Elasticsearch-Datenbank. Jedes Log-Ereignis wird getaggt und dynamische Daten wie Account-IDs, Spieler-IDs, etc. werden in benannte Felder extrahiert, was die Suche nach Ereignissen oder bestimmten Feldern - wie z.B. einer "AccountID" - sehr effizient macht. Dies ermöglicht den Entwicklern einen einfachen Zugriff auf die Logs von einem zentralen Ort aus und die Verfolgung komplexer Nachrichten und Ereignisse, die zwischen mehreren Diensten stattfinden.
Persistente Technik
Entity Erstellung & Spawn Entkopplung
In Vorbereitung auf das persistente Streaming wurde der Prozess der Entitätserstellung vom Spawnen der Entitäten entkoppelt. Dies erlaubt es uns, den Anfangszustand des Universums in die persistente Datenbank zu "seeden", indem wir alle dynamischen Entitäten vor der Simulation erzeugen. DGS-Prozesse werden dann während der Simulation persistente Entitäten aus dieser Datenbank streamen (spawn/despawn). Dies ist ein wichtiger Schritt auf dem Weg zu einem vollständig persistenten Universum.
Parallele Spawn-Warteschlangen
Als eine Optimierung haben wir mehrere parallele Spawn-Warteschlangen auf jedem Spielserver eingeführt. Dies erlaubt es uns, mehrere verschiedene Orte (wie Lorville und New Babbage) parallel in separaten Threads auf demselben Server zu spawnen. In früheren Versionen gab es nur eine einzige Warteschlange und daher würden wir (in diesem Beispiel) erst mit New Babbage beginnen, wenn Lorville vollständig gespawnt ist. Auf ausgelasteten Servern kann dies die Wartezeit in einigen Fällen wirklich reduzieren. Zum Beispiel beim Spawnen von Wellen von KI-Schiffen oder beim Respawn in einem Hab.
Netzwerk Tech
Zeit & De-Syncs
Die Art und Weise, wie die Engine den Ablauf der Zeit misst, wurde komplett überarbeitet. Die Genauigkeit wurde sowohl bei der Messung der Zeit als auch bei der Synchronisation zwischen Server und Clients verbessert. Die Art und Weise, wie die Engine die Zeit nutzt, um ihre Logik- und Physiksimulation zu aktualisieren, wurde geändert, um Fehler zu beseitigen, die dazu führen konnten, dass die Simulationszeit auf dem Server und den Clients unterschiedlich verlaufen konnte. Viele kleinere Bugs, die dazu führten, dass Zeitfehler auf lang laufenden Servern anwuchsen, wurden ebenfalls behoben. Die Netzwerksynchronisation von Fahrzeugen und Physikobjekten wurde aktualisiert, um den vollen Nutzen aus den Verbesserungen zu ziehen. Das akkumulierte Ergebnis all dieser Änderungen war eine signifikante Reduzierung von Latenz- und Desynchronisationsproblemen in vielen Bereichen, selbst unter harten Testbedingungen für Netzwerk- und Serverleistung. Neben der Verbesserung des allgemeinen Spielerlebnisses war diese Arbeit ein notwendiger Schritt in Richtung Server-Meshing, wo die Simulation des Spiels über mehrere Spielserver Desynchronisationsprobleme aufgrund von Timing-Fehlern verschlimmert hätte.
Autoritäts-API
In Vorbereitung auf das Server Meshing hat das Team die verbleibenden Aufgaben zur Konvertierung des Codes auf die Authority API durchgeführt. In den letzten 12 Monaten gab es eine koordinierte Anstrengung von allen Teams, um den Code der Game-End-Engine auf dieses neue System zu aktualisieren. Dank ihrer Arbeit konnte ein Großteil dieser Aufgaben abgeschlossen werden. Mit einem konzertierten Vorstoß haben wir die Anzahl der verbleibenden Aufgaben auf eine einstellige Zahl reduziert.
Verbindungsfluss
In einem Server Mesh kann sich ein Client während einer Spielsitzung mit vielen verschiedenen Servern verbinden. Ein Teil der Arbeit in Richtung Server Meshing erfordert es, den Prozess der Verbindung eines Clients mit einem Server in verschiedene Phasen zu unterteilen. Diese Phasen können dann unabhängig voneinander ausgeführt werden, ohne dass ein Client seine bestehende Spielsitzung komplett aufgeben muss. Es wurden bereits bedeutende Fortschritte in diese Richtung gemacht, obwohl es noch mehr Arbeit zu tun gibt.
Marco Corbetta
VP der Technologie
Wir sehen uns im 'Verse!
Wir glauben, dass es sehr wertvoll ist, diesen Einblick in unseren Entwicklungsprozess zu geben, vor allem, wenn du die Gedankengänge, Überlegungen und Lehren direkt von unseren Senior-Entwicklern lesen kannst. Wie schon beim letzten Mal erwähnt, haben wir uns zu einer transparenten Entwicklung verpflichtet und werden auch in Zukunft vierteljährliche Patch-Postmortems zur Verfügung stellen.