Star Citizen Wiki
Wir laden dich herzlich auf unseren Star Citizen Wiki Discord Server ein! Dein direkter Draht für Fragen, Anmerkungen oder Kritik.

Comm-Link:18028 - XenoThreat Postmortem

Aus Star Citizen Wiki

Achtung

Dieser Comm-Link wurde mittels künstlicher Intelligenz übersetzt und automatisiert angelegt.
Eine Revision und Lektorierung zur Qualitätssteigerung ist erforderlich.
Um Korrekturen vorzunehmen, erstelle dazu einfach ein Benutzerkonto oder melde dich mit einem bestehenden Konto an und klicke auf bearbeiten.

XenoThreat Postmortem
ID 18028
Veröffentlichung 11.03.2021
Channel Feedback
Kategorie Undefined
Serie None
RSI XenoThreat Postmortem
API Metadaten

XenoThreat Postmortem 03/10/2021 - 12:00 UHR

Am 4. Februar 2021 haben wir die Alpha 3.12.1: Assault on Stanton, welches das erste dynamische Event im Star Citizen Universum einführte. Der folgende Postmortem stammt von den Senior-Entwicklern selbst und beschreibt, was geliefert wurde und was sie darüber denken, wie es gelaufen ist.

XenoThreat Mission Was ist gut gelaufen? Das ursprüngliche Design für XenoThreat wurde von Luke Pressley und mir (Tony Z) erstellt. Wir kennen beide den aktuellen Stand des Spiels sehr gut und nach einigen Iterationen fühlte sich der endgültige Entwurf solide und realistisch an. Es gab eine gute Menge an Dokumentation, wie das Event ablaufen würde, einschließlich einer High-Level-Aufschlüsselung, wie man es spielt, welche Feinde spawnen sollten, wie die Belohnungen funktionierten und wie man die Screen-Overrides testet. Dies alles wurde während der Entwicklung beibehalten und diente als schnelle Referenz für die QA und andere Abteilungen.

Nach einem etwas holprigen Start war die Feedbackschleife bei XenoThreat am Ende eine ziemlich gut geölte Maschine. Der Prozess des Sammelns von Feedback von der PTU über das Player Experience Team und die Feedback Reports, das Einsenden von Bugs mit den entsprechenden Labels und das Überprüfen und Triagieren neuer Bugs jeden Tag, um Prioritätsanrufe zu erhalten, endete als ein sehr sauberer Prozess. Später im Prozess haben wir uns dafür entschieden, dass die QA die Tracking-Aufgaben in JIRA eingibt, sobald der Feedback-Report eintrifft, anstatt auf interne Reproduktionen zu warten. Dies ermöglichte eine schnellere Iteration, so dass die Entwickler manchmal in der Lage waren, das Feedback zu adressieren, noch bevor QA die Chance hatte, einen richtigen Bug dafür einzugeben.

Was das Event selbst angeht, so gab es eine Reihe von Features, die positiv aufgenommen wurden. Der gemeinsame Einkommenspool, die soziale Verteilung der Aufgaben und Spieltypen und die Zusammenarbeit beim Entladen der Ladung waren bei der Community sehr beliebt. Dies allein war schon ein großer Teil der positiven Aufnahme. Wenn alles reibungslos funktionierte, war auch das gesamte Spielgefühl und der Look atemberaubend. Wir sind sehr zufrieden damit, wie die Balance von Design, VFX und SFX zusammenkam. Wir haben ein Strike-Team zusammengestellt, das sich darum kümmerte, dass sich die Kämpfe großartig anfühlen, was eine schnelle Iteration ermöglichte. Die Erzählung, die mit der Veröffentlichung einherging, war auch ziemlich cool und der XenoThreat Kommandant war effektiv und einschüchternd.

Andere Aspekte des Events, die wir als erfolgreich empfanden, waren die großen In-Game-Einkommensmöglichkeiten für Spieler (alle Phasen), die FPS-Piraten, die die Wrackplätze bevölkerten (Phase 2), und der teamorientierte Auszahlungsstil (Phase 2). Viele Spieler schätzten den Bonus, dass sie für die Durchführung des Events in allen Phasen sehr gut bezahlt wurden - dies bot einen weiteren Anreiz zum Weiterspielen und erhöhte die Wiederspielbarkeit. Obwohl es einige Probleme mit den FPS-KI-Charakteren gab, machte ihre generelle Präsenz das Durchqueren der Wrackstätten für die Spieler interessanter und trug zum abwechslungsreichen Spielstil bei. Es gab einige Kritiker, die sich mehr Einkommen pro Kiste in einem individuelleren Auszahlungssystem wünschten, aber es gab weitaus mehr, die den teamorientierten Stil der Auszahlung mochten, wobei viele sagten, dass es die Zusammenarbeit förderte.

