{"data":{"id":18243,"title":"Alpha 3.13 & Invictus Launch Week Postmortem","rsi_url":"https:\/\/robertsspaceindustries.com\/comm-link\/SCW\/18243-API","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-links\/18243","api_public_url":"https:\/\/api.star-citizen.wiki\/comm-links\/18243","channel":"Undefined","category":"Undefined","series":"None","images":[{"id":27732,"name":"source.jpg","rsi_url":"https:\/\/media.robertsspaceindustries.com\/bmdfwn2hec5bm\/source.jpg","alt":"","size":549221,"mime_type":"image\/jpeg","last_modified":"2021-05-20T19:49:42+00:00","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/27732","similar_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/27732\/similar"}],"images_count":5,"translations":{"en_EN":"Alpha 3.13 & Invictus Launch Week Postmortem\n07\/21\/2021 - 9:00 PM\n\nOn April 22, 2021, we launched Alpha 3.13: Underground Infamy, which introduced a number of new features and changes, including ship-to-ship docking, additional cave entrances, and the Reputation Manager. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. As a side note, this postmortem focuses on both the Alpha 3.13 patch and the Invictus Launch Week event.\n\nVehicle Pillar\nJohn Crewe, Vehicle Director\n\nFor Star Citizen Alpha 3.13, the Vehicle Pillar delivered a mixture of new features, the groundwork for future initiatives, and our usual content drop.\n\nMerlin\/Constellation Docking\nWhat went well?\nWe successfully delivered a long-awaited feature to one of Star Citizen\u2019s most iconic ships. Although we had aimed to do this in Alpha 3.12, the decision to spend an extra quarter polishing it paid dividends upon release as it was much more stable and expansive than originally planned.\n\nWhat didn\u2019t go so well?\nThe decision to delay XenoThreat into 2021 meant we were caught up longer than expected in bug fixing for the event, which reduced our ability to react to issues with the feature before it went to Evocati for testing.\n\nWhat we\u2019ll do differently in the future\nGenerally, the feature process went well, so aside from more testing sooner, there isn\u2019t a huge amount we\u2019ll improve on in the future.\n\nVehicle Names\/Serials\nWhat went well?\nThe ability to personalize your ship has been a long-requested feature, and it\u2019s something we\u2019ve wanted to deliver for a long time, but we\u2019ve had a few behind-the-scenes technical issues we had to solve regarding the rendering and platform-to-game entitlement flow. The delivery for a small selection of ships proved out the tech and helped us better understand the limitations of the system.\n\nWhat didn\u2019t go so well?\nBy far the biggest issue was readability, particularly for shorter names where the font size stayed the same as a maximum-length 32-character name. A short name combined with less-than-ideal exterior ship lighting and the inability to customize text color lead to some major readability problems.\n\nWhat we\u2019ll do differently in the future\nWe\u2019re working with the Graphics and UI teams on better implementation via Building Blocks to allow us to dynamically change the font size based on the input string length. An optimized UV layout will be created to accommodate this. The paint system will also have work done in the future to allow players to pick the name color to avoid clashing.\n\n\nHull Visual Degradation\nWhat went well?\nSince Star Citizen Alpha 3.6 when we introduced item degradation and misfires, the big part missing was having your ship\u2019s hull visually degrade alongside the other items. Now we\u2019ve completed this, you get a much-improved read on the state of your ship based on the hull\u2019s visuals rather than having to go MFD hunting. The system ties into our existing production pipeline for vehicles so we didn\u2019t have to go back and add it to any ships, making the implementation much quicker.\n\nWhat didn\u2019t go so well?\nThere were quite a few ships that were missed in our internal testing sweeps, leading to the canopy entirely \u2018scratching\u2019 over, blocking the view. This was not our intention - restricting wear to the edge of the view was the goal.\n\nWhile the actual content side has been part of our pipeline, it wasn\u2019t easily visualized, so the Content Team have to go back and manually adjust the wear maps and settings on older ships.\n\nWhat we\u2019ll do differently in the future\nAs mentioned, a few ships are dramatically wearing too much in key areas, which will be fixed case-by-case. In the future, with physical damage, this will move from being a purely visual feature to it having structural and gameplay consequences.\n\nShip-to-Station Docking\nWhile officially not part of the Alpha 3.13 release, we did in fact launch this feature with the patch, albeit disabled ready to come online with 3.13.1 (Invictus Launch Week). We had originally aimed to deliver both features in the same patch but made the decision to officially hold it back, much for the same reasons we held back Connie\/Merlin docking - to improve the quality of the release.\n\nTumbril Cyclone MT\nThe Cyclone MT was a surprise straight-to-release vehicle that we worked on during downtime between releases that helped expand our ground vehicle line up, particularly for Theaters of War.\n\nThe challenge of having a mounted turret controlling both missiles and weapons caused some head scratching in the setup phase, but the MT provides an interesting firepower addition to the Cyclone lineup at the expense of being the slowest in the family.\n\nGreycat ROC-DS\nThe ROC-DS was a vehicle that struggled both through its development and public release, having originally been designed to be the primary vehicle in the family. However, due to production timelines, we had to release the ROC well in advance of the ROC-DS. The original aim was to have them both release together to provide clearer options for players but having the significant time gap between them just increased the perception issues surrounding its role and usefulness.\n\nWhile it did get some hefty upgrades during the Evocati and PTU phases increasing both its capacity and range, these goals were not communicated well enough at the start of the release cycle, leaving it to suffer more than expected. The ROC-DS was never supposed to be a clear upgrade from the ROC; it\u2019s a companion allowing two players to work together in more demanding locations further away from base.\n\nIt currently sits in a poor position, however future changes to inventory behavior, the cargo system, and cave setups will perhaps let it regain the position we had intended for it. If it doesn\u2019t, we\u2019ll investigate further changes to improve its reception.\n\nLive Pillar\nTodd Papy, Star Citizen Live Director\n\nEUPU: Mining Sub-Components\nWhat went well?\nWe continued to add depth and expand on the mining gameplay and got the sub-components up and running fairly smoothly. The Quality Assurance Test Request (QATR) process went well too, with great communication among the team\n\nWhat didn\u2019t go so well?\nGame-dev stability was poor, which caused delays in getting up-to-date builds with integrations.\n\nWhat we\u2019ll do differently in the future\nThe team is creating QATRs to integrate their work to game dev as a usual process. Unfortunately, QA were super busy with the Alpha 3.13 and 3.13.1 releases, both of which were big ones. This is currently affecting the efficiency of the QATR process, leading to sprint integrations of non-upcoming releases being heavily delayed.\n\nLive Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries\nWhat went well?\nIt went smoothly because it was using existing tech, a lot of which was created for the XenoThreat mission.\n\nWhat didn\u2019t go so well?\nSome of the boxes didn't behave as expected, which ended up being an issue with the entity behavior. The timers were not showing the correct time and the box would explode with two mins left.\n\nHurston isn't the best location for long-flight missions because of the location distribution. We did increase the payout but will look at continued refinements.\n\nWhat we\u2019ll do differently in the future\nWe need to improve the handoff of the entity behaviors and clear up responsibility between the teams.\n\nCore Gameplay Pillar\nRichard Tyrer, S42 FPS Game Director\n\nMounted Guns\nWhat went well?\nStar Citizen by its very nature is a mixed arms game combining on-foot, vehicle, and ship combat. Mounted guns slot directly into that trifecta by allowing on-foot players to challenge vehicles and smaller ships. We already have the Animus missile launcher and Scourge railgun, but they only provide a small amount of resistance before you would run out of ammo. With the long-term intention of homesteads and outposts, we wanted to provide the player and AI with additional options for defending these areas.\n\nWe faced two main challenges with the mounted gun: its size and the control scheme. The eagle-eyed among you will probably have noticed that the mounted gun is a Size 1 ship weapon as we needed that sort of firepower. While these are small on a ship, they are huge in the players\u2019 hands, and this provided us with several issues. Firstly, it took up the whole screen in first-person, so the line of sight was terrible and, secondly, the pivot point for ship weapons was not ideal for a character trying to aim down the sights and pivot vertically. As we already had a ship weapon, we were able to get it into the editor quickly, and this allowed us to iterate on the first-person experience very early on without having to worry too much about metrics. This was a real boon as we were able to work out the pivot of the weapon, its viewing angles, and ADS views while still retaining a believability that this was a weapon that could take down a ship.\n\nThe other challenge we faced was the control scheme. We debated for a long time over whether we should use a more FPS-centric control scheme or have something more akin to a ship turret. Fortunately, we had scheduled enough time for us to implement both schemes and play them to see which felt the best. This allowed us to hone in on the experience and deliver a good first iteration. We have also planned long-term to try and add the additional control options to the menu screens so players can choose which they prefer.\n\nWhat didn\u2019t go so well?\nUsing a pre-existing ship weapon allowed us to iterate early on and dial in the metrics without having to create a whole suite of new art. This also had the advantage that, going forward, any Size 1 ship weapon could theoretically be mounted onto a mount. Unfortunately, this didn\u2019t go as smoothly as we hoped, because ship weapons mount from the top rather than the bottom. This meant that the weapon was mounted upside down and had lots of additional geometry that blocked the main view. While this is a relatively easy fix, it does mean that any new weapon we want to use in the future will require further art tweaks and additional data to support it.\n\nWhat we\u2019ll do differently in the future\nMounted guns are a feature that requires a content team to implement it into the \u2018verse (it\u2019s not a systemic feature like jump or actor status). While we always want to get features into the hands of players as soon as possible for testing purposes, I think its current implementation in the PU doesn\u2019t really serve a purpose. In hindsight, I think it would have been better to implement it, ask for specific PTU\/Evocati feedback, and then release it in a later patch once the content teams had had enough chance to build something around it.\n\nTrolley Push\/Pull\nWhat went well?\nTrolley Push\/Pull is a feature that allows players to interact with an object, such as a trolley or block, and push or pull it in the direction of their choosing (providing they have grip). As Star Citizen is a sandbox game that has multiple gravities and planets, we needed to make sure the feature was systemic so that it could work and scale with different weights and environments. We also wanted the trolley to feel physically correct, with heavier loads being harder to control. The team worked directly with the physics programmers in delivering a physically correct model that really feels like you are pushing a trolley or block. The character leans into heavier loads and the controls feel weighty and grounded.\n\nWhat didn\u2019t go so well?\nThe team were highly focused on making sure the trolley felt grounded in the world and they built an elaborate test map that tested multiple facets of the feature including loading onto a ship. This highlighted a significant problem. A lot of the trolleys built over the years had been designed to a character metric with relatively small wheels. Unfortunately, the ships all have different ramps, with some having very hard angular edges and others not lowering to touch the floor at all. This meant that a lot of the trolleys struggled to go up ship ramps and, in some cases, could not get over the edge of the ramp as it was too large (think trying to push a shopping trolley up a curb). As the Vehicle Team was already scheduled for the quarter, we were not able to deliver the full trolley experience.\n\nWhat we\u2019ll do differently in the future\nTrolley Push\/Pull was always designed to serve two purposes: a puzzle mechanic and for cargo loading. As a puzzle mechanic, the feature works well and allows the designers to start creating new and interesting missions\/spaces where players can use trolleys and blocks to access higher vantage points. As a cargo-loading mechanic, it falls short due to the limitations of the wheels and the sizes of ship ramps. Going forward, we will be developing a hover trolley that will alleviate a lot of our issues and rely on the more traditional trolleys for landing zones and specific missions.\n\nSystemic Gameplay & Services\nTony Zurovec, PU Game Director\n\nReputation UI\nWhat went well?\nFor Alpha 3.13, we were able to release the Reputation UI, giving players a visual representation and context for our initial T0 release of the Reputation System in Q4 2020. For that release, we had hooked up reputation to the bounty hunting missions (and a few others), but players had zero visibility on why their mission progression changed. We have also instituted the first pass of rewarding players based on their reputation progress. With the UI now in place, players have much more clarity on their status with both organizations and mission givers.\n\nThe overall development and release for this feature went smoothly for the team. The analytics reports we received showed incredibly positive results with players in the Alpha 3.13 release, which resulted in a higher engagement rate of the bounty hunting missions.\n\nWhat didn\u2019t go so well?\nThere was an unexpected hiccup with some changes to the Reputation Service that were not communicated well to the Feature Team. This resulted in a few urgent fixes that needed to be done awfully close to Alpha 3.13\u2019s release.\n\nAdditionally, we have not converted the entirety of our mission content over to the new system yet, nor have we had time to refactor the mission giver behaviors to be as reactive to the Affinity and Reliability meters. While this is an ongoing effort, and players should look for continued progress, this will unfortunately take time to churn through the entirety of our missions and refactor the mission-giver behaviors.\n\nWhat we\u2019ll do differently in the future?\nWe\u2019ll be aiming to improve our global communication on features going forward, notably for any that involve services or external feature team support. Cross-team initiatives have consistently proven to have some level of communication breakdown due to our global distribution, so we\u2019re always looking for ways to improve this pipeline. Specifically, we are trying to create more technical design documents (TDD) prior to starting these larger initiatives. This should help create global awareness since all applicable groups are required to provide feedback on the TDDs during this process.\n\nAlso, with the system now in place and our second star system on the horizon once server meshing comes online, we are having ongoing design discussions about how we will structure organizations within the universe for the first five systems. These talks include everything from the new-player experience and their starting location, how players progress within a single system, and how major organizations will influence content across multiple systems. This also allows us to define what gameplay will be involved for each of the major mission types, with the current plan to associate each mission type with the reputation tracks within organizations. Throughout this process, we have made significant strides towards (what we feel) will be the initial version\/vision of how this major progression mechanic will affect the overall player experience. While we still need to get final signoff, we feel this falls in line with how reputation has been previously pitched to the public and look forward to driving this forward.\n\nInvictus Launch Week\nWhat went well?\nThe expo event associated with Invictus Launch Week went very smoothly. This is a process that we\u2019ve done multiple times to date, so setting up a new expo event is a known quantity.\n\nOn the other side of the spectrum, the USPU Team did help to get some additional features out with Invictus that expand our Dynamic Mission Service toolbox. This was the first time we have been able to change the inventory of a shop dynamically based on in-game events (something we refer to as Dynamic Shop Modifiers). This will ultimately be tied\/controlled by the Quanta tooling that you may have seen us discuss in our most recent video presentation. We can also use it to not only add new event-specific items, but we can also change whether a shop consumes or replenishes these commodities, which ultimately changes the overall price of the item. These changes are for a limited time during the event, so it allows us to change the economic climate of as many shops as we like to achieve the desired results.\n\nWe also added something related to this that will eventually help us expand the cargo profession. We call them \u201cPrice Threshold Triggers.\u201d These are intended to allow us to trigger missions based on the shop inventories hitting designated levels. However, as a first step towards the creation of missions, we used it to give the players valuable insight into what is currently in demand (to purchase or to sell) at a given location for the duration of the event. This was temporarily done via the journal entries that are generated by the mission system. Now that these are in, the next step will be to send out game-wide requests (any distance we choose across a solar system or between systems) as we move towards a Quanta-driven universe. While the work towards visualizing the shop info within the journal is a temporary solution, all of the underlying functionality is implemented as intended, so there will be very little throw away work once we redo the mission manager UI or add some level of economy info elsewhere within the game (the timeframe on that addition is still TBD).\n\nFinally, with all that said, the players enjoyed the fact that the shops were exposing items and\/or changing the prices dynamically during the event. We are looking forward to expanding on this system as it is really one of the major underpinnings of the economic and cargo systems.\n\nWhat didn\u2019t go so well?\nWe had some changes to the ships\u2019 landing gear system that caused irregularities with their default\/spawned compression values. This ultimately caused a lot of tedious testing on our side to ensure that everything was placed as intended so that we could confirm that anything we DID see was a legitimate problem and not just a placement problem.\n\nFor Dynamic Shop Modifiers, the biggest stressor was that some of the functionality came in quite late in the process, which left very little time for testing the feature in the PTU. Had this feature not worked very well when we finally did get it, this would have been a larger problem. The Ninetails Lockdown event (supposed to go out with Alpha 3.13, then Invictus, and now ultimately Alpha 3.14), was also competing for QA bandwidth during this time, which was one of the main reasons it was pushed to Alpha 3.14. With the priority needing to stay on Invictus, we had no choice but to sacrifice Ninetails as a result, which was a letdown internally.\n\nThe workflow for setting up the shop modifiers and the price threshold triggers was also not conducive to making largescale changes quickly. Additionally, it is currently a bit confusing because, historically, we use the context of \u2018buy\u2019 and \u2018sell\u2019 from the perspective of the player, but this was somehow reversed in the context of threshold triggers. This obviously leads to a lot of confusion when setting these up and absolutely needs to be fixed before going wide with this feature.\n\nAdditionally, while tuning the threshold triggers, we had a strong desire to change shop entries that we didn\u2019t have the ability to edit from the shop modifier UI within Subsumption, including base price offset, current inventory, and a couple of others. We hacked around this by adding items to the inventory to set them up, THEN changing their context from buy to sell when commodities were available to be gathered\/purchased elsewhere within the universe. While this is a common tactic for designers when tools don\u2019t do what they want, it\u2019s generally frowned upon because it\u2019s ultimately adding debt that you need to go back and fix later.\n\nWhat we\u2019ll do differently in the future\nI would like to get additional debugging into the engine that would allow us to quickly debug the landing gear compression discrepancies. To this point though, we\u2019ve already added some new debugging methods into the game since our last expo event. However, these discrepancies could potentially be easier to spot with additional debugging feedback. As we approach the next expo event, I would like to dedicate time to ensuring these issues are easily identified and are easily solved by data-driven solutions.\n\nWe would like to see some better coordination between QA and the dev teams that require larger-scale QA involvement, such as Invictus and Ninetails. We\u2019ve certainly seen and acknowledged several of the pain points that this has caused, but this will continue to come up as we make more of these events, so we will need to tighten up this workflow moving forward. Ideally, we would try and get the delivery of all gameplay features and related services well in advance of any potential delivery date. For example, well before we branch the next release stream and certainly before going to the PTU. I would also like to see less feature development in the release stream as we move forward.\n\nWhile this still needs to be scheduled, I would like to see the UI presentation of the journal entries cleaned up in any future revisions, as they relate to commodities that are in demand. It needs to order them by landing zone and then, within each landing zone, show things you can buy and what you can sell. The ideal solution is to have some type of economic info available someplace like the star map, or a separate app, but as mentioned above, this work currently needs to be scheduled so any additions are TBD.\n\nMission Features\nWhat went well?\nXenoThreat and Fleet Week were two major events worked on by the Mission Feature Team in the first quarter of 2021. The collaboration between us and other departments on both initiatives, especially QA, was stronger than it has ever been previously, and we think you can see that in the finished product.\n\nXenoThreat needed a bit more time to balance and iron out the remaining bugs and thankfully we were allowed that time, even though the initial expectation was that it would be released for the holiday season.\n\nLuckily, we were able to add content to the caves. This was not even on our planned deliverables list for the quarter, but it seemed a shame to release new cave entrances without something present there. We also added a lot more mission locations in the Yela asteroid ring.\n\nOur team was able to add a new debug GUI, which is now proving invaluable for identifying issues at a far more rapid pace. And the creation of new delivery missions went quickly and smoothly, notably due to well-established mission modules and the reuse of entities from XenoThreat.\n\nWhat didn\u2019t go so well?\nXenoThreat, as mentioned, didn\u2019t hit its intended release date. This was obviously unfortunate but, given the scope of what we were trying to achieve with the event, we felt this was understandable and thankfully we were able to give it the proper amount of time to further polish it until it was ready.\n\nCreating and maintaining unique entities was also an issue. For example, the quantum-travel-sensitive boxes were a mixture of several teams' work, so when it comes to bugs it was often difficult to get traction. Continued maintenance of these could now also be an issue as there isn't really a defined developer to own and sustain them.\n\nParasite ships also caused issues for the law system that weren\u2019t spotted until after the initial release of Alpha 3.13.\n\nWhat we\u2019ll do differently in the future\nWe\u2019ll aim to push for the team to be included on any feature that may affect or require support from the law system to try, and get ahead of, and hopefully minimize, any unforeseen issues for future initiatives.\n\nSystemic Services & Tools\nWhat went well?\nAdditional resources from the backend teams provided immediate relief for workload for the Systemic Services & Tools (SST) Team. The SuperCache was deployed and work was able to start on several longer-term initiatives to integrate Quantum into more services. The public presentation came together well and was received very positively. The technology that we invested into presentation displays will be used to demonstrate other high-level concepts in the future.\n\nQuasar was deployed, which is the dynamic mission tool demonstrated during the SST update video released in April. Development of Quasar was straightforward due to the previous work done with Odin last year, which tackled most of the foundational work required to hook into live services and DGS instances. Going forward, the Quasar tool will provide a platform through which dynamic mission content can be instantiated via Quantum.\n\nWork on the ATC service continued, and SST spent time developing a standalone object container decompressor to allow the injection of specific data points to assets without needing to manually re-export each object container through the editor. This work will unlock several other critical areas for data manipulation required for future SST projects.\n\nWhat didn\u2019t go so well?\nA new high-speed AI service was needed to map live positions of mission-spawned NPCs, which ended up being deceptively complex. This new service required work from various teams and pillars, which caused delays and difficulties in testing. Many of our team resources continue to be absorbed addressing bugs that don\u2019t end up being in our sphere of responsibility.\n\nWhat we\u2019ll do differently in the future\nFuture presentations will be significantly more straightforward in terms of the content we demonstrate, and we invested in visualization tools to be able to show high-level concepts on the Starmap quickly and easily.\n\nWe identified issues causing delays on new services like the high-speed AI service and are now more capable of dealing with cross-team initiatives like this going forward. With the groundwork of Quantum laid, we will be able to focus on the integration of other services.\n\nWe\u2019re now better able to identify issues that don\u2019t fall under the responsibility of our team and plan to re-route these issues to the appropriate teams, saving our team members much-needed time to develop services work.\n\nLocations\nIan Leyland, Star Citizen Art Director\n\nWhen went well?\nInvictus Launch Week at the Tobin Convention Centre was fantastic to see, as were the new space-station docking modules and military docks for the event. Outside of what we released in Alpha 3.13, it allowed the team to focus on making solid progress on future locations for the game.\n\nWhat didn\u2019t go so well?\nThe docking feature caused some back and forth among the various teams involved, reducing efficiency. The trolley push\/pull feature created a lot of bugs for the teams that could have been reduced too.\n\nWhat we\u2019ll do differently in the future\nInternally, we follow a process of features and locations having a \u2018go\/no go.\u2019 With regards to a feature like docking, the teams were very compressed in building the feature and creating the locations at the same time. In the future, to reduce the inefficiency this creates, we will look to have more of a buffer between a feature being made and the location being made that utilizes it.","de_DE":"Alpha 3.13 & Invictus Launch Woche Postmortem\n21.07.2021 - 9:00 UHR\n\nAm 22. April 2021 starteten wir die Alpha 3.13: Underground Infamy, die eine Reihe von neuen Features und \u00c4nderungen einf\u00fchrte, darunter das Andocken von Schiff zu Schiff, zus\u00e4tzliche H\u00f6hleneing\u00e4nge und den Reputationsmanager. Der folgende Postmortem stammt von den leitenden Entwicklern selbst und beschreibt detailliert, was geliefert wurde und was sie dar\u00fcber denken, wie es gelaufen ist. Nebenbei bemerkt, konzentriert sich dieser Postmortem sowohl auf den Alpha 3.13 Patch als auch auf das Invictus Launch Week Event.\n\nFahrzeug-S\u00e4ule\nJohn Crewe, Fahrzeug-Direktor\n\nF\u00fcr Star Citizen Alpha 3.13 lieferte die Vehicle Pillar eine Mischung aus neuen Features, der Grundlage f\u00fcr zuk\u00fcnftige Initiativen und unserem \u00fcblichen Content Drop.\n\nMerlin\/Constellation Docking\nWas ist gut gelaufen?\nWir haben erfolgreich ein lang erwartetes Feature f\u00fcr eines der kultigsten Schiffe von Star Citizen geliefert. Obwohl wir das Ziel hatten, dies in Alpha 3.12 zu tun, hat sich die Entscheidung, ein zus\u00e4tzliches Vierteljahr f\u00fcr den Feinschliff zu verwenden, bei der Ver\u00f6ffentlichung ausgezahlt, da es viel stabiler und umfangreicher war als urspr\u00fcnglich geplant.\n\nWas ist nicht so gut gelaufen?\nDie Entscheidung, XenoThreat bis ins Jahr 2021 zu verschieben, bedeutete, dass wir l\u00e4nger als erwartet mit der Fehlerbehebung f\u00fcr das Event besch\u00e4ftigt waren, was unsere M\u00f6glichkeiten einschr\u00e4nkte, auf Probleme mit dem Feature zu reagieren, bevor es an Evocati zum Testen ging.\n\nWas wir in Zukunft anders machen werden\nIm Gro\u00dfen und Ganzen verlief der Feature-Prozess gut, so dass es abgesehen von mehr Tests zu einem fr\u00fcheren Zeitpunkt nicht viel gibt, was wir in Zukunft verbessern werden.\n\n\n\nFahrzeugnamen\/Seriennummern\nWas ist gut gelaufen?\nDie M\u00f6glichkeit, dein Schiff zu personalisieren, ist ein lang ersehntes Feature und etwas, das wir schon lange liefern wollten, aber wir hatten ein paar technische Probleme hinter den Kulissen, die wir in Bezug auf das Rendering und den Fluss von Plattform zu Spielberechtigung l\u00f6sen mussten. Die Auslieferung einer kleinen Auswahl von Schiffen hat die Technik getestet und uns geholfen, die Grenzen des Systems besser zu verstehen.\n\nWas ist nicht so gut gelaufen?\nDas mit Abstand gr\u00f6\u00dfte Problem war die Lesbarkeit, vor allem bei k\u00fcrzeren Namen, bei denen die Schriftgr\u00f6\u00dfe die gleiche blieb wie bei einem maximal 32 Zeichen langen Namen. Ein kurzer Name in Kombination mit der nicht ganz so idealen Au\u00dfenbeleuchtung des Schiffes und der Unm\u00f6glichkeit, die Textfarbe anzupassen, f\u00fchrte zu einigen gro\u00dfen Problemen bei der Lesbarkeit.\n\nWas wir in Zukunft anders machen werden\nWir arbeiten mit den Grafik- und UI-Teams an einer besseren Implementierung \u00fcber Building Blocks, damit wir die Schriftgr\u00f6\u00dfe dynamisch basierend auf der L\u00e4nge des eingegebenen Strings \u00e4ndern k\u00f6nnen. Ein optimiertes UV-Layout wird erstellt, um dies zu ber\u00fccksichtigen. Auch das Farbsystem wird in Zukunft \u00fcberarbeitet, um den Spielern die M\u00f6glichkeit zu geben, die Farbe des Namens zu w\u00e4hlen, um \u00dcberschneidungen zu vermeiden.\n\n\nVisuelle Verschlechterung des Rumpfes\nWas ist gut gelaufen?\nSeit Star Citizen Alpha 3.6, als wir die Degradierung von Gegenst\u00e4nden und Fehlz\u00fcndungen eingef\u00fchrt haben, fehlte der gro\u00dfe Teil, dass der Rumpf deines Schiffes zusammen mit den anderen Gegenst\u00e4nden visuell degradiert. Jetzt, wo wir dies vervollst\u00e4ndigt haben, kannst du den Zustand deines Schiffes anhand der visuellen Darstellung des Rumpfes besser einsch\u00e4tzen, als wenn du auf MFD-Jagd gehen m\u00fcsstest. Das System f\u00fcgt sich in unsere bestehende Produktionspipeline f\u00fcr Fahrzeuge ein, sodass wir nicht zur\u00fcckgehen und es zu allen Schiffen hinzuf\u00fcgen mussten, was die Implementierung viel schneller machte.\n\nWas ist nicht so gut gelaufen?\nEs gab eine ganze Reihe von Schiffen, die bei unseren internen Testdurchl\u00e4ufen \u00fcbersehen wurden, was dazu f\u00fchrte, dass der Baldachin komplett \"\u00fcberkratzte\" und die Sicht versperrte. Das war nicht unsere Absicht - das Ziel war es, die Abnutzung auf den Rand der Sicht zu beschr\u00e4nken.\n\nW\u00e4hrend die eigentliche Inhaltsseite Teil unserer Pipeline war, war es nicht leicht zu visualisieren, so dass das Content Team zur\u00fcckgehen und die Abnutzungskarten und Einstellungen auf \u00e4lteren Schiffen manuell anpassen musste.\n\nWas wir in Zukunft anders machen werden\nWie bereits erw\u00e4hnt, verschlei\u00dfen einige Schiffe in Schl\u00fcsselbereichen dramatisch zu stark, was von Fall zu Fall behoben wird. In Zukunft wird der physische Schaden nicht mehr nur ein rein visuelles Feature sein, sondern auch strukturelle und spielerische Konsequenzen haben.\n\n\n\nSchiff-an-Station-Andocken\nObwohl offiziell nicht Teil der Alpha 3.13, haben wir dieses Feature tats\u00e4chlich mit dem Patch eingef\u00fchrt, wenn auch deaktiviert, um mit 3.13.1 (Invictus Launch Week) online zu gehen. Urspr\u00fcnglich wollten wir beide Features mit demselben Patch ausliefern, aber wir haben uns entschieden, es offiziell zur\u00fcckzuhalten, aus den gleichen Gr\u00fcnden, aus denen wir das Andocken von Connie und Merlin zur\u00fcckgehalten haben - um die Qualit\u00e4t der Ver\u00f6ffentlichung zu verbessern.\n\n\n\nTumbril Cyclone MT\nDer Cyclone MT war ein \u00fcberraschendes Fahrzeug, an dem wir w\u00e4hrend der Downtime zwischen den Ver\u00f6ffentlichungen gearbeitet haben, um unser Angebot an Bodenfahrzeugen zu erweitern, insbesondere f\u00fcr Theaters of War.\n\nDie Herausforderung, einen montierten Turm zu haben, der sowohl Raketen als auch Waffen steuert, verursachte einige Kopfkratzer in der Setup-Phase, aber der MT bietet eine interessante Feuerkraft-Erg\u00e4nzung der Cyclone-Reihe auf Kosten des langsamsten Fahrzeugs der Familie.\n\n\n\nGreycat ROC-DS\nDer ROC-DS war ein Fahrzeug, das sowohl bei der Entwicklung als auch bei der Ver\u00f6ffentlichung zu k\u00e4mpfen hatte, da er urspr\u00fcnglich als prim\u00e4res Fahrzeug der Familie konzipiert war. Aufgrund der Produktionszeiten mussten wir jedoch den ROC deutlich vor dem ROC-DS ver\u00f6ffentlichen. Das urspr\u00fcngliche Ziel war es, beide zusammen zu ver\u00f6ffentlichen, um den Spielern klarere Optionen zu bieten, aber der gro\u00dfe zeitliche Abstand zwischen den beiden Fahrzeugen hat die Wahrnehmung der Rolle und des Nutzens des ROC nur noch verst\u00e4rkt.\n\nW\u00e4hrend der Evocati- und der PTU-Phase erhielt der ROC-DS zwar einige kr\u00e4ftige Upgrades, die sowohl seine Kapazit\u00e4t als auch seine Reichweite erh\u00f6hten, aber diese Ziele wurden zu Beginn des Release-Zyklus nicht gut genug kommuniziert, sodass der ROC-DS mehr leiden musste als erwartet. Der ROC-DS sollte nie ein klares Upgrade des ROC sein, sondern ein Begleiter, der es zwei Spielern erm\u00f6glicht, an anspruchsvolleren Orten, die weiter von der Basis entfernt sind, zusammenzuarbeiten.\n\nEs befindet sich derzeit in einer schlechten Position, aber zuk\u00fcnftige \u00c4nderungen am Inventarverhalten, dem Frachtsystem und den H\u00f6hlen-Setups werden es vielleicht wieder in die Position bringen, die wir ihm zugedacht haben. Sollte dies nicht der Fall sein, werden wir weitere \u00c4nderungen vornehmen, um seine Akzeptanz zu verbessern.\n\nLive S\u00e4ule\nTodd Papy, Star Citizen Live Direktor\n\nEUPU: Bergbau Sub-Komponenten\nWas ist gut gelaufen?\nWir haben das Mining-Gameplay weiter vertieft und erweitert und die Sub-Komponenten ziemlich reibungslos zum Laufen gebracht. Der Quality Assurance Test Request (QATR) Prozess verlief ebenfalls gut, mit einer gro\u00dfartigen Kommunikation im Team.\n\nWas ist nicht so gut gelaufen?\nDie Stabilit\u00e4t der Spielentwicklung war schlecht, was zu Verz\u00f6gerungen bei der Erstellung aktueller Builds mit Integrationen f\u00fchrte.\n\nWas wir in Zukunft anders machen werden\nDas Team erstellt QATRs, um ihre Arbeit in die Spielentwicklung zu integrieren, was ein normaler Prozess ist. Ungl\u00fccklicherweise war die QA mit den beiden gro\u00dfen Releases Alpha 3.13 und 3.13.1 super besch\u00e4ftigt. Dies beeintr\u00e4chtigt derzeit die Effizienz des QATR-Prozesses, was dazu f\u00fchrt, dass Sprint-Integrationen von nicht kommenden Releases stark verz\u00f6gert werden.\n\n\n\nLive Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries\nWas lief gut?\nDie Mission verlief reibungslos, da sie auf bestehende Technologien zur\u00fcckgriff, von denen ein Gro\u00dfteil f\u00fcr die XenoThreat-Mission entwickelt wurde.\n\nWas ist nicht so gut gelaufen?\nEinige der Kisten verhielten sich nicht wie erwartet, was auf ein Problem mit dem Verhalten der Entit\u00e4ten zur\u00fcckzuf\u00fchren war. Die Timer zeigten nicht die richtige Zeit an und die Kiste explodierte zwei Minuten vor Schluss.\n\nHurston ist nicht der beste Ort f\u00fcr lange Flugmissionen aufgrund der Ortsverteilung. Wir haben die Auszahlung erh\u00f6ht, aber wir werden uns weitere Verfeinerungen ansehen.\n\nWas wir in Zukunft anders machen werden\nWir m\u00fcssen die \u00dcbergabe der Verhaltensweisen der Entit\u00e4ten verbessern und die Verantwortung zwischen den Teams kl\u00e4ren.\n\nKern-Gameplay-Pfeiler\nRichard Tyrer, S42 FPS Game Director\n\nMontierte Waffen\nWas ist gut gelaufen?\nStar Citizen ist von Natur aus ein Spiel mit gemischten Waffen, das K\u00e4mpfe zu Fu\u00df, mit Fahrzeugen und Schiffen kombiniert. Die Mounted Guns f\u00fcgen sich direkt in dieses Dreiergespann ein, indem sie den Spielern zu Fu\u00df erlauben, Fahrzeuge und kleinere Schiffe herauszufordern. Wir haben bereits den Animus-Raketenwerfer und die Scourge-Railgun, aber sie bieten nur eine kleine Menge an Widerstand, bevor dir die Munition ausgeht. Mit der langfristigen Absicht, Geh\u00f6fte und Au\u00dfenposten zu errichten, wollten wir dem Spieler und der KI zus\u00e4tzliche M\u00f6glichkeiten geben, diese Gebiete zu verteidigen.\n\nWir standen vor zwei gro\u00dfen Herausforderungen mit dem montierten Gesch\u00fctz: seine Gr\u00f6\u00dfe und das Steuerungsschema. Die Adleraugen unter euch werden wahrscheinlich bemerkt haben, dass das montierte Gesch\u00fctz eine Schiffswaffe der Gr\u00f6\u00dfe 1 ist, da wir diese Art von Feuerkraft ben\u00f6tigten. W\u00e4hrend diese auf einem Schiff klein sind, sind sie in den H\u00e4nden der Spieler riesig, was uns mehrere Probleme bereitete. Erstens nahm sie in der Ego-Perspektive den ganzen Bildschirm ein, so dass die Sichtlinie schrecklich war, und zweitens war der Drehpunkt f\u00fcr Schiffswaffen nicht ideal f\u00fcr einen Charakter, der versucht, auf das Visier zu zielen und sich vertikal zu drehen. Da wir bereits eine Schiffswaffe hatten, konnten wir sie schnell in den Editor einf\u00fcgen, was es uns erm\u00f6glichte, die Ego-Perspektive schon sehr fr\u00fch zu verbessern, ohne uns zu viele Gedanken \u00fcber die Metriken machen zu m\u00fcssen. Das war ein echter Segen, denn so konnten wir den Drehpunkt der Waffe, ihre Blickwinkel und ADS-Ansichten ausarbeiten, ohne dabei die Glaubw\u00fcrdigkeit zu verlieren, dass es sich um eine Waffe handelt, die ein Schiff zerst\u00f6ren kann.\n\nDie andere Herausforderung, der wir gegen\u00fcberstanden, war das Kontrollschema. Wir haben lange dar\u00fcber debattiert, ob wir ein eher FPS-zentriertes Kontrollschema verwenden sollten oder etwas, das eher einem Schiffsturm \u00e4hnelt. Gl\u00fccklicherweise hatten wir genug Zeit eingeplant, um beide Systeme zu implementieren und zu spielen, um zu sehen, welches sich am besten anf\u00fchlt. Das erlaubte uns, die Erfahrung zu verfeinern und eine gute erste Iteration zu liefern. Wir haben auch langfristig geplant, die zus\u00e4tzlichen Steuerungsoptionen in die Men\u00fcbildschirme einzubauen, damit die Spieler w\u00e4hlen k\u00f6nnen, was sie bevorzugen.\n\nWas ist nicht so gut gelaufen?\nDie Verwendung einer bereits existierenden Schiffswaffe erlaubte es uns, fr\u00fch zu iterieren und die Metriken einzustellen, ohne eine ganze Reihe neuer Kunstwerke erstellen zu m\u00fcssen. Das hatte auch den Vorteil, dass in Zukunft theoretisch jede Schiffswaffe der Gr\u00f6\u00dfe 1 auf ein Reittier montiert werden konnte. Leider verlief dies nicht so reibungslos wie erhofft, da Schiffswaffen von oben und nicht von unten montiert werden. Das bedeutete, dass die Waffe verkehrt herum montiert wurde und eine Menge zus\u00e4tzlicher Geometrie hatte, die die Hauptansicht blockierte. Das ist zwar relativ einfach zu beheben, aber es bedeutet, dass jede neue Waffe, die wir in Zukunft verwenden wollen, weitere k\u00fcnstlerische Anpassungen und zus\u00e4tzliche Daten ben\u00f6tigt, um sie zu unterst\u00fctzen.\n\nWas wir in Zukunft anders machen werden\nBerittene Waffen sind ein Feature, das ein Content-Team ben\u00f6tigt, um es in das Verse zu implementieren (es ist kein systemisches Feature wie Sprung oder Schauspieler-Status). Obwohl wir Features immer so schnell wie m\u00f6glich zu Testzwecken in die H\u00e4nde der Spieler geben wollen, denke ich, dass die aktuelle Implementierung im PU nicht wirklich einen Zweck erf\u00fcllt. Im Nachhinein denke ich, dass es besser gewesen w\u00e4re, es zu implementieren, nach spezifischem PTU\/Evocati-Feedback zu fragen und es dann in einem sp\u00e4teren Patch zu ver\u00f6ffentlichen, wenn die Content-Teams genug Gelegenheit hatten, etwas darum herum zu bauen.\n\n\n\nTrolley Push\/Pull\nWas ist gut gelaufen?\nTrolley Push\/Pull ist eine Funktion, die es den Spielern erlaubt, mit einem Objekt zu interagieren, wie z.B. einem Trolley oder einem Block, und ihn in die Richtung ihrer Wahl zu schieben oder zu ziehen (vorausgesetzt, sie haben Grip). Da Star Citizen ein Sandbox-Spiel ist, das verschiedene Schwerkr\u00e4fte und Planeten hat, mussten wir sicherstellen, dass das Feature systemisch ist, damit es mit verschiedenen Gewichten und Umgebungen funktioniert und skaliert. Wir wollten auch, dass sich der Wagen physikalisch korrekt anf\u00fchlt, wobei schwerere Lasten schwieriger zu kontrollieren sind. Das Team arbeitete direkt mit den Physikprogrammierern zusammen, um ein physikalisch korrektes Modell zu liefern, das sich wirklich so anf\u00fchlt, als w\u00fcrde man einen Wagen oder Block schieben. Der Charakter lehnt sich an schwerere Lasten an und die Steuerung f\u00fchlt sich gewichtig und geerdet an.\n\nWas ist nicht so gut gelaufen?\nDas Team war sehr darauf fokussiert, dass sich der Wagen in der Welt geerdet anf\u00fchlt und sie bauten eine aufwendige Testkarte, die mehrere Facetten des Features testete, einschlie\u00dflich des Ladens auf ein Schiff. Dabei wurde ein gro\u00dfes Problem deutlich. Viele der Trolleys, die im Laufe der Jahre gebaut wurden, waren auf eine Charakter-Metrik mit relativ kleinen R\u00e4dern ausgelegt. Leider haben die Schiffe alle unterschiedliche Rampen, wobei einige sehr harte, eckige Kanten haben und andere sich gar nicht bis zum Boden absenken. Das bedeutete, dass viele der Trolleys Schwierigkeiten hatten, die Schiffsrampen hinaufzufahren und in einigen F\u00e4llen nicht \u00fcber die Kante der Rampe kommen konnten, da diese zu gro\u00df war (man denke an das Verseuch, einen Einkaufswagen einen Bordstein hinaufzuschieben). Da das Fahrzeugteam bereits f\u00fcr das Quartal eingeplant war, konnten wir nicht das volle Trolley-Erlebnis liefern.\n\nWas wir in Zukunft anders machen werden\nTrolley Push\/Pull wurde immer so konzipiert, dass es zwei Zwecke erf\u00fcllt: eine R\u00e4tselmechanik und zum Beladen der Ladung. Als R\u00e4tselmechanik funktioniert das Feature gut und erlaubt es den Designern, neue und interessante Missionen\/R\u00e4ume zu erschaffen, in denen Spieler Trolleys und Bl\u00f6cke benutzen k\u00f6nnen, um h\u00f6here Aussichtspunkte zu erreichen. Als Frachtlademechanik f\u00e4llt es aufgrund der Einschr\u00e4nkungen der R\u00e4der und der Gr\u00f6\u00dfe der Schiffsrampen zu kurz. In Zukunft werden wir einen Schwebetrolley entwickeln, der viele unserer Probleme lindern wird und sich auf die traditionelleren Trolleys f\u00fcr Landezonen und spezielle Missionen verlassen wird.\n\nSystemisches Gameplay & Dienstleistungen\nTony Zurovec, PU Spielleiter\n\nReputation UI\nWas ist gut gelaufen?\nIn der Alpha 3.13 konnten wir das Reputations-UI ver\u00f6ffentlichen, das den Spielern eine visuelle Darstellung und einen Kontext f\u00fcr unser erstes T0-Release des Reputationssystems im vierten Quartal 2020 bietet. F\u00fcr diese Ver\u00f6ffentlichung hatten wir den Ruf an die Kopfgeldj\u00e4germissionen (und ein paar andere) gekoppelt, aber die Spieler hatten keinerlei Einblick, warum sich ihr Missionsfortschritt ver\u00e4nderte. Wir haben auch den ersten Durchgang der Belohnung von Spielern basierend auf ihrem Ruffortschritt eingeleitet. Mit der neuen Benutzeroberfl\u00e4che haben die Spieler nun viel mehr Klarheit \u00fcber ihren Status bei Organisationen und Missionsgebern.\n\nDie gesamte Entwicklung und Ver\u00f6ffentlichung dieses Features verlief f\u00fcr das Team reibungslos. Die Analyseberichte, die wir erhalten haben, zeigten unglaublich positive Ergebnisse bei den Spielern in der Alpha 3.13, was zu einer h\u00f6heren Engagement-Rate der Kopfgeldjagdmissionen f\u00fchrte.\n\nWas ist nicht so gut gelaufen?\nEs gab einen unerwarteten Schluckauf mit einigen \u00c4nderungen am Reputation Service, die dem Feature Team nicht gut kommuniziert wurden. Dies f\u00fchrte zu einigen dringenden Korrekturen, die sehr kurz vor der Ver\u00f6ffentlichung der Alpha 3.13 durchgef\u00fchrt werden mussten.\n\nAu\u00dferdem haben wir noch nicht den gesamten Missionsinhalt auf das neue System umgestellt und hatten auch noch keine Zeit, das Verhalten der Missionsgeber so zu \u00fcberarbeiten, dass sie auf die Affinit\u00e4ts- und Zuverl\u00e4ssigkeitsanzeigen reagieren k\u00f6nnen. Dies ist zwar ein fortlaufender Prozess und die Spieler sollten sich auf weitere Fortschritte freuen, aber es wird leider einige Zeit dauern, bis wir alle Missionen umgestellt haben und das Verhalten der Missionsgeber \u00fcberarbeitet haben.\n\nWas wir in Zukunft anders machen werden?\nWir werden uns bem\u00fchen, unsere globale Kommunikation zu den Features zu verbessern, vor allem, wenn es sich um Dienstleistungen oder externe Unterst\u00fctzung handelt. Es hat sich gezeigt, dass es bei team\u00fcbergreifenden Initiativen aufgrund unserer globalen Verteilung immer wieder zu Kommunikationsproblemen kommt, daher suchen wir immer nach M\u00f6glichkeiten, diese Pipeline zu verbessern. Insbesondere versuchen wir, mehr technische Designdokumente (TDD) zu erstellen, bevor wir diese gr\u00f6\u00dferen Initiativen starten. Dies sollte helfen, ein globales Bewusstsein zu schaffen, da alle betroffenen Gruppen w\u00e4hrend dieses Prozesses Feedback zu den TDDs geben m\u00fcssen.\n\nDa das System nun steht und unser zweites Sternensystem am Horizont auftaucht, sobald die Serververmaschung online ist, f\u00fchren wir au\u00dferdem fortlaufende Designgespr\u00e4che dar\u00fcber, wie wir die Organisationen innerhalb des Universums f\u00fcr die ersten f\u00fcnf Systeme strukturieren werden. Diese Gespr\u00e4che beinhalten alles, von der Erfahrung eines neuen Spielers und seinem Startort, wie Spieler innerhalb eines einzelnen Systems vorankommen und wie gro\u00dfe Organisationen den Inhalt \u00fcber mehrere Systeme hinweg beeinflussen werden. Dies erlaubt uns auch, das Gameplay f\u00fcr jeden der Hauptmissionstypen zu definieren, wobei der aktuelle Plan vorsieht, jeden Missionstyp mit den Rufspuren innerhalb der Organisationen zu verkn\u00fcpfen. W\u00e4hrend dieses Prozesses haben wir bedeutende Fortschritte gemacht, die uns zu einer ersten Version\/Vision gef\u00fchrt haben, wie diese wichtige Fortschrittsmechanik das gesamte Spielerlebnis beeinflussen wird. Auch wenn wir noch die endg\u00fcltige Freigabe ben\u00f6tigen, glauben wir, dass dies mit der Art und Weise \u00fcbereinstimmt, wie der Ruf der \u00d6ffentlichkeit bisher pr\u00e4sentiert wurde und freuen uns darauf, dies voranzutreiben.\n\n\n\nInvictus Startwoche\nWas ist gut gelaufen?\nDas Expo-Event, das mit der Invictus Launch Week verbunden war, verlief sehr reibungslos. Das ist ein Prozess, den wir schon mehrfach gemacht haben, also ist das Einrichten eines neuen Expo-Events eine bekannte Gr\u00f6\u00dfe.\n\nAuf der anderen Seite des Spektrums hat das USPU Team dazu beigetragen, einige zus\u00e4tzliche Features mit Invictus herauszubringen, die unsere Dynamic Mission Service Toolbox erweitern. Es war das erste Mal, dass wir in der Lage waren, das Inventar eines Shops dynamisch zu ver\u00e4ndern, basierend auf In-Game-Events (etwas, das wir als Dynamic Shop Modifiers bezeichnen). Dies wird letztendlich mit dem Quanta-Tooling verkn\u00fcpft\/kontrolliert werden, das wir in unserer letzten Videopr\u00e4sentation besprochen haben. Wir k\u00f6nnen damit nicht nur neue ereignisspezifische Gegenst\u00e4nde hinzuf\u00fcgen, sondern auch \u00e4ndern, ob ein Shop diese Waren verbraucht oder wieder auff\u00fcllt, was letztendlich den Gesamtpreis des Gegenstandes ver\u00e4ndert. Diese \u00c4nderungen sind f\u00fcr eine begrenzte Zeit w\u00e4hrend des Events, so dass es uns erlaubt, das wirtschaftliche Klima von so vielen L\u00e4den zu ver\u00e4ndern, wie wir wollen, um die gew\u00fcnschten Ergebnisse zu erzielen.\n\nWir haben auch etwas hinzugef\u00fcgt, das damit zusammenh\u00e4ngt und uns schlie\u00dflich dabei helfen wird, den Beruf des Ladens zu erweitern. Wir nennen sie \"Preisschwellenausl\u00f6ser\". Diese sollen es uns erm\u00f6glichen, Missionen auszul\u00f6sen, die darauf basieren, dass die Vorr\u00e4te der L\u00e4den ein bestimmtes Niveau erreichen. Als ersten Schritt zur Erstellung von Missionen haben wir sie jedoch genutzt, um den Spielern einen wertvollen Einblick zu geben, was an einem bestimmten Ort f\u00fcr die Dauer des Events gerade gefragt ist (zum Kaufen oder Verkaufen). Dies geschah vor\u00fcbergehend \u00fcber die Journaleintr\u00e4ge, die durch das Missionssystem generiert werden. Jetzt, wo diese drin sind, wird der n\u00e4chste Schritt sein, spielweite Anfragen zu verschicken (jede beliebige Distanz, die wir \u00fcber ein Sonnensystem oder zwischen Systemen w\u00e4hlen), w\u00e4hrend wir uns in Richtung eines Quanta-gesteuerten Universums bewegen. W\u00e4hrend die Arbeit an der Visualisierung der Shop-Informationen im Journal eine tempor\u00e4re L\u00f6sung ist, ist die gesamte zugrundeliegende Funktionalit\u00e4t wie beabsichtigt implementiert, so dass es nur sehr wenig wegwerfbare Arbeit geben wird, sobald wir die Missionsmanager-UI \u00fcberarbeiten oder ein gewisses Ma\u00df an Wirtschaftsinformationen an anderer Stelle im Spiel hinzuf\u00fcgen (der Zeitrahmen f\u00fcr diese Erg\u00e4nzung ist noch offen).\n\nAbschlie\u00dfend sei gesagt, dass die Spieler die Tatsache genossen haben, dass die L\u00e4den w\u00e4hrend des Events Gegenst\u00e4nde freilegen und\/oder die Preise dynamisch \u00e4ndern. Wir freuen uns darauf, dieses System weiter auszubauen, da es wirklich eine der wichtigsten Grundlagen f\u00fcr das Wirtschafts- und Frachtsystem ist.\n\nWas ist nicht so gut gelaufen?\nWir hatten einige \u00c4nderungen am Fahrwerkssystem der Schiffe, die Unregelm\u00e4\u00dfigkeiten mit den Standard-\/Spawned-Kompressionswerten verursachten. Dies f\u00fchrte zu einer Menge langwieriger Tests auf unserer Seite, um sicherzustellen, dass alles wie vorgesehen platziert wurde, so dass wir best\u00e4tigen konnten, dass alles, was wir sahen, ein legitimes Problem war und nicht nur ein Platzierungsproblem.\n\nBei den Dynamic Shop Modifiern war der gr\u00f6\u00dfte Stressfaktor, dass einige der Funktionen erst sehr sp\u00e4t in den Prozess kamen, was sehr wenig Zeit f\u00fcr das Testen des Features in der PTU lie\u00df. H\u00e4tte dieses Feature nicht sehr gut funktioniert, als wir es endlich bekamen, w\u00e4re dies ein gr\u00f6\u00dferes Problem gewesen. Das Ninetails Lockdown Event (das mit Alpha 3.13, dann mit Invictus und schlie\u00dflich mit Alpha 3.14 ver\u00f6ffentlicht werden sollte) konkurrierte in dieser Zeit ebenfalls um die QA-Bandbreite, was einer der Hauptgr\u00fcnde war, warum es auf Alpha 3.14 verschoben wurde. Da die Priorit\u00e4t auf Invictus liegen musste, hatten wir keine andere Wahl, als Ninetails zu opfern, was intern eine Entt\u00e4uschung war.\n\nDer Workflow f\u00fcr die Einrichtung der Shop-Modifikatoren und der Preisschwellenausl\u00f6ser war auch nicht gerade f\u00f6rderlich, um schnell gro\u00dfe \u00c4nderungen vorzunehmen. Au\u00dferdem ist es momentan etwas verwirrend, weil wir historisch gesehen den Kontext von 'Kaufen' und 'Verkaufen' aus der Perspektive des Spielers verwenden, aber das wurde im Kontext der Schwellenwertausl\u00f6ser irgendwie umgekehrt. Das f\u00fchrt offensichtlich zu einer Menge Verwirrung beim Einrichten dieser und muss unbedingt behoben werden, bevor man dieses Feature in die Breite tr\u00e4gt.\n\nW\u00e4hrend wir die Schwellenwert-Trigger einstellten, hatten wir au\u00dferdem den starken Wunsch, Shop-Eintr\u00e4ge zu \u00e4ndern, die wir nicht \u00fcber die Shop-Modifikator-UI innerhalb von Subsumption bearbeiten konnten, wie z.B. den Grundpreis-Offset, den aktuellen Bestand und einige andere. Wir umgingen dies, indem wir Gegenst\u00e4nde zum Inventar hinzuf\u00fcgten, um sie einzurichten, DANN \u00e4nderten wir ihren Kontext von Kaufen zu Verkaufen, wenn Waren verf\u00fcgbar waren, um anderswo im Universum gesammelt\/gekauft zu werden. Das ist zwar eine \u00fcbliche Taktik f\u00fcr Designer, wenn Werkzeuge nicht das tun, was sie wollen, aber es ist im Allgemeinen verp\u00f6nt, weil es letztendlich Schuld bedeutet, die man sp\u00e4ter wieder beheben muss.\n\nWas wir in Zukunft anders machen werden\nIch w\u00fcrde gerne zus\u00e4tzliches Debugging in die Engine einbauen, um die Unstimmigkeiten bei der Fahrwerkskompression schnell beheben zu k\u00f6nnen. Allerdings haben wir seit unserem letzten Expo-Event bereits einige neue Debugging-Methoden in das Spiel eingebaut. Allerdings k\u00f6nnten diese Unstimmigkeiten mit zus\u00e4tzlichem Debugging-Feedback leichter zu erkennen sein. W\u00e4hrend wir uns dem n\u00e4chsten Expo-Event n\u00e4hern, w\u00fcrde ich gerne Zeit darauf verwenden, sicherzustellen, dass diese Probleme leicht identifiziert und durch datengesteuerte L\u00f6sungen gel\u00f6st werden k\u00f6nnen.\n\nWir w\u00fcrden gerne eine bessere Koordination zwischen QA und den Entwicklerteams sehen, die eine gr\u00f6\u00dfere QA-Beteiligung ben\u00f6tigen, wie z.B. Invictus und Ninetails. Wir haben sicherlich einige der Schmerzpunkte, die dies verursacht hat, gesehen und anerkannt, aber dies wird weiterhin auftauchen, wenn wir mehr dieser Events machen, also werden wir diesen Workflow in Zukunft straffen m\u00fcssen. Idealerweise w\u00fcrden wir versuchen, die Lieferung aller Gameplay-Features und der dazugeh\u00f6rigen Services lange vor einem m\u00f6glichen Liefertermin zu bekommen. Zum Beispiel, lange bevor wir den n\u00e4chsten Release-Stream abzweigen und sicherlich bevor wir zum PTU gehen. Ich w\u00fcrde auch gerne weniger Feature-Entwicklung im Release-Stream sehen, wenn wir vorankommen.\n\nW\u00e4hrend dies noch geplant werden muss, w\u00fcrde ich gerne die UI-Pr\u00e4sentation der Journaleintr\u00e4ge in zuk\u00fcnftigen Revisionen aufger\u00e4umt sehen, da sie sich auf nachgefragte Waren beziehen. Sie m\u00fcssen nach Landezone geordnet werden und dann innerhalb jeder Landezone zeigen, was man kaufen und was man verkaufen kann. Die ideale L\u00f6sung w\u00e4re es, eine Art von Wirtschaftsinformationen irgendwo auf der Sternenkarte oder in einer separaten App zur Verf\u00fcgung zu haben, aber wie oben erw\u00e4hnt, muss diese Arbeit derzeit geplant werden, daher sind alle Erg\u00e4nzungen TBD.\n\n\n\nMission Features\nWas ist gut gelaufen?\nXenoThreat und Fleet Week waren zwei gro\u00dfe Ereignisse, an denen das Mission Feature Team im ersten Quartal 2021 gearbeitet hat. Die Zusammenarbeit zwischen uns und anderen Abteilungen bei beiden Initiativen, insbesondere der QA, war st\u00e4rker als je zuvor, und wir denken, dass man das im fertigen Produkt sehen kann.\n\nXenoThreat brauchte etwas mehr Zeit, um die verbleibenden Fehler auszubalancieren und auszub\u00fcgeln und zum Gl\u00fcck wurde uns diese Zeit zugestanden, auch wenn die urspr\u00fcngliche Erwartung war, dass es zur Weihnachtszeit ver\u00f6ffentlicht werden w\u00fcrde.\n\nGl\u00fccklicherweise waren wir in der Lage, Inhalte zu den H\u00f6hlen hinzuzuf\u00fcgen. Dies stand nicht einmal auf unserer geplanten Lieferliste f\u00fcr das Quartal, aber es schien eine Schande zu sein, neue H\u00f6hleneing\u00e4nge zu ver\u00f6ffentlichen, ohne dass dort etwas vorhanden ist. Wir haben auch eine Menge weiterer Missionsorte im Yela-Asteroidenring hinzugef\u00fcgt.\n\nUnser Team war in der Lage, eine neue Debug-GUI hinzuzuf\u00fcgen, die sich nun als unsch\u00e4tzbar erweist, um Probleme viel schneller zu identifizieren. Und die Erstellung neuer Liefermissionen ging schnell und reibungslos vonstatten, vor allem dank gut etablierter Missionsmodule und der Wiederverwendung von Entit\u00e4ten aus XenoThreat.\n\nWas ist nicht so gut gelaufen?\nXenoThreat hat, wie bereits erw\u00e4hnt, sein geplantes Ver\u00f6ffentlichungsdatum nicht erreicht. Das war nat\u00fcrlich ungl\u00fccklich, aber in Anbetracht des Umfangs dessen, was wir mit dem Event erreichen wollten, war das verst\u00e4ndlich und zum Gl\u00fcck konnten wir ihm die n\u00f6tige Zeit geben, um es weiter zu polieren, bis es fertig war.\n\nDie Erstellung und Pflege einzigartiger Entit\u00e4ten war ebenfalls ein Thema. Zum Beispiel waren die Quantenreise-empfindlichen Boxen eine Mischung aus der Arbeit mehrerer Teams, so dass es bei Bugs oft schwierig war, diese in den Griff zu bekommen. Die fortlaufende Wartung dieser k\u00f6nnte nun auch ein Problem sein, da es nicht wirklich einen definierten Entwickler gibt, der sie besitzt und aufrechterh\u00e4lt.\n\nParasitenschiffe verursachten auch Probleme mit dem Rechtssystem, die erst nach der Ver\u00f6ffentlichung der Alpha 3.13 entdeckt wurden.\n\nWas wir in Zukunft anders machen werden\nWir werden darauf dr\u00e4ngen, dass das Team bei allen Features, die das Gesetzessystem betreffen oder Unterst\u00fctzung ben\u00f6tigen, mit einbezogen wird, um unvorhergesehene Probleme f\u00fcr zuk\u00fcnftige Initiativen zu vermeiden und hoffentlich zu minimieren.\n\n\n\nSystemische Dienste & Tools\nWas ist gut gelaufen?\nZus\u00e4tzliche Ressourcen aus den Backend-Teams sorgten f\u00fcr eine sofortige Entlastung des Systemic Services & Tools (SST) Teams. Der SuperCache wurde implementiert und die Arbeit an mehreren l\u00e4ngerfristigen Initiativen zur Integration von Quantum in weitere Dienste konnte beginnen. Die \u00f6ffentliche Pr\u00e4sentation kam gut zusammen und wurde sehr positiv aufgenommen. Die Technologie, die wir in die Pr\u00e4sentationsdisplays investiert haben, wird in Zukunft f\u00fcr die Demonstration anderer High-Level-Konzepte verwendet werden.\n\nQuasar wurde eingesetzt, das dynamische Missionstool, das w\u00e4hrend des SST Update Videos im April gezeigt wurde. Die Entwicklung von Quasar war aufgrund der vorangegangenen Arbeit mit Odin im letzten Jahr, die die meisten der grundlegenden Arbeiten, die f\u00fcr die Anbindung an Live-Services und DGS-Instanzen erforderlich sind, in Angriff genommen hat, sehr einfach. In Zukunft wird das Quasar-Tool eine Plattform bieten, \u00fcber die dynamische Missionsinhalte \u00fcber Quantum instanziiert werden k\u00f6nnen.\n\nDie Arbeit am ATC Service wurde fortgesetzt und SST verbrachte Zeit mit der Entwicklung eines eigenst\u00e4ndigen Objektcontainer-Dekompressors, der es erm\u00f6glicht, spezifische Datenpunkte in Assets zu injizieren, ohne jeden Objektcontainer manuell durch den Editor neu exportieren zu m\u00fcssen. Diese Arbeit wird mehrere andere kritische Bereiche f\u00fcr die Datenmanipulation freischalten, die f\u00fcr zuk\u00fcnftige SST Projekte ben\u00f6tigt werden.\n\nWas ist nicht so gut gelaufen?\nEin neuer Hochgeschwindigkeits-KI-Dienst wurde ben\u00f6tigt, um die Live-Positionen der in den Missionen gespawnten NPCs zu kartieren, was sich als \u00e4u\u00dferst komplex herausstellte. Dieser neue Dienst erforderte Arbeit von verschiedenen Teams und S\u00e4ulen, was zu Verz\u00f6gerungen und Schwierigkeiten beim Testen f\u00fchrte. Viele unserer Team-Ressourcen sind weiterhin damit besch\u00e4ftigt, Fehler zu beheben, die am Ende nicht in unserem Verantwortungsbereich liegen.\n\nWas wir in Zukunft anders machen werden\nZuk\u00fcnftige Pr\u00e4sentationen werden deutlich geradliniger sein, was die Inhalte angeht, die wir zeigen, und wir haben in Visualisierungswerkzeuge investiert, um High-Level-Konzepte auf der Starmap schnell und einfach zeigen zu k\u00f6nnen.\n\nWir haben Probleme identifiziert, die zu Verz\u00f6gerungen bei neuen Diensten wie dem Hochgeschwindigkeits-KI-Service gef\u00fchrt haben und sind nun besser in der Lage, team\u00fcbergreifende Initiativen wie diese in Zukunft zu bew\u00e4ltigen. Da die Grundlagen f\u00fcr Quantum gelegt sind, k\u00f6nnen wir uns auf die Integration anderer Dienste konzentrieren.\n\nWir sind nun besser in der Lage, Probleme zu identifizieren, die nicht in den Verantwortungsbereich unseres Teams fallen und planen, diese Probleme an die entsprechenden Teams weiterzuleiten, was unseren Teammitgliedern dringend ben\u00f6tigte Zeit f\u00fcr die Entwicklung der Dienste spart.\n\nStandorte\nIan Leyland, Star Citizen Art Director\n\nWann lief es gut?\nDie Invictus Launch Week im Tobin Convention Centre war fantastisch, ebenso wie die neuen Raumstations-Andockmodule und Milit\u00e4rdocks f\u00fcr das Event. Abgesehen von dem, was wir in der Alpha 3.13 ver\u00f6ffentlicht haben, erlaubte es dem Team, sich darauf zu konzentrieren, solide Fortschritte bei zuk\u00fcnftigen Locations f\u00fcr das Spiel zu machen.\n\nWas ist nicht so gut gelaufen?\nDas Docking-Feature verursachte einige Hin- und Herbewegungen zwischen den verschiedenen beteiligten Teams, was die Effizienz reduzierte. Das Trolley Push\/Pull Feature verursachte eine Menge Bugs f\u00fcr die Teams, die ebenfalls h\u00e4tten reduziert werden k\u00f6nnen.\n\nWas wir in Zukunft anders machen werden\nIntern folgen wir einem Prozess, bei dem Features und Standorte ein 'Go\/No Go' haben. In Bezug auf ein Feature wie das Andocken waren die Teams sehr komprimiert, wenn es darum ging, das Feature zu bauen und gleichzeitig die Standorte zu erstellen. Um die Ineffizienz, die dadurch entsteht, zu reduzieren, werden wir in Zukunft versuchen, einen gr\u00f6\u00dferen Puffer zwischen der Erstellung eines Features und der Erstellung des Ortes, der es nutzt, zu haben.","zh_CN":"Alpha 3.13 & Invictus Launch Week Postmortem\n07\/21\/2021 - 9:00 PM\n\nOn April 22, 2021, we launched Alpha 3.13: Underground Infamy, which introduced a number of new features and changes, including ship-to-ship docking, additional cave entrances, and the Reputation Manager. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. As a side note, this postmortem focuses on both the Alpha 3.13 patch and the Invictus Launch Week event.\n\nVehicle Pillar\nJohn Crewe, Vehicle Director\n\nFor Star Citizen Alpha 3.13, the Vehicle Pillar delivered a mixture of new features, the groundwork for future initiatives, and our usual content drop.\n\nMerlin\/Constellation Docking\nWhat went well?\nWe successfully delivered a long-awaited feature to one of Star Citizen\u2019s most iconic ships. Although we had aimed to do this in Alpha 3.12, the decision to spend an extra quarter polishing it paid dividends upon release as it was much more stable and expansive than originally planned.\n\nWhat didn\u2019t go so well?\nThe decision to delay XenoThreat into 2021 meant we were caught up longer than expected in bug fixing for the event, which reduced our ability to react to issues with the feature before it went to Evocati for testing.\n\nWhat we\u2019ll do differently in the future\nGenerally, the feature process went well, so aside from more testing sooner, there isn\u2019t a huge amount we\u2019ll improve on in the future.\n\nVehicle Names\/Serials\nWhat went well?\nThe ability to personalize your ship has been a long-requested feature, and it\u2019s something we\u2019ve wanted to deliver for a long time, but we\u2019ve had a few behind-the-scenes technical issues we had to solve regarding the rendering and platform-to-game entitlement flow. The delivery for a small selection of ships proved out the tech and helped us better understand the limitations of the system.\n\nWhat didn\u2019t go so well?\nBy far the biggest issue was readability, particularly for shorter names where the font size stayed the same as a maximum-length 32-character name. A short name combined with less-than-ideal exterior ship lighting and the inability to customize text color lead to some major readability problems.\n\nWhat we\u2019ll do differently in the future\nWe\u2019re working with the Graphics and UI teams on better implementation via Building Blocks to allow us to dynamically change the font size based on the input string length. An optimized UV layout will be created to accommodate this. The paint system will also have work done in the future to allow players to pick the name color to avoid clashing.\n\n\nHull Visual Degradation\nWhat went well?\nSince Star Citizen Alpha 3.6 when we introduced item degradation and misfires, the big part missing was having your ship\u2019s hull visually degrade alongside the other items. Now we\u2019ve completed this, you get a much-improved read on the state of your ship based on the hull\u2019s visuals rather than having to go MFD hunting. The system ties into our existing production pipeline for vehicles so we didn\u2019t have to go back and add it to any ships, making the implementation much quicker.\n\nWhat didn\u2019t go so well?\nThere were quite a few ships that were missed in our internal testing sweeps, leading to the canopy entirely \u2018scratching\u2019 over, blocking the view. This was not our intention - restricting wear to the edge of the view was the goal.\n\nWhile the actual content side has been part of our pipeline, it wasn\u2019t easily visualized, so the Content Team have to go back and manually adjust the wear maps and settings on older ships.\n\nWhat we\u2019ll do differently in the future\nAs mentioned, a few ships are dramatically wearing too much in key areas, which will be fixed case-by-case. In the future, with physical damage, this will move from being a purely visual feature to it having structural and gameplay consequences.\n\nShip-to-Station Docking\nWhile officially not part of the Alpha 3.13 release, we did in fact launch this feature with the patch, albeit disabled ready to come online with 3.13.1 (Invictus Launch Week). We had originally aimed to deliver both features in the same patch but made the decision to officially hold it back, much for the same reasons we held back Connie\/Merlin docking - to improve the quality of the release.\n\nTumbril Cyclone MT\nThe Cyclone MT was a surprise straight-to-release vehicle that we worked on during downtime between releases that helped expand our ground vehicle line up, particularly for Theaters of War.\n\nThe challenge of having a mounted turret controlling both missiles and weapons caused some head scratching in the setup phase, but the MT provides an interesting firepower addition to the Cyclone lineup at the expense of being the slowest in the family.\n\nGreycat ROC-DS\nThe ROC-DS was a vehicle that struggled both through its development and public release, having originally been designed to be the primary vehicle in the family. However, due to production timelines, we had to release the ROC well in advance of the ROC-DS. The original aim was to have them both release together to provide clearer options for players but having the significant time gap between them just increased the perception issues surrounding its role and usefulness.\n\nWhile it did get some hefty upgrades during the Evocati and PTU phases increasing both its capacity and range, these goals were not communicated well enough at the start of the release cycle, leaving it to suffer more than expected. The ROC-DS was never supposed to be a clear upgrade from the ROC; it\u2019s a companion allowing two players to work together in more demanding locations further away from base.\n\nIt currently sits in a poor position, however future changes to inventory behavior, the cargo system, and cave setups will perhaps let it regain the position we had intended for it. If it doesn\u2019t, we\u2019ll investigate further changes to improve its reception.\n\nLive Pillar\nTodd Papy, Star Citizen Live Director\n\nEUPU: Mining Sub-Components\nWhat went well?\nWe continued to add depth and expand on the mining gameplay and got the sub-components up and running fairly smoothly. The Quality Assurance Test Request (QATR) process went well too, with great communication among the team\n\nWhat didn\u2019t go so well?\nGame-dev stability was poor, which caused delays in getting up-to-date builds with integrations.\n\nWhat we\u2019ll do differently in the future\nThe team is creating QATRs to integrate their work to game dev as a usual process. Unfortunately, QA were super busy with the Alpha 3.13 and 3.13.1 releases, both of which were big ones. This is currently affecting the efficiency of the QATR process, leading to sprint integrations of non-upcoming releases being heavily delayed.\n\nLive Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries\nWhat went well?\nIt went smoothly because it was using existing tech, a lot of which was created for the XenoThreat mission.\n\nWhat didn\u2019t go so well?\nSome of the boxes didn't behave as expected, which ended up being an issue with the entity behavior. The timers were not showing the correct time and the box would explode with two mins left.\n\nHurston isn't the best location for long-flight missions because of the location distribution. We did increase the payout but will look at continued refinements.\n\nWhat we\u2019ll do differently in the future\nWe need to improve the handoff of the entity behaviors and clear up responsibility between the teams.\n\nCore Gameplay Pillar\nRichard Tyrer, S42 FPS Game Director\n\nMounted Guns\nWhat went well?\nStar Citizen by its very nature is a mixed arms game combining on-foot, vehicle, and ship combat. Mounted guns slot directly into that trifecta by allowing on-foot players to challenge vehicles and smaller ships. We already have the Animus missile launcher and Scourge railgun, but they only provide a small amount of resistance before you would run out of ammo. With the long-term intention of homesteads and outposts, we wanted to provide the player and AI with additional options for defending these areas.\n\nWe faced two main challenges with the mounted gun: its size and the control scheme. The eagle-eyed among you will probably have noticed that the mounted gun is a Size 1 ship weapon as we needed that sort of firepower. While these are small on a ship, they are huge in the players\u2019 hands, and this provided us with several issues. Firstly, it took up the whole screen in first-person, so the line of sight was terrible and, secondly, the pivot point for ship weapons was not ideal for a character trying to aim down the sights and pivot vertically. As we already had a ship weapon, we were able to get it into the editor quickly, and this allowed us to iterate on the first-person experience very early on without having to worry too much about metrics. This was a real boon as we were able to work out the pivot of the weapon, its viewing angles, and ADS views while still retaining a believability that this was a weapon that could take down a ship.\n\nThe other challenge we faced was the control scheme. We debated for a long time over whether we should use a more FPS-centric control scheme or have something more akin to a ship turret. Fortunately, we had scheduled enough time for us to implement both schemes and play them to see which felt the best. This allowed us to hone in on the experience and deliver a good first iteration. We have also planned long-term to try and add the additional control options to the menu screens so players can choose which they prefer.\n\nWhat didn\u2019t go so well?\nUsing a pre-existing ship weapon allowed us to iterate early on and dial in the metrics without having to create a whole suite of new art. This also had the advantage that, going forward, any Size 1 ship weapon could theoretically be mounted onto a mount. Unfortunately, this didn\u2019t go as smoothly as we hoped, because ship weapons mount from the top rather than the bottom. This meant that the weapon was mounted upside down and had lots of additional geometry that blocked the main view. While this is a relatively easy fix, it does mean that any new weapon we want to use in the future will require further art tweaks and additional data to support it.\n\nWhat we\u2019ll do differently in the future\nMounted guns are a feature that requires a content team to implement it into the \u2018verse (it\u2019s not a systemic feature like jump or actor status). While we always want to get features into the hands of players as soon as possible for testing purposes, I think its current implementation in the PU doesn\u2019t really serve a purpose. In hindsight, I think it would have been better to implement it, ask for specific PTU\/Evocati feedback, and then release it in a later patch once the content teams had had enough chance to build something around it.\n\nTrolley Push\/Pull\nWhat went well?\nTrolley Push\/Pull is a feature that allows players to interact with an object, such as a trolley or block, and push or pull it in the direction of their choosing (providing they have grip). As Star Citizen is a sandbox game that has multiple gravities and planets, we needed to make sure the feature was systemic so that it could work and scale with different weights and environments. We also wanted the trolley to feel physically correct, with heavier loads being harder to control. The team worked directly with the physics programmers in delivering a physically correct model that really feels like you are pushing a trolley or block. The character leans into heavier loads and the controls feel weighty and grounded.\n\nWhat didn\u2019t go so well?\nThe team were highly focused on making sure the trolley felt grounded in the world and they built an elaborate test map that tested multiple facets of the feature including loading onto a ship. This highlighted a significant problem. A lot of the trolleys built over the years had been designed to a character metric with relatively small wheels. Unfortunately, the ships all have different ramps, with some having very hard angular edges and others not lowering to touch the floor at all. This meant that a lot of the trolleys struggled to go up ship ramps and, in some cases, could not get over the edge of the ramp as it was too large (think trying to push a shopping trolley up a curb). As the Vehicle Team was already scheduled for the quarter, we were not able to deliver the full trolley experience.\n\nWhat we\u2019ll do differently in the future\nTrolley Push\/Pull was always designed to serve two purposes: a puzzle mechanic and for cargo loading. As a puzzle mechanic, the feature works well and allows the designers to start creating new and interesting missions\/spaces where players can use trolleys and blocks to access higher vantage points. As a cargo-loading mechanic, it falls short due to the limitations of the wheels and the sizes of ship ramps. Going forward, we will be developing a hover trolley that will alleviate a lot of our issues and rely on the more traditional trolleys for landing zones and specific missions.\n\nSystemic Gameplay & Services\nTony Zurovec, PU Game Director\n\nReputation UI\nWhat went well?\nFor Alpha 3.13, we were able to release the Reputation UI, giving players a visual representation and context for our initial T0 release of the Reputation System in Q4 2020. For that release, we had hooked up reputation to the bounty hunting missions (and a few others), but players had zero visibility on why their mission progression changed. We have also instituted the first pass of rewarding players based on their reputation progress. With the UI now in place, players have much more clarity on their status with both organizations and mission givers.\n\nThe overall development and release for this feature went smoothly for the team. The analytics reports we received showed incredibly positive results with players in the Alpha 3.13 release, which resulted in a higher engagement rate of the bounty hunting missions.\n\nWhat didn\u2019t go so well?\nThere was an unexpected hiccup with some changes to the Reputation Service that were not communicated well to the Feature Team. This resulted in a few urgent fixes that needed to be done awfully close to Alpha 3.13\u2019s release.\n\nAdditionally, we have not converted the entirety of our mission content over to the new system yet, nor have we had time to refactor the mission giver behaviors to be as reactive to the Affinity and Reliability meters. While this is an ongoing effort, and players should look for continued progress, this will unfortunately take time to churn through the entirety of our missions and refactor the mission-giver behaviors.\n\nWhat we\u2019ll do differently in the future?\nWe\u2019ll be aiming to improve our global communication on features going forward, notably for any that involve services or external feature team support. Cross-team initiatives have consistently proven to have some level of communication breakdown due to our global distribution, so we\u2019re always looking for ways to improve this pipeline. Specifically, we are trying to create more technical design documents (TDD) prior to starting these larger initiatives. This should help create global awareness since all applicable groups are required to provide feedback on the TDDs during this process.\n\nAlso, with the system now in place and our second star system on the horizon once server meshing comes online, we are having ongoing design discussions about how we will structure organizations within the universe for the first five systems. These talks include everything from the new-player experience and their starting location, how players progress within a single system, and how major organizations will influence content across multiple systems. This also allows us to define what gameplay will be involved for each of the major mission types, with the current plan to associate each mission type with the reputation tracks within organizations. Throughout this process, we have made significant strides towards (what we feel) will be the initial version\/vision of how this major progression mechanic will affect the overall player experience. While we still need to get final signoff, we feel this falls in line with how reputation has been previously pitched to the public and look forward to driving this forward.\n\nInvictus Launch Week\nWhat went well?\nThe expo event associated with Invictus Launch Week went very smoothly. This is a process that we\u2019ve done multiple times to date, so setting up a new expo event is a known quantity.\n\nOn the other side of the spectrum, the USPU Team did help to get some additional features out with Invictus that expand our Dynamic Mission Service toolbox. This was the first time we have been able to change the inventory of a shop dynamically based on in-game events (something we refer to as Dynamic Shop Modifiers). This will ultimately be tied\/controlled by the Quanta tooling that you may have seen us discuss in our most recent video presentation. We can also use it to not only add new event-specific items, but we can also change whether a shop consumes or replenishes these commodities, which ultimately changes the overall price of the item. These changes are for a limited time during the event, so it allows us to change the economic climate of as many shops as we like to achieve the desired results.\n\nWe also added something related to this that will eventually help us expand the cargo profession. We call them \u201cPrice Threshold Triggers.\u201d These are intended to allow us to trigger missions based on the shop inventories hitting designated levels. However, as a first step towards the creation of missions, we used it to give the players valuable insight into what is currently in demand (to purchase or to sell) at a given location for the duration of the event. This was temporarily done via the journal entries that are generated by the mission system. Now that these are in, the next step will be to send out game-wide requests (any distance we choose across a solar system or between systems) as we move towards a Quanta-driven universe. While the work towards visualizing the shop info within the journal is a temporary solution, all of the underlying functionality is implemented as intended, so there will be very little throw away work once we redo the mission manager UI or add some level of economy info elsewhere within the game (the timeframe on that addition is still TBD).\n\nFinally, with all that said, the players enjoyed the fact that the shops were exposing items and\/or changing the prices dynamically during the event. We are looking forward to expanding on this system as it is really one of the major underpinnings of the economic and cargo systems.\n\nWhat didn\u2019t go so well?\nWe had some changes to the ships\u2019 landing gear system that caused irregularities with their default\/spawned compression values. This ultimately caused a lot of tedious testing on our side to ensure that everything was placed as intended so that we could confirm that anything we DID see was a legitimate problem and not just a placement problem.\n\nFor Dynamic Shop Modifiers, the biggest stressor was that some of the functionality came in quite late in the process, which left very little time for testing the feature in the PTU. Had this feature not worked very well when we finally did get it, this would have been a larger problem. The Ninetails Lockdown event (supposed to go out with Alpha 3.13, then Invictus, and now ultimately Alpha 3.14), was also competing for QA bandwidth during this time, which was one of the main reasons it was pushed to Alpha 3.14. With the priority needing to stay on Invictus, we had no choice but to sacrifice Ninetails as a result, which was a letdown internally.\n\nThe workflow for setting up the shop modifiers and the price threshold triggers was also not conducive to making largescale changes quickly. Additionally, it is currently a bit confusing because, historically, we use the context of \u2018buy\u2019 and \u2018sell\u2019 from the perspective of the player, but this was somehow reversed in the context of threshold triggers. This obviously leads to a lot of confusion when setting these up and absolutely needs to be fixed before going wide with this feature.\n\nAdditionally, while tuning the threshold triggers, we had a strong desire to change shop entries that we didn\u2019t have the ability to edit from the shop modifier UI within Subsumption, including base price offset, current inventory, and a couple of others. We hacked around this by adding items to the inventory to set them up, THEN changing their context from buy to sell when commodities were available to be gathered\/purchased elsewhere within the universe. While this is a common tactic for designers when tools don\u2019t do what they want, it\u2019s generally frowned upon because it\u2019s ultimately adding debt that you need to go back and fix later.\n\nWhat we\u2019ll do differently in the future\nI would like to get additional debugging into the engine that would allow us to quickly debug the landing gear compression discrepancies. To this point though, we\u2019ve already added some new debugging methods into the game since our last expo event. However, these discrepancies could potentially be easier to spot with additional debugging feedback. As we approach the next expo event, I would like to dedicate time to ensuring these issues are easily identified and are easily solved by data-driven solutions.\n\nWe would like to see some better coordination between QA and the dev teams that require larger-scale QA involvement, such as Invictus and Ninetails. We\u2019ve certainly seen and acknowledged several of the pain points that this has caused, but this will continue to come up as we make more of these events, so we will need to tighten up this workflow moving forward. Ideally, we would try and get the delivery of all gameplay features and related services well in advance of any potential delivery date. For example, well before we branch the next release stream and certainly before going to the PTU. I would also like to see less feature development in the release stream as we move forward.\n\nWhile this still needs to be scheduled, I would like to see the UI presentation of the journal entries cleaned up in any future revisions, as they relate to commodities that are in demand. It needs to order them by landing zone and then, within each landing zone, show things you can buy and what you can sell. The ideal solution is to have some type of economic info available someplace like the star map, or a separate app, but as mentioned above, this work currently needs to be scheduled so any additions are TBD.\n\nMission Features\nWhat went well?\nXenoThreat and Fleet Week were two major events worked on by the Mission Feature Team in the first quarter of 2021. The collaboration between us and other departments on both initiatives, especially QA, was stronger than it has ever been previously, and we think you can see that in the finished product.\n\nXenoThreat needed a bit more time to balance and iron out the remaining bugs and thankfully we were allowed that time, even though the initial expectation was that it would be released for the holiday season.\n\nLuckily, we were able to add content to the caves. This was not even on our planned deliverables list for the quarter, but it seemed a shame to release new cave entrances without something present there. We also added a lot more mission locations in the Yela asteroid ring.\n\nOur team was able to add a new debug GUI, which is now proving invaluable for identifying issues at a far more rapid pace. And the creation of new delivery missions went quickly and smoothly, notably due to well-established mission modules and the reuse of entities from XenoThreat.\n\nWhat didn\u2019t go so well?\nXenoThreat, as mentioned, didn\u2019t hit its intended release date. This was obviously unfortunate but, given the scope of what we were trying to achieve with the event, we felt this was understandable and thankfully we were able to give it the proper amount of time to further polish it until it was ready.\n\nCreating and maintaining unique entities was also an issue. For example, the quantum-travel-sensitive boxes were a mixture of several teams' work, so when it comes to bugs it was often difficult to get traction. Continued maintenance of these could now also be an issue as there isn't really a defined developer to own and sustain them.\n\nParasite ships also caused issues for the law system that weren\u2019t spotted until after the initial release of Alpha 3.13.\n\nWhat we\u2019ll do differently in the future\nWe\u2019ll aim to push for the team to be included on any feature that may affect or require support from the law system to try, and get ahead of, and hopefully minimize, any unforeseen issues for future initiatives.\n\nSystemic Services & Tools\nWhat went well?\nAdditional resources from the backend teams provided immediate relief for workload for the Systemic Services & Tools (SST) Team. The SuperCache was deployed and work was able to start on several longer-term initiatives to integrate Quantum into more services. The public presentation came together well and was received very positively. The technology that we invested into presentation displays will be used to demonstrate other high-level concepts in the future.\n\nQuasar was deployed, which is the dynamic mission tool demonstrated during the SST update video released in April. Development of Quasar was straightforward due to the previous work done with Odin last year, which tackled most of the foundational work required to hook into live services and DGS instances. Going forward, the Quasar tool will provide a platform through which dynamic mission content can be instantiated via Quantum.\n\nWork on the ATC service continued, and SST spent time developing a standalone object container decompressor to allow the injection of specific data points to assets without needing to manually re-export each object container through the editor. This work will unlock several other critical areas for data manipulation required for future SST projects.\n\nWhat didn\u2019t go so well?\nA new high-speed AI service was needed to map live positions of mission-spawned NPCs, which ended up being deceptively complex. This new service required work from various teams and pillars, which caused delays and difficulties in testing. Many of our team resources continue to be absorbed addressing bugs that don\u2019t end up being in our sphere of responsibility.\n\nWhat we\u2019ll do differently in the future\nFuture presentations will be significantly more straightforward in terms of the content we demonstrate, and we invested in visualization tools to be able to show high-level concepts on the Starmap quickly and easily.\n\nWe identified issues causing delays on new services like the high-speed AI service and are now more capable of dealing with cross-team initiatives like this going forward. With the groundwork of Quantum laid, we will be able to focus on the integration of other services.\n\nWe\u2019re now better able to identify issues that don\u2019t fall under the responsibility of our team and plan to re-route these issues to the appropriate teams, saving our team members much-needed time to develop services work.\n\nLocations\nIan Leyland, Star Citizen Art Director\n\nWhen went well?\nInvictus Launch Week at the Tobin Convention Centre was fantastic to see, as were the new space-station docking modules and military docks for the event. Outside of what we released in Alpha 3.13, it allowed the team to focus on making solid progress on future locations for the game.\n\nWhat didn\u2019t go so well?\nThe docking feature caused some back and forth among the various teams involved, reducing efficiency. The trolley push\/pull feature created a lot of bugs for the teams that could have been reduced too.\n\nWhat we\u2019ll do differently in the future\nInternally, we follow a process of features and locations having a \u2018go\/no go.\u2019 With regards to a feature like docking, the teams were very compressed in building the feature and creating the locations at the same time. In the future, to reduce the inefficiency this creates, we will look to have more of a buffer between a feature being made and the location being made that utilizes it."},"links_count":0,"comment_count":0,"created_at":"2021-07-21T22:00:00+00:00","created_at_human":"4 years ago"},"meta":{"processed_at":"2026-05-14 17:27:54","valid_relations":["images","links"],"prev_id":18242,"next_id":18244}}