XenoThreat Postmortem - [Comm-Links](https://api.star-citizen.wiki/comm-links) - XenoThreat Postmortem XenoThreat Postmortem ===================== Undefined Undefined None [Previous](https://api.star-citizen.wiki/comm-links/18027) [Next](https://api.star-citizen.wiki/comm-links/18029) Content ------- English XenoThreat Postmortem 03/10/2021 - 1:00 AM On February 4, 2021, we launched Alpha 3.12.1: Assault on Stanton, which introduced the first dynamic event in the Star Citizen universe. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. XenoThreat Mission What went well? The initial design for XenoThreat was put together by Luke Pressley and I (Tony Z). We both have a strong working knowledge of the current state of the game and, after a few iterations, the final pitch felt solid and realistic. There was a good amount of documentation for how the event would be run, including a high-level breakdown of how to play it, what enemies should spawn, how the rewards worked, and how to test the screen overrides. This was all maintained throughout development, which worked as a quick reference for QA and other departments. After a somewhat clunky start, the feedback loop on XenoThreat ended up being a pretty well-oiled machine. The process of gathering feedback from the PTU via the Player Experience Team and Feedback Reports, getting bugs in with the appropriate labels, and reviewing and triaging new bugs each day to get priority calls ended up being a very clean process. We made a call later in the process to have QA enter tracking tasks in JIRA as soon as the Feedback Report came in instead of waiting for internal reproductions. This allowed for more rapid iteration, so sometimes the developers were able to address the feedback even before QA got a chance to enter a proper bug for it. Regarding the event itself, there were a number of features that were positively received. The shared income pool, social style distribution of tasks and gameplay types, and work-together nature of the cargo unloading were immensely popular with the community. This by itself was a huge part of the positive reception. Also, when everything was working smoothly, the entire feel and look was stunning. We are very happy with how the balance of design, VFX, and SFX came together. We created a strike-team dedicated to making the combat feel great, which made quick iteration more viable. The narrative that went along with the release was also quite cool, and the XenoThreat commander was effective and intimidating. Other aspects of the event we found successful were large in-game income opportunities for players (all phases), FPS pirates populating the wreck sites (Phase 2), and team-oriented payout style (Phase 2). Many players appreciated the bonus of getting paid very well for doing the event in all phases - this further incentivized continued play and added replayability. Although there were some issues with the FPS AI characters, their general presence made going through the wreck sites more interesting for players and added to the varied style of gameplay. There were some detractors who wanted more income per-box in a more individualized payout system, but there were far more who liked the team-oriented style of payout, with many saying it encouraged cooperation. While it was unfortunate we weren’t able to launch it at the end of the year, the decision to delay the event until 2021 benefited it massively. The difference between what we would have released before Christmas and what we did release are night and day when it comes to stability, performance, and quality of life. It was a great decision by the executive team. What didn’t go so well? Dynamic Events are a huge feat of management as their delivery relies on multiple departments. They require one owner with a clear vision and knowledge of all aspects to be on hand to answer questions and address feedback. In order to give XenoThreat the attention it required and deserved, a lot of folks had to juggle responsibilities. This type of thing can easily lead to other responsibilities sliding. If events of this scale are required several times a year, they cannot just be absorbed by an existing team as their other responsibilities can suffer. The dialogue added a lot to the mission, but getting it in was a big undertaking with long lead times to deliver it and the mission triggers. There was insufficient time to get the actual lines into the fully functioning mission and iterate on appropriate changes. We did get placeholder lines in earlier but, due to the feature that triggered them still not being fully functioning and the mission not being completely finished, it was difficult to actually review them in situ. In the past, we have used programs like Visio to create flows of what lines trigger when and what orderings should occur. We didn't have time to do this for XenoThreat, so dialogue was implemented straight into the logic. This made the processes more ad-hoc, and extra flow-graph planning would have eased the process of designing the logic to support the dialogue triggers. Usurprisingly, much of the dialogue triggering had to be heavily woven into the mission logic for it to be fired at the right time, which meant that efforts to review the dialogue in context were unrealistic even if everything had been working and the mission finished when placeholder lines were delivered. I think we need to be more considerate about expectations on reviewing dialogue in the mix when that mix only really plays out during QA, PTU, and Evocati playtests. More time spent prototyping would have been extremely beneficial, particularly for the Starfarer derelicts, as the feature requirements changed in the middle of development. Requests were made to add gravity to the interiors and to add targeting capability and UI support. We ended up shipping with one less version of the Starfarer derelicts than originally planned due to issues with zero-g. More prototyping would have also enabled us to better understand what balance was required to get to the point where we knew the combat worked as intended. There were times that the feedback could be red herrings, such as server performance being a cause instead of actual balance issues. This sometimes made it difficult to pinpoint where problems were occurring without extensive testing to verify. Internal testing was sometimes especially challenging due to the difficulty of reproduction, breadth of repro steps, large number of testers required, and time-zone differences. Sometimes, the developers would get bugs without repro steps that they were unable to reproduce internally, while other times, the repro steps would be incredibly long and would take a massive amount of time to test. We need to be able to test the mission more easily so we can get a better understanding of the state of it at any given time. Later in development, we added new tools to bypass select aspects of the mission and modify internal parameters to help expedite the testing process. This should have been done earlier. There was a lot of feedback from our community on aspects of the event that could have been better. Players weren’t made aware of how long Phase 3 would remain active and were surprised when it came to an end. Better information to manage expectations would have improved the situation. Event terminology regarding phases was confusing at times, with differences between how things were referred to internally and what was described to backers on Spectrum’s feedback threads. We knew from the beginning that performance would be a limiting factor and that meant we wouldn’t be able to deliver a sufficient number of enemies to generate the level of challenge that we actually wanted in certain situations. As a result, some players found the Idris far too easy to kill and, when this happened, it derailed Phase 3 significantly. With the right loadouts (Typhoon torpedoes) a single Retaliator could drop the shields of an Idris and multiple players could kill it in just a few minutes. Rapid mission finishing and a long cooldown meant players trying to do the mission struggled to find a server with it active and, if they did, get there in time to participate. In addition, the Idris offered almost no threat to players even if they didn’t kill it quickly, it mostly acting as a bullet sponge with many players mentioning it holding still and continuously firing. Hostility detection and CrimeStat determination are still too simplistic, with no modifier for shared mission participants whether the ship hit is targeted or any link to targeting at all. With so many ships in close proximity in a complex scenario, friendly fire was frequent and often resulted in players accidentally getting a CrimeStat, being dumped from the mission, and sent to prison upon death. While we wanted to allow players complete freedom to choose which side to support, there was insufficient time. This caused problems when, inevitably, many PVP-oriented players took it upon themselves to attack players attempting the event. This was most prevalent in Phase 2. Since the event didn’t support this, however, there were few ways for mission participants to prevent or counter this, resulting in some strong opinions on either side. Most players just left those servers to find one without PVP. On our end, we're thinking about how we can support both play-styles. Many players mentioned poor client framerate during both combat phases. In addition, there were numerous reports of mission-critical assets loading slowly including wreck sites, supply ships, XenoThreat fighters, and FPS AI (which loaded in after players started clearing cargo at times). As opposed to Phase 2, Phase 3 was singularly focused on ship combat. This meant that alternative play styles, such as salvage and FPS combat, were not able to contribute, which caused considerable consternation and frustration amongst some players. Players have very limited and shallow friend or foe identification systems (IFF), with red being either directly hostile to the player or someone with a CrimeStat and blue representing everyone else. There’s no way for players to tell who is on the mission, who is aggressive or hostile to others (without a comm array), and often who is in their party as the party markers are not always reliable. This was most critical on foot in the wreck, where no identification was used at all and hostile NPCs, hostile players, and cooperative players on the mission all appeared identically. AI fighters wiggled, warped, teleported, flew erratically, and generally offered no threat, with players frequently calling them cannon fodder. In addition, players frequently mentioned how low their numbers seemed, limiting the sense of danger. AI fighters also seemed to lack aggressive behaviors, such as targeting cargo ships or bombers, and sometimes ignored incoming damage in the process. Although some players commented that it was far better than previous patches, EVA remains an issue, especially on physics-grid transitions (entering and exiting a ship), with players frequently taking damage or even dying. Specifically reported were bad transitions that involved players falling over and/or taking damage, generally sloppy and imprecise motion in flight, and awkward loss of control when bumping into objects. Torpedo spam dominated Phase 3 and was further encouraged by massive payouts for hits. The Idrises often failed to properly counter them and the simplistic nature of their use (lock, launch, done) contributed heavily to the “easy” feeling of Phase 3. The law and hostility systems need significant work, especially with regards to potentially friendly fire and accidental damage. Included in this are how and why we apply a CrimeStat, how charges are pressed, how hostility is determined, and a thorough discussion of how to better identify friends and foes. That should include distinction and markers for players on the mission, counter-mission players (if appropriate), aggressive players, hostile players, criminals, and factions where appropriate. What we’ll do differently to improve in the future: There are several issues called out above that we are actively discussing and plan to address for future events. Over the coming weeks, we’ll look at each piece of feedback in turn and discern how to address them, which teams will work on them, and where they fit into the schedule. Issues with performance, AI, PVP design, and the law system are at the forefront of our minds to ensure these events are as good as they can be. Tony Zurovec, Persistent Universe Game Director AI Team What went well? XenoThreat was a great opportunity to have a company goal across multiple teams. This is common whenever we establish specific common goals (milestones or specific releases) and it usually brings several departments together. For these types of event, we rely a lot on other teams. For example, the PU Mission Team was hugely responsive and reactive and we constantly had a key person to contact about the mission flow. This helped us understand the goals they were trying to achieve and adjust the logic and suggest different ways of approaching problems whenever we could. The collaboration has been fantastic. These events also give us the opportunity to utilize both new features and make improvements to existing ones. For example, we were able to make the initial pass on capital ship combat, expose the new assignment for requesting docking, and improve the current mastergraph flow for pilot combat. During the event, we specifically reviewed AI behaviors and the player experience. Having all the relevant directors in the review allowed us to quickly collect feedback and discuss what could have been done in the defined timeframe. What didn’t go so well The idea behind XenoThreat was to use a specific timeframe assigned to the mission to achieve very specific goals. The intention was to not overload the AI Team with requests and make smart decisions in starting development of capital ship combat. For example, focusing on improving target selection distribution across the multiple ship seat operators or implement the ability to use the railgun. Unfortunately, in the overall schedule, the amount of work required to iterate on making it fun meant addressing edge cases was not fully considered and it affected the workload of the team. During development, we also got caught in situations where we assumed bugs were caused by AI code or performance. However, they turned out to be a combination of other things that could have been addressed quicker if brought properly to our attention. Better due diligence while testing the flow can prevent a lot of this confusion. Trying to improve performance at the same time as bug fixing made the final part of development a bit hectic but we also expected that, so we were not so surprised. Francesco Roccucci, AI Director Vehicle Experience Team What went well? The Vehicle Experience Team’s work on XenoThreat was mostly focused on balancing the flight experience of capital ships with the weapons they used, but also the weapons that would be used against them by ships like the Eclipse and Retaliator. The tuning of the flight balance with the Idris and Javelin came down to allowing the AI to position each ship correctly to attack and defend. We made some compromises along the way so when these ships get into the players’ hands they will feel slightly different. But at the time, this was the right decision to make until we have improved some of the turret behaviors so they don’t rely upon the movement of the ships as much as they do now. The most impactful changes we made were to the speed and strength of the weapons. The entire event pushed us to add stronger weapons, including the introduction of the railgun to the PU, but we wanted to balance this with speed. The more powerful a weapon is, the slower it generally travels, apart from the railgun which we used to push the limits of speed in Star Citizen. We really wanted the railgun to be feared, using the visuals to build the anticipation of what was to come and give players the chance to avoid it if the Idris managed to line them up, and for the moment it fired to be special. The highlight of XenoThreat for the Vehicle Experience Team was seeing the various teams come together to deliver what was a fantastic event to not only take part in but to watch. We worked closely with the audio and visual effect teams to make sure the balance we had implemented was accurately reflected in how it looked and sounded. The devs spent many evenings watching the various streams that the backers had put on, each morning sharing the best moments with the rest of the team. What didn’t go so well? From a balance perspective, the main difficulty we had with XenoThreat was getting consistent, repeatable results to evaluate the balance in a real-world battle as the event was so dependent upon the performance of the game. As development went on, this got easier as performance increased, but it wasn’t until the final couple of weeks before release that we got to a point where, if things ran smoothly, the event would play out from start to finish as expected. But on the positive side, the performance problems we had during development highlighted specific issues with both the weapons and shields that we were able to drastically improve under lower-performance scenarios. It also further highlighted some of the holes that we currently have in the balance, which we will be rectifying over coming builds. Rich Towler, Lead Game Designer Performance What went well? We are constantly looking to improve performance, which is very hard as we constantly add more features to the game. And while there’s a lot to do to get framerates at the levels we are aiming for, I think the main performance positive for XenoThreat is that we got it to a level where we could deliver an overall enjoyable event for lots of players. When we’ve tried this kind of capital ship combat in past years, we’ve been so far off the mark performance-wise that we couldn’t deliver an event of this scale, so hopefully this is a good first foot on the ladder that we can now improve on. What didn’t go so well? Many players mentioned poor client framerate, especially during ship battles in both Phase 2 and Phase 3, with emphasis on the latter. We know that server performance needs to be better, as that will help improve things like the response times of AI. What we’ll do differently in the future: I think the main takeaway from XenoThreat and the last few releases is we need a better system for profiling and performance regression, so we have the tools for all teams to more easily profile and optimize for performance rather than being bottlenecked or dependent on a small handful of engineers. The Engine Team and I have already been looking into this and made some good first steps this year. We have a new stress test framework that’s easy for code to use, better imGUI debug profiling support, and better auto-capturing and analysis of performance data. Whilst it may be a little early to bear much fruit for Alpha 3.13, it should be a big help for us in the long run. There is also a mandate this year for all teams to assign more time to optimizations that will help in this effort. And with server meshing on the horizon along with several other longer-term planned optimizations, we potentially have some much more significant gains we can make when those come online. Rob Johnson, Engineering Director - Persistent Universe Gameplay 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 XenoThreat Postmortem 03/10/2021 - 1:00 AM On February 4, 2021, we launched Alpha 3.12.1: Assault on Stanton, which introduced the first dynamic event in the Star Citizen universe. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. XenoThreat Mission What went well? The initial design for XenoThreat was put together by Luke Pressley and I (Tony Z). We both have a strong working knowledge of the current state of the game and, after a few iterations, the final pitch felt solid and realistic. There was a good amount of documentation for how the event would be run, including a high-level breakdown of how to play it, what enemies should spawn, how the rewards worked, and how to test the screen overrides. This was all maintained throughout development, which worked as a quick reference for QA and other departments. After a somewhat clunky start, the feedback loop on XenoThreat ended up being a pretty well-oiled machine. The process of gathering feedback from the PTU via the Player Experience Team and Feedback Reports, getting bugs in with the appropriate labels, and reviewing and triaging new bugs each day to get priority calls ended up being a very clean process. We made a call later in the process to have QA enter tracking tasks in JIRA as soon as the Feedback Report came in instead of waiting for internal reproductions. This allowed for more rapid iteration, so sometimes the developers were able to address the feedback even before QA got a chance to enter a proper bug for it. Regarding the event itself, there were a number of features that were positively received. The shared income pool, social style distribution of tasks and gameplay types, and work-together nature of the cargo unloading were immensely popular with the community. This by itself was a huge part of the positive reception. Also, when everything was working smoothly, the entire feel and look was stunning. We are very happy with how the balance of design, VFX, and SFX came together. We created a strike-team dedicated to making the combat feel great, which made quick iteration more viable. The narrative that went along with the release was also quite cool, and the XenoThreat commander was effective and intimidating. Other aspects of the event we found successful were large in-game income opportunities for players (all phases), FPS pirates populating the wreck sites (Phase 2), and team-oriented payout style (Phase 2). Many players appreciated the bonus of getting paid very well for doing the event in all phases - this further incentivized continued play and added replayability. Although there were some issues with the FPS AI characters, their general presence made going through the wreck sites more interesting for players and added to the varied style of gameplay. There were some detractors who wanted more income per-box in a more individualized payout system, but there were far more who liked the team-oriented style of payout, with many saying it encouraged cooperation. While it was unfortunate we weren’t able to launch it at the end of the year, the decision to delay the event until 2021 benefited it massively. The difference between what we would have released before Christmas and what we did release are night and day when it comes to stability, performance, and quality of life. It was a great decision by the executive team. What didn’t go so well? Dynamic Events are a huge feat of management as their delivery relies on multiple departments. They require one owner with a clear vision and knowledge of all aspects to be on hand to answer questions and address feedback. In order to give XenoThreat the attention it required and deserved, a lot of folks had to juggle responsibilities. This type of thing can easily lead to other responsibilities sliding. If events of this scale are required several times a year, they cannot just be absorbed by an existing team as their other responsibilities can suffer. The dialogue added a lot to the mission, but getting it in was a big undertaking with long lead times to deliver it and the mission triggers. There was insufficient time to get the actual lines into the fully functioning mission and iterate on appropriate changes. We did get placeholder lines in earlier but, due to the feature that triggered them still not being fully functioning and the mission not being completely finished, it was difficult to actually review them in situ. In the past, we have used programs like Visio to create flows of what lines trigger when and what orderings should occur. We didn't have time to do this for XenoThreat, so dialogue was implemented straight into the logic. This made the processes more ad-hoc, and extra flow-graph planning would have eased the process of designing the logic to support the dialogue triggers. Usurprisingly, much of the dialogue triggering had to be heavily woven into the mission logic for it to be fired at the right time, which meant that efforts to review the dialogue in context were unrealistic even if everything had been working and the mission finished when placeholder lines were delivered. I think we need to be more considerate about expectations on reviewing dialogue in the mix when that mix only really plays out during QA, PTU, and Evocati playtests. More time spent prototyping would have been extremely beneficial, particularly for the Starfarer derelicts, as the feature requirements changed in the middle of development. Requests were made to add gravity to the interiors and to add targeting capability and UI support. We ended up shipping with one less version of the Starfarer derelicts than originally planned due to issues with zero-g. More prototyping would have also enabled us to better understand what balance was required to get to the point where we knew the combat worked as intended. There were times that the feedback could be red herrings, such as server performance being a cause instead of actual balance issues. This sometimes made it difficult to pinpoint where problems were occurring without extensive testing to verify. Internal testing was sometimes especially challenging due to the difficulty of reproduction, breadth of repro steps, large number of testers required, and time-zone differences. Sometimes, the developers would get bugs without repro steps that they were unable to reproduce internally, while other times, the repro steps would be incredibly long and would take a massive amount of time to test. We need to be able to test the mission more easily so we can get a better understanding of the state of it at any given time. Later in development, we added new tools to bypass select aspects of the mission and modify internal parameters to help expedite the testing process. This should have been done earlier. There was a lot of feedback from our community on aspects of the event that could have been better. Players weren’t made aware of how long Phase 3 would remain active and were surprised when it came to an end. Better information to manage expectations would have improved the situation. Event terminology regarding phases was confusing at times, with differences between how things were referred to internally and what was described to backers on Spectrum’s feedback threads. We knew from the beginning that performance would be a limiting factor and that meant we wouldn’t be able to deliver a sufficient number of enemies to generate the level of challenge that we actually wanted in certain situations. As a result, some players found the Idris far too easy to kill and, when this happened, it derailed Phase 3 significantly. With the right loadouts (Typhoon torpedoes) a single Retaliator could drop the shields of an Idris and multiple players could kill it in just a few minutes. Rapid mission finishing and a long cooldown meant players trying to do the mission struggled to find a server with it active and, if they did, get there in time to participate. In addition, the Idris offered almost no threat to players even if they didn’t kill it quickly, it mostly acting as a bullet sponge with many players mentioning it holding still and continuously firing. Hostility detection and CrimeStat determination are still too simplistic, with no modifier for shared mission participants whether the ship hit is targeted or any link to targeting at all. With so many ships in close proximity in a complex scenario, friendly fire was frequent and often resulted in players accidentally getting a CrimeStat, being dumped from the mission, and sent to prison upon death. While we wanted to allow players complete freedom to choose which side to support, there was insufficient time. This caused problems when, inevitably, many PVP-oriented players took it upon themselves to attack players attempting the event. This was most prevalent in Phase 2. Since the event didn’t support this, however, there were few ways for mission participants to prevent or counter this, resulting in some strong opinions on either side. Most players just left those servers to find one without PVP. On our end, we're thinking about how we can support both play-styles. Many players mentioned poor client framerate during both combat phases. In addition, there were numerous reports of mission-critical assets loading slowly including wreck sites, supply ships, XenoThreat fighters, and FPS AI (which loaded in after players started clearing cargo at times). As opposed to Phase 2, Phase 3 was singularly focused on ship combat. This meant that alternative play styles, such as salvage and FPS combat, were not able to contribute, which caused considerable consternation and frustration amongst some players. Players have very limited and shallow friend or foe identification systems (IFF), with red being either directly hostile to the player or someone with a CrimeStat and blue representing everyone else. There’s no way for players to tell who is on the mission, who is aggressive or hostile to others (without a comm array), and often who is in their party as the party markers are not always reliable. This was most critical on foot in the wreck, where no identification was used at all and hostile NPCs, hostile players, and cooperative players on the mission all appeared identically. AI fighters wiggled, warped, teleported, flew erratically, and generally offered no threat, with players frequently calling them cannon fodder. In addition, players frequently mentioned how low their numbers seemed, limiting the sense of danger. AI fighters also seemed to lack aggressive behaviors, such as targeting cargo ships or bombers, and sometimes ignored incoming damage in the process. Although some players commented that it was far better than previous patches, EVA remains an issue, especially on physics-grid transitions (entering and exiting a ship), with players frequently taking damage or even dying. Specifically reported were bad transitions that involved players falling over and/or taking damage, generally sloppy and imprecise motion in flight, and awkward loss of control when bumping into objects. Torpedo spam dominated Phase 3 and was further encouraged by massive payouts for hits. The Idrises often failed to properly counter them and the simplistic nature of their use (lock, launch, done) contributed heavily to the “easy” feeling of Phase 3. The law and hostility systems need significant work, especially with regards to potentially friendly fire and accidental damage. Included in this are how and why we apply a CrimeStat, how charges are pressed, how hostility is determined, and a thorough discussion of how to better identify friends and foes. That should include distinction and markers for players on the mission, counter-mission players (if appropriate), aggressive players, hostile players, criminals, and factions where appropriate. What we’ll do differently to improve in the future: There are several issues called out above that we are actively discussing and plan to address for future events. Over the coming weeks, we’ll look at each piece of feedback in turn and discern how to address them, which teams will work on them, and where they fit into the schedule. Issues with performance, AI, PVP design, and the law system are at the forefront of our minds to ensure these events are as good as they can be. Tony Zurovec, Persistent Universe Game Director AI Team What went well? XenoThreat was a great opportunity to have a company goal across multiple teams. This is common whenever we establish specific common goals (milestones or specific releases) and it usually brings several departments together. For these types of event, we rely a lot on other teams. For example, the PU Mission Team was hugely responsive and reactive and we constantly had a key person to contact about the mission flow. This helped us understand the goals they were trying to achieve and adjust the logic and suggest different ways of approaching problems whenever we could. The collaboration has been fantastic. These events also give us the opportunity to utilize both new features and make improvements to existing ones. For example, we were able to make the initial pass on capital ship combat, expose the new assignment for requesting docking, and improve the current mastergraph flow for pilot combat. During the event, we specifically reviewed AI behaviors and the player experience. Having all the relevant directors in the review allowed us to quickly collect feedback and discuss what could have been done in the defined timeframe. What didn’t go so well The idea behind XenoThreat was to use a specific timeframe assigned to the mission to achieve very specific goals. The intention was to not overload the AI Team with requests and make smart decisions in starting development of capital ship combat. For example, focusing on improving target selection distribution across the multiple ship seat operators or implement the ability to use the railgun. Unfortunately, in the overall schedule, the amount of work required to iterate on making it fun meant addressing edge cases was not fully considered and it affected the workload of the team. During development, we also got caught in situations where we assumed bugs were caused by AI code or performance. However, they turned out to be a combination of other things that could have been addressed quicker if brought properly to our attention. Better due diligence while testing the flow can prevent a lot of this confusion. Trying to improve performance at the same time as bug fixing made the final part of development a bit hectic but we also expected that, so we were not so surprised. Francesco Roccucci, AI Director Vehicle Experience Team What went well? The Vehicle Experience Team’s work on XenoThreat was mostly focused on balancing the flight experience of capital ships with the weapons they used, but also the weapons that would be used against them by ships like the Eclipse and Retaliator. The tuning of the flight balance with the Idris and Javelin came down to allowing the AI to position each ship correctly to attack and defend. We made some compromises along the way so when these ships get into the players’ hands they will feel slightly different. But at the time, this was the right decision to make until we have improved some of the turret behaviors so they don’t rely upon the movement of the ships as much as they do now. The most impactful changes we made were to the speed and strength of the weapons. The entire event pushed us to add stronger weapons, including the introduction of the railgun to the PU, but we wanted to balance this with speed. The more powerful a weapon is, the slower it generally travels, apart from the railgun which we used to push the limits of speed in Star Citizen. We really wanted the railgun to be feared, using the visuals to build the anticipation of what was to come and give players the chance to avoid it if the Idris managed to line them up, and for the moment it fired to be special. The highlight of XenoThreat for the Vehicle Experience Team was seeing the various teams come together to deliver what was a fantastic event to not only take part in but to watch. We worked closely with the audio and visual effect teams to make sure the balance we had implemented was accurately reflected in how it looked and sounded. The devs spent many evenings watching the various streams that the backers had put on, each morning sharing the best moments with the rest of the team. What didn’t go so well? From a balance perspective, the main difficulty we had with XenoThreat was getting consistent, repeatable results to evaluate the balance in a real-world battle as the event was so dependent upon the performance of the game. As development went on, this got easier as performance increased, but it wasn’t until the final couple of weeks before release that we got to a point where, if things ran smoothly, the event would play out from start to finish as expected. But on the positive side, the performance problems we had during development highlighted specific issues with both the weapons and shields that we were able to drastically improve under lower-performance scenarios. It also further highlighted some of the holes that we currently have in the balance, which we will be rectifying over coming builds. Rich Towler, Lead Game Designer Performance What went well? We are constantly looking to improve performance, which is very hard as we constantly add more features to the game. And while there’s a lot to do to get framerates at the levels we are aiming for, I think the main performance positive for XenoThreat is that we got it to a level where we could deliver an overall enjoyable event for lots of players. When we’ve tried this kind of capital ship combat in past years, we’ve been so far off the mark performance-wise that we couldn’t deliver an event of this scale, so hopefully this is a good first foot on the ladder that we can now improve on. What didn’t go so well? Many players mentioned poor client framerate, especially during ship battles in both Phase 2 and Phase 3, with emphasis on the latter. We know that server performance needs to be better, as that will help improve things like the response times of AI. What we’ll do differently in the future: I think the main takeaway from XenoThreat and the last few releases is we need a better system for profiling and performance regression, so we have the tools for all teams to more easily profile and optimize for performance rather than being bottlenecked or dependent on a small handful of engineers. The Engine Team and I have already been looking into this and made some good first steps this year. We have a new stress test framework that’s easy for code to use, better imGUI debug profiling support, and better auto-capturing and analysis of performance data. Whilst it may be a little early to bear much fruit for Alpha 3.13, it should be a big help for us in the long run. There is also a mandate this year for all teams to assign more time to optimizations that will help in this effort. And with server meshing on the horizon along with several other longer-term planned optimizations, we potentially have some much more significant gains we can make when those come online. Rob Johnson, Engineering Director - Persistent Universe Gameplay Links ----- No links available. Images ------ 3 image/jpeg [ ![](https://robertsspaceindustries.com/media/ytla5z7bq5h29r/source/XenothreatScreens_Phase01_122020.jpg) ](https://robertsspaceindustries.com/media/ytla5z7bq5h29r/source/XenothreatScreens_Phase01_122020.jpg) XenothreatScreens_Phase01_122020.jpg [Details](https://api.star-citizen.wiki/comm-links/images/26655) Last Modified 5 years ago Size 4.01 MB [Source](https://robertsspaceindustries.com/media/ytla5z7bq5h29r/source/XenothreatScreens_Phase01_122020.jpg) [Info](https://api.star-citizen.wiki/comm-links/images/26655) image/jpeg [ ![](https://robertsspaceindustries.com/media/w30khqhoiqk6xr/source/Xenothreat_Supply.jpg) ](https://robertsspaceindustries.com/media/w30khqhoiqk6xr/source/Xenothreat_Supply.jpg) Xenothreat_Supply.jpg [Details](https://api.star-citizen.wiki/comm-links/images/26664) Last Modified 5 years ago Size 4.48 MB [Source](https://robertsspaceindustries.com/media/w30khqhoiqk6xr/source/Xenothreat_Supply.jpg) [Info](https://api.star-citizen.wiki/comm-links/images/26664) image/jpeg [ ![](https://robertsspaceindustries.com/media/j5ktx2dyvbudur/source/Xenothreat_Phase4_12020.jpg) ](https://robertsspaceindustries.com/media/j5ktx2dyvbudur/source/Xenothreat_Phase4_12020.jpg) Xenothreat_Phase4_12020.jpg [Details](https://api.star-citizen.wiki/comm-links/images/26839) Last Modified 5 years ago Size 5.89 MB [Source](https://robertsspaceindustries.com/media/j5ktx2dyvbudur/source/Xenothreat_Phase4_12020.jpg) [Info](https://api.star-citizen.wiki/comm-links/images/26839) Metadata -------- CIG ID 18028 Channel Undefined Category Undefined Series None Comments 0 Published 5 years ago (2021-03-11T01:00:00+00:00) [RSI Article](https://robertsspaceindustries.com/comm-link/SCW/18028-API) [API](https://api.star-citizen.wiki/api/comm-links/18028)