Es war zwar bedauerlich, dass wir nicht in der Lage waren, es am Ende des Jahres zu starten, aber die Entscheidung, das Event auf 2021 zu verschieben, kam ihm massiv zugute. Der Unterschied zwischen dem, was wir vor Weihnachten veröffentlicht hätten und dem, was wir veröffentlicht haben, sind Tag und Nacht, wenn es um Stabilität, Leistung und Lebensqualität geht. Es war eine großartige Entscheidung des Führungsteams.

Was ist nicht so gut gelaufen? Dynamische Events sind ein großer Kraftakt im Management, da ihre Durchführung von mehreren Abteilungen abhängt. Sie erfordern einen Eigentümer mit einer klaren Vision und Wissen über alle Aspekte, der für Fragen und Feedback zur Verfügung steht. Um XenoThreat die Aufmerksamkeit zu geben, die es braucht und verdient, mussten viele Leute mit ihren Verantwortlichkeiten jonglieren. So etwas kann leicht dazu führen, dass andere Verantwortlichkeiten ins Rutschen kommen. Wenn Veranstaltungen dieser Größenordnung mehrmals im Jahr erforderlich sind, können sie nicht einfach von einem bestehenden Team aufgefangen werden, da ihre anderen Verantwortlichkeiten darunter leiden können. Der Dialog fügte der Mission eine Menge hinzu, aber ihn einzuführen war ein großes Unterfangen mit langen Vorlaufzeiten, um ihn und die Missionsauslöser zu liefern. Die Zeit reichte nicht aus, um die tatsächlichen Zeilen in die voll funktionierende Mission einzubauen und die entsprechenden Änderungen zu iterieren. Wir haben zwar schon früher Platzhalterlinien eingebaut, aber da das Feature, das sie auslöste, noch nicht vollständig funktionierte und die Mission noch nicht komplett fertig war, war es schwierig, sie vor Ort zu überprüfen. In der Vergangenheit haben wir Programme wie Visio benutzt, um Abläufe zu erstellen, welche Linien wann auslösen und welche Reihenfolgen auftreten sollten. Für XenoThreat hatten wir keine Zeit, dies zu tun, also wurde der Dialog direkt in die Logik implementiert. Das machte die Abläufe ad-hoc und eine zusätzliche Flussdiagramm-Planung hätte den Prozess der Gestaltung der Logik zur Unterstützung der Dialog-Trigger erleichtert. Überraschenderweise musste ein Großteil der Dialogauslösung stark in die Missionslogik eingewoben werden, damit sie zum richtigen Zeitpunkt abgefeuert wurde, was bedeutete, dass die Bemühungen, den Dialog im Kontext zu überprüfen, unrealistisch waren, selbst wenn alles funktioniert hätte und die Mission beendet worden wäre, wenn Platzhalterzeilen geliefert worden wären. Ich denke, wir müssen rücksichtsvoller mit den Erwartungen an die Überprüfung von Dialogen im Mix umgehen, wenn dieser Mix nur während der QA-, PTU- und Evocati-Playtests wirklich zum Tragen kommt.

Mehr Zeit für das Prototyping wäre extrem vorteilhaft gewesen, besonders für die Starfarer-Derelikte, da sich die Anforderungen an das Feature in der Mitte der Entwicklung geändert haben. Es wurden Wünsche geäußert, die Schwerkraft zu den Innenräumen hinzuzufügen und die Zielfunktion und UI-Unterstützung zu erweitern. Am Ende haben wir eine Version der Starfarer-Derelikte weniger ausgeliefert als ursprünglich geplant, da es Probleme mit der Schwerelosigkeit gab. Mehr Prototyping hätte es uns auch ermöglicht, besser zu verstehen, welche Balance nötig war, um an den Punkt zu kommen, an dem wir wussten, dass der Kampf wie beabsichtigt funktionierte. Es gab Zeiten, in denen das Feedback ein Ablenkungsmanöver war, wie z.B. dass die Server-Performance eine Ursache war, anstatt tatsächliche Balance-Probleme. Das machte es manchmal schwierig, ohne umfangreiche Tests zu überprüfen, wo die Probleme auftraten.

