{"data":{"id":18028,"title":"XenoThreat Postmortem","rsi_url":"https:\/\/robertsspaceindustries.com\/comm-link\/SCW\/18028-API","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-links\/18028","api_public_url":"https:\/\/api.star-citizen.wiki\/comm-links\/18028","channel":"Undefined","category":"Undefined","series":"None","images":[{"id":26655,"name":"XenothreatScreens_Phase01_122020.jpg","rsi_url":"https:\/\/robertsspaceindustries.com\/media\/ytla5z7bq5h29r\/source\/XenothreatScreens_Phase01_122020.jpg","alt":"","size":4201958,"mime_type":"image\/jpeg","last_modified":"2020-12-14T18:32:30+00:00","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26655","similar_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26655\/similar"},{"id":26664,"name":"Xenothreat_Supply.jpg","rsi_url":"https:\/\/robertsspaceindustries.com\/media\/w30khqhoiqk6xr\/source\/Xenothreat_Supply.jpg","alt":"","size":4701052,"mime_type":"image\/jpeg","last_modified":"2020-12-14T18:52:51+00:00","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26664","similar_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26664\/similar"},{"id":26839,"name":"Xenothreat_Phase4_12020.jpg","rsi_url":"https:\/\/robertsspaceindustries.com\/media\/j5ktx2dyvbudur\/source\/Xenothreat_Phase4_12020.jpg","alt":"","size":6177804,"mime_type":"image\/jpeg","last_modified":"2020-12-14T18:32:27+00:00","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26839","similar_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/26839\/similar"}],"images_count":5,"translations":{"en_EN":"XenoThreat Postmortem\n03\/10\/2021 - 1:00 AM\n\nOn 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.\n\nXenoThreat Mission\nWhat went well?\nThe 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.\n\nAfter 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.\n\nRegarding 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.\n\nOther 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.\n\nWhile it was unfortunate we weren\u2019t 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.\n\nWhat didn\u2019t go so well?\nDynamic 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.\nThe 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.\n\nMore 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.\n\nInternal 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.\n\nThere was a lot of feedback from our community on aspects of the event that could have been better. Players weren\u2019t 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\u2019s feedback threads.\n\nWe knew from the beginning that performance would be a limiting factor and that meant we wouldn\u2019t 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\u2019t kill it quickly, it mostly acting as a bullet sponge with many players mentioning it holding still and continuously firing.\n\nHostility 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.\n\nWhile 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\u2019t 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.\n\nMany 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).\n\nAs 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.\n\nPlayers 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\u2019s 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.\n\nAI 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.\n\nAlthough 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.\n\nTorpedo 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 \u201ceasy\u201d feeling of Phase 3.\n\nThe 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.\n\nWhat we\u2019ll do differently to improve in the future:\nThere are several issues called out above that we are actively discussing and plan to address for future events. Over the coming weeks, we\u2019ll 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.\n\nTony Zurovec, Persistent Universe Game Director\n\nAI Team\nWhat went well?\nXenoThreat 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.\n\nFor 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.\n\nThese 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.\n\nDuring 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.\n\nWhat didn\u2019t go so well\nThe 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.\n\nDuring 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.\n\nTrying 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.\n\nFrancesco Roccucci, AI Director\n\nVehicle Experience Team\nWhat went well?\nThe Vehicle Experience Team\u2019s 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.\n\nThe 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\u2019 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\u2019t rely upon the movement of the ships as much as they do now.\n\nThe 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.\n\nThe 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.\n\nWhat didn\u2019t go so well?\nFrom 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\u2019t 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.\n\nBut 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.\n\nRich Towler, Lead Game Designer\n\nPerformance\nWhat went well?\nWe are constantly looking to improve performance, which is very hard as we constantly add more features to the game. And while there\u2019s 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\u2019ve tried this kind of capital ship combat in past years, we\u2019ve been so far off the mark performance-wise that we couldn\u2019t deliver an event of this scale, so hopefully this is a good first foot on the ladder that we can now improve on.\n\nWhat didn\u2019t go so well?\nMany 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.\n\nWhat we\u2019ll do differently in the future:\nI 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\u2019s 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.\n\nRob Johnson, Engineering Director - Persistent Universe Gameplay","de_DE":"XenoThreat Postmortem\n03\/10\/2021 - 12:00 UHR\n\nAm 4. Februar 2021 haben wir die Alpha 3.12.1: Assault on Stanton, welches das erste dynamische Event im Star Citizen Universum einf\u00fchrte. Der folgende Postmortem stammt von den Senior-Entwicklern selbst und beschreibt, was geliefert wurde und was sie dar\u00fcber denken, wie es gelaufen ist.\n\nXenoThreat Mission\nWas ist gut gelaufen?\nDas urspr\u00fcngliche Design f\u00fcr 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\u00fchlte sich der endg\u00fcltige Entwurf solide und realistisch an. Es gab eine gute Menge an Dokumentation, wie das Event ablaufen w\u00fcrde, einschlie\u00dflich einer High-Level-Aufschl\u00fcsselung, wie man es spielt, welche Feinde spawnen sollten, wie die Belohnungen funktionierten und wie man die Screen-Overrides testet. Dies alles wurde w\u00e4hrend der Entwicklung beibehalten und diente als schnelle Referenz f\u00fcr die QA und andere Abteilungen.\n\nNach einem etwas holprigen Start war die Feedbackschleife bei XenoThreat am Ende eine ziemlich gut ge\u00f6lte Maschine. Der Prozess des Sammelns von Feedback von der PTU \u00fcber das Player Experience Team und die Feedback Reports, das Einsenden von Bugs mit den entsprechenden Labels und das \u00dcberpr\u00fcfen und Triagieren neuer Bugs jeden Tag, um Priorit\u00e4tsanrufe zu erhalten, endete als ein sehr sauberer Prozess. Sp\u00e4ter im Prozess haben wir uns daf\u00fcr entschieden, dass die QA die Tracking-Aufgaben in JIRA eingibt, sobald der Feedback-Report eintrifft, anstatt auf interne Reproduktionen zu warten. Dies erm\u00f6glichte 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\u00fcr einzugeben.\n\nWas 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\u00dfer Teil der positiven Aufnahme. Wenn alles reibungslos funktionierte, war auch das gesamte Spielgef\u00fchl 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\u00fcmmerte, dass sich die K\u00e4mpfe gro\u00dfartig anf\u00fchlen, was eine schnelle Iteration erm\u00f6glichte. Die Erz\u00e4hlung, die mit der Ver\u00f6ffentlichung einherging, war auch ziemlich cool und der XenoThreat Kommandant war effektiv und einsch\u00fcchternd.\n\nAndere Aspekte des Events, die wir als erfolgreich empfanden, waren die gro\u00dfen In-Game-Einkommensm\u00f6glichkeiten f\u00fcr Spieler (alle Phasen), die FPS-Piraten, die die Wrackpl\u00e4tze bev\u00f6lkerten (Phase 2), und der teamorientierte Auszahlungsstil (Phase 2). Viele Spieler sch\u00e4tzten den Bonus, dass sie f\u00fcr die Durchf\u00fchrung des Events in allen Phasen sehr gut bezahlt wurden - dies bot einen weiteren Anreiz zum Weiterspielen und erh\u00f6hte die Wiederspielbarkeit. Obwohl es einige Probleme mit den FPS-KI-Charakteren gab, machte ihre generelle Pr\u00e4senz das Durchqueren der Wrackst\u00e4tten f\u00fcr die Spieler interessanter und trug zum abwechslungsreichen Spielstil bei. Es gab einige Kritiker, die sich mehr Einkommen pro Kiste in einem individuelleren Auszahlungssystem w\u00fcnschten, aber es gab weitaus mehr, die den teamorientierten Stil der Auszahlung mochten, wobei viele sagten, dass es die Zusammenarbeit f\u00f6rderte.\n\nEs 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\u00f6ffentlicht h\u00e4tten und dem, was wir ver\u00f6ffentlicht haben, sind Tag und Nacht, wenn es um Stabilit\u00e4t, Leistung und Lebensqualit\u00e4t geht. Es war eine gro\u00dfartige Entscheidung des F\u00fchrungsteams.\n\nWas ist nicht so gut gelaufen?\nDynamische Events sind ein gro\u00dfer Kraftakt im Management, da ihre Durchf\u00fchrung von mehreren Abteilungen abh\u00e4ngt. Sie erfordern einen Eigent\u00fcmer mit einer klaren Vision und Wissen \u00fcber alle Aspekte, der f\u00fcr Fragen und Feedback zur Verf\u00fcgung 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\u00fchren, dass andere Verantwortlichkeiten ins Rutschen kommen. Wenn Veranstaltungen dieser Gr\u00f6\u00dfenordnung mehrmals im Jahr erforderlich sind, k\u00f6nnen sie nicht einfach von einem bestehenden Team aufgefangen werden, da ihre anderen Verantwortlichkeiten darunter leiden k\u00f6nnen.\nDer Dialog f\u00fcgte der Mission eine Menge hinzu, aber ihn einzuf\u00fchren war ein gro\u00dfes Unterfangen mit langen Vorlaufzeiten, um ihn und die Missionsausl\u00f6ser zu liefern. Die Zeit reichte nicht aus, um die tats\u00e4chlichen Zeilen in die voll funktionierende Mission einzubauen und die entsprechenden \u00c4nderungen zu iterieren. Wir haben zwar schon fr\u00fcher Platzhalterlinien eingebaut, aber da das Feature, das sie ausl\u00f6ste, noch nicht vollst\u00e4ndig funktionierte und die Mission noch nicht komplett fertig war, war es schwierig, sie vor Ort zu \u00fcberpr\u00fcfen. In der Vergangenheit haben wir Programme wie Visio benutzt, um Abl\u00e4ufe zu erstellen, welche Linien wann ausl\u00f6sen und welche Reihenfolgen auftreten sollten. F\u00fcr XenoThreat hatten wir keine Zeit, dies zu tun, also wurde der Dialog direkt in die Logik implementiert. Das machte die Abl\u00e4ufe ad-hoc und eine zus\u00e4tzliche Flussdiagramm-Planung h\u00e4tte den Prozess der Gestaltung der Logik zur Unterst\u00fctzung der Dialog-Trigger erleichtert. \u00dcberraschenderweise musste ein Gro\u00dfteil der Dialogausl\u00f6sung stark in die Missionslogik eingewoben werden, damit sie zum richtigen Zeitpunkt abgefeuert wurde, was bedeutete, dass die Bem\u00fchungen, den Dialog im Kontext zu \u00fcberpr\u00fcfen, unrealistisch waren, selbst wenn alles funktioniert h\u00e4tte und die Mission beendet worden w\u00e4re, wenn Platzhalterzeilen geliefert worden w\u00e4ren. Ich denke, wir m\u00fcssen r\u00fccksichtsvoller mit den Erwartungen an die \u00dcberpr\u00fcfung von Dialogen im Mix umgehen, wenn dieser Mix nur w\u00e4hrend der QA-, PTU- und Evocati-Playtests wirklich zum Tragen kommt.\n\nMehr Zeit f\u00fcr das Prototyping w\u00e4re extrem vorteilhaft gewesen, besonders f\u00fcr die Starfarer-Derelikte, da sich die Anforderungen an das Feature in der Mitte der Entwicklung ge\u00e4ndert haben. Es wurden W\u00fcnsche ge\u00e4u\u00dfert, die Schwerkraft zu den Innenr\u00e4umen hinzuzuf\u00fcgen und die Zielfunktion und UI-Unterst\u00fctzung zu erweitern. Am Ende haben wir eine Version der Starfarer-Derelikte weniger ausgeliefert als urspr\u00fcnglich geplant, da es Probleme mit der Schwerelosigkeit gab. Mehr Prototyping h\u00e4tte es uns auch erm\u00f6glicht, besser zu verstehen, welche Balance n\u00f6tig 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\u00f6ver war, wie z.B. dass die Server-Performance eine Ursache war, anstatt tats\u00e4chliche Balance-Probleme. Das machte es manchmal schwierig, ohne umfangreiche Tests zu \u00fcberpr\u00fcfen, wo die Probleme auftraten.\n\nInterne Tests waren manchmal besonders herausfordernd aufgrund der Schwierigkeit der Reproduktion, der Breite der Reproschritte, der gro\u00dfen Anzahl an ben\u00f6tigten Testern und der Zeitzonenunterschiede. Manchmal bekamen die Entwickler Bugs ohne Repro-Schritte, die sie intern nicht reproduzieren konnten, w\u00e4hrend zu anderen Zeiten die Repro-Schritte unglaublich lang waren und einen enormen Zeitaufwand f\u00fcr das Testen erforderten. Wir m\u00fcssen in der Lage sein, die Mission einfacher zu testen, damit wir ein besseres Verst\u00e4ndnis f\u00fcr den Zustand der Mission zu einem bestimmten Zeitpunkt bekommen k\u00f6nnen. Sp\u00e4ter in der Entwicklung haben wir neue Werkzeuge hinzugef\u00fcgt, um ausgew\u00e4hlte Aspekte der Mission zu umgehen und interne Parameter zu ver\u00e4ndern, um den Testprozess zu beschleunigen. Dies h\u00e4tte schon fr\u00fcher gemacht werden sollen.\n\nEs gab eine Menge Feedback von unserer Community zu Aspekten des Events, die besser h\u00e4tten sein k\u00f6nnen. Die Spieler wurden nicht dar\u00fcber aufgekl\u00e4rt, wie lange Phase 3 aktiv bleiben w\u00fcrde und waren \u00fcberrascht, als sie zu Ende ging. Bessere Informationen, um die Erwartungen zu managen, h\u00e4tten 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\u00fcr die Backer in den Feedback-Threads von Spectrum.\n\nWir wussten von Anfang an, dass die Leistung ein limitierender Faktor sein w\u00fcrde und das bedeutete, dass wir nicht in der Lage sein w\u00fcrden, 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\u00f6ten empfanden, was Phase 3 erheblich beeintr\u00e4chtigte. 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\u00f6ten. 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\u00dferdem stellte die Idris so gut wie keine Bedrohung f\u00fcr die Spieler dar, selbst wenn sie sie nicht schnell t\u00f6teten, da sie haupts\u00e4chlich als Kugelschwamm fungierte und viele Spieler erw\u00e4hnten, dass sie stillhielt und kontinuierlich feuerte.\n\nFeindseligkeitserkennung und CrimeStat-Bestimmung sind immer noch zu simpel, ohne Modifikator f\u00fcr gemeinsame Missionsteilnehmer, ob das getroffene Schiff anvisiert wird oder \u00fcberhaupt eine Verbindung zum Zielen. Mit so vielen Schiffen in unmittelbarer N\u00e4he in einem komplexen Szenario, war Friendly Fire h\u00e4ufig und f\u00fchrte oft dazu, dass Spieler versehentlich einen CrimeStat bekamen, aus der Mission geworfen wurden und nach dem Tod ins Gef\u00e4ngnis geschickt wurden.\n\nW\u00e4hrend wir den Spielern die v\u00f6llige Freiheit lassen wollten, zu w\u00e4hlen, welche Seite sie unterst\u00fctzen wollen, war die Zeit daf\u00fcr nicht ausreichend. Dies f\u00fchrte 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\u00fctzte, gab es nur wenige M\u00f6glichkeiten f\u00fcr die Missionsteilnehmer, dies zu verhindern oder zu kontern, was zu einigen starken Meinungen auf beiden Seiten f\u00fchrte. Die meisten Spieler haben diese Server einfach verlassen, um einen Server ohne PVP zu finden. Von unserer Seite aus denken wir dar\u00fcber nach, wie wir beide Spielstile unterst\u00fctzen k\u00f6nnen.\n\nViele Spieler erw\u00e4hnten die schlechte Framerate des Clients w\u00e4hrend beider Kampfphasen. Au\u00dferdem gab es zahlreiche Berichte \u00fcber das langsame Laden von missionskritischen Objekten wie Wracks, Versorgungsschiffen, XenoThreat-J\u00e4gern und der FPS-KI (die manchmal erst geladen wurde, nachdem die Spieler mit dem L\u00f6schen der Fracht begonnen hatten).\n\nIm Gegensatz zu Phase 2 war Phase 3 ausschlie\u00dflich auf den Schiffskampf ausgerichtet. Das bedeutete, dass alternative Spielstile, wie Bergungen und FPS-K\u00e4mpfe, nicht zum Spiel beitragen konnten, was bei einigen Spielern zu erheblicher Ver\u00e4rgerung und Frustration f\u00fchrte.\n\nDie Spieler haben ein sehr begrenztes und oberfl\u00e4chliches Freund-Feind-Identifikationssystem (IFF), wobei rot entweder direkt feindlich gegen\u00fcber dem Spieler oder jemand mit einem CrimeStat ist und blau alle anderen repr\u00e4sentiert. Es gibt keine M\u00f6glichkeit f\u00fcr die Spieler zu sagen, wer auf der Mission ist, wer aggressiv oder feindlich gegen\u00fcber anderen ist (ohne ein Kommunikationsfeld) und oft auch, wer in ihrer Gruppe ist, da die Gruppenmarker nicht immer zuverl\u00e4ssig sind. Dies war am kritischsten zu Fu\u00df im Wrack, wo \u00fcberhaupt keine Identifikation verwendet wurde und feindliche NSCs, feindliche Spieler und kooperative Spieler in der Mission alle identisch erschienen.\n\nDie KI-K\u00e4mpfer wackelten, warpten, teleportierten sich, flogen unberechenbar und stellten generell keine Bedrohung dar, wobei die Spieler sie h\u00e4ufig als Kanonenfutter bezeichneten. Dar\u00fcber hinaus erw\u00e4hnten die Spieler h\u00e4ufig, wie gering ihre Anzahl zu sein schien, was das Gef\u00fchl der Gefahr einschr\u00e4nkte. Die KI-J\u00e4ger schienen auch kein aggressives Verhalten zu zeigen, wie z.B. das Anvisieren von Frachtschiffen oder Bombern, und ignorierten dabei manchmal eingehenden Schaden.\n\nObwohl einige Spieler anmerkten, dass es viel besser als fr\u00fchere Patches sei, bleibt EVA ein Problem, besonders bei den \u00dcberg\u00e4ngen zwischen den Physik-Gittern (Betreten und Verlassen eines Schiffes), wobei Spieler h\u00e4ufig Schaden nehmen oder sogar sterben. Es wurde von schlechten \u00dcberg\u00e4ngen berichtet, bei denen die Spieler umfallen und\/oder Schaden nehmen, von allgemein schlampigen und unpr\u00e4zisen Bewegungen im Flug und von unangenehmen Kontrollverlusten, wenn man gegen Objekte st\u00f6\u00dft.\n\nTorpedo-Spam dominierte Phase 3 und wurde durch massive Auszahlungen f\u00fcr Treffer weiter gef\u00f6rdert. Die Idrises konnten sie oft nicht richtig kontern und die einfache Art ihrer Nutzung (sperren, abfeuern, fertig) trug stark zum \"einfachen\" Gef\u00fchl von Phase 3 bei.\n\nDie Rechts- und Feindschaftssysteme bed\u00fcrfen erheblicher Arbeit, besonders im Hinblick auf potenzielles Friendly Fire und versehentlichen Schaden. Dazu geh\u00f6rt, wie und warum wir eine CrimeStat anwenden, wie Anklagen erhoben werden, wie Feindseligkeit bestimmt wird, und eine gr\u00fcndliche Diskussion dar\u00fcber, 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.\n\nWas wir anders machen werden, um uns in Zukunft zu verbessern:\nEs gibt mehrere oben genannte Probleme, die wir aktiv diskutieren und f\u00fcr zuk\u00fcnftige 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\u00f6glich sind.\n\nTony Zurovec, Persistent Universe Game Director\n\nKI-Team\nWas ist gut gelaufen?\nXenoThreat war eine gro\u00dfartige Gelegenheit, ein Unternehmensziel \u00fcber mehrere Teams hinweg zu verfolgen. Das ist \u00fcblich, wenn wir bestimmte gemeinsame Ziele festlegen (Meilensteine oder bestimmte Ver\u00f6ffentlichungen) und es bringt normalerweise mehrere Abteilungen zusammen.\n\nF\u00fcr diese Art von Events verlassen wir uns sehr auf andere Teams. Zum Beispiel war das PU-Missionsteam enorm reaktionsfreudig und wir hatten st\u00e4ndig eine Schl\u00fcsselperson als Ansprechpartner f\u00fcr 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.\n\nDiese Events geben uns auch die M\u00f6glichkeit, sowohl neue Features zu nutzen als auch Verbesserungen an bestehenden vorzunehmen. So konnten wir zum Beispiel den ersten Durchgang f\u00fcr den Kampf mit Gro\u00dfkampfschiffen machen, die neue Zuweisung f\u00fcr das Anfordern des Andockens enth\u00fcllen und den aktuellen Mastergraph-Flow f\u00fcr den Pilotenkampf verbessern.\n\nW\u00e4hrend des Events haben wir speziell das KI-Verhalten und das Spielerlebnis \u00fcberpr\u00fcft. Die Tatsache, dass alle relevanten Regisseure an der \u00dcberpr\u00fcfung teilnahmen, erm\u00f6glichte es uns, schnell Feedback zu sammeln und zu diskutieren, was in dem definierten Zeitrahmen noch h\u00e4tte getan werden k\u00f6nnen.\n\nWas nicht so gut gelaufen ist\nDie 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 \u00fcberlasten und kluge Entscheidungen zu treffen, wenn man mit der Entwicklung des Kampfes gegen Kapitalschiffe beginnt. Zum Beispiel, sich auf die Verbesserung der Zielauswahlverteilung \u00fcber die verschiedenen Schiffssitze zu konzentrieren oder die F\u00e4higkeit zu implementieren, die Railgun zu benutzen. Ungl\u00fccklicherweise bedeutete die Menge an Arbeit, die f\u00fcr die Iteration erforderlich war, dass das Ansprechen von Edge Cases nicht vollst\u00e4ndig ber\u00fccksichtigt wurde, was sich auf die Arbeitsbelastung des Teams auswirkte.\n\nW\u00e4hrend 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\u00e4tten behoben werden k\u00f6nnen, wenn man uns richtig darauf aufmerksam gemacht h\u00e4tte. Eine bessere Sorgfaltspflicht beim Testen des Flows kann eine Menge dieser Verwirrung verhindern.\n\nDer 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 \u00fcberrascht.\n\nFrancesco Roccucci, AI Direktor\n\nVehicle Experience Team\nWas ist gut gelaufen?\nDie Arbeit des Vehicle Experience Teams an XenoThreat konzentrierte sich haupts\u00e4chlich darauf, das Flugerlebnis von Gro\u00dfkampfschiffen 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\u00fcrden.\n\nDas Tuning der Flugbalance mit der Idris und der Javelin lief darauf hinaus, der KI zu erm\u00f6glichen, 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\u00e4nde der Spieler gelangen, etwas anders anf\u00fchlen werden. Aber zu diesem Zeitpunkt war dies die richtige Entscheidung, bis wir einige der Verhaltensweisen der Gesch\u00fctzt\u00fcrme verbessert haben, sodass sie nicht mehr so sehr von der Bewegung der Schiffe abh\u00e4ngen.\n\nDie einflussreichsten \u00c4nderungen, die wir vorgenommen haben, betrafen die Geschwindigkeit und St\u00e4rke der Waffen. Das gesamte Event hat uns dazu gedr\u00e4ngt, st\u00e4rkere Waffen hinzuzuf\u00fcgen, einschlie\u00dflich der Einf\u00fchrung der Railgun in die PU, aber wir wollten dies mit der Geschwindigkeit ausgleichen. Je st\u00e4rker 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\u00fcrchtet wird, indem wir die Optik nutzen, um die Vorfreude auf das, was kommt, aufzubauen und den Spielern die M\u00f6glichkeit zu geben, ihr auszuweichen, wenn die Idris es schafft, sie in eine Reihe zu stellen, und f\u00fcr den Moment schie\u00dft sie, um besonders zu sein.\n\nDas Highlight von XenoThreat war f\u00fcr 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\u00fcr 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.\n\nWas ist nicht so gut gelaufen?\nAus 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\u00e4ngig war. Im Laufe der Entwicklung wurde dies mit zunehmender Leistung immer einfacher, aber erst in den letzten Wochen vor der Ver\u00f6ffentlichung erreichten wir einen Punkt, an dem das Event von Anfang bis Ende wie erwartet ablief, wenn alles reibungslos lief.\n\nPositiv ist jedoch, dass die Performance-Probleme, die wir w\u00e4hrend 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\u00f6cher in der Balance aufgezeigt, die wir in den kommenden Builds beheben werden.\n\nRich Towler, Lead Game Designer\n\nLeistung\nWas ist gut gelaufen?\nWir versuchen st\u00e4ndig, die Leistung zu verbessern, was sehr schwierig ist, da wir dem Spiel st\u00e4ndig neue Features hinzuf\u00fcgen. Und obwohl es noch viel zu tun gibt, um die Framerate auf das Niveau zu bringen, das wir anstreben, denke ich, dass der gr\u00f6\u00dfte Vorteil von XenoThreat darin liegt, dass wir es auf ein Niveau gebracht haben, das vielen Spielern Spa\u00df macht. Als wir in den vergangenen Jahren diese Art von Kampf mit Gro\u00dfkampfschiffen ausprobiert haben, waren wir von der Leistung her so weit entfernt, dass wir ein Event dieser Gr\u00f6\u00dfenordnung nicht liefern konnten, also ist das hoffentlich ein guter erster Schritt, den wir nun verbessern k\u00f6nnen.\n\nWas ist nicht so gut gelaufen?\nViele Spieler erw\u00e4hnten die schlechte Framerate des Clients, besonders w\u00e4hrend der Schiffsk\u00e4mpfe 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.\n\nWas wir in Zukunft anders machen werden:\nIch denke, die wichtigste Erkenntnis aus XenoThreat und den letzten paar Releases ist, dass wir ein besseres System f\u00fcr Profiling und Performance-Regression brauchen, damit wir die Werkzeuge f\u00fcr alle Teams haben, um einfacher Profile zu erstellen und die Performance zu optimieren, anstatt von Engp\u00e4ssen oder einer kleinen Handvoll Ingenieure abh\u00e4ngig 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\u00fcr den Code einfach zu benutzen ist, bessere imGUI Debug-Profiling-Unterst\u00fctzung und eine bessere automatische Erfassung und Analyse von Leistungsdaten. Auch wenn es noch ein wenig fr\u00fch ist, um viele Fr\u00fcchte f\u00fcr Alpha 3.13 zu tragen, sollte es langfristig eine gro\u00dfe Hilfe f\u00fcr uns sein. Au\u00dferdem gibt es in diesem Jahr ein Mandat f\u00fcr alle Teams, mehr Zeit f\u00fcr Optimierungen zu verwenden, die dabei helfen werden. Und mit dem Server Meshing am Horizont, zusammen mit einigen anderen l\u00e4ngerfristig geplanten Optimierungen, haben wir potenziell einige viel bedeutendere Gewinne, die wir machen k\u00f6nnen, wenn diese online gehen.\n\nRob Johnson, Technischer Direktor - Persistent Universe Gameplay","zh_CN":"XenoThreat Postmortem\n03\/10\/2021 - 1:00 AM\n\nOn 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.\n\nXenoThreat Mission\nWhat went well?\nThe 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.\n\nAfter 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.\n\nRegarding 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.\n\nOther 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.\n\nWhile it was unfortunate we weren\u2019t 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.\n\nWhat didn\u2019t go so well?\nDynamic 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.\nThe 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.\n\nMore 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.\n\nInternal 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.\n\nThere was a lot of feedback from our community on aspects of the event that could have been better. Players weren\u2019t 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\u2019s feedback threads.\n\nWe knew from the beginning that performance would be a limiting factor and that meant we wouldn\u2019t 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\u2019t kill it quickly, it mostly acting as a bullet sponge with many players mentioning it holding still and continuously firing.\n\nHostility 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.\n\nWhile 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\u2019t 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.\n\nMany 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).\n\nAs 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.\n\nPlayers 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\u2019s 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.\n\nAI 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.\n\nAlthough 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.\n\nTorpedo 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 \u201ceasy\u201d feeling of Phase 3.\n\nThe 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.\n\nWhat we\u2019ll do differently to improve in the future:\nThere are several issues called out above that we are actively discussing and plan to address for future events. Over the coming weeks, we\u2019ll 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.\n\nTony Zurovec, Persistent Universe Game Director\n\nAI Team\nWhat went well?\nXenoThreat 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.\n\nFor 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.\n\nThese 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.\n\nDuring 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.\n\nWhat didn\u2019t go so well\nThe 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.\n\nDuring 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.\n\nTrying 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.\n\nFrancesco Roccucci, AI Director\n\nVehicle Experience Team\nWhat went well?\nThe Vehicle Experience Team\u2019s 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.\n\nThe 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\u2019 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\u2019t rely upon the movement of the ships as much as they do now.\n\nThe 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.\n\nThe 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.\n\nWhat didn\u2019t go so well?\nFrom 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\u2019t 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.\n\nBut 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.\n\nRich Towler, Lead Game Designer\n\nPerformance\nWhat went well?\nWe are constantly looking to improve performance, which is very hard as we constantly add more features to the game. And while there\u2019s 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\u2019ve tried this kind of capital ship combat in past years, we\u2019ve been so far off the mark performance-wise that we couldn\u2019t deliver an event of this scale, so hopefully this is a good first foot on the ladder that we can now improve on.\n\nWhat didn\u2019t go so well?\nMany 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.\n\nWhat we\u2019ll do differently in the future:\nI 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\u2019s 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.\n\nRob Johnson, Engineering Director - Persistent Universe Gameplay"},"links_count":0,"comment_count":0,"created_at":"2021-03-11T01:00:00+00:00","created_at_human":"5 years ago"},"meta":{"processed_at":"2026-05-07 20:20:44","valid_relations":["images","links"],"prev_id":18027,"next_id":18029}}