{"data":{"id":17991,"title":"Alpha 3.12 Postmortem","rsi_url":"https:\/\/robertsspaceindustries.com\/comm-link\/transmission\/17991-Alpha-312-Postmortem","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-links\/17991","api_public_url":"https:\/\/api.star-citizen.wiki\/comm-links\/17991","channel":"Undefined","category":"Undefined","series":"None","images":[{"id":22574,"name":"Misc.png","rsi_url":"https:\/\/robertsspaceindustries.com\/media\/vfkyf0zbkq2sur\/source\/Misc.png","alt":"","size":3788,"mime_type":"image\/png","last_modified":"2016-12-14T20:45:47+00:00","api_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/22574","similar_url":"https:\/\/api.star-citizen.wiki\/api\/comm-link-images\/22574\/similar"}],"images_count":17,"translations":{"en_EN":"Alpha 3.12 Postmortem\nOn December 17, 2020, we launched Alpha 3.12: Assault on Stanton, which introduced a number of new features and changes, including refinery decks, AI improvements, and gas clouds. 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 specifically focuses on the Alpha 3.12 patch \u2013 we will release a separate postmortem Comm-Link focusing on the XenoThreat dynamic event separately. Vehicle Team\n\nWhat went well\nThe Vehicle Pillar primarily supported a lot of other teams\u2019 work for Star Citizen Alpha 3.12, particularly with capital ship combat ahead of the Arlington Bounty, CS5 UEE Navy Idris, and XenoThreat events. We worked not just on how the vehicles function and perform (being the largest ships deployed to the servers yet) but also helped deal with the increased lethality of torpedoes with smarter and more effective AI countermeasure usage.\nPlayers also benefitted from this work with the ability to choose the type of countermeasure and how many are fired in a burst, adding greater tactical choice to the act of diverting incoming missiles and torpedoes. We also added further HUD elements to allow players to see how many of each type they have left along with the current burst size.\nThe last change to countermeasures was an expansion of the Alpha 3.11 changes. This makes each countermeasure type work against all missile seeker types but changes how effective they are depending on the type and number of incoming missiles. Decoys replaced flares as a time-limited point distraction while noise, formerly chaff, became an area-of-effect signal blocker (more countermeasures launched provides a higher chance of spoofing). We also changed the missiles themselves to provide minor variance in their tracking so a successful countermeasure would not divert all missiles equally. In addition to controlling the burst size manually, we added a panic function that empties 25% of available countermeasures in an attempt to overpower a surge of incoming missiles.\nWhat didn\u2019t go so well\n\nWe discovered a lot of issues with the missile setup and balance that caused odd behaviors. However, we decided to leave this until missiles are converted to IFCS 2.0 in Alpha 3.13 as it requires a comprehensive ground-up retune of all missile behaviors. In the future, we want to expand countermeasures by giving players better feedback on their own signatures and missile abilities, which will start coming online with Missile Operator Mode.\nVehicle Entry Identification was a much-requested quality-of-life feature (building upon the ASOP Hangar Spawn notifications of Alpha 3.11) that allows players to quickly identify the points of entrance into a ship. These markers update depending on whether the ship is landed or in zero-g, removing a common complaint new players had of being unable to figure out how to get into their ship. Occasionally these displays wildly offset from the vehicle, which we\u2019re looking into, but that was pretty much the only negative issue with the feature and it was generally well-received.\nThe main content delivery in Alpha 3.12 was the Esperia Talon and Talon Shrike, which are a pair of light fighters that expand the line-up in-game. Generally, these went pretty well and we discussed their development in multiple ISC episodes, including our work on the Hard Surface Shader and iridescent materials.\nUnfortunately, a few issues were present at release that we\u2019re aiming to fix in future patches. These include the screen requiring toggling in Arena Commander (also present on the Prowler) and the Talon Shrike\u2019s missile launchers sometimes stopping functioning after a large number have been fired.\nJohn Crewe\nVehicle Director\n\nUSPU Gameplay Feature Team\nQ4 for the USPU team is always a busy one. Not just for us, but for the entire company. Here\u2019s a brief summary of our more important initiatives that we were able to get into your hands during the quarter. Thankfully, for better or for worse, we didn\u2019t have a massive CitizenCon demo to prepare for this year, but that didn\u2019t stop us from being extremely busy.\nInternational Aerospace Exposition (IAE)\nWhat went well We successfully extended our IAE content into the high-tech art style, which took place at New Babbage on planet microTech. We added several new things to the event this year that tried to cater to comments from the fans. Firstly, we had each manufacturer\u2019s expo hall run for two consecutive days in case fans missed the first and extended the free rental period from one day to two. Hopefully these two things allowed everyone the opportunity to rent the ships they were eager to try. We also had two expo halls running on any given day. This obviously allowed for more things for the players to see and, in the spirit of \u201cmore things to see,\u201d we decided to showcase many of our ship components and weapons in the main hall. Between two halls active each day and all the additional items, this was a true testament that our tech is getting more and more optimized as we would never have been able to do that in the past. Finally, to try and extend accessibility, we added a series of rental kiosks into the \u201cBest In Show\u201d hall, which ran for four days. In these kiosks, we put every vehicle that was shown throughout the course of the show and gave the same two-day rental period. Between all of this, we feel it was the most engaging iteration we\u2019ve created to date.\nWhat didn\u2019t go so well We had two vehicles that were introduced to the game at the IAE show that really came down to the wire in terms of their development. Ultimately, this didn\u2019t allow us to lock down the build until a few days before the show. Because this show is open to the public in November, it had to be released as a point-patch to the Alpha 3.11 build. Not being able to lock down the build before we branched to the Alpha 3.12 build caused some file-management headaches. Critical fixes are still being made to the point release and those same fixes also need to be in the newly branched stream content. This inevitably leads to work getting stomped here and there and, at the end of the day, eats valuable time that could be used to fix other bugs or make new things. Also, some things that we intended to keep secret until a bit closer to the time of the event leaked. This was hardly a major issue, but it\u2019s always nice to be able to surprise the fans from time to time.\nWhat we\u2019ll do differently in the future A few things I really want to focus on as we move forward with this event are: Modularity\/re-use of assets from previous events. The faster we can make these events happen, the more time we\u2019ll have to focus on new content ideas or other solar systems.\n\nPreproduction planning. We know the event will happen again next November, so I would like to iron out things like the color scheme, event logos, location, etc. as early as possible. This way, when it comes time to work on the content, nobody is waiting for anything to be decided and we can just put our heads down and work.\n\nGet all content for the event into the build so we can avoid requiring a point release. As mentioned above, having two release streams\/branches running in parallel is simply asking for trouble.\n\n\nReputation System\nWhat went well Another important system that was added in Q4 was the reputation system that we\u2019ve always intended to have. While this isn\u2019t visible to players yet, they are able to experience it through our mission givers and some of our mission chains (the bounty hunter chain is the most notable series that is currently being unlocked by reputation gains). Not every mission has been converted to the new system, though it will be an ongoing process over the next quarter or two. This new reputation system will be the foundation for a significant number of gameplay systems as we move forward. Not only will this be the main way that content is released to players, it will also be tied to things like NPC responses (currently seen in mission givers), perks and benefits that can be earned by participating in content, for tracking player progress through career paths, for dictating relationships between the organizations within the game, and a number of other essential gameplay loops. We felt that this was so important to get into the game that we elected to release it without any player facing UI (which is in progress for Q1\/Q2 release). But because this is going to be so ingrained in a significant number of systems moving forward, we felt it was worth the sacrifice. Not only will it be represented in a standalone reputation UI that will allow players to view their career tracks with various organizations, it will also track the key NPCs they have interacted with along with their current standing with each. Reputations will be exposed in this UI as they come across them in the universe so that it encourages players to travel around and engage with the content to expose them. Additionally, we will be revamping the Mission Manager to include player visibility as to what sort of reputation requirements they need to acquire missions. Reputation is going to be one of the largest progression mechanics that Star Citizen will have going for it outside of the economy since we are a skill-based sandbox game not driven by \u201cleveling\u201d or \u201ctalent tree\u201d systems. Reputation is now service-driven on the backend as well. This means that all reputation gains can be preserved between patches, which will be a great thing for the players.\nWhat didn\u2019t go so well As far as general development of this feature, it went quite smoothly once we got to dig our heels into it. We had started work on it about a year prior to this but unfortunately got pulled onto some higher priority stuff at the time. If I had it to do over, I would have kept the team on this until it was done and had the desired UI\/UX changes to go along with it. Not having the UI in place with its release, while not game-breaking, is a critical piece of this feature. Ensuring that all our features are intuitive often relies on this type of visual feedback.\nWhat we\u2019ll do differently in the future Moving forward, I would like to try and budget the required time to release a more \u201ccomplete\u201d feature. While it\u2019s not always possible to convert all of a game\u2019s existing content over to new systems like this, I would like to try and make sure we can do more when big changes like these happen in the future. I was happy that we got more than the original intention into place but would have loved to get more time with the Mission Team to help convert even more than we did. The next time something as foundational as this comes up, I would like to personally do a better job of raising global awareness across the company so we can convert as much of it as possible. Front End Conversion to Building Blocks\nWhat went well We were able to convert the initial two screens in the frontend to utilize our Building Blocks tech. In general, I think this process went fairly well. It didn\u2019t require a ton of people and was a fairly self-contained bit of work. We also got the opportunity to fix a few things that we wanted to address since adding the \u201cnew friends\u201d service back in Q1 2020. Switching this over to our new UI system also allowed us to fade all of the UI elements together. Going through this process gave us some time to critically think through the frontend since the project has evolved so much over the last few years. We also set it up so that the current solution can scale up as we add more solar systems. We cleaned up the main screen so that we can have a greater view of the background images. I\u2019m happy that we were able to attribute a different image for each possible landing zone; I think it really helps give new players a sense of what type of location they\u2019re choosing.\nWhat didn\u2019t go so well The frontend is very ingrained with the original CryEngine toolset that we originally started with. The Building Blocks system works based on entities, which means that our core data needs to be loaded so that we have an entity to run the canvas on. On top of that, the original system requires a level to be loaded. Because of this, we were not able to replace any elements prior to selecting what game mode players want to play (at least not with Building-Blocks-based tech\/implementation). The ultimate solution is to completely rework this code base but that was way outside the scope of what we were able to deal with, nor was it our main directive here.\nWhat we\u2019ll do differently in the future The bottom line here is that the game that we based our original frontend on is much different from the game that we are building towards today. I\u2019m not sure how much the USPU Team will be changing the frontend in the future, but the next time we make changes here I\u2019d really like to be working towards the final vision. This would allow us to really streamline the new user experience so that getting into the game for the first time, or back into the game for returning players, is as simple and intuitive as possible. Because we have been bolting on new features one at a time, this part of the game has suffered as a result. If this can be redefined from the ground up, there\u2019s a lot that we\u2019d do differently based on how much the game has evolved.\nRob Reininger\nLead System Designer and USPU Product Owner\n\nSystemic Services & Tools Team\nWhat went well The Systemic Services and Tools (SST) Team continued working on the Quantum simulation and integrating it into services alongside internal presentations of new technology that we\u2019re excited to share with the community soon.\nAdministrative work occurred last quarter to shift around internal CIG resources for SST. The team will be increasing in size to accommodate the growing need for services and support for Quantum across many aspects of the game.\nOutside of services and simulation work, SST created new tools to support the upcoming reputation system and the way reputation is distributed across the game universe. SST continues to support the Star Citizen economy with Data Tools to help alleviate the massive amount of data while we prepare for Quantum to take the reins.\nWhat didn\u2019t go so well As we transition into a larger department, we had some growing pains with our response times to other teams. Features like the refinery service didn\u2019t get the immediate attention they needed while our attention was elsewhere.\nWhat we\u2019ll do differently in the future We\u2019re looking for ways to better streamline and distribute the work coming into SST for the growing team. In addition, we\u2019ve set up automated messaging to supplement the communication coming out of SST to dependent teams.\nJake Muehle\nSenior Technical Designer\n\nDesign Team\nAI Intercepting Torpedoes\nWhat went well Turrets on the Idris intercepting torpedoes works well, and it creates some very cool moments when they successfully intercept.\nWhat didn\u2019t go so well AI accuracy is not good enough to reliably shoot down incoming torpedoes depending on server framerate.\nWhat we\u2019ll do differently in the future We will look to improve the AI accuracy so we can have greater control over how many torpedoes slip through turret defenses.\nAI Fire Mode Usage and Targeting Priorities\nWhat went well The AI using burst-fire greatly improves the look of AI turret fire. Plus, the targeting priorities ensure that the AI are attacking a sensible target for their ship class\/turret size.\nWhat didn\u2019t go so well At the minute, using burst-fire puts the AI at a disadvantage compared to the players as fully automatic firing increases damage.\nWhat we\u2019ll do differently in the future We will rebalance AI burst-firing when capacitors are introduced to reduce the effectiveness of holding down the fire button.\nAI Accuracy Convergence\nWhat went well The new accuracy system acts in a more believable manner as it tracks the target\u2019s position and continues to fire at that position until the target moves. This is preferable to the old system where the AI\u2019s aim would swing wildly as it attempted to miss stationary targets in front of it.\nWhat didn\u2019t go so well The AI is not accurate enough to pose a decent level of threat to the player at the minute. And, the new system tends to miss behind the target\u2019s movement instead of in front, so the players don\u2019t see that they are being shot at as much.\nWhat we\u2019ll do differently in the future We want to improve the accuracy overall and make it so different NPCs have a more noticeable accuracy difference between skilled and unskilled AI. The accuracy system will also be iterated upon to make it overshoot as opposed to undershoot the target more often.\nCapital Ship Combat Behavior\nWhat went well The capital ships now put a good amount of consideration into distance and relative position when engaging other ships. Capital ships without frontal guns will attempt to get in close enough to utilize all of their turrets, while those with large frontal guns will attempt to keep out of the enemy\u2019s range and utilize their powerful long-ranged weapons.\nWhat didn\u2019t go so well The tactic selection doesn\u2019t consider the AI ship\u2019s strength relative to the target enough. For example, when the Idris is fighting a gunship or capital ship, it will attempt to stay at a distance and use its railgun. This often makes sense but can lead to it running away from smaller gunships that it could easily take in a close-range slap fight.\nWhat we\u2019ll do differently in the future We will iterate on the tactic selection so the AI consider their own ship and target in more detail than just the ship class. Also, we will want to allow pilot character traits to affect the capital ship behavior as well.\nElevator Panels\nWhat went well We successfully laid the groundwork for future elevator panels (and other re-styleable screens), making them inherit their styles from the transit system and be usable on any shaped canvas. This means all future panels can use the same two files but still look different.\nWhat didn\u2019t go so well The transit system is very difficult to set up and test in its current form \u2013 the UI Team were unable to get it working properly and had to rely on Level Design to implement. However, UI and Level Design didn\u2019t work on the feature at the same time, resulting in work starting and stopping in different streams and bugs getting missed. New Building Blocks styles are extremely time-consuming to implement due to a lack of tools and an inability to merge files.\nWhat we\u2019ll do differently in the future We\u2019ll make sure that the feature is developed, implemented, and tested in one go in a feature stream so that bugs are picked up and fixed before it\u2019s \u201cfinished.\u201d We\u2019ll also make sure the team that owns the feature has time to fix code issues as part of the feature development cycle and have the UI Team focus on the UI.\nStation Based Refining\nWhat went well We finished the initial gameplay loop for refining, complete with refineries having their own material specializations, workloads, and the ability to refine, collect, and sell refined materials at various places across the galaxy. The refinery decks themselves look spectacular and the UI for the refinery terminal itself is in a great place to expand upon the gameplay loop with very little in the way of reworking things, which should mean quicker iteration down the line.\nWhat didn\u2019t go so well Our planning for every step was extremely thorough, however, due to several situations out of our control, we were unable to reach a point early enough where we could balance the refinery loop the way we intended to. So, we brought forward another already-intended set of changes in the form of the initial mining rebalance to compensate as best we could until we can get the refinery balance to the level we originally wanted. This mining rebalance had the added bonus that it made the MISC Prospector a bit more appealing for people to start out with or rent as well as providing more gameplay experiences for the Argo MOLE or multiple players with Prospectors.\nWhat we\u2019ll do differently in the future Get the UI art play-tested earlier. Some players didn\u2019t know what parts of the screen they could interact with and this would have allowed us to have more time to make changes.\nMining UI Refactor\nWhat went well We reworked the entire mining UI to work with Building Blocks. This went a lot smoother than any of us could have ever hoped as a lot of the mining gameplay loop setup actually worked with Building Blocks straight out of the box without much reworking at all. This gave us leeway to add more to the mining UI than we originally intended to, meaning we were able to not only provide an entirely new UI that\u2019s scalable across three different mining vehicles, but we showed off that scalability by quickly iterating on UI canvas pieces to support previously introduced systems. This included volatile cargo and added an entirely new cargo hold piece that further provides players with information we always wanted to provide but never had the ability to do so.\n\nWhat didn\u2019t go so well The initial pass of the mining UI refactor was trickier to implement than it was to build, with different vehicles having different spaces available to them for the UI, meaning that a lot of behind-the-scenes tweaking was required to actually display the UI in a comfortable way. This is still being fine-tuned and, with future tech coming soon, we hope to broadcast the UI in a slightly more visually appealing way that works better than the current implementation.\nWhat we\u2019ll do differently in the future We\u2019ll iterate more quickly in the future on things like this as we now have a firmer understanding of Building Blocks and its benefits.\nTodd Papy\nStar Citizen Live Director\n\nCore Gameplay Pillar\nMulti-Tool Tractor Beam\nThe Multi-Tool Tractor Beam is an exciting addition to the \u2018verse and is a core piece of functionality that unlocks several gameplay loops that we are working on, such as cargo hauling and EVA traversal spaces. The main use-case for the Tractor Beam in Alpha 3.12 is to allow for easier collection of cargo boxes in EVA either during lost in space missions or for the collection of post-ship-combat loot. While on the surface the Tractor Beam is a point-and-shoot tool, under the hood a lot is going on, and I think the team did a fantastic job of creating a truly systemic feature that is accessible and easy to use.\nThe first challenge that we faced is that we wanted it to work in several different gravity settings and to utilize the weight of an object. This led to several issues, as in zero-g everything is weightless, so it meant that you could potentially move something huge that weighed very little. For example, a planet-sized polystyrene ball. We designed the Tractor Beam around two core concepts \u2013 volume and force. Volume dictates the general size of the object you can lift while force dictates the amount of effort the gun needs to apply to lift the object. This means that for any item that has a mass and physics collider (which every item should already have), the force required to lift it is automatically calculated using the environment\u2019s gravity. This allowed us to build a feature that works with any physics object in the game without having to do lots of manual set up.\nThe second challenge was how do we explain to the player what they can and cannot lift without having to ADS on everything or even worse, use trial and error. Fortunately, the Multi-Tool already has a small screen on the back that allowed us to implement some simple iconography alongside a traffic light color-coding system. This means that we\u2019re able to clearly show all five states of an object by just looking at it: Object can be lifted\n\nObject can be lifted but is out of range\n\nObject is too heavy\n\nObject can never be lifted\n\nYou will travel to the object\n\nWhile we did provide additional information in the ADS view, everything that you need to know is on the back of the tool and I was really pleased we were able to distill so much information into such a small screen.\nWhat didn\u2019t go so well When planning any feature, you want to identify the core experience and then outline any secondary mechanics that would enhance that experience. For example, a jump mechanic by itself is a standalone feature, but you may decide that in-air control (a secondary mechanic) enhances that core experience. With the Tractor Beam, we sat down and identified the core experience of being able to manipulate objects and use it as a grapple hook in EVA, and I feel we delivered on this. But there were some secondary mechanics that I would have liked to ship that we ran out of time to deliver. Specifically, allowing the manipulation of your trajectory using your suit thrusters when using the grapple hook functionality in zero-G.\nUnfortunately, the two systems did not really work well together, with the force used to pull you along overriding any force used by the suit thrusters. It also didn\u2019t help that EVA was also being moved over to using IFCS at the same time and this led to us having to make a priority call to focus on the core experience and make sure that was as polished as can be for release. This happens all the time with features and is the nature of game development, but it was a shame it missed the first iteration. We will add this functionality in a later release.\nWhat we\u2019ll do differently in the future Delivering a feature for release requires lots of different teams coordinating together, from VFX to Audio to the feature team working on the functionality. One of the biggest things I am trying to improve upon is to give the mission designers more time to allow them to integrate all of these different features into the \u2018verse in a meaningful way. If you have read my previous postmortems, you will probably see a trend that this is something I am actively trying to improve, but as multiple teams and schedules are involved, it takes a little bit of time to readjust. If I could go back in time, I would probably have tried to get a simple version into the hands of the mission\/level designers sooner so they could have played with it a little bit more.\nWeapon Zeroing\nWhat went well Weapon zeroing, as the title suggests, allows you to zero weapons to different ranges, allowing you to shoot accurately at much further distances. This means the scope considers the fall-off of the bullet at a specific range and allows you to adjust the sight so you can still aim your reticule at the target. I.e. you don\u2019t have to aim above the target. We already have lots of scopes available and the first challenge was deciding which scopes should zero at all and then deciding whether they should auto-zero or manually-zero. This led to a much wider discussion surrounding manufacturers and their specific traits, such as high-tech or low-tech. While the team could have just focussed on the feature and pushed it out, they have also delivered a long-term plan for the scope attachments for not just current manufacturers but future ones as well.\nThis is something that I fundamentally believe in \u2013 that even though we are working on a live product, we should be making decisions around the final experience in the released game. Sometimes that\u2019s hard as it can mean that certain features are not seen in their best light on first inspection or misunderstood in the short-term by the players. But it\u2019s my job to make sure we are working towards the final vision and the team did a fantastic job of providing a feature that is fun to use but scalable in the future.\nWhat didn\u2019t go so well This was the first feature one of our newest team members worked on. As such, we made sure he had plenty of time to deliver it way before the actual release. In fact, the functionality (not the visuals) was delivered the quarter before and he did a great job. Now, in most cases, this is fantastic as it means we can focus on the experience and make sure it\u2019s of the highest quality. In this case though, due to other priorities and this being done so far ahead of the release, it did not get the full focus of the testing team as they were (rightfully) busy checking things going imminently live. Unfortunately, this meant a fundamental edge case was missed until just before the release, which was that zeroing did not work when the physics patches for the environment streamed out.\nLet me explain. When a character spawns on a planet a series of patches (squares) spawn around them in ever-increasing sizes. These patches cover the render (graphics) quality and the physics collision, with patches further away having less detail and eventually no collision (as physics is relatively expensive). Now, when you move around, the patches dynamically update but it\u2019s not one-to-one. So, a patch you might have just been in may still have its collision as you may want to go back there and it\u2019s more performant to keep it there in the short-term than to keep loading and unloading it. In this case though, it meant when a designer loaded into the editor to test the feature, the patch was loaded and then they moved 2 km away to test weapon zeroing and it worked. Though if a player had never gone to the original position there would be no collision and so the scope would have nothing to test against. This meant in normal game conditions it didn\u2019t work as intended, so we had to reauthor the weapon zeroing code to test against the render geometry instead of the physics one. While this change was not major, it was not ideal as we had planned to work on other features.\nWhat we\u2019ll do differently in the future If I could go back in time, I would most definitely make sure that the feature had been thoroughly tested when it was completed rather than wait for the more traditional go\/no go. While it didn\u2019t affect the feature\u2019s release, it did have knock-on effects for future work as we had to reprioritize during the quarter.\nGemini A03 Sniper Rifle & Behring FS-9 LMG\nWhat went well As with every weapon we add to the game, we must always make sure it fits into the existing weapons\u2019 matrix and offers something unique that doesn\u2019t already exist. With the Gemini A03 sniper rifle, the intention was to make a lightweight, responsive marksman rifle with a lower caliber than its heavier counterparts but high speed and accuracy. I think the team really delivered on that intention and struck a good balance between the high-caliber sniper rifles like the P6-LR and the more assault-orientated weapons like the Gemini S71. While the A03 was a simple addition, the Behring FS-9 was a bit trickier. LMGs as a weapon category are not in a great place right now as they are outgunned by SMG\/shotguns at close range and outmatched by assault rifles at mid-to-long range. This is something we are acutely aware of and have been working behind the scenes to improve. The Behring FS-9 sets the standard for what we want LMGs to be \u2013 high-capacity machineguns that allow players to suppress an area without a huge loss of accuracy.\nWhat didn\u2019t go so well While we were working on the FS-9, we were also working out the design intentions for all the other LMGs so we could deliver an update across the board in one release. Unfortunately, we ran out of time on the existing weapons, although we did manage to do some tweaks to raise their effectiveness. We do plan on updating the existing LMGs to raise them to the same quality bar as the FS-9, but it does mean in the short term it\u2019s vastly superior to the other weapons in the same category. But as I mentioned above, I will always prioritize decisions around what we want the end goal to be so that we are constantly moving forward.\nWhat we\u2019ll do differently in the future We have a plan to overhaul all the weapon categories and hopefully you can see that each weapon we release slightly improves on those that came before it. With this intention, I would have added more time to polish the existing LMGs as I would have liked to release them all together. No matter how experienced you are, you are always learning and this is something I will be implementing for future weapons.\nRichard Tyrer\nCore Gameplay Director\n\nLocations\nSpace Station Refinery Decks\nWhat went well For this release, we were able to introduce refinery decks to some specific space station locations. These spaces are themed around the mining and refining gameplay loops and also serve as a location for future gameplay opportunities. Inside the refinery deck, we created a space specific for refining and processing along with a shop and guild space below.\nAfter seeing the response to the cargo decks and the new space station interiors in Alpha 3.11, we agreed with the comments about players wanting to see more of a visible connection with the exterior to physically understand where they are in the station. Even though we were quite far through developing the refinery deck interior, we pivoted and adapted the space to include the mini viewing deck by the elevator lobbies. Visually, we had wanted to explore a space station experience more focused towards industrial activity for some time, including the global composition of the station to the hot and noisy interior.\nWhat didn\u2019t go so well It was a shame not to see specific NPC loadouts release with the refinery decks or be able to expand some of the specific usables. However, these are all planned so hopefully we will see them come online soon.\nWhat we\u2019ll do differently in the future As mentioned above, we introduced the viewing deck quite late in the process, so we could have designed a superior space with this in mind during concept and whiteboxing.\nStanton Planet Improvements & Polish\nWhat went well Continuing to build on the planetary improvements made throughout 2020, this was the first opportunity the team had to introduce the new and improved workflows developed when creating Pyro\u2019s planets and moons to Stanton.\nImprovement to the workflow included having the time and focus to go deeper on the global painting process. For planets like Stanton I and IV, the global painting was completely redone to be both more accurate to temperature parameters and to have a better blend and distribution of hues. As a second part to the painting, all object presents and distribution rulesets were done from scratch. In general, the focus was to do more with less. So, rather than use many types of geology all in the same space, just use one or two that work really well together. The end result is something much more realistic and natural. A good example of this is on Daymar. Another area we wanted to improve was the increased use of ground scatter objects to complexify the terrain read. We combined a mixture of geology assets like plates, scree, and small rocks with the distribution of the geology packs to give a much more integrated read to the scene.\nAdditionally, some outstanding geology packs were converted to use the organics shader and were processed correctly through Houdini as part of our pipeline.\nSome new tech features came online during this release that we were excited to take advantage of, the first being terrain displacement which replaces POM. So, now you can actually see the terrain geometry get tessellated and displaced giving actual depth and more complex intersections with objects. The second feature is biome accumulation, which means assets can procedurally receive a thin layer of material on their top surface depending on the biome. For example, sand gathering on the top of the rocks on Daymar.\nWhat didn\u2019t go so well As we were trying to close out the year and hit the Alpha 3.12 release, some moons were not able to be taken to the polish level we wanted. Also, as part of introducing our new workflows and methodology to the Stanton system, we noticed the visual styles between some moons are becoming too close together and we\u2019re losing some diversity.\nWhat we\u2019ll do differently in the future More assets will help reduce art fatigue and improve visual diversity, so moving into this year, we\u2019re investing time and energy into more asset packs.\nStanton System Spacescaping\nWhat went well We were all really excited to be able to showcase the gas cloud tech as part of the PU in Alpha 3.12. Lots of hard work was done by many teams to create this new feature, so the process was about establishing a team dedicated to creating content for Stanton, and then starting to look at what we could do for the Lagrange points.\nConsidering this was the first release version of the tech, I feel we created a variety of visual scenarios to show the potential of the tech.\nWhat didn\u2019t go so well As this was the first release, there was obviously a lot to figure out in terms of performance, and there is a great deal we can do in terms of pipeline refinement. There is also some visible noise in some lighting scenarios that we would like to reduce in the future as performance allows.\nWhat we\u2019ll do differently in the future We are already improving our development workflow and looking at ways to improve the process. We are exploring how we can tie together the background spacescape into more mini-system-based forms, which then leads to smaller, volumetric gas pockets. For future gameplay opportunities, we\u2019re looking at encouraging risk\/reward gameplay inside the gas pockets with elements like lightning, radiation, temperature ranges, and flight handling.\nIan Leyland\nStar Citizen Art Director\n\nTechnology\nFor Alpha 3.12, the Graphics Team mainly focussed on improving stability and fixing bugs with the various graphics features utilized in the release. Many of the bug fixes related to the introduction of gas clouds, such as fixing a visible dither pattern when the sun is obscured by a cloud and preventing gas clouds and particles from clipping inside spaceships by improving both the volumetric culling and particle culling systems. Such issues were expected but largely unavoidable because, although the tech has been used extensively in the development of SQ42, the artwork and scenarios are quite different in the PU. Plus, the sandbox nature of the PU and extensive testing it receives meant many previously unknown issues were discovered or raised in priority.\nThe team also managed to resolve dozens of other bugs ranging from popping shadows to over-bright camera exposure when a planet is streamed in. The proportion of time spent bug-fixing compared to new features was higher than we\u2019d have ideally liked, but there\u2019s always an emphasis on stability and quality at the end of the year and feature work has already resumed, so this is not of concern. Despite the slowdown in feature work, we did manage to maintain good progress on the new Gen12 renderer, which will be our primary focus for early 2021.\nThe Physics Team worked on the volumetric soft body prototype as well as the related rendering of volumetric deformation. Moreover, various optimizations were done in physics. For example, we improved the threading of various subsystems, added faster spatial grid queries, removed contention accessing local command queue, and removed contention for actor\/living entities step functions (improving the living entity step performance by a factor of 2x \u2013 5x). We also implemented a better way to pre-physicalize the planet terrain patches used for collision checks. With regard to collision detection, we also fixed a longstanding issue that could introduce additional ghost contacts far off from where the actual contacts were being processed. Furthermore, improvements were made to event queueing. The first draft of propagating physicalized shockwaves was submitted and box-shaped physics grids and bullet drag were added. SDF support was improved and research started on improvements to the setup of touch bending vegetation.\nOn the renderer, we continued with our ongoing Gen12 transition and related refactoring. For instance, we added a parameterizable feature set for the deferred pipeline, implemented per-object resource set updates (including RTT update for brushes) for Gen12 scene-rendering and legacy pipeline state caching (to save DX API calls while we\u2019re still fully transitioning to Gen12). In the shader system, we cleaned up all shader reloading code, which will improve shader editing during development and give a much-improved response when changing system spec settings (e.g. graphics settings that require the use of different shader combinations). We also started a larger refactor of the shader cache backend system as it\u2019s quite outdated and a constant source of grief with regards to maintenance and Gen12 fitness. Several optimizations were done in the renderer code. For instance, the way material constants are uploaded to the GPU was simplified and optimized.\nOn the graphics side, various fixes for depth-of-field were provided. The hair shader received several improvements, such as the ability to disable specular highlights on eyelashes, improved boundary occlusion at hairlines, support for ambient lights in forward shading, as well as improved hair quality during camera cuts. Dual lobe approximation for the skin shader was improved and the eye shader received a couple of improvements as well. As far as atmospheres, clouds, and the unified raymarcher go, the improvements mentioned in the previous postmortem are now available in Alpha 3.12. With that out of the way, most of the time was focused on volumetric cloud rendering. The initial draft of the cloud renderer was implemented and work on volumetric cloud shadows made good progress. Work will commence on improvements to local cloud shaping. Note that there\u2019s still quite a lot of work to be done before release.\nFor the core engine system, we implemented a dynamic zone culling path in the zone system. We also fixed a few view distance-related culling bugs to do with pixel-sized objects that went into Alpha 3.11. People have already noticed that they can now see players over 1000 meters away instead of just a few hundred or so. A lot of bug fixes and improvements were provided for vis-areas, such as a fix for streaming meshes for animated vis-areas and the ability to add vis areas to CGA joints. The entity system received several improvements and optimizations to avoid unnecessary updates and searches. Similarly, the entity aggregate manager received low-level optimizations to improve work balancing and reduce memory use and contention when working with entity bubbles. There were also a few smaller improvements made to the entity component update scheduler. Radix tree culling logic has been improved, with its threading logic adjusted to reduce contention and SIMD culling implemented to check up to four bubbles vs objects per node. With regards to performance, progress continues on the engine profiler, which saw a lot of enhancements. Work on a real-time sampling profiler based on event traces will commence soon. Various optimizations were implemented in the entity system, component updates, and zone system. Based on telemetry from the PU and PTU, we continued our ongoing investigations into memory usage. As such, the engine-wide memory allocator and memory tracking system, including its toolchain, was substantially refactored and improved. To provide an additional performance boost to our servers, the Linux DGS was switched to a monolithic executable to allow the compiler to generate better code (thread local storage access in particular). As part of our initiative to build a performance regression system, we added a stress test for object container streaming too.\nRegarding crash-handling, we now capture a hex stack of the render thread and embed it in mini-dumps that you (optionally) send to us in case the game crashes. This allows us to recover the full render thread call stack during postmortem debugging without the need for third-party binaries (that might be part of call stack or the video driver) to fully unwind the stack. This saves quite a bit of time as we don\u2019t have to download the various drivers that players use.\nOn the animation side, we fixed code so that character blend shapes and the dynamic lighting rig don\u2019t switch too late at every camera cut when rendering cutscenes.\nLastly, C++ 14 support was enabled for the entirety of the client server editor and relevant tool projects.\nOnline Tech\nLoad Balancing Test Framework The pestilence warmer for Alpha 3.12 received major updates. First and foremost, the warmer now uses the new JWT identification system that allows it to fetch many tokens for impersonation purposes very rapidly. This has 10x the throughput of warmer instances we can run at the same time.\nA major subsystem was added that enables the warmer to connect as a service to the diffusion gateway allowing for executing load scenarios that coordinate both as a client connected through the hub and as a service on the diffusion network.\nBackend Concurrency Improvements We were able to increase the performance of the variable service, loadouts, and the main persistence cache service. The stability of the backend increased greatly, surpassing the performance and reliability that we had in previous releases. Our low-level networking code was updated to improve both performance, scalability, and robustness. We also made several fixes and optimizations to the transaction service, rentals, and our entitlement processor.\nUnified and Centralized Logging With our new unified centralized logging system, all services send formatted JSON messages to a centralized Elasticsearch database. Each log event is tagged and dynamic data such as account IDs, player IDs, etc. are extracted into named fields, which makes searching for events or specific fields \u2013 such as an \u201cAccountID\u201d \u2013 very efficient. This allows the devs to easily access logs from a centralized place and track complex messages and events happening between multiple services.\nPersistent Tech\nEntity Creation & Spawn Decoupling In preparation for persistent streaming, the entity creation process was decoupled from entity spawning. This allows us to \u201cseed\u201d the initial state of the universe into the persistent database by creating all dynamic entities prior to simulation. DGS processes will then stream persistent entities (spawn\/despawn) from that database during simulation. This is an important steppingstone for a fully persistent universe.\nParallel Spawn Queues As an optimization, we introduced multiple parallel spawn queues on each game server. This allows us to spawn multiple distinct locations (such as Lorville and New Babbage) in parallel on separate threads on the same server. Previous releases had a single queue and therefore (in this example) we wouldn\u2019t start on New Babbage until Lorville was fully spawned. On busy servers, this can really reduce the wait time in some cases. For example, when spawning waves of AI ships or respawning in a hab.\nNetwork Tech\nTime & De-Syncs How the engine measures the passage of time underwent a complete overhaul. Accuracy was improved both in the measurement of time and in its synchronization between server and clients. How the engine uses time to update its logic and physics simulation was changed to eliminate errors that could result in simulation time passing differently on the server and clients. Many smaller bugs that had caused timing errors to grow on long-running servers were also fixed. The network synchronization of vehicles and physics objects were updated to take full advantage of the improvements. The accumulated result of all these changes was a significant reduction in latency and desynchronization issues in many areas, even under harsh test conditions for network and server performance. Besides improving the overall player experience, this work was a necessary step towards server meshing, where simulating the game across multiple game servers would have made desynchronization issues due to timing errors worse.\nAuthority API In preparation for server meshing, the team performed a sweep on the remaining tasks to convert code to the Authority API. Over the last 12 months, there has been a coordinated effort by all teams to update the game-end engine code to this new system. Thanks to their work, a large majority of these tasks have been completed. With a concerted push, we\u2019ve reduced the number of remaining tasks into single digits.\nConnection Flow In a server mesh, a client may connect to many different servers during a game session. Part of the work towards server meshing requires separating the process of connecting a client to a server into distinct stages. These stages can then be executed independently without requiring a client to completely abandon its existing game session. Significant progress has been made towards this although there is more work to be done.\nMarco Corbetta\nVP of Technology\n\n\nSee you in the \u2018Verse!\nWe believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we\u2019re committed to transparent development and will continue to provide quarterly patch postmortems going forward.","de_DE":"Alpha 3.12 Postmortem\nAm 17. Dezember 2020 haben wir die Alpha 3.12: Assault on Stanton ver\u00f6ffentlicht, die eine Reihe von neuen Features und \u00c4nderungen eingef\u00fchrt hat, darunter Raffinerie-Decks, KI-Verbesserungen und Gaswolken. Der folgende Postmortem stammt von den leitenden Entwicklern selbst und beschreibt, was geliefert wurde und was sie dar\u00fcber denken, wie es gelaufen ist. Nebenbei bemerkt konzentriert sich dieser Postmortem speziell auf den Alpha 3.12 Patch - wir werden einen separaten Postmortem Comm-Link ver\u00f6ffentlichen, der sich auf das dynamische Ereignis XenoThreat konzentriert.\n\n\nFahrzeug-Team\n\nWas gut lief\n\n\nDas Vehicle Pillar hat vor allem die Arbeit anderer Teams f\u00fcr Star Citizen Alpha 3.12 unterst\u00fctzt, vor allem bei den K\u00e4mpfen mit Gro\u00dfkampfschiffen vor den Events Arlington Bounty, CS5 UEE Navy Idris und XenoThreat. Wir haben nicht nur daran gearbeitet, wie die Fahrzeuge funktionieren und sich verhalten (sie sind die gr\u00f6\u00dften Schiffe, die bisher auf den Servern eingesetzt wurden), sondern haben auch dabei geholfen, mit der erh\u00f6hten T\u00f6dlichkeit von Torpedos umzugehen, indem wir intelligentere und effektivere KI-Gegenma\u00dfnahmen eingesetzt haben.\nDie Spieler profitierten auch von dieser Arbeit mit der M\u00f6glichkeit, die Art der Gegenma\u00dfnahme zu w\u00e4hlen und wie viele in einem Burst abgefeuert werden, was eine gr\u00f6\u00dfere taktische Auswahl bei der Ablenkung von ankommenden Raketen und Torpedos erm\u00f6glicht. Wir haben auch weitere HUD-Elemente hinzugef\u00fcgt, damit die Spieler sehen k\u00f6nnen, wie viele von jedem Typ sie \u00fcbrig haben, zusammen mit der aktuellen Burst-Gr\u00f6\u00dfe.\nDie letzte \u00c4nderung an den Gegenma\u00dfnahmen war eine Erweiterung der \u00c4nderungen aus Alpha 3.11. Dies f\u00fchrt dazu, dass jeder Gegenma\u00dfnahmentyp gegen alle Raketensuchertypen funktioniert, aber die Effektivit\u00e4t in Abh\u00e4ngigkeit von der Art und Anzahl der ankommenden Raketen ver\u00e4ndert. T\u00e4uschk\u00f6rper ersetzten Leuchtraketen als zeitlich begrenzte, punktuelle Ablenkung, w\u00e4hrend L\u00e4rm, ehemals D\u00fcppel, zu einem fl\u00e4chendeckenden Signalblocker wurde (mehr abgeschossene Gegenma\u00dfnahmen bieten eine h\u00f6here Chance auf Spoofing). Wir haben auch die Raketen selbst ver\u00e4ndert, um eine kleine Varianz in ihrer Verfolgung zu erm\u00f6glichen, damit eine erfolgreiche Gegenma\u00dfnahme nicht alle Raketen gleicherma\u00dfen ablenkt. Zus\u00e4tzlich zur manuellen Steuerung der Burst-Gr\u00f6\u00dfe f\u00fcgten wir eine Panikfunktion hinzu, die 25% der verf\u00fcgbaren Gegenma\u00dfnahmen leert, um eine Flut von ankommenden Raketen zu \u00fcberw\u00e4ltigen.\nWas nicht so gut geklappt hat\n\nWir entdeckten eine Menge Probleme mit dem Raketen-Setup und der Balance, die zu seltsamen Verhaltensweisen f\u00fchrten. Wir haben uns jedoch entschieden, dies zu belassen, bis die Raketen in der Alpha 3.13 auf IFCS 2.0 umgestellt werden, da dies eine umfassende \u00dcberarbeitung aller Verhaltensweisen der Raketen von Grund auf erfordert. In der Zukunft wollen wir die Gegenma\u00dfnahmen erweitern, indem wir den Spielern ein besseres Feedback zu ihren eigenen Signaturen und Raketenf\u00e4higkeiten geben, was mit dem Missile Operator Mode kommen wird.\nDie Fahrzeug-Eingangs-Identifikation war ein viel gefordertes Quality-of-Life-Feature (aufbauend auf den ASOP-Hangar-Spawn-Benachrichtigungen der Alpha 3.11), das es den Spielern erm\u00f6glicht, die Einstiegspunkte in ein Schiff schnell zu identifizieren. Diese Markierungen aktualisieren sich je nachdem, ob das Schiff gelandet ist oder sich in der Schwerelosigkeit befindet, was eine h\u00e4ufige Beschwerde neuer Spieler beseitigt, die nicht herausfinden konnten, wie sie in ihr Schiff gelangen. Gelegentlich sind diese Anzeigen wild vom Fahrzeug abgewichen, was wir untersuchen, aber das war so ziemlich das einzige negative Problem mit dem Feature und es wurde allgemein gut angenommen.\nDie Hauptinhalte der Alpha 3.12 waren die Esperia Talon und Talon Shrike, zwei leichte J\u00e4ger, die das Line-Up im Spiel erweitern. Im Allgemeinen liefen diese ziemlich gut und wir diskutierten ihre Entwicklung in mehreren ISC-Episoden, einschlie\u00dflich unserer Arbeit am Hard Surface Shader und irisierenden Materialien.\nLeider gab es bei der Ver\u00f6ffentlichung ein paar Probleme, die wir in zuk\u00fcnftigen Patches beheben wollen. Dazu geh\u00f6ren der Bildschirm, der im Arena Commander umgeschaltet werden muss (auch auf dem Prowler) und die Raketenwerfer der Talon Shrike, die manchmal nicht mehr funktionieren, nachdem eine gro\u00dfe Anzahl von Raketen abgefeuert wurde.\nJohn Crewe\nFahrzeug Direktor\n\nUSPU-Gameplay-Feature-Team\nDas vierte Quartal ist f\u00fcr das USPU Team immer ein arbeitsreiches. Nicht nur f\u00fcr uns, sondern f\u00fcr das gesamte Unternehmen. Hier ist eine kurze Zusammenfassung unserer wichtigeren Initiativen, die wir w\u00e4hrend des Quartals in die H\u00e4nde bekommen konnten. Zum Gl\u00fcck mussten wir dieses Jahr keine gro\u00dfe CitizenCon-Demo vorbereiten, aber das hat uns nicht davon abgehalten, extrem besch\u00e4ftigt zu sein.\nInternationale Luft- und Raumfahrt-Ausstellung (IAE)\nWas gut lief\n\n\nWir haben unseren IAE-Inhalt erfolgreich in den High-Tech-Art-Stil erweitert, der auf New Babbage auf dem Planeten microTech stattfand. Wir f\u00fcgten der Veranstaltung in diesem Jahr einige neue Dinge hinzu, die versuchten, auf die Kommentare der Fans einzugehen. Erstens lie\u00dfen wir die Ausstellungshalle jedes Herstellers an zwei aufeinanderfolgenden Tagen laufen, f\u00fcr den Fall, dass die Fans den ersten Tag verpasst hatten, und wir verl\u00e4ngerten die kostenlose Ausleihzeit von einem auf zwei Tage. Hoffentlich haben diese beiden Dinge jedem die M\u00f6glichkeit gegeben, die Schiffe zu mieten, die er unbedingt ausprobieren wollte. Wir hatten auch zwei Ausstellungshallen an einem Tag. Dies erm\u00f6glichte es den Spielern, mehr Dinge zu sehen, und im Sinne von \"mehr Dinge zu sehen\" haben wir beschlossen, viele unserer Schiffskomponenten und Waffen in der Haupthalle zu pr\u00e4sentieren. Mit zwei aktiven Hallen pro Tag und all den zus\u00e4tzlichen Gegenst\u00e4nden war dies ein wahrer Beweis daf\u00fcr, dass unsere Technik immer mehr optimiert wird, da wir in der Vergangenheit niemals in der Lage gewesen w\u00e4ren, dies zu tun. Um die Zug\u00e4nglichkeit zu erh\u00f6hen, haben wir in der \"Best In Show\"-Halle, die vier Tage lang lief, eine Reihe von Verleihkiosken aufgestellt. In diesen Kiosken haben wir jedes Fahrzeug, das im Laufe der Show gezeigt wurde, untergebracht und die gleiche zweit\u00e4gige Mietdauer gew\u00e4hrt. Wir denken, dass dies die ansprechendste Iteration war, die wir bis jetzt geschaffen haben.\nWas nicht so gut gelaufen ist\n\n\nWir hatten zwei Fahrzeuge, die auf der IAE-Show vorgestellt wurden und deren Entwicklung wirklich auf der Kippe stand. Letztendlich konnten wir den Build erst ein paar Tage vor der Show fertigstellen. Da die Messe im November f\u00fcr die \u00d6ffentlichkeit zug\u00e4nglich ist, musste der Build als Point-Patch zur Alpha 3.11 ver\u00f6ffentlicht werden. Die Tatsache, dass wir nicht in der Lage waren, den Build abzuschlie\u00dfen, bevor wir auf den Alpha 3.12 Build verzweigt haben, verursachte einige Kopfschmerzen bei der Dateiverwaltung. Kritische Korrekturen werden immer noch am Point-Release vorgenommen und die gleichen Korrekturen m\u00fcssen auch im neu verzweigten Stream-Content enthalten sein. Das f\u00fchrt unweigerlich dazu, dass die Arbeit hier und da eingestampft wird und frisst am Ende des Tages wertvolle Zeit, die f\u00fcr die Behebung anderer Fehler oder die Entwicklung neuer Dinge genutzt werden k\u00f6nnte. Au\u00dferdem sickerten einige Dinge durch, die wir eigentlich bis kurz vor dem Event geheim halten wollten. Das war kein gro\u00dfes Problem, aber es ist immer sch\u00f6n, wenn man die Fans von Zeit zu Zeit \u00fcberraschen kann.\nWas wir in Zukunft anders machen werden\n\n\nEin paar Dinge, auf die ich mich wirklich konzentrieren m\u00f6chte, wenn wir mit diesem Event weitermachen, sind: Modularit\u00e4t\/Wiederverwendung von Assets aus fr\u00fcheren Events. Je schneller wir diese Events umsetzen k\u00f6nnen, desto mehr Zeit haben wir, um uns auf neue Content-Ideen oder andere Sonnensysteme zu konzentrieren. Vorproduktionsplanung. Wir wissen, dass das Event im n\u00e4chsten November wieder stattfinden wird, also m\u00f6chte ich Dinge wie das Farbschema, Eventlogos, die Location, etc. so fr\u00fch wie m\u00f6glich ausb\u00fcgeln. Auf diese Weise muss niemand auf eine Entscheidung warten, wenn es Zeit ist, an den Inhalten zu arbeiten, und wir k\u00f6nnen einfach unsere K\u00f6pfe hinlegen und arbeiten. Bringe alle Inhalte f\u00fcr das Event in den Build, so dass wir eine Punktver\u00f6ffentlichung vermeiden k\u00f6nnen. Wie bereits erw\u00e4hnt, sind zwei parallel laufende Release-Streams\/Abzweigungen einfach nur eine Einladung zum \u00c4rger.\nReputationssystem\nWas gut gelaufen ist\n\n\nEin weiteres wichtiges System, das in Q4 hinzugef\u00fcgt wurde, war das Rufsystem, das wir schon immer haben wollten. W\u00e4hrend es f\u00fcr die Spieler noch nicht sichtbar ist, k\u00f6nnen sie es durch unsere Missionsgeber und einige unserer Missionsketten erleben (die Kopfgeldj\u00e4gerkette ist die bemerkenswerteste Serie, die derzeit durch Rufgewinne freigeschaltet wird). Noch sind nicht alle Missionen auf das neue System umgestellt, aber das wird ein fortlaufender Prozess in den n\u00e4chsten ein bis zwei Quartalen sein. Dieses neue Rufsystem wird die Grundlage f\u00fcr eine betr\u00e4chtliche Anzahl von Gameplay-Systemen sein, w\u00e4hrend wir vorankommen. Es wird nicht nur der Hauptweg sein, auf dem Inhalte f\u00fcr die Spieler freigegeben werden, sondern es wird auch mit Dingen wie den Reaktionen der NPCs (derzeit in den Missionsgebern zu sehen), den Verg\u00fcnstigungen und Vorteilen, die durch die Teilnahme an Inhalten verdient werden k\u00f6nnen, f\u00fcr die Verfolgung des Spielerfortschritts durch die Karrierewege, f\u00fcr das Diktieren der Beziehungen zwischen den Organisationen innerhalb des Spiels und einer Reihe von anderen essentiellen Gameplay-Schleifen verbunden sein. Wir hatten das Gef\u00fchl, dass dies so wichtig f\u00fcr das Spiel war, dass wir uns daf\u00fcr entschieden haben, es ohne eine dem Spieler zugewandte UI zu ver\u00f6ffentlichen (was f\u00fcr die Ver\u00f6ffentlichung in Q1\/Q2 in Arbeit ist). Aber da dies in einer betr\u00e4chtlichen Anzahl von Systemen in der Zukunft so tief verwurzelt sein wird, dachten wir, dass es das Opfer wert ist. Es wird nicht nur in einer eigenst\u00e4ndigen Reputations-UI dargestellt, die es den Spielern erlaubt, ihre Karrierestrecken bei verschiedenen Organisationen einzusehen, sondern auch die wichtigsten NSCs, mit denen sie interagiert haben, zusammen mit ihrem aktuellen Stand bei jedem von ihnen zu verfolgen. Die Reputationen werden in diesem UI sichtbar sein, sobald sie im Universum auf sie sto\u00dfen, so dass es die Spieler dazu ermutigt, herumzureisen und sich mit den Inhalten zu besch\u00e4ftigen, um sie freizulegen. Zus\u00e4tzlich werden wir den Missionsmanager \u00fcberarbeiten, um den Spielern die M\u00f6glichkeit zu geben, zu sehen, welche Art von Rufanforderungen sie ben\u00f6tigen, um Missionen zu erhalten. Der Ruf wird eine der gr\u00f6\u00dften Fortschrittsmechaniken in Star Citizen sein, abgesehen von der Wirtschaft, da wir ein f\u00e4higkeitsbasiertes Sandbox-Spiel sind, das nicht durch \"Leveling\"- oder \"Talentbaum\"-Systeme angetrieben wird. Die Reputation ist nun auch im Backend servicegesteuert. Das bedeutet, dass alle Rufgewinne zwischen den Patches erhalten bleiben, was eine gro\u00dfartige Sache f\u00fcr die Spieler sein wird.\nWas nicht so gut gelaufen ist\n\n\nWas die allgemeine Entwicklung dieses Features angeht, so lief es ziemlich reibungslos, sobald wir uns in die Arbeit gest\u00fcrzt hatten. Wir hatten etwa ein Jahr zuvor mit der Arbeit daran begonnen, aber leider wurden wir zu dieser Zeit von einigen Dingen mit h\u00f6herer Priorit\u00e4t abgehalten. Wenn ich noch einmal die Wahl h\u00e4tte, w\u00fcrde ich das Team so lange daran arbeiten lassen, bis es fertig ist und die gew\u00fcnschten UI\/UX-\u00c4nderungen vorgenommen wurden. Das UI nicht mit dem Release fertig zu haben, ist zwar nicht spielentscheidend, aber ein kritischer Teil dieses Features. Um sicherzustellen, dass alle unsere Features intuitiv sind, sind wir oft auf diese Art von visuellem Feedback angewiesen.\nWas wir in Zukunft anders machen werden\n\n\nIn Zukunft w\u00fcrde ich gerne versuchen, die n\u00f6tige Zeit einzuplanen, um ein \"kompletteres\" Feature zu ver\u00f6ffentlichen. Es ist zwar nicht immer m\u00f6glich, alle bestehenden Inhalte eines Spiels auf neue Systeme wie dieses umzustellen, aber ich w\u00fcrde gerne versuchen, sicherzustellen, dass wir mehr tun k\u00f6nnen, wenn gro\u00dfe \u00c4nderungen wie diese in der Zukunft passieren. Ich war froh, dass wir mehr als die urspr\u00fcngliche Absicht umgesetzt haben, aber ich h\u00e4tte gerne mehr Zeit mit dem Missionsteam gehabt, um noch mehr zu konvertieren, als wir es getan haben. Das n\u00e4chste Mal, wenn so etwas Grundlegendes ansteht, w\u00fcrde ich pers\u00f6nlich gerne einen besseren Job machen, um das globale Bewusstsein im Unternehmen zu erh\u00f6hen, damit wir so viel wie m\u00f6glich umwandeln k\u00f6nnen.\nFront End Konvertierung zu Building Blocks\nWas gut lief\n\n\nWir waren in der Lage, die ersten zwei Screens im Frontend auf unsere Building Blocks Technologie umzustellen. Im Allgemeinen denke ich, dass dieser Prozess ziemlich gut gelaufen ist. Es brauchte nicht viele Leute und war eine ziemlich eigenst\u00e4ndige Arbeit. Wir hatten auch die M\u00f6glichkeit, ein paar Dinge zu beheben, die wir seit der Einf\u00fchrung des \"Neue Freunde\"-Services in Q1 2020 angehen wollten. Die Umstellung auf unser neues UI-System erlaubte es uns auch, alle UI-Elemente zusammen auszublenden. Dieser Prozess gab uns die Zeit, das Frontend kritisch zu durchdenken, da sich das Projekt in den letzten Jahren so sehr entwickelt hat. Wir haben es auch so eingerichtet, dass die aktuelle L\u00f6sung skaliert werden kann, wenn wir weitere Solarsysteme hinzuf\u00fcgen. Wir haben den Hauptbildschirm aufger\u00e4umt, damit wir einen gr\u00f6\u00dferen Blick auf die Hintergrundbilder haben. Ich bin froh, dass wir in der Lage waren, jeder m\u00f6glichen Landezone ein anderes Bild zuzuordnen; ich denke, es hilft neuen Spielern wirklich, ein Gef\u00fchl daf\u00fcr zu bekommen, welche Art von Ort sie w\u00e4hlen.\nWas nicht so gut gelaufen ist\n\n\nDas Frontend ist sehr stark mit dem urspr\u00fcnglichen CryEngine-Toolset verwurzelt, mit dem wir urspr\u00fcnglich angefangen haben. Das Building Blocks System arbeitet auf Basis von Entit\u00e4ten, was bedeutet, dass unsere Kerndaten geladen werden m\u00fcssen, damit wir eine Entit\u00e4t haben, auf der wir den Canvas ausf\u00fchren k\u00f6nnen. Au\u00dferdem erfordert das urspr\u00fcngliche System, dass ein Level geladen wird. Aus diesem Grund waren wir nicht in der Lage, irgendwelche Elemente zu ersetzen, bevor wir ausgew\u00e4hlt haben, welchen Spielmodus die Spieler spielen wollen (zumindest nicht mit der auf Building-Blocks basierenden Tech\/Implementierung). Die ultimative L\u00f6sung w\u00e4re eine komplette \u00dcberarbeitung dieser Codebasis, aber das lag weit au\u00dferhalb des Rahmens dessen, was wir bew\u00e4ltigen konnten, und war auch nicht unsere Hauptdirektive hier.\nWas wir in Zukunft anders machen werden\n\n\nDie Quintessenz hier ist, dass das Spiel, auf dem unser urspr\u00fcngliches Frontend basierte, sich sehr von dem Spiel unterscheidet, auf das wir heute hinbauen. Ich bin mir nicht sicher, wie sehr das USPU Team das Frontend in der Zukunft ver\u00e4ndern wird, aber wenn wir hier das n\u00e4chste Mal \u00c4nderungen vornehmen, w\u00fcrde ich wirklich gerne auf die endg\u00fcltige Vision hinarbeiten. Das w\u00fcrde uns erlauben, das neue Benutzererlebnis wirklich zu optimieren, so dass der Einstieg ins Spiel zum ersten Mal oder der Wiedereinstieg f\u00fcr zur\u00fcckkehrende Spieler so einfach und intuitiv wie m\u00f6glich ist. Da wir die neuen Features nach und nach eingebaut haben, hat dieser Teil des Spiels darunter gelitten. Wenn dies von Grund auf neu definiert werden kann, gibt es eine Menge, was wir anders machen w\u00fcrden, basierend darauf, wie sehr sich das Spiel entwickelt hat.\nRob Reininger\nLead System Designer und USPU Product Owner\n\nSystemische Dienste & Tools Team\nWas gut gelaufen ist\n\n\nDas Systemic Services and Tools (SST) Team hat weiter an der Quantum Simulation gearbeitet und sie in die Services integriert, neben internen Pr\u00e4sentationen neuer Technologien, die wir bald mit der Community teilen werden.\nAdministrative Arbeit fand im letzten Quartal statt, um die internen CIG Ressourcen f\u00fcr SST umzuschichten. Das Team wird vergr\u00f6\u00dfert, um dem wachsenden Bedarf an Dienstleistungen und Support f\u00fcr Quantum in vielen Aspekten des Spiels gerecht zu werden.\nAu\u00dferhalb der Dienstleistungen und der Simulationsarbeit hat SST neue Tools entwickelt, um das kommende Reputationssystem zu unterst\u00fctzen und die Art und Weise, wie Reputation im Spieluniversum verteilt wird. SST unterst\u00fctzt weiterhin die Star Citizen Wirtschaft mit Data Tools, um die massive Datenmenge zu lindern, w\u00e4hrend wir uns darauf vorbereiten, dass Quantum die Z\u00fcgel in die Hand nimmt.\nWas nicht so gut gelaufen ist\n\n\nW\u00e4hrend wir zu einer gr\u00f6\u00dferen Abteilung werden, hatten wir einige Wachstumsschmerzen mit unseren Reaktionszeiten auf andere Teams. Features wie der Raffinerie-Service bekamen nicht die sofortige Aufmerksamkeit, die sie brauchten, w\u00e4hrend unsere Aufmerksamkeit woanders lag.\nWas wir in Zukunft anders machen werden\n\n\nWir suchen nach M\u00f6glichkeiten, die Arbeit, die bei SST ankommt, f\u00fcr das wachsende Team besser zu rationalisieren und zu verteilen. Au\u00dferdem haben wir automatisierte Nachrichten eingerichtet, um die Kommunikation zwischen SST und den abh\u00e4ngigen Teams zu erg\u00e4nzen.\nJake M\u00fchle\nSenior Technischer Designer\n\nDesign Team\nKI f\u00e4ngt Torpedos ab\nWas gut lief\n\n\nDie Gesch\u00fctzt\u00fcrme der Idris, die Torpedos abfangen, funktionieren gut und es gibt einige sehr coole Momente, wenn sie erfolgreich abfangen.\nWas nicht so gut gelaufen ist\n\n\nDie KI-Genauigkeit ist nicht gut genug, um ankommende Torpedos zuverl\u00e4ssig abzuschie\u00dfen, abh\u00e4ngig von der Framerate des Servers.\nWas wir in Zukunft anders machen werden\n\n\nWir werden uns bem\u00fchen, die KI-Genauigkeit zu verbessern, damit wir mehr Kontrolle dar\u00fcber haben, wie viele Torpedos durch die Turmverteidigung schl\u00fcpfen.\nKI-Feuermodus-Nutzung und Zielpriorit\u00e4ten\nWas gut gelaufen ist\n\n\nDie KI, die Burst-Feuer verwendet, verbessert das Aussehen des KI-Turmfeuers erheblich. Au\u00dferdem stellen die Zielpriorit\u00e4ten sicher, dass die KI ein vern\u00fcnftiges Ziel f\u00fcr ihre Schiffsklasse und Gesch\u00fctzgr\u00f6\u00dfe angreift.\nWas nicht so gut gelaufen ist\n\n\nIm Moment benachteiligt die Verwendung von Burst-Fire die KI im Vergleich zu den Spielern, da vollautomatisches Feuern den Schaden erh\u00f6ht.\nWas wir in Zukunft anders machen werden\n\n\nWir werden die KI-Serienfeuer neu ausbalancieren, wenn Kondensatoren eingef\u00fchrt werden, um die Effektivit\u00e4t des Gedr\u00fcckthaltens der Feuertaste zu reduzieren.\nKI-Genauigkeitskonvergenz\nWas gut gelaufen ist\n\n\nDas neue Genauigkeitssystem verh\u00e4lt sich glaubw\u00fcrdiger, da es die Position des Ziels verfolgt und weiter auf diese Position feuert, bis sich das Ziel bewegt. Das ist besser als das alte System, bei dem das Ziel der KI wild hin und her schwankte, w\u00e4hrend sie versuchte, station\u00e4re Ziele vor ihr zu verfehlen.\nWas nicht so gut geklappt hat\n\n\nDie KI ist noch nicht genau genug, um den Spieler ernsthaft zu bedrohen. Au\u00dferdem neigt das neue System dazu, hinter die Bewegung des Ziels zu schie\u00dfen, anstatt davor, sodass die Spieler nicht so oft sehen, dass sie beschossen werden.\nWas wir in Zukunft anders machen werden\n\n\nWir wollen die Genauigkeit insgesamt verbessern und es so gestalten, dass verschiedene NSCs einen deutlicheren Unterschied in der Genauigkeit zwischen ge\u00fcbter und unge\u00fcbter KI haben. Das Genauigkeitssystem wird auch dahingehend \u00fcberarbeitet, dass es das Ziel \u00f6fter \u00fcber- als unterschie\u00dft.\nKampfverhalten von Gro\u00dfkampfschiffen\nWas gut gelaufen ist\n\n\nDie Gro\u00dfkampfschiffe ber\u00fccksichtigen nun die Entfernung und die relative Position, wenn sie andere Schiffe angreifen. Gro\u00dfkampfschiffe ohne Frontalgesch\u00fctze werden versuchen, nahe genug heranzukommen, um alle ihre Gesch\u00fctzt\u00fcrme zu nutzen, w\u00e4hrend Schiffe mit gro\u00dfen Frontalgesch\u00fctzen versuchen werden, sich aus der Reichweite des Feindes herauszuhalten und ihre m\u00e4chtigen Fernwaffen zu nutzen.\nWas nicht so gut gelaufen ist\n\n\nDie Taktikauswahl ber\u00fccksichtigt die St\u00e4rke des KI-Schiffs relativ zum Ziel nicht ausreichend. Wenn die Idris zum Beispiel gegen ein Kanonenschiff oder ein Gro\u00dfkampfschiff k\u00e4mpft, wird sie versuchen, auf Distanz zu bleiben und ihre Railgun zu benutzen. Das macht oft Sinn, kann aber dazu f\u00fchren, dass sie vor kleineren Kanonenschiffen wegl\u00e4uft, die sie in einem Nahkampf leicht einnehmen k\u00f6nnte.\nWas wir in Zukunft anders machen werden\n\n\nWir werden die Taktikauswahl \u00fcberarbeiten, damit die KI das eigene Schiff und das Ziel detaillierter betrachtet als nur die Schiffsklasse. Au\u00dferdem werden wir den Charaktereigenschaften der Piloten erlauben, das Verhalten des Hauptschiffs zu beeinflussen.\nAufzugspaneele\nWas gut gelaufen ist\n\n\nWir haben erfolgreich den Grundstein f\u00fcr zuk\u00fcnftige Aufzugspaneele (und andere umgestaltbare Bildschirme) gelegt, indem wir sie dazu gebracht haben, ihre Stile vom Transitsystem zu erben und auf jedem geformten Canvas verwendbar zu sein. Das bedeutet, dass alle zuk\u00fcnftigen Panels die gleichen zwei Dateien verwenden k\u00f6nnen und trotzdem unterschiedlich aussehen.\nWas nicht so gut gelaufen ist\n\n\nDas Transitsystem ist in seiner jetzigen Form sehr schwierig einzurichten und zu testen - das UI Team war nicht in der Lage, es richtig zum Laufen zu bringen und musste sich bei der Implementierung auf das Level Design verlassen. Allerdings haben UI und Level Design nicht gleichzeitig an dem Feature gearbeitet, was dazu f\u00fchrte, dass die Arbeit in unterschiedlichen Str\u00f6men begann und endete und Bugs \u00fcbersehen wurden. Neue Building Blocks Styles sind extrem zeitaufwendig zu implementieren, da es an Werkzeugen mangelt und die Dateien nicht zusammengef\u00fchrt werden k\u00f6nnen.\nWas wir in Zukunft anders machen werden\n\n\nWir werden sicherstellen, dass das Feature in einem Rutsch in einem Feature Stream entwickelt, implementiert und getestet wird, so dass Bugs aufgegriffen und behoben werden, bevor es \"fertig\" ist. Wir werden auch sicherstellen, dass das Team, das f\u00fcr das Feature verantwortlich ist, Zeit hat, um Code-Probleme als Teil des Feature-Entwicklungszyklus zu beheben und dass das UI-Team sich auf die Benutzeroberfl\u00e4che konzentriert.\nStationsbasiertes Refining\nWas gut gelaufen ist\n\n\nWir haben den ersten Gameplay-Loop f\u00fcr das Raffinieren fertiggestellt, komplett mit Raffinerien, die ihre eigenen Materialspezialisierungen und Arbeitslasten haben, und der M\u00f6glichkeit, raffinierte Materialien an verschiedenen Orten in der Galaxie zu sammeln und zu verkaufen. Die Raffinerie-Decks selbst sehen spektakul\u00e4r aus und die Benutzeroberfl\u00e4che des Raffinerie-Terminals ist an einem gro\u00dfartigen Ort, um den Gameplay-Loop mit sehr wenig Nacharbeit zu erweitern, was eine schnellere Iteration in der Folge bedeuten sollte.\nWas nicht so gut gelaufen ist\n\n\nUnsere Planung f\u00fcr jeden Schritt war extrem gr\u00fcndlich, jedoch konnten wir aufgrund mehrerer Situationen, die au\u00dferhalb unserer Kontrolle lagen, nicht fr\u00fch genug einen Punkt erreichen, an dem wir den Raffinerie-Loop so ausbalancieren konnten, wie wir es vorhatten. Daher haben wir ein weiteres, bereits geplantes Set von \u00c4nderungen in Form des ersten Bergbau-Rebalances vorgezogen, um so gut wie m\u00f6glich zu kompensieren, bis wir die Raffinerie-Balance auf das Niveau bringen k\u00f6nnen, das wir urspr\u00fcnglich wollten. Dieses Bergbau-Rebalance hatte den zus\u00e4tzlichen Bonus, dass es den MISC-Prospector ein wenig attraktiver f\u00fcr Leute machte, die mit ihm anfangen oder ihn mieten wollten, und dass es mehr Spielerfahrung f\u00fcr die Argo MOLE oder mehrere Spieler mit Prospectors bot.\nWas wir in Zukunft anders machen werden\n\n\nDie UI-Kunst fr\u00fcher spielerisch testen lassen. Einige Spieler wussten nicht, mit welchen Teilen des Bildschirms sie interagieren k\u00f6nnen und das h\u00e4tte uns mehr Zeit gegeben, um \u00c4nderungen vorzunehmen.\nBergbau UI Refactor\nWas gut lief\n\n\nWir haben die gesamte Bergbau-UI \u00fcberarbeitet, um mit Building Blocks zu arbeiten. Das ging viel reibungsloser, als wir es uns je erhofft hatten, da ein gro\u00dfer Teil des Mining-Gameplay-Loops direkt mit Building Blocks funktionierte, ohne dass wir viel nacharbeiten mussten. Das gab uns den Spielraum, mehr zur Mining UI hinzuzuf\u00fcgen, als wir urspr\u00fcnglich vorhatten. Das bedeutet, dass wir nicht nur eine komplett neue UI bereitstellen konnten, die \u00fcber drei verschiedene Mining-Fahrzeuge hinweg skalierbar ist, sondern wir haben diese Skalierbarkeit gezeigt, indem wir schnell UI-Canvas-Teile iteriert haben, um zuvor eingef\u00fchrte Systeme zu unterst\u00fctzen. Dazu geh\u00f6rte auch die fl\u00fcchtige Ladung und ein komplett neues Laderaumteil, das den Spielern weitere Informationen bietet, die wir schon immer bereitstellen wollten, aber nie die M\u00f6glichkeit hatten, dies zu tun.\nWas nicht so gut gelaufen ist\n\n\nDer erste Durchgang des UI-Refactors f\u00fcr den Bergbau war schwieriger zu implementieren als zu bauen, da verschiedene Fahrzeuge unterschiedliche Fl\u00e4chen f\u00fcr das UI zur Verf\u00fcgung hatten, was bedeutete, dass eine Menge Tweaking hinter den Kulissen n\u00f6tig war, um das UI tats\u00e4chlich auf eine komfortable Weise darzustellen. Wir arbeiten immer noch an der Feinabstimmung und hoffen, dass wir die Benutzeroberfl\u00e4che in Zukunft auf eine visuell ansprechendere Art und Weise darstellen k\u00f6nnen, die besser funktioniert als die aktuelle Implementierung.\nWas wir in Zukunft anders machen werden\n\n\nWir werden in Zukunft schneller iterieren, da wir jetzt ein besseres Verst\u00e4ndnis von Building Blocks und seinen Vorteilen haben.\nTodd Papy\nStar Citizen Live Direktor\n\nKern Gameplay S\u00e4ule\nMulti-Tool Traktorstrahl\nDer Multi-Tool Tractor Beam ist eine aufregende Erg\u00e4nzung zum 'Verse' und ist ein Kernst\u00fcck der Funktionalit\u00e4t, die mehrere Gameplay-Loops freischaltet, an denen wir arbeiten, wie z.B. Frachttransport und EVA-Traversalr\u00e4ume. Der Hauptanwendungsfall f\u00fcr den Tractor Beam in Alpha 3.12 ist das einfachere Einsammeln von Frachtkisten in EVAs, entweder w\u00e4hrend verlorener Weltraummissionen oder f\u00fcr das Einsammeln von Beute nach einem Schiffskampf. Oberfl\u00e4chlich betrachtet ist der Tractor Beam ein einfaches Werkzeug, aber unter der Haube passiert eine Menge und ich denke, das Team hat einen fantastischen Job gemacht, um ein wirklich systemisches Feature zu erschaffen, das zug\u00e4nglich und einfach zu benutzen ist.\nDie erste Herausforderung, mit der wir konfrontiert waren, war, dass wir wollten, dass es in verschiedenen Schwerkraft-Einstellungen funktioniert und das Gewicht eines Objekts ausnutzt. Dies f\u00fchrte zu mehreren Problemen, da in der Schwerelosigkeit alles schwerelos ist, was bedeutet, dass man potentiell etwas Riesiges bewegen kann, das sehr wenig wiegt. Zum Beispiel eine planetengro\u00dfe Styroporkugel. Wir haben den Tractor Beam um zwei Kernkonzepte herum entworfen - Volumen und Kraft. Das Volumen diktiert die generelle Gr\u00f6\u00dfe des Objekts, das du anheben kannst, w\u00e4hrend die Kraft die Menge an Anstrengung diktiert, die die Waffe aufbringen muss, um das Objekt anzuheben. Das bedeutet, dass f\u00fcr jeden Gegenstand, der eine Masse und einen Physikkollider hat (was jeder Gegenstand bereits haben sollte), die Kraft, die ben\u00f6tigt wird, um ihn anzuheben, automatisch anhand der Schwerkraft der Umgebung berechnet wird. Dies erlaubte uns, ein Feature zu bauen, das mit jedem Physik-Objekt im Spiel funktioniert, ohne dass wir eine Menge manueller Einstellungen vornehmen m\u00fcssen.\nDie zweite Herausforderung war, wie erkl\u00e4ren wir dem Spieler, was er heben kann und was nicht, ohne alles mit ADS zu belegen oder, noch schlimmer, Versuch und Irrtum anzuwenden. Gl\u00fccklicherweise hat das Multi-Tool bereits einen kleinen Bildschirm auf der R\u00fcckseite, der es uns erm\u00f6glichte, eine einfache Ikonographie zusammen mit einem Ampel-Farbcodierungssystem zu implementieren. Das bedeutet, dass wir in der Lage sind, alle f\u00fcnf Zust\u00e4nde eines Objekts deutlich zu zeigen, indem wir es einfach anschauen:\nObjekt kann angehoben werden Objekt kann angehoben werden, ist aber au\u00dfer Reichweite Objekt ist zu schwer Objekt kann niemals angehoben werden Du wirst zu dem Objekt reisen\nObwohl wir zus\u00e4tzliche Informationen in der ADS-Ansicht zur Verf\u00fcgung gestellt haben, befindet sich alles, was du wissen musst, auf der R\u00fcckseite des Werkzeugs und ich war wirklich froh, dass wir so viele Informationen in einen so kleinen Bildschirm destillieren konnten.\n\n\nWas nicht so gut gelaufen ist\n\n\nWenn du ein Feature planst, solltest du das Haupterlebnis identifizieren und dann alle sekund\u00e4ren Mechaniken skizzieren, die dieses Erlebnis verbessern w\u00fcrden. Zum Beispiel ist eine Sprungmechanik f\u00fcr sich genommen ein eigenst\u00e4ndiges Feature, aber du k\u00f6nntest entscheiden, dass die Kontrolle in der Luft (eine sekund\u00e4re Mechanik) das Kernerlebnis verbessert. Mit dem Traktorstrahl haben wir uns hingesetzt und das Haupterlebnis identifiziert, n\u00e4mlich die M\u00f6glichkeit, Objekte zu manipulieren und ihn als Greifhaken in EVA zu benutzen, und ich glaube, das haben wir geschafft. Aber es gab einige sekund\u00e4re Mechaniken, die ich gerne eingebaut h\u00e4tte, f\u00fcr die uns aber die Zeit fehlte. Insbesondere die M\u00f6glichkeit, die Flugbahn mit den Triebwerken des Anzugs zu manipulieren, wenn man den Greifhaken in der Schwerelosigkeit benutzt.\nLeider funktionierten die beiden Systeme nicht wirklich gut zusammen, da die Kraft, die zum Ziehen verwendet wurde, die Kraft der Anzugtriebwerke \u00fcberlagerte. Es war auch nicht hilfreich, dass EVA zur gleichen Zeit auf IFCS umgestellt wurde, was dazu f\u00fchrte, dass wir uns auf die Kernfunktion konzentrieren mussten, um sicherzustellen, dass diese bis zur Ver\u00f6ffentlichung so gut wie m\u00f6glich ausgefeilt war. Das passiert bei Features immer wieder und liegt in der Natur der Spieleentwicklung, aber es war eine Schande, dass es in der ersten Iteration fehlte. Wir werden diese Funktionalit\u00e4t in einer sp\u00e4teren Version hinzuf\u00fcgen.\nWas wir in Zukunft anders machen werden\n\n\nUm ein Feature zur Ver\u00f6ffentlichung zu bringen, m\u00fcssen viele verschiedene Teams zusammenarbeiten, von VFX \u00fcber Audio bis hin zum Feature-Team, das an der Funktionalit\u00e4t arbeitet. Eines der gr\u00f6\u00dften Dinge, die ich versuche zu verbessern, ist, den Missionsdesignern mehr Zeit zu geben, damit sie all diese verschiedenen Features sinnvoll in das Verse integrieren k\u00f6nnen. Wenn du meine vorherigen Postmortems gelesen hast, wirst du wahrscheinlich einen Trend erkennen, dass dies etwas ist, was ich aktiv versuche zu verbessern, aber da mehrere Teams und Zeitpl\u00e4ne involviert sind, braucht es ein wenig Zeit, um sich umzustellen. Wenn ich in der Zeit zur\u00fcckgehen k\u00f6nnte, h\u00e4tte ich wahrscheinlich versucht, eine einfache Version fr\u00fcher in die H\u00e4nde der Missions-\/Leveldesigner zu bekommen, damit sie ein bisschen mehr damit spielen konnten.\nWaffennullstellung\nWas gut lief\n\n\nDas Weapon Zeroing, wie der Titel schon sagt, erlaubt es dir, deine Waffen auf verschiedene Entfernungen zu nullen, was dir erlaubt, auf viel weitere Entfernungen genau zu schie\u00dfen. Das bedeutet, dass das Zielfernrohr den Abfall des Geschosses in einer bestimmten Entfernung ber\u00fccksichtigt und dir erlaubt, die Visierung so einzustellen, dass du dein Fadenkreuz immer noch auf das Ziel richten kannst. D.h. du musst nicht \u00fcber das Ziel hinaus zielen. Wir haben bereits viele Zielfernrohre zur Verf\u00fcgung und die erste Herausforderung war zu entscheiden, welche Zielfernrohre \u00fcberhaupt nullen sollten und dann zu entscheiden, ob sie automatisch oder manuell nullen sollten. Dies f\u00fchrte zu einer viel breiteren Diskussion \u00fcber Hersteller und ihre spezifischen Eigenschaften, wie High-Tech oder Low-Tech. W\u00e4hrend das Team sich nur auf das Feature h\u00e4tte konzentrieren und es herausbringen k\u00f6nnen, haben sie auch einen langfristigen Plan f\u00fcr die Zielfernrohrbefestigungen geliefert, nicht nur f\u00fcr aktuelle Hersteller, sondern auch f\u00fcr zuk\u00fcnftige.\nDas ist etwas, woran ich grunds\u00e4tzlich glaube - dass wir, auch wenn wir an einem Live-Produkt arbeiten, Entscheidungen rund um die finale Erfahrung im ver\u00f6ffentlichten Spiel treffen sollten. Manchmal ist das schwer, da es bedeuten kann, dass bestimmte Features auf den ersten Blick nicht in ihrem besten Licht gesehen werden oder kurzfristig von den Spielern missverstanden werden. Aber es ist mein Job, sicherzustellen, dass wir auf die finale Vision hinarbeiten und das Team hat einen fantastischen Job gemacht, ein Feature bereitzustellen, das Spa\u00df macht, aber in der Zukunft skalierbar ist.\nWas nicht so gut gelaufen ist\n\n\nDies war das erste Feature, an dem eines unserer neuesten Teammitglieder gearbeitet hat. Daher stellten wir sicher, dass er genug Zeit hatte, um es weit vor dem eigentlichen Release zu liefern. Tats\u00e4chlich wurde die Funktionalit\u00e4t (nicht die Optik) im Quartal davor geliefert und er hat einen tollen Job gemacht. In den meisten F\u00e4llen ist das fantastisch, da es bedeutet, dass wir uns auf das Erlebnis konzentrieren und sicherstellen k\u00f6nnen, dass es von h\u00f6chster Qualit\u00e4t ist. In diesem Fall jedoch konnte sich das Testteam aufgrund anderer Priorit\u00e4ten und der Tatsache, dass dies so weit vor der Ver\u00f6ffentlichung geschah, nicht voll und ganz darauf konzentrieren, da es (berechtigterweise) damit besch\u00e4ftigt war, Dinge zu \u00fcberpr\u00fcfen, die kurz vor der Ver\u00f6ffentlichung standen. Ungl\u00fccklicherweise bedeutete dies, dass ein grundlegender Edge Case bis kurz vor der Ver\u00f6ffentlichung \u00fcbersehen wurde, n\u00e4mlich dass das Zeroing nicht funktionierte, als die Physik-Patches f\u00fcr die Umgebung herauskamen.\nLass mich das erkl\u00e4ren. Wenn ein Charakter auf einem Planeten spawnt, spawnen eine Reihe von Patches (Quadrate) um ihn herum in immer gr\u00f6\u00dfer werdenden Gr\u00f6\u00dfen. Diese Patches decken die Renderqualit\u00e4t (Grafik) und die Physikkollision ab, wobei weiter entfernte Patches weniger Details und schlie\u00dflich keine Kollision mehr haben (da die Physik relativ teuer ist). Wenn du dich nun bewegst, werden die Patches dynamisch aktualisiert, aber nicht eins zu eins. So kann ein Patch, in dem du dich gerade befunden hast, immer noch seine Kollision haben, da du vielleicht dorthin zur\u00fcckkehren m\u00f6chtest und es performanter ist, ihn kurzfristig dort zu behalten, als ihn st\u00e4ndig zu laden und zu entladen. In diesem Fall bedeutete es jedoch, dass wenn ein Designer in den Editor geladen wurde, um das Feature zu testen, der Patch geladen war und er sich dann 2 km weg bewegte, um die Waffen-Nullstellung zu testen und es funktionierte. W\u00e4re ein Spieler jedoch nie an die urspr\u00fcngliche Position gegangen, g\u00e4be es keine Kollision und somit h\u00e4tte das Zielfernrohr nichts, gegen das es testen k\u00f6nnte. Das bedeutete, dass es unter normalen Spielbedingungen nicht wie beabsichtigt funktionierte, also mussten wir den Code f\u00fcr die Waffennullstellung neu schreiben, um gegen die Rendergeometrie zu testen, anstatt gegen die Physikgeometrie. Obwohl diese \u00c4nderung nicht gro\u00df war, war sie nicht ideal, da wir geplant hatten, an anderen Features zu arbeiten.\nWas wir in Zukunft anders machen werden\n\n\nWenn ich in der Zeit zur\u00fcckgehen k\u00f6nnte, w\u00fcrde ich auf jeden Fall sicherstellen, dass das Feature gr\u00fcndlich getestet wurde, als es fertiggestellt wurde, anstatt auf das eher traditionelle Go\/No Go zu warten. Obwohl es keinen Einfluss auf die Ver\u00f6ffentlichung des Features hatte Das hatte Auswirkungen auf die zuk\u00fcnftige Arbeit, da wir im Laufe des Quartals die Priorit\u00e4ten neu setzen mussten.\nGemini A03 Scharfsch\u00fctzengewehr & Behring FS-9 LMG\nWas gut lief\n\n\nWie bei jeder Waffe, die wir dem Spiel hinzuf\u00fcgen, m\u00fcssen wir immer sicherstellen, dass sie in die bestehende Waffenmatrix passt und etwas Einzigartiges bietet, das es nicht schon gibt. Mit dem Gemini A03 Scharfsch\u00fctzengewehr war die Absicht, ein leichtes, reaktionsschnelles Scharfsch\u00fctzengewehr mit einem geringeren Kaliber als seine schwereren Gegenst\u00fccke, aber hoher Geschwindigkeit und Genauigkeit zu bauen. Ich denke, dass das Team diese Absicht wirklich umgesetzt hat und eine gute Balance zwischen den hochkalibrigen Scharfsch\u00fctzengewehren wie dem P6-LR und den eher angriffsorientierten Waffen wie dem Gemini S71 gefunden hat. W\u00e4hrend das A03 eine einfache Erg\u00e4nzung war, war das Behring FS-9 ein wenig kniffliger. LMGs als Waffenkategorie stehen momentan nicht gut da, da sie auf kurze Distanz von SMGs\/Schrotflinten und auf mittlere bis lange Distanz von Sturmgewehren \u00fcbertroffen werden. Wir sind uns dessen bewusst und haben hinter den Kulissen daran gearbeitet, dies zu verbessern. Der Behring FS-9 setzt den Standard f\u00fcr das, was wir uns von LMGs w\u00fcnschen - Maschinengewehre mit hoher Kapazit\u00e4t, die es den Spielern erlauben, ein Gebiet ohne gro\u00dfen Verlust an Genauigkeit zu unterdr\u00fccken.\nWas nicht so gut gelaufen ist\n\n\nW\u00e4hrend wir an der FS-9 gearbeitet haben, haben wir auch die Designabsichten f\u00fcr alle anderen LMGs ausgearbeitet, damit wir ein Update f\u00fcr alle in einem Release liefern konnten. Leider ist uns bei den bestehenden Waffen die Zeit ausgegangen, obwohl wir es geschafft haben, einige Tweaks zu machen, um ihre Effektivit\u00e4t zu erh\u00f6hen. Wir planen, die bestehenden LMGs zu aktualisieren, um sie auf die gleiche Qualit\u00e4tsstufe wie die FS-9 zu heben, aber das bedeutet kurzfristig, dass sie den anderen Waffen der gleichen Kategorie weit \u00fcberlegen ist. Aber wie ich bereits erw\u00e4hnt habe, werde ich Entscheidungen immer danach ausrichten, was das Endziel sein soll, damit wir uns st\u00e4ndig weiterentwickeln.\nWas wir in Zukunft anders machen werden\n\n\nWir haben den Plan, alle Waffenkategorien zu \u00fcberarbeiten und ihr k\u00f6nnt hoffentlich sehen, dass jede Waffe, die wir ver\u00f6ffentlichen, die vorherigen leicht verbessert. Mit dieser Absicht h\u00e4tte ich mehr Zeit f\u00fcr den Feinschliff der bestehenden LMGs eingeplant, denn ich h\u00e4tte sie gerne alle zusammen ver\u00f6ffentlicht. Egal wie erfahren man ist, man lernt immer dazu und das ist etwas, das ich f\u00fcr zuk\u00fcnftige Waffen implementieren werde.\nRichard Tyrer\nCore Gameplay Direktor\n\nStandorte\nRaumstation Raffinerie Decks\nWas gut lief\n\n\nF\u00fcr diese Ver\u00f6ffentlichung konnten wir Raffinerie-Decks an einigen speziellen Orten der Raumstation einf\u00fchren. Diese R\u00e4ume sind thematisch an die Bergbau- und Raffinerie-Spielschleifen angelehnt und dienen auch als Standort f\u00fcr zuk\u00fcnftige Spielm\u00f6glichkeiten. Innerhalb des Raffineriedecks haben wir einen Raum speziell f\u00fcr die Raffination und Verarbeitung geschaffen, zusammen mit einem Shop und einem Gildenraum darunter.\nNachdem wir die Reaktionen auf die Frachtdecks und die neuen Innenr\u00e4ume der Raumstation in Alpha 3.11 gesehen hatten, stimmten wir mit den Kommentaren \u00fcberein, dass die Spieler mehr sichtbare Verbindungen mit dem Au\u00dfenbereich sehen wollten, um physisch zu verstehen, wo sie sich in der Station befinden. Obwohl wir mit der Entwicklung des Innenraums des Raffineriedecks schon ziemlich weit waren, schwenkten wir um und passten den Raum an, um das Mini-Aussichtsdeck bei den Aufzug-Lobbys einzubeziehen. Visuell wollten wir schon seit einiger Zeit ein Raumstationserlebnis erkunden, das sich mehr auf industrielle Aktivit\u00e4ten konzentriert.\nWas nicht so gut gelaufen ist\n\n\nEs war schade, dass keine spezifischen NPC-Loadsouts mit den Raffinerie-Decks ver\u00f6ffentlicht wurden oder dass einige der spezifischen Nutzgegenst\u00e4nde nicht erweitert werden konnten. Diese sind jedoch alle geplant, also werden wir sie hoffentlich bald online sehen.\nWas wir in Zukunft anders machen werden\n\n\nWie bereits erw\u00e4hnt, haben wir das Aussichtsdeck erst recht sp\u00e4t im Prozess eingef\u00fchrt, so dass wir w\u00e4hrend des Konzepts und des Whiteboxings einen besseren Platz daf\u00fcr h\u00e4tten entwerfen k\u00f6nnen.\nStanton Planet Verbesserungen & Politur\nWas gut gelaufen ist\n\n\nAufbauend auf den Planetenverbesserungen, die im Laufe von 2020 gemacht wurden, war dies die erste Gelegenheit f\u00fcr das Team, die neuen und verbesserten Arbeitsabl\u00e4ufe, die bei der Erstellung der Planeten und Monde von Pyro entwickelt wurden, in Stanton einzuf\u00fchren.\nDie Verbesserung des Workflows beinhaltete, dass wir die Zeit und den Fokus hatten, tiefer in den globalen Malprozess einzusteigen. F\u00fcr Planeten wie Stanton I und IV wurde die globale Bemalung komplett \u00fcberarbeitet, um sowohl die Temperaturparameter genauer einzuhalten als auch eine bessere Mischung und Verteilung der Farbt\u00f6ne zu erreichen. Als zweiter Teil der Bemalung wurden alle Objektpr\u00e4sentationen und Verteilungsregels\u00e4tze von Grund auf neu erstellt. Im Allgemeinen lag der Fokus darauf, mit weniger mehr zu erreichen. Anstatt also viele Arten von Geologie im gleichen Raum zu verwenden, wurden nur ein oder zwei verwendet, die wirklich gut zusammen funktionieren. Das Endergebnis ist viel realistischer und nat\u00fcrlicher. Ein gutes Beispiel daf\u00fcr ist Daymar. Ein weiterer Bereich, den wir verbessern wollten, war der verst\u00e4rkte Einsatz von Bodenstreuungsobjekten, um das Terrain komplexer zu lesen. Wir haben eine Mischung aus Geologie-Assets wie Platten, Ger\u00f6ll und kleinen Felsen mit der Verteilung der Geologie-Packs kombiniert, um der Szene eine viel integriertere Lesart zu geben.\nZus\u00e4tzlich wurden einige herausragende Geologie-Packs konvertiert, um den organischen Shader zu verwenden und wurden als Teil unserer Pipeline korrekt durch Houdini verarbeitet.\nEinige neue Tech-Features kamen in diesem Release online, die wir mit Begeisterung genutzt haben. Das erste ist Terrain Displacement, das POM ersetzt. Jetzt kannst du tats\u00e4chlich sehen, wie die Geometrie des Gel\u00e4ndes tesseliert und verschoben wird, was eine echte Tiefe und komplexere \u00dcberschneidungen mit Objekten erm\u00f6glicht. Das zweite Feature ist Biome Accumulation, was bedeutet, dass Assets prozedural eine d\u00fcnne Materialschicht auf ihrer Oberseite erhalten k\u00f6nnen, abh\u00e4ngig vom Biome. Zum Beispiel sammelt sich Sand auf der Oberseite der Felsen auf Daymar.\nWas nicht so gut gelaufen ist\n\n\nAls wir versuchten, das Jahr zu beenden und die Alpha 3.12 zu ver\u00f6ffentlichen, konnten einige Monde nicht auf das gew\u00fcnschte Polishing-Niveau gebracht werden. Au\u00dferdem haben wir im Zuge der Einf\u00fchrung unserer neuen Arbeitsabl\u00e4ufe und Methoden in das Stanton-System festgestellt, dass die visuellen Stile zwischen einigen Monden zu eng beieinander liegen und wir dadurch etwas an Vielfalt verlieren.\nWas wir in Zukunft anders machen werden\n\n\nMehr Assets werden helfen, die Kunstm\u00fcdigkeit zu reduzieren und die visuelle Vielfalt zu verbessern, daher werden wir in diesem Jahr Zeit und Energie in mehr Asset-Packs investieren.\nStanton System Spacescaping\nWas gut lief\n\n\nWir waren alle sehr aufgeregt, die Gaswolkentechnologie als Teil des PU in Alpha 3.12 pr\u00e4sentieren zu k\u00f6nnen. Viele Teams haben hart daran gearbeitet, dieses neue Feature zu entwickeln. Es ging also darum, ein Team zu gr\u00fcnden, das sich der Erstellung von Inhalten f\u00fcr Stanton widmet, und dann zu schauen, was wir f\u00fcr die Lagrange-Punkte tun k\u00f6nnen.\nWenn man bedenkt, dass dies die erste Release-Version der Technologie war, denke ich, dass wir eine Vielzahl von visuellen Szenarien geschaffen haben, um das Potenzial der Technologie zu zeigen.\nWas nicht so gut gelaufen ist\n\n\nDa es sich um das erste Release handelte, gab es offensichtlich eine Menge herauszufinden, was die Performance angeht, und es gibt eine Menge, was wir in Bezug auf die Pipeline-Verfeinerung tun k\u00f6nnen. Au\u00dferdem gibt es in einigen Beleuchtungsszenarien sichtbares Rauschen, das wir in Zukunft gerne reduzieren w\u00fcrden, wenn es die Leistung zul\u00e4sst.\nWas wir in Zukunft anders machen werden\n\n\nWir sind bereits dabei, unseren Entwicklungsworkflow zu verbessern und suchen nach M\u00f6glichkeiten, den Prozess zu verbessern. Wir erforschen, wie wir die Hintergrund-Raumlandschaft in mehr Mini-System-basierte Formen zusammenbinden k\u00f6nnen, was dann zu kleineren, volumetrischen Gastaschen f\u00fchrt. F\u00fcr zuk\u00fcnftige Gameplay-M\u00f6glichkeiten schauen wir uns an, wie wir das Risiko\/Belohnungs-Gameplay innerhalb der Gastaschen mit Elementen wie Blitzen, Strahlung, Temperaturbereichen und Flughandling f\u00f6rdern k\u00f6nnen.\nIan Leyland\nStar Citizen Art Director\n\nTechnologie\nIn der Alpha 3.12 konzentrierte sich das Grafikteam haupts\u00e4chlich auf die Verbesserung der Stabilit\u00e4t und die Behebung von Fehlern in den verschiedenen Grafikfeatures, die in der Version verwendet werden. Viele der Fehlerkorrekturen bezogen sich auf die Einf\u00fchrung von Gaswolken, wie z.B. das Beheben eines sichtbaren Dithermusters, wenn die Sonne von einer Wolke verdeckt wird und das Verhindern des Clippings von Gaswolken und Partikeln innerhalb von Raumschiffen durch die Verbesserung des volumetrischen Culling- und Partikel-Culling-Systems. Solche Probleme waren zu erwarten, aber gr\u00f6\u00dftenteils unvermeidbar, denn obwohl die Technik bei der Entwicklung von SQ42 ausgiebig genutzt wurde, sind die Grafik und die Szenarien in PU ganz anders. Au\u00dferdem bedeutete die Sandbox-Natur der PU und die ausgiebigen Tests, die sie erh\u00e4lt, dass viele zuvor unbekannte Probleme entdeckt oder in den Vordergrund gestellt wurden.\nDas Team schaffte es auch, Dutzende anderer Bugs zu beheben, die von \"popping shadows\" bis hin zu einer zu hellen Kamerabelichtung reichen, wenn ein Planet hereingestreamt wird. Der Anteil der Zeit, die f\u00fcr die Behebung von Bugs im Vergleich zu neuen Features aufgewendet wurde, war h\u00f6her, als wir es uns gew\u00fcnscht h\u00e4tten, aber am Ende des Jahres liegt der Schwerpunkt immer auf Stabilit\u00e4t und Qualit\u00e4t und die Arbeit an den Features wurde bereits wieder aufgenommen, also ist dies kein Grund zur Sorge. Trotz der Verlangsamung der Feature-Arbeiten haben wir es geschafft, gute Fortschritte beim neuen Gen12-Renderer zu machen, der Anfang 2021 unser Hauptaugenmerk sein wird.\nDas Physics Team arbeitete an dem volumetrischen Soft Body Prototyp sowie dem damit verbundenen Rendering der volumetrischen Deformation. Au\u00dferdem wurden verschiedene Optimierungen in der Physik vorgenommen. Zum Beispiel verbesserten wir das Threading verschiedener Subsysteme, f\u00fcgten schnellere Spatial Grid Queries hinzu, entfernten Contention beim Zugriff auf die lokale Kommando-Warteschlange und entfernten Contention f\u00fcr die Schrittfunktionen der Actor\/Living Entities (Verbesserung der Living Entity Step Performance um einen Faktor von 2x - 5x). Wir haben auch eine bessere Methode zur Vorphysikalisierung der Terrain-Patches des Planeten implementiert, die f\u00fcr Kollisionspr\u00fcfungen verwendet werden. In Bezug auf die Kollisionserkennung haben wir auch ein langj\u00e4hriges Problem behoben, das zus\u00e4tzliche Geisterkontakte weit weg von den eigentlichen Kontakten einf\u00fchren konnte. Au\u00dferdem wurden Verbesserungen an der Ereignis-Warteschlange vorgenommen. Der erste Entwurf zur Ausbreitung von physikalisierten Schockwellen wurde eingereicht und kastenf\u00f6rmige Physikgitter und Geschosswiderstand wurden hinzugef\u00fcgt. Die SDF-Unterst\u00fctzung wurde verbessert und die Forschung an Verbesserungen des Setups der Touch-Bending-Vegetation begann.\nBeim Renderer haben wir mit der laufenden Gen12-Umstellung und dem damit verbundenen Refactoring weitergemacht. Zum Beispiel f\u00fcgten wir ein parametrisierbares Feature-Set f\u00fcr die Deferred Pipeline hinzu, implementierten Updates pro Objekt-Ressourcenset (einschlie\u00dflich RTT-Update f\u00fcr Pinsel) f\u00fcr das Gen12-Szenen-Rendering und Legacy-Pipeline-Status-Caching (um DX-API-Aufrufe zu sparen, w\u00e4hrend wir noch vollst\u00e4ndig auf Gen12 umstellen). Im Shader-System haben wir den gesamten Code f\u00fcr das Nachladen von Shadern aufger\u00e4umt, was die Shader-Bearbeitung w\u00e4hrend der Entwicklung verbessern wird und eine deutlich verbesserte Reaktion beim \u00c4ndern von System-Spezifikationseinstellungen (z.B. Grafikeinstellungen, die die Verwendung verschiedener Shader-Kombinationen erfordern) erm\u00f6glicht. Wir haben auch ein gr\u00f6\u00dferes Refactoring des Shader-Cache-Backend-Systems begonnen, da es ziemlich veraltet ist und eine st\u00e4ndige Quelle des \u00c4rgers in Bezug auf Wartung und Gen12-Fitness ist. Mehrere Optimierungen wurden im Renderer Code durchgef\u00fchrt. Zum Beispiel wurde die Art und Weise, wie Materialkonstanten auf die GPU hochgeladen werden, vereinfacht und optimiert.\nAuf der Grafikseite wurden verschiedene Fixes f\u00fcr die Tiefensch\u00e4rfe bereitgestellt. Der Haar-Shader erhielt mehrere Verbesserungen, wie die M\u00f6glichkeit, spiegelnde Highlights auf den Wimpern zu deaktivieren, verbesserte Boundary Occlusion an Haarlinien, Unterst\u00fctzung f\u00fcr Umgebungslichter im Forward Shading sowie eine verbesserte Haarqualit\u00e4t bei Kameraschnitten. Die Duallobe-Approximation f\u00fcr den Skin-Shader wurde verbessert und der Eye-Shader erhielt ebenfalls ein paar Verbesserungen. Was Atmosph\u00e4ren, Wolken und den Unified Raymarcher angeht, so sind die im letzten Postmortem erw\u00e4hnten Verbesserungen nun in Alpha 3.12 verf\u00fcgbar. Nachdem das aus dem Weg ger\u00e4umt ist, wurde die meiste Zeit auf das volumetrische Wolkenrendering verwendet. Der erste Entwurf des Wolkenrenderers wurde implementiert und die Arbeit an volumetrischen Wolkenschatten machte gute Fortschritte. Die Arbeit an den Verbesserungen f\u00fcr die lokale Wolkenformung wird beginnen. Beachte, dass es bis zur Ver\u00f6ffentlichung noch eine ganze Menge Arbeit zu erledigen gibt.\nF\u00fcr das Kern-Engine-System haben wir einen dynamischen Zonen-Culling-Pfad in das Zonensystem implementiert. Au\u00dferdem haben wir ein paar Culling-Fehler in Bezug auf die Sichtdistanz behoben, die mit pixelgro\u00dfen Objekten zu tun haben und in Alpha 3.11 auftraten. Die Leute haben bereits bemerkt, dass sie jetzt Spieler sehen k\u00f6nnen, die \u00fcber 1000 Meter entfernt sind, anstatt nur ein paar hundert oder so. Eine Menge Bugfixes und Verbesserungen wurden f\u00fcr Vis-Fl\u00e4chen bereitgestellt, wie z.B. ein Fix f\u00fcr das Streaming von Meshes f\u00fcr animierte Vis-Fl\u00e4chen und die M\u00f6glichkeit, Vis-Fl\u00e4chen zu CGA-Joints hinzuzuf\u00fcgen. Das Entity-System erhielt mehrere Verbesserungen und Optimierungen, um unn\u00f6tige Updates und Suchen zu vermeiden. Ebenso erhielt der Entity-Aggregate-Manager Low-Level-Optimierungen, um das Work-Balancing zu verbessern und den Speicherverbrauch und die Konkurrenzsituation bei der Arbeit mit Entity-Bubbles zu reduzieren. Es gab auch ein paar kleinere Verbesserungen am Entity Component Update Scheduler. Die Culling-Logik des Radix-Baums wurde verbessert, wobei die Threading-Logik angepasst wurde, um Konflikte zu reduzieren und SIMD-Culling implementiert wurde, um bis zu vier Bubbles vs. Objekte pro Knoten zu \u00fcberpr\u00fcfen. In Bezug auf die Performance wurde der Engine-Profiler weiter entwickelt, der viele Verbesserungen erfahren hat. Die Arbeit an einem Echtzeit-Sampling-Profiler basierend auf Event Traces wird bald beginnen. Verschiedene Optimierungen wurden im Entity System, den Komponenten-Updates und dem Zonensystem implementiert. Basierend auf der Telemetrie von der PU und PTU haben wir unsere laufenden Untersuchungen zur Speichernutzung fortgesetzt. So wurde der Engine-weite Memory Allocator und das Memory Tracking System, einschlie\u00dflich der Toolchain, erheblich \u00fcberarbeitet und verbessert. Um unseren Servern einen zus\u00e4tzlichen Leistungsschub zu geben, wurde der Linux DGS auf ein monolithisches Executable umgestellt, um dem Compiler zu erm\u00f6glichen, besseren Code zu generieren (insbesondere f\u00fcr den Thread Local Storage Access). Als Teil unserer Initiative, ein Performance-Regressionssystem aufzubauen, haben wir auch einen Stresstest f\u00fcr Object Container Streaming hinzugef\u00fcgt.\nWas die Crash-Behandlung angeht, erfassen wir nun einen Hex-Stack des Render-Threads und betten ihn in Mini-Dumps ein, die du uns (optional) schickst, falls das Spiel abst\u00fcrzt. Dies erm\u00f6glicht es uns, den kompletten Renderthread-Callstack w\u00e4hrend des Postmortem-Debugging wiederherzustellen, ohne dass Drittanbieter-Binaries (die Teil des Callstacks oder des Videotreibers sein k\u00f6nnten) den Stack vollst\u00e4ndig abwickeln m\u00fcssen. Das spart eine Menge Zeit, da wir die verschiedenen Treiber, die die Spieler verwenden, nicht herunterladen m\u00fcssen.\nAuf der Animationsseite haben wir den Code korrigiert, damit die Charakter\u00fcberblendungen und das dynamische Beleuchtungsrigg beim Rendern von Cutscenes nicht bei jedem Kameraschnitt zu sp\u00e4t umschalten.\nZu guter Letzt wurde die Unterst\u00fctzung von C++ 14 f\u00fcr den gesamten Client-Server-Editor und die relevanten Tool-Projekte aktiviert.\nOnline Technik\nLoad Balancing Test Framework\n\n\nDer Pestilence Warmer f\u00fcr Alpha 3.12 erhielt wichtige Updates. In erster Linie nutzt der Warmer nun das neue JWT-Identifikationssystem, das es ihm erlaubt, sehr schnell viele Token f\u00fcr Impersonationszwecke zu holen. Dies hat den 10-fachen Durchsatz an Warmer-Instanzen, die wir gleichzeitig laufen lassen k\u00f6nnen.\nEin wichtiges Subsystem wurde hinzugef\u00fcgt, das es dem Warmer erm\u00f6glicht, sich als Service mit dem Diffusion Gateway zu verbinden, was die Ausf\u00fchrung von Lastszenarien erm\u00f6glicht, die sich sowohl als Client, der \u00fcber den Hub verbunden ist, als auch als Service im Diffusion Netzwerk koordinieren.\nBackend Gleichzeitigkeitsverbesserungen\n\n\nWir waren in der Lage, die Leistung des variablen Dienstes, der Loadouts und des Haupt-Persistenz-Cache-Dienstes zu erh\u00f6hen. Die Stabilit\u00e4t des Backends wurde stark erh\u00f6ht und \u00fcbertraf die Leistung und Zuverl\u00e4ssigkeit, die wir in fr\u00fcheren Versionen hatten. Unser Low-Level-Netzwerkcode wurde aktualisiert, um sowohl die Leistung als auch die Skalierbarkeit und Robustheit zu verbessern. Wir haben auch verschiedene Korrekturen und Optimierungen am Transaktionsdienst, den Vermietungen und unserem Entitlement-Prozessor vorgenommen.\nVereinheitlichtes und zentralisiertes Logging\n\n\nMit unserem neuen einheitlichen, zentralisierten Logging-System senden alle Dienste formatierte JSON-Nachrichten an eine zentralisierte Elasticsearch-Datenbank. Jedes Log-Ereignis wird getaggt und dynamische Daten wie Account-IDs, Spieler-IDs, etc. werden in benannte Felder extrahiert, was die Suche nach Ereignissen oder bestimmten Feldern - wie z.B. einer \"AccountID\" - sehr effizient macht. Dies erm\u00f6glicht den Entwicklern einen einfachen Zugriff auf die Logs von einem zentralen Ort aus und die Verfolgung komplexer Nachrichten und Ereignisse, die zwischen mehreren Diensten stattfinden.\nPersistente Technik\nEntity Erstellung & Spawn Entkopplung\n\n\nIn Vorbereitung auf das persistente Streaming wurde der Prozess der Entit\u00e4tserstellung vom Spawnen der Entit\u00e4ten entkoppelt. Dies erlaubt es uns, den Anfangszustand des Universums in die persistente Datenbank zu \"seeden\", indem wir alle dynamischen Entit\u00e4ten vor der Simulation erzeugen. DGS-Prozesse werden dann w\u00e4hrend der Simulation persistente Entit\u00e4ten aus dieser Datenbank streamen (spawn\/despawn). Dies ist ein wichtiger Schritt auf dem Weg zu einem vollst\u00e4ndig persistenten Universum.\nParallele Spawn-Warteschlangen\n\n\nAls eine Optimierung haben wir mehrere parallele Spawn-Warteschlangen auf jedem Spielserver eingef\u00fchrt. Dies erlaubt es uns, mehrere verschiedene Orte (wie Lorville und New Babbage) parallel in separaten Threads auf demselben Server zu spawnen. In fr\u00fcheren Versionen gab es nur eine einzige Warteschlange und daher w\u00fcrden wir (in diesem Beispiel) erst mit New Babbage beginnen, wenn Lorville vollst\u00e4ndig gespawnt ist. Auf ausgelasteten Servern kann dies die Wartezeit in einigen F\u00e4llen wirklich reduzieren. Zum Beispiel beim Spawnen von Wellen von KI-Schiffen oder beim Respawn in einem Hab.\nNetzwerk Tech\nZeit & De-Syncs\n\n\nDie Art und Weise, wie die Engine den Ablauf der Zeit misst, wurde komplett \u00fcberarbeitet. Die Genauigkeit wurde sowohl bei der Messung der Zeit als auch bei der Synchronisation zwischen Server und Clients verbessert. Die Art und Weise, wie die Engine die Zeit nutzt, um ihre Logik- und Physiksimulation zu aktualisieren, wurde ge\u00e4ndert, um Fehler zu beseitigen, die dazu f\u00fchren konnten, dass die Simulationszeit auf dem Server und den Clients unterschiedlich verlaufen konnte. Viele kleinere Bugs, die dazu f\u00fchrten, dass Zeitfehler auf lang laufenden Servern anwuchsen, wurden ebenfalls behoben. Die Netzwerksynchronisation von Fahrzeugen und Physikobjekten wurde aktualisiert, um den vollen Nutzen aus den Verbesserungen zu ziehen. Das akkumulierte Ergebnis all dieser \u00c4nderungen war eine signifikante Reduzierung von Latenz- und Desynchronisationsproblemen in vielen Bereichen, selbst unter harten Testbedingungen f\u00fcr Netzwerk- und Serverleistung. Neben der Verbesserung des allgemeinen Spielerlebnisses war diese Arbeit ein notwendiger Schritt in Richtung Server-Meshing, wo die Simulation des Spiels \u00fcber mehrere Spielserver Desynchronisationsprobleme aufgrund von Timing-Fehlern verschlimmert h\u00e4tte.\nAutorit\u00e4ts-API\n\n\nIn Vorbereitung auf das Server Meshing hat das Team die verbleibenden Aufgaben zur Konvertierung des Codes auf die Authority API durchgef\u00fchrt. In den letzten 12 Monaten gab es eine koordinierte Anstrengung von allen Teams, um den Code der Game-End-Engine auf dieses neue System zu aktualisieren. Dank ihrer Arbeit konnte ein Gro\u00dfteil dieser Aufgaben abgeschlossen werden. Mit einem konzertierten Vorsto\u00df haben wir die Anzahl der verbleibenden Aufgaben auf eine einstellige Zahl reduziert.\nVerbindungsfluss\n\n\nIn einem Server Mesh kann sich ein Client w\u00e4hrend einer Spielsitzung mit vielen verschiedenen Servern verbinden. Ein Teil der Arbeit in Richtung Server Meshing erfordert es, den Prozess der Verbindung eines Clients mit einem Server in verschiedene Phasen zu unterteilen. Diese Phasen k\u00f6nnen dann unabh\u00e4ngig voneinander ausgef\u00fchrt werden, ohne dass ein Client seine bestehende Spielsitzung komplett aufgeben muss. Es wurden bereits bedeutende Fortschritte in diese Richtung gemacht, obwohl es noch mehr Arbeit zu tun gibt.\nMarco Corbetta\nVP der Technologie\n\n\nWir sehen uns im 'Verse!\nWir glauben, dass es sehr wertvoll ist, diesen Einblick in unseren Entwicklungsprozess zu geben, vor allem, wenn du die Gedankeng\u00e4nge, \u00dcberlegungen und Lehren direkt von unseren Senior-Entwicklern lesen kannst. Wie schon beim letzten Mal erw\u00e4hnt, haben wir uns zu einer transparenten Entwicklung verpflichtet und werden auch in Zukunft viertelj\u00e4hrliche Patch-Postmortems zur Verf\u00fcgung stellen.","zh_CN":"Alpha 3.12 Postmortem\nOn December 17, 2020, we launched Alpha 3.12: Assault on Stanton, which introduced a number of new features and changes, including refinery decks, AI improvements, and gas clouds. 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 specifically focuses on the Alpha 3.12 patch \u2013 we will release a separate postmortem Comm-Link focusing on the XenoThreat dynamic event separately. Vehicle Team\n\nWhat went well\nThe Vehicle Pillar primarily supported a lot of other teams\u2019 work for Star Citizen Alpha 3.12, particularly with capital ship combat ahead of the Arlington Bounty, CS5 UEE Navy Idris, and XenoThreat events. We worked not just on how the vehicles function and perform (being the largest ships deployed to the servers yet) but also helped deal with the increased lethality of torpedoes with smarter and more effective AI countermeasure usage.\nPlayers also benefitted from this work with the ability to choose the type of countermeasure and how many are fired in a burst, adding greater tactical choice to the act of diverting incoming missiles and torpedoes. We also added further HUD elements to allow players to see how many of each type they have left along with the current burst size.\nThe last change to countermeasures was an expansion of the Alpha 3.11 changes. This makes each countermeasure type work against all missile seeker types but changes how effective they are depending on the type and number of incoming missiles. Decoys replaced flares as a time-limited point distraction while noise, formerly chaff, became an area-of-effect signal blocker (more countermeasures launched provides a higher chance of spoofing). We also changed the missiles themselves to provide minor variance in their tracking so a successful countermeasure would not divert all missiles equally. In addition to controlling the burst size manually, we added a panic function that empties 25% of available countermeasures in an attempt to overpower a surge of incoming missiles.\nWhat didn\u2019t go so well\n\nWe discovered a lot of issues with the missile setup and balance that caused odd behaviors. However, we decided to leave this until missiles are converted to IFCS 2.0 in Alpha 3.13 as it requires a comprehensive ground-up retune of all missile behaviors. In the future, we want to expand countermeasures by giving players better feedback on their own signatures and missile abilities, which will start coming online with Missile Operator Mode.\nVehicle Entry Identification was a much-requested quality-of-life feature (building upon the ASOP Hangar Spawn notifications of Alpha 3.11) that allows players to quickly identify the points of entrance into a ship. These markers update depending on whether the ship is landed or in zero-g, removing a common complaint new players had of being unable to figure out how to get into their ship. Occasionally these displays wildly offset from the vehicle, which we\u2019re looking into, but that was pretty much the only negative issue with the feature and it was generally well-received.\nThe main content delivery in Alpha 3.12 was the Esperia Talon and Talon Shrike, which are a pair of light fighters that expand the line-up in-game. Generally, these went pretty well and we discussed their development in multiple ISC episodes, including our work on the Hard Surface Shader and iridescent materials.\nUnfortunately, a few issues were present at release that we\u2019re aiming to fix in future patches. These include the screen requiring toggling in Arena Commander (also present on the Prowler) and the Talon Shrike\u2019s missile launchers sometimes stopping functioning after a large number have been fired.\nJohn Crewe\nVehicle Director\n\nUSPU Gameplay Feature Team\nQ4 for the USPU team is always a busy one. Not just for us, but for the entire company. Here\u2019s a brief summary of our more important initiatives that we were able to get into your hands during the quarter. Thankfully, for better or for worse, we didn\u2019t have a massive CitizenCon demo to prepare for this year, but that didn\u2019t stop us from being extremely busy.\nInternational Aerospace Exposition (IAE)\nWhat went well We successfully extended our IAE content into the high-tech art style, which took place at New Babbage on planet microTech. We added several new things to the event this year that tried to cater to comments from the fans. Firstly, we had each manufacturer\u2019s expo hall run for two consecutive days in case fans missed the first and extended the free rental period from one day to two. Hopefully these two things allowed everyone the opportunity to rent the ships they were eager to try. We also had two expo halls running on any given day. This obviously allowed for more things for the players to see and, in the spirit of \u201cmore things to see,\u201d we decided to showcase many of our ship components and weapons in the main hall. Between two halls active each day and all the additional items, this was a true testament that our tech is getting more and more optimized as we would never have been able to do that in the past. Finally, to try and extend accessibility, we added a series of rental kiosks into the \u201cBest In Show\u201d hall, which ran for four days. In these kiosks, we put every vehicle that was shown throughout the course of the show and gave the same two-day rental period. Between all of this, we feel it was the most engaging iteration we\u2019ve created to date.\nWhat didn\u2019t go so well We had two vehicles that were introduced to the game at the IAE show that really came down to the wire in terms of their development. Ultimately, this didn\u2019t allow us to lock down the build until a few days before the show. Because this show is open to the public in November, it had to be released as a point-patch to the Alpha 3.11 build. Not being able to lock down the build before we branched to the Alpha 3.12 build caused some file-management headaches. Critical fixes are still being made to the point release and those same fixes also need to be in the newly branched stream content. This inevitably leads to work getting stomped here and there and, at the end of the day, eats valuable time that could be used to fix other bugs or make new things. Also, some things that we intended to keep secret until a bit closer to the time of the event leaked. This was hardly a major issue, but it\u2019s always nice to be able to surprise the fans from time to time.\nWhat we\u2019ll do differently in the future A few things I really want to focus on as we move forward with this event are: Modularity\/re-use of assets from previous events. The faster we can make these events happen, the more time we\u2019ll have to focus on new content ideas or other solar systems.\n\nPreproduction planning. We know the event will happen again next November, so I would like to iron out things like the color scheme, event logos, location, etc. as early as possible. This way, when it comes time to work on the content, nobody is waiting for anything to be decided and we can just put our heads down and work.\n\nGet all content for the event into the build so we can avoid requiring a point release. As mentioned above, having two release streams\/branches running in parallel is simply asking for trouble.\n\n\nReputation System\nWhat went well Another important system that was added in Q4 was the reputation system that we\u2019ve always intended to have. While this isn\u2019t visible to players yet, they are able to experience it through our mission givers and some of our mission chains (the bounty hunter chain is the most notable series that is currently being unlocked by reputation gains). Not every mission has been converted to the new system, though it will be an ongoing process over the next quarter or two. This new reputation system will be the foundation for a significant number of gameplay systems as we move forward. Not only will this be the main way that content is released to players, it will also be tied to things like NPC responses (currently seen in mission givers), perks and benefits that can be earned by participating in content, for tracking player progress through career paths, for dictating relationships between the organizations within the game, and a number of other essential gameplay loops. We felt that this was so important to get into the game that we elected to release it without any player facing UI (which is in progress for Q1\/Q2 release). But because this is going to be so ingrained in a significant number of systems moving forward, we felt it was worth the sacrifice. Not only will it be represented in a standalone reputation UI that will allow players to view their career tracks with various organizations, it will also track the key NPCs they have interacted with along with their current standing with each. Reputations will be exposed in this UI as they come across them in the universe so that it encourages players to travel around and engage with the content to expose them. Additionally, we will be revamping the Mission Manager to include player visibility as to what sort of reputation requirements they need to acquire missions. Reputation is going to be one of the largest progression mechanics that Star Citizen will have going for it outside of the economy since we are a skill-based sandbox game not driven by \u201cleveling\u201d or \u201ctalent tree\u201d systems. Reputation is now service-driven on the backend as well. This means that all reputation gains can be preserved between patches, which will be a great thing for the players.\nWhat didn\u2019t go so well As far as general development of this feature, it went quite smoothly once we got to dig our heels into it. We had started work on it about a year prior to this but unfortunately got pulled onto some higher priority stuff at the time. If I had it to do over, I would have kept the team on this until it was done and had the desired UI\/UX changes to go along with it. Not having the UI in place with its release, while not game-breaking, is a critical piece of this feature. Ensuring that all our features are intuitive often relies on this type of visual feedback.\nWhat we\u2019ll do differently in the future Moving forward, I would like to try and budget the required time to release a more \u201ccomplete\u201d feature. While it\u2019s not always possible to convert all of a game\u2019s existing content over to new systems like this, I would like to try and make sure we can do more when big changes like these happen in the future. I was happy that we got more than the original intention into place but would have loved to get more time with the Mission Team to help convert even more than we did. The next time something as foundational as this comes up, I would like to personally do a better job of raising global awareness across the company so we can convert as much of it as possible. Front End Conversion to Building Blocks\nWhat went well We were able to convert the initial two screens in the frontend to utilize our Building Blocks tech. In general, I think this process went fairly well. It didn\u2019t require a ton of people and was a fairly self-contained bit of work. We also got the opportunity to fix a few things that we wanted to address since adding the \u201cnew friends\u201d service back in Q1 2020. Switching this over to our new UI system also allowed us to fade all of the UI elements together. Going through this process gave us some time to critically think through the frontend since the project has evolved so much over the last few years. We also set it up so that the current solution can scale up as we add more solar systems. We cleaned up the main screen so that we can have a greater view of the background images. I\u2019m happy that we were able to attribute a different image for each possible landing zone; I think it really helps give new players a sense of what type of location they\u2019re choosing.\nWhat didn\u2019t go so well The frontend is very ingrained with the original CryEngine toolset that we originally started with. The Building Blocks system works based on entities, which means that our core data needs to be loaded so that we have an entity to run the canvas on. On top of that, the original system requires a level to be loaded. Because of this, we were not able to replace any elements prior to selecting what game mode players want to play (at least not with Building-Blocks-based tech\/implementation). The ultimate solution is to completely rework this code base but that was way outside the scope of what we were able to deal with, nor was it our main directive here.\nWhat we\u2019ll do differently in the future The bottom line here is that the game that we based our original frontend on is much different from the game that we are building towards today. I\u2019m not sure how much the USPU Team will be changing the frontend in the future, but the next time we make changes here I\u2019d really like to be working towards the final vision. This would allow us to really streamline the new user experience so that getting into the game for the first time, or back into the game for returning players, is as simple and intuitive as possible. Because we have been bolting on new features one at a time, this part of the game has suffered as a result. If this can be redefined from the ground up, there\u2019s a lot that we\u2019d do differently based on how much the game has evolved.\nRob Reininger\nLead System Designer and USPU Product Owner\n\nSystemic Services & Tools Team\nWhat went well The Systemic Services and Tools (SST) Team continued working on the Quantum simulation and integrating it into services alongside internal presentations of new technology that we\u2019re excited to share with the community soon.\nAdministrative work occurred last quarter to shift around internal CIG resources for SST. The team will be increasing in size to accommodate the growing need for services and support for Quantum across many aspects of the game.\nOutside of services and simulation work, SST created new tools to support the upcoming reputation system and the way reputation is distributed across the game universe. SST continues to support the Star Citizen economy with Data Tools to help alleviate the massive amount of data while we prepare for Quantum to take the reins.\nWhat didn\u2019t go so well As we transition into a larger department, we had some growing pains with our response times to other teams. Features like the refinery service didn\u2019t get the immediate attention they needed while our attention was elsewhere.\nWhat we\u2019ll do differently in the future We\u2019re looking for ways to better streamline and distribute the work coming into SST for the growing team. In addition, we\u2019ve set up automated messaging to supplement the communication coming out of SST to dependent teams.\nJake Muehle\nSenior Technical Designer\n\nDesign Team\nAI Intercepting Torpedoes\nWhat went well Turrets on the Idris intercepting torpedoes works well, and it creates some very cool moments when they successfully intercept.\nWhat didn\u2019t go so well AI accuracy is not good enough to reliably shoot down incoming torpedoes depending on server framerate.\nWhat we\u2019ll do differently in the future We will look to improve the AI accuracy so we can have greater control over how many torpedoes slip through turret defenses.\nAI Fire Mode Usage and Targeting Priorities\nWhat went well The AI using burst-fire greatly improves the look of AI turret fire. Plus, the targeting priorities ensure that the AI are attacking a sensible target for their ship class\/turret size.\nWhat didn\u2019t go so well At the minute, using burst-fire puts the AI at a disadvantage compared to the players as fully automatic firing increases damage.\nWhat we\u2019ll do differently in the future We will rebalance AI burst-firing when capacitors are introduced to reduce the effectiveness of holding down the fire button.\nAI Accuracy Convergence\nWhat went well The new accuracy system acts in a more believable manner as it tracks the target\u2019s position and continues to fire at that position until the target moves. This is preferable to the old system where the AI\u2019s aim would swing wildly as it attempted to miss stationary targets in front of it.\nWhat didn\u2019t go so well The AI is not accurate enough to pose a decent level of threat to the player at the minute. And, the new system tends to miss behind the target\u2019s movement instead of in front, so the players don\u2019t see that they are being shot at as much.\nWhat we\u2019ll do differently in the future We want to improve the accuracy overall and make it so different NPCs have a more noticeable accuracy difference between skilled and unskilled AI. The accuracy system will also be iterated upon to make it overshoot as opposed to undershoot the target more often.\nCapital Ship Combat Behavior\nWhat went well The capital ships now put a good amount of consideration into distance and relative position when engaging other ships. Capital ships without frontal guns will attempt to get in close enough to utilize all of their turrets, while those with large frontal guns will attempt to keep out of the enemy\u2019s range and utilize their powerful long-ranged weapons.\nWhat didn\u2019t go so well The tactic selection doesn\u2019t consider the AI ship\u2019s strength relative to the target enough. For example, when the Idris is fighting a gunship or capital ship, it will attempt to stay at a distance and use its railgun. This often makes sense but can lead to it running away from smaller gunships that it could easily take in a close-range slap fight.\nWhat we\u2019ll do differently in the future We will iterate on the tactic selection so the AI consider their own ship and target in more detail than just the ship class. Also, we will want to allow pilot character traits to affect the capital ship behavior as well.\nElevator Panels\nWhat went well We successfully laid the groundwork for future elevator panels (and other re-styleable screens), making them inherit their styles from the transit system and be usable on any shaped canvas. This means all future panels can use the same two files but still look different.\nWhat didn\u2019t go so well The transit system is very difficult to set up and test in its current form \u2013 the UI Team were unable to get it working properly and had to rely on Level Design to implement. However, UI and Level Design didn\u2019t work on the feature at the same time, resulting in work starting and stopping in different streams and bugs getting missed. New Building Blocks styles are extremely time-consuming to implement due to a lack of tools and an inability to merge files.\nWhat we\u2019ll do differently in the future We\u2019ll make sure that the feature is developed, implemented, and tested in one go in a feature stream so that bugs are picked up and fixed before it\u2019s \u201cfinished.\u201d We\u2019ll also make sure the team that owns the feature has time to fix code issues as part of the feature development cycle and have the UI Team focus on the UI.\nStation Based Refining\nWhat went well We finished the initial gameplay loop for refining, complete with refineries having their own material specializations, workloads, and the ability to refine, collect, and sell refined materials at various places across the galaxy. The refinery decks themselves look spectacular and the UI for the refinery terminal itself is in a great place to expand upon the gameplay loop with very little in the way of reworking things, which should mean quicker iteration down the line.\nWhat didn\u2019t go so well Our planning for every step was extremely thorough, however, due to several situations out of our control, we were unable to reach a point early enough where we could balance the refinery loop the way we intended to. So, we brought forward another already-intended set of changes in the form of the initial mining rebalance to compensate as best we could until we can get the refinery balance to the level we originally wanted. This mining rebalance had the added bonus that it made the MISC Prospector a bit more appealing for people to start out with or rent as well as providing more gameplay experiences for the Argo MOLE or multiple players with Prospectors.\nWhat we\u2019ll do differently in the future Get the UI art play-tested earlier. Some players didn\u2019t know what parts of the screen they could interact with and this would have allowed us to have more time to make changes.\nMining UI Refactor\nWhat went well We reworked the entire mining UI to work with Building Blocks. This went a lot smoother than any of us could have ever hoped as a lot of the mining gameplay loop setup actually worked with Building Blocks straight out of the box without much reworking at all. This gave us leeway to add more to the mining UI than we originally intended to, meaning we were able to not only provide an entirely new UI that\u2019s scalable across three different mining vehicles, but we showed off that scalability by quickly iterating on UI canvas pieces to support previously introduced systems. This included volatile cargo and added an entirely new cargo hold piece that further provides players with information we always wanted to provide but never had the ability to do so.\n\nWhat didn\u2019t go so well The initial pass of the mining UI refactor was trickier to implement than it was to build, with different vehicles having different spaces available to them for the UI, meaning that a lot of behind-the-scenes tweaking was required to actually display the UI in a comfortable way. This is still being fine-tuned and, with future tech coming soon, we hope to broadcast the UI in a slightly more visually appealing way that works better than the current implementation.\nWhat we\u2019ll do differently in the future We\u2019ll iterate more quickly in the future on things like this as we now have a firmer understanding of Building Blocks and its benefits.\nTodd Papy\nStar Citizen Live Director\n\nCore Gameplay Pillar\nMulti-Tool Tractor Beam\nThe Multi-Tool Tractor Beam is an exciting addition to the \u2018verse and is a core piece of functionality that unlocks several gameplay loops that we are working on, such as cargo hauling and EVA traversal spaces. The main use-case for the Tractor Beam in Alpha 3.12 is to allow for easier collection of cargo boxes in EVA either during lost in space missions or for the collection of post-ship-combat loot. While on the surface the Tractor Beam is a point-and-shoot tool, under the hood a lot is going on, and I think the team did a fantastic job of creating a truly systemic feature that is accessible and easy to use.\nThe first challenge that we faced is that we wanted it to work in several different gravity settings and to utilize the weight of an object. This led to several issues, as in zero-g everything is weightless, so it meant that you could potentially move something huge that weighed very little. For example, a planet-sized polystyrene ball. We designed the Tractor Beam around two core concepts \u2013 volume and force. Volume dictates the general size of the object you can lift while force dictates the amount of effort the gun needs to apply to lift the object. This means that for any item that has a mass and physics collider (which every item should already have), the force required to lift it is automatically calculated using the environment\u2019s gravity. This allowed us to build a feature that works with any physics object in the game without having to do lots of manual set up.\nThe second challenge was how do we explain to the player what they can and cannot lift without having to ADS on everything or even worse, use trial and error. Fortunately, the Multi-Tool already has a small screen on the back that allowed us to implement some simple iconography alongside a traffic light color-coding system. This means that we\u2019re able to clearly show all five states of an object by just looking at it: Object can be lifted\n\nObject can be lifted but is out of range\n\nObject is too heavy\n\nObject can never be lifted\n\nYou will travel to the object\n\nWhile we did provide additional information in the ADS view, everything that you need to know is on the back of the tool and I was really pleased we were able to distill so much information into such a small screen.\nWhat didn\u2019t go so well When planning any feature, you want to identify the core experience and then outline any secondary mechanics that would enhance that experience. For example, a jump mechanic by itself is a standalone feature, but you may decide that in-air control (a secondary mechanic) enhances that core experience. With the Tractor Beam, we sat down and identified the core experience of being able to manipulate objects and use it as a grapple hook in EVA, and I feel we delivered on this. But there were some secondary mechanics that I would have liked to ship that we ran out of time to deliver. Specifically, allowing the manipulation of your trajectory using your suit thrusters when using the grapple hook functionality in zero-G.\nUnfortunately, the two systems did not really work well together, with the force used to pull you along overriding any force used by the suit thrusters. It also didn\u2019t help that EVA was also being moved over to using IFCS at the same time and this led to us having to make a priority call to focus on the core experience and make sure that was as polished as can be for release. This happens all the time with features and is the nature of game development, but it was a shame it missed the first iteration. We will add this functionality in a later release.\nWhat we\u2019ll do differently in the future Delivering a feature for release requires lots of different teams coordinating together, from VFX to Audio to the feature team working on the functionality. One of the biggest things I am trying to improve upon is to give the mission designers more time to allow them to integrate all of these different features into the \u2018verse in a meaningful way. If you have read my previous postmortems, you will probably see a trend that this is something I am actively trying to improve, but as multiple teams and schedules are involved, it takes a little bit of time to readjust. If I could go back in time, I would probably have tried to get a simple version into the hands of the mission\/level designers sooner so they could have played with it a little bit more.\nWeapon Zeroing\nWhat went well Weapon zeroing, as the title suggests, allows you to zero weapons to different ranges, allowing you to shoot accurately at much further distances. This means the scope considers the fall-off of the bullet at a specific range and allows you to adjust the sight so you can still aim your reticule at the target. I.e. you don\u2019t have to aim above the target. We already have lots of scopes available and the first challenge was deciding which scopes should zero at all and then deciding whether they should auto-zero or manually-zero. This led to a much wider discussion surrounding manufacturers and their specific traits, such as high-tech or low-tech. While the team could have just focussed on the feature and pushed it out, they have also delivered a long-term plan for the scope attachments for not just current manufacturers but future ones as well.\nThis is something that I fundamentally believe in \u2013 that even though we are working on a live product, we should be making decisions around the final experience in the released game. Sometimes that\u2019s hard as it can mean that certain features are not seen in their best light on first inspection or misunderstood in the short-term by the players. But it\u2019s my job to make sure we are working towards the final vision and the team did a fantastic job of providing a feature that is fun to use but scalable in the future.\nWhat didn\u2019t go so well This was the first feature one of our newest team members worked on. As such, we made sure he had plenty of time to deliver it way before the actual release. In fact, the functionality (not the visuals) was delivered the quarter before and he did a great job. Now, in most cases, this is fantastic as it means we can focus on the experience and make sure it\u2019s of the highest quality. In this case though, due to other priorities and this being done so far ahead of the release, it did not get the full focus of the testing team as they were (rightfully) busy checking things going imminently live. Unfortunately, this meant a fundamental edge case was missed until just before the release, which was that zeroing did not work when the physics patches for the environment streamed out.\nLet me explain. When a character spawns on a planet a series of patches (squares) spawn around them in ever-increasing sizes. These patches cover the render (graphics) quality and the physics collision, with patches further away having less detail and eventually no collision (as physics is relatively expensive). Now, when you move around, the patches dynamically update but it\u2019s not one-to-one. So, a patch you might have just been in may still have its collision as you may want to go back there and it\u2019s more performant to keep it there in the short-term than to keep loading and unloading it. In this case though, it meant when a designer loaded into the editor to test the feature, the patch was loaded and then they moved 2 km away to test weapon zeroing and it worked. Though if a player had never gone to the original position there would be no collision and so the scope would have nothing to test against. This meant in normal game conditions it didn\u2019t work as intended, so we had to reauthor the weapon zeroing code to test against the render geometry instead of the physics one. While this change was not major, it was not ideal as we had planned to work on other features.\nWhat we\u2019ll do differently in the future If I could go back in time, I would most definitely make sure that the feature had been thoroughly tested when it was completed rather than wait for the more traditional go\/no go. While it didn\u2019t affect the feature\u2019s release, it did have knock-on effects for future work as we had to reprioritize during the quarter.\nGemini A03 Sniper Rifle & Behring FS-9 LMG\nWhat went well As with every weapon we add to the game, we must always make sure it fits into the existing weapons\u2019 matrix and offers something unique that doesn\u2019t already exist. With the Gemini A03 sniper rifle, the intention was to make a lightweight, responsive marksman rifle with a lower caliber than its heavier counterparts but high speed and accuracy. I think the team really delivered on that intention and struck a good balance between the high-caliber sniper rifles like the P6-LR and the more assault-orientated weapons like the Gemini S71. While the A03 was a simple addition, the Behring FS-9 was a bit trickier. LMGs as a weapon category are not in a great place right now as they are outgunned by SMG\/shotguns at close range and outmatched by assault rifles at mid-to-long range. This is something we are acutely aware of and have been working behind the scenes to improve. The Behring FS-9 sets the standard for what we want LMGs to be \u2013 high-capacity machineguns that allow players to suppress an area without a huge loss of accuracy.\nWhat didn\u2019t go so well While we were working on the FS-9, we were also working out the design intentions for all the other LMGs so we could deliver an update across the board in one release. Unfortunately, we ran out of time on the existing weapons, although we did manage to do some tweaks to raise their effectiveness. We do plan on updating the existing LMGs to raise them to the same quality bar as the FS-9, but it does mean in the short term it\u2019s vastly superior to the other weapons in the same category. But as I mentioned above, I will always prioritize decisions around what we want the end goal to be so that we are constantly moving forward.\nWhat we\u2019ll do differently in the future We have a plan to overhaul all the weapon categories and hopefully you can see that each weapon we release slightly improves on those that came before it. With this intention, I would have added more time to polish the existing LMGs as I would have liked to release them all together. No matter how experienced you are, you are always learning and this is something I will be implementing for future weapons.\nRichard Tyrer\nCore Gameplay Director\n\nLocations\nSpace Station Refinery Decks\nWhat went well For this release, we were able to introduce refinery decks to some specific space station locations. These spaces are themed around the mining and refining gameplay loops and also serve as a location for future gameplay opportunities. Inside the refinery deck, we created a space specific for refining and processing along with a shop and guild space below.\nAfter seeing the response to the cargo decks and the new space station interiors in Alpha 3.11, we agreed with the comments about players wanting to see more of a visible connection with the exterior to physically understand where they are in the station. Even though we were quite far through developing the refinery deck interior, we pivoted and adapted the space to include the mini viewing deck by the elevator lobbies. Visually, we had wanted to explore a space station experience more focused towards industrial activity for some time, including the global composition of the station to the hot and noisy interior.\nWhat didn\u2019t go so well It was a shame not to see specific NPC loadouts release with the refinery decks or be able to expand some of the specific usables. However, these are all planned so hopefully we will see them come online soon.\nWhat we\u2019ll do differently in the future As mentioned above, we introduced the viewing deck quite late in the process, so we could have designed a superior space with this in mind during concept and whiteboxing.\nStanton Planet Improvements & Polish\nWhat went well Continuing to build on the planetary improvements made throughout 2020, this was the first opportunity the team had to introduce the new and improved workflows developed when creating Pyro\u2019s planets and moons to Stanton.\nImprovement to the workflow included having the time and focus to go deeper on the global painting process. For planets like Stanton I and IV, the global painting was completely redone to be both more accurate to temperature parameters and to have a better blend and distribution of hues. As a second part to the painting, all object presents and distribution rulesets were done from scratch. In general, the focus was to do more with less. So, rather than use many types of geology all in the same space, just use one or two that work really well together. The end result is something much more realistic and natural. A good example of this is on Daymar. Another area we wanted to improve was the increased use of ground scatter objects to complexify the terrain read. We combined a mixture of geology assets like plates, scree, and small rocks with the distribution of the geology packs to give a much more integrated read to the scene.\nAdditionally, some outstanding geology packs were converted to use the organics shader and were processed correctly through Houdini as part of our pipeline.\nSome new tech features came online during this release that we were excited to take advantage of, the first being terrain displacement which replaces POM. So, now you can actually see the terrain geometry get tessellated and displaced giving actual depth and more complex intersections with objects. The second feature is biome accumulation, which means assets can procedurally receive a thin layer of material on their top surface depending on the biome. For example, sand gathering on the top of the rocks on Daymar.\nWhat didn\u2019t go so well As we were trying to close out the year and hit the Alpha 3.12 release, some moons were not able to be taken to the polish level we wanted. Also, as part of introducing our new workflows and methodology to the Stanton system, we noticed the visual styles between some moons are becoming too close together and we\u2019re losing some diversity.\nWhat we\u2019ll do differently in the future More assets will help reduce art fatigue and improve visual diversity, so moving into this year, we\u2019re investing time and energy into more asset packs.\nStanton System Spacescaping\nWhat went well We were all really excited to be able to showcase the gas cloud tech as part of the PU in Alpha 3.12. Lots of hard work was done by many teams to create this new feature, so the process was about establishing a team dedicated to creating content for Stanton, and then starting to look at what we could do for the Lagrange points.\nConsidering this was the first release version of the tech, I feel we created a variety of visual scenarios to show the potential of the tech.\nWhat didn\u2019t go so well As this was the first release, there was obviously a lot to figure out in terms of performance, and there is a great deal we can do in terms of pipeline refinement. There is also some visible noise in some lighting scenarios that we would like to reduce in the future as performance allows.\nWhat we\u2019ll do differently in the future We are already improving our development workflow and looking at ways to improve the process. We are exploring how we can tie together the background spacescape into more mini-system-based forms, which then leads to smaller, volumetric gas pockets. For future gameplay opportunities, we\u2019re looking at encouraging risk\/reward gameplay inside the gas pockets with elements like lightning, radiation, temperature ranges, and flight handling.\nIan Leyland\nStar Citizen Art Director\n\nTechnology\nFor Alpha 3.12, the Graphics Team mainly focussed on improving stability and fixing bugs with the various graphics features utilized in the release. Many of the bug fixes related to the introduction of gas clouds, such as fixing a visible dither pattern when the sun is obscured by a cloud and preventing gas clouds and particles from clipping inside spaceships by improving both the volumetric culling and particle culling systems. Such issues were expected but largely unavoidable because, although the tech has been used extensively in the development of SQ42, the artwork and scenarios are quite different in the PU. Plus, the sandbox nature of the PU and extensive testing it receives meant many previously unknown issues were discovered or raised in priority.\nThe team also managed to resolve dozens of other bugs ranging from popping shadows to over-bright camera exposure when a planet is streamed in. The proportion of time spent bug-fixing compared to new features was higher than we\u2019d have ideally liked, but there\u2019s always an emphasis on stability and quality at the end of the year and feature work has already resumed, so this is not of concern. Despite the slowdown in feature work, we did manage to maintain good progress on the new Gen12 renderer, which will be our primary focus for early 2021.\nThe Physics Team worked on the volumetric soft body prototype as well as the related rendering of volumetric deformation. Moreover, various optimizations were done in physics. For example, we improved the threading of various subsystems, added faster spatial grid queries, removed contention accessing local command queue, and removed contention for actor\/living entities step functions (improving the living entity step performance by a factor of 2x \u2013 5x). We also implemented a better way to pre-physicalize the planet terrain patches used for collision checks. With regard to collision detection, we also fixed a longstanding issue that could introduce additional ghost contacts far off from where the actual contacts were being processed. Furthermore, improvements were made to event queueing. The first draft of propagating physicalized shockwaves was submitted and box-shaped physics grids and bullet drag were added. SDF support was improved and research started on improvements to the setup of touch bending vegetation.\nOn the renderer, we continued with our ongoing Gen12 transition and related refactoring. For instance, we added a parameterizable feature set for the deferred pipeline, implemented per-object resource set updates (including RTT update for brushes) for Gen12 scene-rendering and legacy pipeline state caching (to save DX API calls while we\u2019re still fully transitioning to Gen12). In the shader system, we cleaned up all shader reloading code, which will improve shader editing during development and give a much-improved response when changing system spec settings (e.g. graphics settings that require the use of different shader combinations). We also started a larger refactor of the shader cache backend system as it\u2019s quite outdated and a constant source of grief with regards to maintenance and Gen12 fitness. Several optimizations were done in the renderer code. For instance, the way material constants are uploaded to the GPU was simplified and optimized.\nOn the graphics side, various fixes for depth-of-field were provided. The hair shader received several improvements, such as the ability to disable specular highlights on eyelashes, improved boundary occlusion at hairlines, support for ambient lights in forward shading, as well as improved hair quality during camera cuts. Dual lobe approximation for the skin shader was improved and the eye shader received a couple of improvements as well. As far as atmospheres, clouds, and the unified raymarcher go, the improvements mentioned in the previous postmortem are now available in Alpha 3.12. With that out of the way, most of the time was focused on volumetric cloud rendering. The initial draft of the cloud renderer was implemented and work on volumetric cloud shadows made good progress. Work will commence on improvements to local cloud shaping. Note that there\u2019s still quite a lot of work to be done before release.\nFor the core engine system, we implemented a dynamic zone culling path in the zone system. We also fixed a few view distance-related culling bugs to do with pixel-sized objects that went into Alpha 3.11. People have already noticed that they can now see players over 1000 meters away instead of just a few hundred or so. A lot of bug fixes and improvements were provided for vis-areas, such as a fix for streaming meshes for animated vis-areas and the ability to add vis areas to CGA joints. The entity system received several improvements and optimizations to avoid unnecessary updates and searches. Similarly, the entity aggregate manager received low-level optimizations to improve work balancing and reduce memory use and contention when working with entity bubbles. There were also a few smaller improvements made to the entity component update scheduler. Radix tree culling logic has been improved, with its threading logic adjusted to reduce contention and SIMD culling implemented to check up to four bubbles vs objects per node. With regards to performance, progress continues on the engine profiler, which saw a lot of enhancements. Work on a real-time sampling profiler based on event traces will commence soon. Various optimizations were implemented in the entity system, component updates, and zone system. Based on telemetry from the PU and PTU, we continued our ongoing investigations into memory usage. As such, the engine-wide memory allocator and memory tracking system, including its toolchain, was substantially refactored and improved. To provide an additional performance boost to our servers, the Linux DGS was switched to a monolithic executable to allow the compiler to generate better code (thread local storage access in particular). As part of our initiative to build a performance regression system, we added a stress test for object container streaming too.\nRegarding crash-handling, we now capture a hex stack of the render thread and embed it in mini-dumps that you (optionally) send to us in case the game crashes. This allows us to recover the full render thread call stack during postmortem debugging without the need for third-party binaries (that might be part of call stack or the video driver) to fully unwind the stack. This saves quite a bit of time as we don\u2019t have to download the various drivers that players use.\nOn the animation side, we fixed code so that character blend shapes and the dynamic lighting rig don\u2019t switch too late at every camera cut when rendering cutscenes.\nLastly, C++ 14 support was enabled for the entirety of the client server editor and relevant tool projects.\nOnline Tech\nLoad Balancing Test Framework The pestilence warmer for Alpha 3.12 received major updates. First and foremost, the warmer now uses the new JWT identification system that allows it to fetch many tokens for impersonation purposes very rapidly. This has 10x the throughput of warmer instances we can run at the same time.\nA major subsystem was added that enables the warmer to connect as a service to the diffusion gateway allowing for executing load scenarios that coordinate both as a client connected through the hub and as a service on the diffusion network.\nBackend Concurrency Improvements We were able to increase the performance of the variable service, loadouts, and the main persistence cache service. The stability of the backend increased greatly, surpassing the performance and reliability that we had in previous releases. Our low-level networking code was updated to improve both performance, scalability, and robustness. We also made several fixes and optimizations to the transaction service, rentals, and our entitlement processor.\nUnified and Centralized Logging With our new unified centralized logging system, all services send formatted JSON messages to a centralized Elasticsearch database. Each log event is tagged and dynamic data such as account IDs, player IDs, etc. are extracted into named fields, which makes searching for events or specific fields \u2013 such as an \u201cAccountID\u201d \u2013 very efficient. This allows the devs to easily access logs from a centralized place and track complex messages and events happening between multiple services.\nPersistent Tech\nEntity Creation & Spawn Decoupling In preparation for persistent streaming, the entity creation process was decoupled from entity spawning. This allows us to \u201cseed\u201d the initial state of the universe into the persistent database by creating all dynamic entities prior to simulation. DGS processes will then stream persistent entities (spawn\/despawn) from that database during simulation. This is an important steppingstone for a fully persistent universe.\nParallel Spawn Queues As an optimization, we introduced multiple parallel spawn queues on each game server. This allows us to spawn multiple distinct locations (such as Lorville and New Babbage) in parallel on separate threads on the same server. Previous releases had a single queue and therefore (in this example) we wouldn\u2019t start on New Babbage until Lorville was fully spawned. On busy servers, this can really reduce the wait time in some cases. For example, when spawning waves of AI ships or respawning in a hab.\nNetwork Tech\nTime & De-Syncs How the engine measures the passage of time underwent a complete overhaul. Accuracy was improved both in the measurement of time and in its synchronization between server and clients. How the engine uses time to update its logic and physics simulation was changed to eliminate errors that could result in simulation time passing differently on the server and clients. Many smaller bugs that had caused timing errors to grow on long-running servers were also fixed. The network synchronization of vehicles and physics objects were updated to take full advantage of the improvements. The accumulated result of all these changes was a significant reduction in latency and desynchronization issues in many areas, even under harsh test conditions for network and server performance. Besides improving the overall player experience, this work was a necessary step towards server meshing, where simulating the game across multiple game servers would have made desynchronization issues due to timing errors worse.\nAuthority API In preparation for server meshing, the team performed a sweep on the remaining tasks to convert code to the Authority API. Over the last 12 months, there has been a coordinated effort by all teams to update the game-end engine code to this new system. Thanks to their work, a large majority of these tasks have been completed. With a concerted push, we\u2019ve reduced the number of remaining tasks into single digits.\nConnection Flow In a server mesh, a client may connect to many different servers during a game session. Part of the work towards server meshing requires separating the process of connecting a client to a server into distinct stages. These stages can then be executed independently without requiring a client to completely abandon its existing game session. Significant progress has been made towards this although there is more work to be done.\nMarco Corbetta\nVP of Technology\n\n\nSee you in the \u2018Verse!\nWe believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we\u2019re committed to transparent development and will continue to provide quarterly patch postmortems going forward."},"links_count":0,"comment_count":63,"created_at":"2021-02-15T00:00:00+00:00","created_at_human":"5 years ago"},"meta":{"processed_at":"2026-05-07 20:24:48","valid_relations":["images","links"],"prev_id":17989,"next_id":17992}}