Interne Tests waren manchmal besonders herausfordernd aufgrund der Schwierigkeit der Reproduktion, der Breite der Reproschritte, der großen Anzahl an benötigten Testern und der Zeitzonenunterschiede. Manchmal bekamen die Entwickler Bugs ohne Repro-Schritte, die sie intern nicht reproduzieren konnten, während zu anderen Zeiten die Repro-Schritte unglaublich lang waren und einen enormen Zeitaufwand für das Testen erforderten. Wir müssen in der Lage sein, die Mission einfacher zu testen, damit wir ein besseres Verständnis für den Zustand der Mission zu einem bestimmten Zeitpunkt bekommen können. Später in der Entwicklung haben wir neue Werkzeuge hinzugefügt, um ausgewählte Aspekte der Mission zu umgehen und interne Parameter zu verändern, um den Testprozess zu beschleunigen. Dies hätte schon früher gemacht werden sollen.

Es gab eine Menge Feedback von unserer Community zu Aspekten des Events, die besser hätten sein können. Die Spieler wurden nicht darüber aufgeklärt, wie lange Phase 3 aktiv bleiben würde und waren überrascht, als sie zu Ende ging. Bessere Informationen, um die Erwartungen zu managen, hätten die Situation verbessert. Die Terminologie des Events in Bezug auf die Phasen war manchmal verwirrend, mit Unterschieden zwischen den internen Bezeichnungen und den Beschreibungen für die Backer in den Feedback-Threads von Spectrum.

Wir wussten von Anfang an, dass die Leistung ein limitierender Faktor sein würde und das bedeutete, dass wir nicht in der Lage sein würden, eine ausreichende Anzahl von Gegnern zu liefern, um in bestimmten Situationen den Grad an Herausforderung zu erzeugen, den wir eigentlich wollten. Das Ergebnis war, dass einige Spieler die Idris als viel zu leicht zu töten empfanden, was Phase 3 erheblich beeinträchtigte. Mit den richtigen Loadouts (Typhoon-Torpedos) konnte ein einzelner Retaliator die Schilde einer Idris fallen lassen und mehrere Spieler konnten sie in nur wenigen Minuten töten. Die schnelle Beendigung der Mission und die lange Abklingzeit bedeuteten, dass Spieler, die die Mission machen wollten, Schwierigkeiten hatten, einen Server zu finden, auf dem sie aktiv war, und wenn sie es schafften, rechtzeitig dort zu sein, um teilzunehmen. Außerdem stellte die Idris so gut wie keine Bedrohung für die Spieler dar, selbst wenn sie sie nicht schnell töteten, da sie hauptsächlich als Kugelschwamm fungierte und viele Spieler erwähnten, dass sie stillhielt und kontinuierlich feuerte.

Feindseligkeitserkennung und CrimeStat-Bestimmung sind immer noch zu simpel, ohne Modifikator für gemeinsame Missionsteilnehmer, ob das getroffene Schiff anvisiert wird oder überhaupt eine Verbindung zum Zielen. Mit so vielen Schiffen in unmittelbarer Nähe in einem komplexen Szenario, war Friendly Fire häufig und führte oft dazu, dass Spieler versehentlich einen CrimeStat bekamen, aus der Mission geworfen wurden und nach dem Tod ins Gefängnis geschickt wurden.

Während wir den Spielern die völlige Freiheit lassen wollten, zu wählen, welche Seite sie unterstützen wollen, war die Zeit dafür nicht ausreichend. Dies führte zu Problemen, als viele PVP-orientierte Spieler es auf sich nahmen, Spieler anzugreifen, die das Event versuchten. Dies war vor allem in Phase 2 der Fall. Da das Event dies jedoch nicht unterstützte, gab es nur wenige Möglichkeiten für die Missionsteilnehmer, dies zu verhindern oder zu kontern, was zu einigen starken Meinungen auf beiden Seiten führte. Die meisten Spieler haben diese Server einfach verlassen, um einen Server ohne PVP zu finden. Von unserer Seite aus denken wir darüber nach, wie wir beide Spielstile unterstützen können.

Viele Spieler erwähnten die schlechte Framerate des Clients während beider Kampfphasen. Außerdem gab es zahlreiche Berichte über das langsame Laden von missionskritischen Objekten wie Wracks, Versorgungsschiffen, XenoThreat-Jägern und der FPS-KI (die manchmal erst geladen wurde, nachdem die Spieler mit dem Löschen der Fracht begonnen hatten).

Im Gegensatz zu Phase 2 war Phase 3 ausschließlich auf den Schiffskampf ausgerichtet. Das bedeutete, dass alternative Spielstile, wie Bergungen und FPS-Kämpfe, nicht zum Spiel beitragen konnten, was bei einigen Spielern zu erheblicher Verärgerung und Frustration führte.

Die Spieler haben ein sehr begrenztes und oberflächliches Freund-Feind-Identifikationssystem (IFF), wobei rot entweder direkt feindlich gegenüber dem Spieler oder jemand mit einem CrimeStat ist und blau alle anderen repräsentiert. Es gibt keine Möglichkeit für die Spieler zu sagen, wer auf der Mission ist, wer aggressiv oder feindlich gegenüber anderen ist (ohne ein Kommunikationsfeld) und oft auch, wer in ihrer Gruppe ist, da die Gruppenmarker nicht immer zuverlässig sind. Dies war am kritischsten zu Fuß im Wrack, wo überhaupt keine Identifikation verwendet wurde und feindliche NSCs, feindliche Spieler und kooperative Spieler in der Mission alle identisch erschienen.

Die KI-Kämpfer wackelten, warpten, teleportierten sich, flogen unberechenbar und stellten generell keine Bedrohung dar, wobei die Spieler sie häufig als Kanonenfutter bezeichneten. Darüber hinaus erwähnten die Spieler häufig, wie gering ihre Anzahl zu sein schien, was das Gefühl der Gefahr einschränkte. Die KI-Jäger schienen auch kein aggressives Verhalten zu zeigen, wie z.B. das Anvisieren von Frachtschiffen oder Bombern, und ignorierten dabei manchmal eingehenden Schaden.

Obwohl einige Spieler anmerkten, dass es viel besser als frühere Patches sei, bleibt EVA ein Problem, besonders bei den Übergängen zwischen den Physik-Gittern (Betreten und Verlassen eines Schiffes), wobei Spieler häufig Schaden nehmen oder sogar sterben. Es wurde von schlechten Übergängen berichtet, bei denen die Spieler umfallen und/oder Schaden nehmen, von allgemein schlampigen und unpräzisen Bewegungen im Flug und von unangenehmen Kontrollverlusten, wenn man gegen Objekte stößt.

Torpedo-Spam dominierte Phase 3 und wurde durch massive Auszahlungen für Treffer weiter gefördert. Die Idrises konnten sie oft nicht richtig kontern und die einfache Art ihrer Nutzung (sperren, abfeuern, fertig) trug stark zum "einfachen" Gefühl von Phase 3 bei.

Die Rechts- und Feindschaftssysteme bedürfen erheblicher Arbeit, besonders im Hinblick auf potenzielles Friendly Fire und versehentlichen Schaden. Dazu gehört, wie und warum wir eine CrimeStat anwenden, wie Anklagen erhoben werden, wie Feindseligkeit bestimmt wird, und eine gründliche Diskussion darüber, wie man Freunde und Feinde besser identifizieren kann. Das sollte die Unterscheidung und Markierung von Spielern in der Mission, Spielern in der Gegenmission (falls zutreffend), aggressiven Spielern, feindlichen Spielern, Kriminellen und Fraktionen beinhalten, falls zutreffend.

Was wir anders machen werden, um uns in Zukunft zu verbessern: Es gibt mehrere oben genannte Probleme, die wir aktiv diskutieren und für zukünftige Events angehen wollen. In den kommenden Wochen werden wir uns jedes Feedback der Reihe nach ansehen und entscheiden, wie wir sie angehen, welche Teams daran arbeiten und wo sie in den Zeitplan passen. Probleme mit der Leistung, der KI, dem PVP-Design und dem Rechtssystem stehen im Vordergrund, um sicherzustellen, dass diese Events so gut wie möglich sind.

Tony Zurovec, Persistent Universe Game Director

KI-Team Was ist gut gelaufen? XenoThreat war eine großartige Gelegenheit, ein Unternehmensziel über mehrere Teams hinweg zu verfolgen. Das ist üblich, wenn wir bestimmte gemeinsame Ziele festlegen (Meilensteine oder bestimmte Veröffentlichungen) und es bringt normalerweise mehrere Abteilungen zusammen.

Für diese Art von Events verlassen wir uns sehr auf andere Teams. Zum Beispiel war das PU-Missionsteam enorm reaktionsfreudig und wir hatten ständig eine Schlüsselperson als Ansprechpartner für den Missionsablauf. Das half uns, die Ziele, die sie zu erreichen versuchten, zu verstehen und die Logik anzupassen und andere Wege vorzuschlagen, um Probleme anzugehen, wann immer wir konnten. Die Zusammenarbeit war fantastisch.

Diese Events geben uns auch die Möglichkeit, sowohl neue Features zu nutzen als auch Verbesserungen an bestehenden vorzunehmen. So konnten wir zum Beispiel den ersten Durchgang für den Kampf mit Großkampfschiffen machen, die neue Zuweisung für das Anfordern des Andockens enthüllen und den aktuellen Mastergraph-Flow für den Pilotenkampf verbessern.

Während des Events haben wir speziell das KI-Verhalten und das Spielerlebnis überprüft. Die Tatsache, dass alle relevanten Regisseure an der Überprüfung teilnahmen, ermöglichte es uns, schnell Feedback zu sammeln und zu diskutieren, was in dem definierten Zeitrahmen noch hätte getan werden können.

Was nicht so gut gelaufen ist Die Idee hinter XenoThreat war es, einen bestimmten Zeitrahmen, der der Mission zugewiesen wurde, zu nutzen, um sehr spezifische Ziele zu erreichen. Die Absicht war, das KI-Team nicht mit Anfragen zu überlasten und kluge Entscheidungen zu treffen, wenn man mit der Entwicklung des Kampfes gegen Kapitalschiffe beginnt. Zum Beispiel, sich auf die Verbesserung der Zielauswahlverteilung über die verschiedenen Schiffssitze zu konzentrieren oder die Fähigkeit zu implementieren, die Railgun zu benutzen. Unglücklicherweise bedeutete die Menge an Arbeit, die für die Iteration erforderlich war, dass das Ansprechen von Edge Cases nicht vollständig berücksichtigt wurde, was sich auf die Arbeitsbelastung des Teams auswirkte.

Während der Entwicklung gerieten wir auch in Situationen, in denen wir annahmen, dass Bugs durch den KI-Code oder die Performance verursacht wurden. Es stellte sich jedoch heraus, dass es sich um eine Kombination aus anderen Dingen handelte, die schneller hätten behoben werden können, wenn man uns richtig darauf aufmerksam gemacht hätte. Eine bessere Sorgfaltspflicht beim Testen des Flows kann eine Menge dieser Verwirrung verhindern.

Der Versuch, die Leistung zu verbessern und gleichzeitig Bugs zu beheben, machte den letzten Teil der Entwicklung etwas hektisch, aber das hatten wir auch erwartet, also waren wir nicht so überrascht.

Francesco Roccucci, AI Direktor

Vehicle Experience Team Was ist gut gelaufen? Die Arbeit des Vehicle Experience Teams an XenoThreat konzentrierte sich hauptsächlich darauf, das Flugerlebnis von Großkampfschiffen mit den von ihnen verwendeten Waffen auszubalancieren, aber auch die Waffen, die von Schiffen wie der Eclipse und dem Retaliator gegen sie eingesetzt werden würden.

Das Tuning der Flugbalance mit der Idris und der Javelin lief darauf hinaus, der KI zu ermöglichen, jedes Schiff richtig zu positionieren, um anzugreifen und zu verteidigen. Wir sind auf dem Weg einige Kompromisse eingegangen, sodass sich diese Schiffe, wenn sie in die Hände der Spieler gelangen, etwas anders anfühlen werden. Aber zu diesem Zeitpunkt war dies die richtige Entscheidung, bis wir einige der Verhaltensweisen der Geschütztürme verbessert haben, sodass sie nicht mehr so sehr von der Bewegung der Schiffe abhängen.

Die einflussreichsten Änderungen, die wir vorgenommen haben, betrafen die Geschwindigkeit und Stärke der Waffen. Das gesamte Event hat uns dazu gedrängt, stärkere Waffen hinzuzufügen, einschließlich der Einführung der Railgun in die PU, aber wir wollten dies mit der Geschwindigkeit ausgleichen. Je stärker eine Waffe ist, desto langsamer bewegt sie sich im Allgemeinen, abgesehen von der Railgun, mit der wir die Grenzen der Geschwindigkeit in Star Citizen ausreizen. Wir wollten wirklich, dass die Railgun gefürchtet wird, indem wir die Optik nutzen, um die Vorfreude auf das, was kommt, aufzubauen und den Spielern die Möglichkeit zu geben, ihr auszuweichen, wenn die Idris es schafft, sie in eine Reihe zu stellen, und für den Moment schießt sie, um besonders zu sein.

Das Highlight von XenoThreat war für das Vehicle Experience Team zu sehen, wie die verschiedenen Teams zusammenkamen, um ein fantastisches Event abzuliefern, bei dem man nicht nur mitmachen, sondern auch zuschauen konnte. Wir arbeiteten eng mit den Teams für Audio- und visuelle Effekte zusammen, um sicherzustellen, dass die Balance, die wir implementiert hatten, genau so aussah und klang, wie sie aussah. Die Entwickler verbrachten viele Abende damit, sich die verschiedenen Streams anzuschauen, die die Backer auf die Beine gestellt hatten und teilten jeden Morgen die besten Momente mit dem Rest des Teams.

Was ist nicht so gut gelaufen? Aus der Balance-Perspektive war die Hauptschwierigkeit, die wir bei XenoThreat hatten, konsistente, wiederholbare Ergebnisse zu bekommen, um die Balance in einer realen Schlacht zu bewerten, da das Event so sehr von der Performance des Spiels abhängig war. Im Laufe der Entwicklung wurde dies mit zunehmender Leistung immer einfacher, aber erst in den letzten Wochen vor der Veröffentlichung erreichten wir einen Punkt, an dem das Event von Anfang bis Ende wie erwartet ablief, wenn alles reibungslos lief.

Positiv ist jedoch, dass die Performance-Probleme, die wir während der Entwicklung hatten, spezifische Probleme mit den Waffen und Schilden aufzeigten, die wir in Szenarien mit geringerer Performance drastisch verbessern konnten. Es hat auch einige der Löcher in der Balance aufgezeigt, die wir in den kommenden Builds beheben werden.

Rich Towler, Lead Game Designer

Leistung Was ist gut gelaufen? Wir versuchen ständig, die Leistung zu verbessern, was sehr schwierig ist, da wir dem Spiel ständig neue Features hinzufügen. Und obwohl es noch viel zu tun gibt, um die Framerate auf das Niveau zu bringen, das wir anstreben, denke ich, dass der größte Vorteil von XenoThreat darin liegt, dass wir es auf ein Niveau gebracht haben, das vielen Spielern Spaß macht. Als wir in den vergangenen Jahren diese Art von Kampf mit Großkampfschiffen ausprobiert haben, waren wir von der Leistung her so weit entfernt, dass wir ein Event dieser Größenordnung nicht liefern konnten, also ist das hoffentlich ein guter erster Schritt, den wir nun verbessern können.

Was ist nicht so gut gelaufen? Viele Spieler erwähnten die schlechte Framerate des Clients, besonders während der Schiffskämpfe in Phase 2 und Phase 3, wobei die Betonung auf letzterem lag. Wir wissen, dass die Server-Performance besser werden muss, denn das wird helfen, Dinge wie die Reaktionszeiten der KI zu verbessern.

Was wir in Zukunft anders machen werden: Ich denke, die wichtigste Erkenntnis aus XenoThreat und den letzten paar Releases ist, dass wir ein besseres System für Profiling und Performance-Regression brauchen, damit wir die Werkzeuge für alle Teams haben, um einfacher Profile zu erstellen und die Performance zu optimieren, anstatt von Engpässen oder einer kleinen Handvoll Ingenieure abhängig zu sein. Das Engine Team und ich haben uns bereits damit befasst und dieses Jahr einige gute erste Schritte gemacht. Wir haben ein neues Stresstest-Framework, das für den Code einfach zu benutzen ist, bessere imGUI Debug-Profiling-Unterstützung und eine bessere automatische Erfassung und Analyse von Leistungsdaten. Auch wenn es noch ein wenig früh ist, um viele Früchte für Alpha 3.13 zu tragen, sollte es langfristig eine große Hilfe für uns sein. Außerdem gibt es in diesem Jahr ein Mandat für alle Teams, mehr Zeit für Optimierungen zu verwenden, die dabei helfen werden. Und mit dem Server Meshing am Horizont, zusammen mit einigen anderen längerfristig geplanten Optimierungen, haben wir potenziell einige viel bedeutendere Gewinne, die wir machen können, wenn diese online gehen.

Rob Johnson, Technischer Direktor - Persistent Universe Gameplay

Cookies helfen uns bei der Bereitstellung dieses Wikis. Durch die Nutzung des Star Citizen Wiki erklärst du dich damit einverstanden, dass wir Cookies speichern.