On April 22, 2021, we launched Alpha 3.13: Underground Infamy, which introduced a number of new features and changes, including ship-to-ship docking, additional cave entrances, and the Reputation Manager. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. As a side note, this postmortem focuses on both the Alpha 3.13 patch and the Invictus Launch Week event.
Vehicle Pillar
John Crewe, Vehicle Director
For Star Citizen Alpha 3.13, the Vehicle Pillar delivered a mixture of new features, the groundwork for future initiatives, and our usual content drop.
Merlin/Constellation Docking
What went well?
We successfully delivered a long-awaited feature to one of Star Citizen’s most iconic ships. Although we had aimed to do this in Alpha 3.12, the decision to spend an extra quarter polishing it paid dividends upon release as it was much more stable and expansive than originally planned.
What didn’t go so well?
The decision to delay XenoThreat into 2021 meant we were caught up longer than expected in bug fixing for the event, which reduced our ability to react to issues with the feature before it went to Evocati for testing.
What we’ll do differently in the future
Generally, the feature process went well, so aside from more testing sooner, there isn’t a huge amount we’ll improve on in the future.
Vehicle Names/Serials
What went well?
The ability to personalize your ship has been a long-requested feature, and it’s something we’ve wanted to deliver for a long time, but we’ve had a few behind-the-scenes technical issues we had to solve regarding the rendering and platform-to-game entitlement flow. The delivery for a small selection of ships proved out the tech and helped us better understand the limitations of the system.
What didn’t go so well?
By far the biggest issue was readability, particularly for shorter names where the font size stayed the same as a maximum-length 32-character name. A short name combined with less-than-ideal exterior ship lighting and the inability to customize text color lead to some major readability problems.
What we’ll do differently in the future
We’re working with the Graphics and UI teams on better implementation via Building Blocks to allow us to dynamically change the font size based on the input string length. An optimized UV layout will be created to accommodate this. The paint system will also have work done in the future to allow players to pick the name color to avoid clashing.
Hull Visual Degradation
What went well?
Since Star Citizen Alpha 3.6 when we introduced item degradation and misfires, the big part missing was having your ship’s hull visually degrade alongside the other items. Now we’ve completed this, you get a much-improved read on the state of your ship based on the hull’s visuals rather than having to go MFD hunting. The system ties into our existing production pipeline for vehicles so we didn’t have to go back and add it to any ships, making the implementation much quicker.
What didn’t go so well?
There were quite a few ships that were missed in our internal testing sweeps, leading to the canopy entirely ‘scratching’ over, blocking the view. This was not our intention - restricting wear to the edge of the view was the goal.
While the actual content side has been part of our pipeline, it wasn’t easily visualized, so the Content Team have to go back and manually adjust the wear maps and settings on older ships.
What we’ll do differently in the future
As mentioned, a few ships are dramatically wearing too much in key areas, which will be fixed case-by-case. In the future, with physical damage, this will move from being a purely visual feature to it having structural and gameplay consequences.
Ship-to-Station Docking
While officially not part of the Alpha 3.13 release, we did in fact launch this feature with the patch, albeit disabled ready to come online with 3.13.1 (Invictus Launch Week). We had originally aimed to deliver both features in the same patch but made the decision to officially hold it back, much for the same reasons we held back Connie/Merlin docking - to improve the quality of the release.
Tumbril Cyclone MT
The Cyclone MT was a surprise straight-to-release vehicle that we worked on during downtime between releases that helped expand our ground vehicle line up, particularly for Theaters of War.
The challenge of having a mounted turret controlling both missiles and weapons caused some head scratching in the setup phase, but the MT provides an interesting firepower addition to the Cyclone lineup at the expense of being the slowest in the family.
Greycat ROC-DS
The ROC-DS was a vehicle that struggled both through its development and public release, having originally been designed to be the primary vehicle in the family. However, due to production timelines, we had to release the ROC well in advance of the ROC-DS. The original aim was to have them both release together to provide clearer options for players but having the significant time gap between them just increased the perception issues surrounding its role and usefulness.
While it did get some hefty upgrades during the Evocati and PTU phases increasing both its capacity and range, these goals were not communicated well enough at the start of the release cycle, leaving it to suffer more than expected. The ROC-DS was never supposed to be a clear upgrade from the ROC; it’s a companion allowing two players to work together in more demanding locations further away from base.
It currently sits in a poor position, however future changes to inventory behavior, the cargo system, and cave setups will perhaps let it regain the position we had intended for it. If it doesn’t, we’ll investigate further changes to improve its reception.
Live Pillar
Todd Papy, Star Citizen Live Director
EUPU: Mining Sub-Components
What went well?
We continued to add depth and expand on the mining gameplay and got the sub-components up and running fairly smoothly. The Quality Assurance Test Request (QATR) process went well too, with great communication among the team
What didn’t go so well?
Game-dev stability was poor, which caused delays in getting up-to-date builds with integrations.
What we’ll do differently in the future
The team is creating QATRs to integrate their work to game dev as a usual process. Unfortunately, QA were super busy with the Alpha 3.13 and 3.13.1 releases, both of which were big ones. This is currently affecting the efficiency of the QATR process, leading to sprint integrations of non-upcoming releases being heavily delayed.
Live Mission Content: Quantum-Sensitive Deliveries & Timed Multi-Drop Deliveries
What went well?
It went smoothly because it was using existing tech, a lot of which was created for the XenoThreat mission.
What didn’t go so well?
Some of the boxes didn't behave as expected, which ended up being an issue with the entity behavior. The timers were not showing the correct time and the box would explode with two mins left.
Hurston isn't the best location for long-flight missions because of the location distribution. We did increase the payout but will look at continued refinements.
What we’ll do differently in the future
We need to improve the handoff of the entity behaviors and clear up responsibility between the teams.
Core Gameplay Pillar
Richard Tyrer, S42 FPS Game Director
Mounted Guns
What went well?
Star Citizen by its very nature is a mixed arms game combining on-foot, vehicle, and ship combat. Mounted guns slot directly into that trifecta by allowing on-foot players to challenge vehicles and smaller ships. We already have the Animus missile launcher and Scourge railgun, but they only provide a small amount of resistance before you would run out of ammo. With the long-term intention of homesteads and outposts, we wanted to provide the player and AI with additional options for defending these areas.
We faced two main challenges with the mounted gun: its size and the control scheme. The eagle-eyed among you will probably have noticed that the mounted gun is a Size 1 ship weapon as we needed that sort of firepower. While these are small on a ship, they are huge in the players’ hands, and this provided us with several issues. Firstly, it took up the whole screen in first-person, so the line of sight was terrible and, secondly, the pivot point for ship weapons was not ideal for a character trying to aim down the sights and pivot vertically. As we already had a ship weapon, we were able to get it into the editor quickly, and this allowed us to iterate on the first-person experience very early on without having to worry too much about metrics. This was a real boon as we were able to work out the pivot of the weapon, its viewing angles, and ADS views while still retaining a believability that this was a weapon that could take down a ship.
The other challenge we faced was the control scheme. We debated for a long time over whether we should use a more FPS-centric control scheme or have something more akin to a ship turret. Fortunately, we had scheduled enough time for us to implement both schemes and play them to see which felt the best. This allowed us to hone in on the experience and deliver a good first iteration. We have also planned long-term to try and add the additional control options to the menu screens so players can choose which they prefer.
What didn’t go so well?
Using a pre-existing ship weapon allowed us to iterate early on and dial in the metrics without having to create a whole suite of new art. This also had the advantage that, going forward, any Size 1 ship weapon could theoretically be mounted onto a mount. Unfortunately, this didn’t go as smoothly as we hoped, because ship weapons mount from the top rather than the bottom. This meant that the weapon was mounted upside down and had lots of additional geometry that blocked the main view. While this is a relatively easy fix, it does mean that any new weapon we want to use in the future will require further art tweaks and additional data to support it.
What we’ll do differently in the future
Mounted guns are a feature that requires a content team to implement it into the ‘verse (it’s not a systemic feature like jump or actor status). While we always want to get features into the hands of players as soon as possible for testing purposes, I think its current implementation in the PU doesn’t really serve a purpose. In hindsight, I think it would have been better to implement it, ask for specific PTU/Evocati feedback, and then release it in a later patch once the content teams had had enough chance to build something around it.
Trolley Push/Pull
What went well?
Trolley Push/Pull is a feature that allows players to interact with an object, such as a trolley or block, and push or pull it in the direction of their choosing (providing they have grip). As Star Citizen is a sandbox game that has multiple gravities and planets, we needed to make sure the feature was systemic so that it could work and scale with different weights and environments. We also wanted the trolley to feel physically correct, with heavier loads being harder to control. The team worked directly with the physics programmers in delivering a physically correct model that really feels like you are pushing a trolley or block. The character leans into heavier loads and the controls feel weighty and grounded.
What didn’t go so well?
The team were highly focused on making sure the trolley felt grounded in the world and they built an elaborate test map that tested multiple facets of the feature including loading onto a ship. This highlighted a significant problem. A lot of the trolleys built over the years had been designed to a character metric with relatively small wheels. Unfortunately, the ships all have different ramps, with some having very hard angular edges and others not lowering to touch the floor at all. This meant that a lot of the trolleys struggled to go up ship ramps and, in some cases, could not get over the edge of the ramp as it was too large (think trying to push a shopping trolley up a curb). As the Vehicle Team was already scheduled for the quarter, we were not able to deliver the full trolley experience.
What we’ll do differently in the future
Trolley Push/Pull was always designed to serve two purposes: a puzzle mechanic and for cargo loading. As a puzzle mechanic, the feature works well and allows the designers to start creating new and interesting missions/spaces where players can use trolleys and blocks to access higher vantage points. As a cargo-loading mechanic, it falls short due to the limitations of the wheels and the sizes of ship ramps. Going forward, we will be developing a hover trolley that will alleviate a lot of our issues and rely on the more traditional trolleys for landing zones and specific missions.
Systemic Gameplay & Services
Tony Zurovec, PU Game Director
Reputation UI
What went well?
For Alpha 3.13, we were able to release the Reputation UI, giving players a visual representation and context for our initial T0 release of the Reputation System in Q4 2020. For that release, we had hooked up reputation to the bounty hunting missions (and a few others), but players had zero visibility on why their mission progression changed. We have also instituted the first pass of rewarding players based on their reputation progress. With the UI now in place, players have much more clarity on their status with both organizations and mission givers.
The overall development and release for this feature went smoothly for the team. The analytics reports we received showed incredibly positive results with players in the Alpha 3.13 release, which resulted in a higher engagement rate of the bounty hunting missions.
What didn’t go so well?
There was an unexpected hiccup with some changes to the Reputation Service that were not communicated well to the Feature Team. This resulted in a few urgent fixes that needed to be done awfully close to Alpha 3.13’s release.
Additionally, we have not converted the entirety of our mission content over to the new system yet, nor have we had time to refactor the mission giver behaviors to be as reactive to the Affinity and Reliability meters. While this is an ongoing effort, and players should look for continued progress, this will unfortunately take time to churn through the entirety of our missions and refactor the mission-giver behaviors.
What we’ll do differently in the future?
We’ll be aiming to improve our global communication on features going forward, notably for any that involve services or external feature team support. Cross-team initiatives have consistently proven to have some level of communication breakdown due to our global distribution, so we’re always looking for ways to improve this pipeline. Specifically, we are trying to create more technical design documents (TDD) prior to starting these larger initiatives. This should help create global awareness since all applicable groups are required to provide feedback on the TDDs during this process.
Also, with the system now in place and our second star system on the horizon once server meshing comes online, we are having ongoing design discussions about how we will structure organizations within the universe for the first five systems. These talks include everything from the new-player experience and their starting location, how players progress within a single system, and how major organizations will influence content across multiple systems. This also allows us to define what gameplay will be involved for each of the major mission types, with the current plan to associate each mission type with the reputation tracks within organizations. Throughout this process, we have made significant strides towards (what we feel) will be the initial version/vision of how this major progression mechanic will affect the overall player experience. While we still need to get final signoff, we feel this falls in line with how reputation has been previously pitched to the public and look forward to driving this forward.
Invictus Launch Week
What went well?
The expo event associated with Invictus Launch Week went very smoothly. This is a process that we’ve done multiple times to date, so setting up a new expo event is a known quantity.
On the other side of the spectrum, the USPU Team did help to get some additional features out with Invictus that expand our Dynamic Mission Service toolbox. This was the first time we have been able to change the inventory of a shop dynamically based on in-game events (something we refer to as Dynamic Shop Modifiers). This will ultimately be tied/controlled by the Quanta tooling that you may have seen us discuss in our most recent video presentation. We can also use it to not only add new event-specific items, but we can also change whether a shop consumes or replenishes these commodities, which ultimately changes the overall price of the item. These changes are for a limited time during the event, so it allows us to change the economic climate of as many shops as we like to achieve the desired results.
We also added something related to this that will eventually help us expand the cargo profession. We call them “Price Threshold Triggers.” These are intended to allow us to trigger missions based on the shop inventories hitting designated levels. However, as a first step towards the creation of missions, we used it to give the players valuable insight into what is currently in demand (to purchase or to sell) at a given location for the duration of the event. This was temporarily done via the journal entries that are generated by the mission system. Now that these are in, the next step will be to send out game-wide requests (any distance we choose across a solar system or between systems) as we move towards a Quanta-driven universe. While the work towards visualizing the shop info within the journal is a temporary solution, all of the underlying functionality is implemented as intended, so there will be very little throw away work once we redo the mission manager UI or add some level of economy info elsewhere within the game (the timeframe on that addition is still TBD).
Finally, with all that said, the players enjoyed the fact that the shops were exposing items and/or changing the prices dynamically during the event. We are looking forward to expanding on this system as it is really one of the major underpinnings of the economic and cargo systems.
What didn’t go so well?
We had some changes to the ships’ landing gear system that caused irregularities with their default/spawned compression values. This ultimately caused a lot of tedious testing on our side to ensure that everything was placed as intended so that we could confirm that anything we DID see was a legitimate problem and not just a placement problem.
For Dynamic Shop Modifiers, the biggest stressor was that some of the functionality came in quite late in the process, which left very little time for testing the feature in the PTU. Had this feature not worked very well when we finally did get it, this would have been a larger problem. The Ninetails Lockdown event (supposed to go out with Alpha 3.13, then Invictus, and now ultimately Alpha 3.14), was also competing for QA bandwidth during this time, which was one of the main reasons it was pushed to Alpha 3.14. With the priority needing to stay on Invictus, we had no choice but to sacrifice Ninetails as a result, which was a letdown internally.
The workflow for setting up the shop modifiers and the price threshold triggers was also not conducive to making largescale changes quickly. Additionally, it is currently a bit confusing because, historically, we use the context of ‘buy’ and ‘sell’ from the perspective of the player, but this was somehow reversed in the context of threshold triggers. This obviously leads to a lot of confusion when setting these up and absolutely needs to be fixed before going wide with this feature.
Additionally, while tuning the threshold triggers, we had a strong desire to change shop entries that we didn’t have the ability to edit from the shop modifier UI within Subsumption, including base price offset, current inventory, and a couple of others. We hacked around this by adding items to the inventory to set them up, THEN changing their context from buy to sell when commodities were available to be gathered/purchased elsewhere within the universe. While this is a common tactic for designers when tools don’t do what they want, it’s generally frowned upon because it’s ultimately adding debt that you need to go back and fix later.
What we’ll do differently in the future
I would like to get additional debugging into the engine that would allow us to quickly debug the landing gear compression discrepancies. To this point though, we’ve already added some new debugging methods into the game since our last expo event. However, these discrepancies could potentially be easier to spot with additional debugging feedback. As we approach the next expo event, I would like to dedicate time to ensuring these issues are easily identified and are easily solved by data-driven solutions.
We would like to see some better coordination between QA and the dev teams that require larger-scale QA involvement, such as Invictus and Ninetails. We’ve certainly seen and acknowledged several of the pain points that this has caused, but this will continue to come up as we make more of these events, so we will need to tighten up this workflow moving forward. Ideally, we would try and get the delivery of all gameplay features and related services well in advance of any potential delivery date. For example, well before we branch the next release stream and certainly before going to the PTU. I would also like to see less feature development in the release stream as we move forward.
While this still needs to be scheduled, I would like to see the UI presentation of the journal entries cleaned up in any future revisions, as they relate to commodities that are in demand. It needs to order them by landing zone and then, within each landing zone, show things you can buy and what you can sell. The ideal solution is to have some type of economic info available someplace like the star map, or a separate app, but as mentioned above, this work currently needs to be scheduled so any additions are TBD.
Mission Features
What went well?
XenoThreat and Fleet Week were two major events worked on by the Mission Feature Team in the first quarter of 2021. The collaboration between us and other departments on both initiatives, especially QA, was stronger than it has ever been previously, and we think you can see that in the finished product.
XenoThreat needed a bit more time to balance and iron out the remaining bugs and thankfully we were allowed that time, even though the initial expectation was that it would be released for the holiday season.
Luckily, we were able to add content to the caves. This was not even on our planned deliverables list for the quarter, but it seemed a shame to release new cave entrances without something present there. We also added a lot more mission locations in the Yela asteroid ring.
Our team was able to add a new debug GUI, which is now proving invaluable for identifying issues at a far more rapid pace. And the creation of new delivery missions went quickly and smoothly, notably due to well-established mission modules and the reuse of entities from XenoThreat.
What didn’t go so well?
XenoThreat, as mentioned, didn’t hit its intended release date. This was obviously unfortunate but, given the scope of what we were trying to achieve with the event, we felt this was understandable and thankfully we were able to give it the proper amount of time to further polish it until it was ready.
Creating and maintaining unique entities was also an issue. For example, the quantum-travel-sensitive boxes were a mixture of several teams' work, so when it comes to bugs it was often difficult to get traction. Continued maintenance of these could now also be an issue as there isn't really a defined developer to own and sustain them.
Parasite ships also caused issues for the law system that weren’t spotted until after the initial release of Alpha 3.13.
What we’ll do differently in the future
We’ll aim to push for the team to be included on any feature that may affect or require support from the law system to try, and get ahead of, and hopefully minimize, any unforeseen issues for future initiatives.
Systemic Services & Tools
What went well?
Additional resources from the backend teams provided immediate relief for workload for the Systemic Services & Tools (SST) Team. The SuperCache was deployed and work was able to start on several longer-term initiatives to integrate Quantum into more services. The public presentation came together well and was received very positively. The technology that we invested into presentation displays will be used to demonstrate other high-level concepts in the future.
Quasar was deployed, which is the dynamic mission tool demonstrated during the SST update video released in April. Development of Quasar was straightforward due to the previous work done with Odin last year, which tackled most of the foundational work required to hook into live services and DGS instances. Going forward, the Quasar tool will provide a platform through which dynamic mission content can be instantiated via Quantum.
Work on the ATC service continued, and SST spent time developing a standalone object container decompressor to allow the injection of specific data points to assets without needing to manually re-export each object container through the editor. This work will unlock several other critical areas for data manipulation required for future SST projects.
What didn’t go so well?
A new high-speed AI service was needed to map live positions of mission-spawned NPCs, which ended up being deceptively complex. This new service required work from various teams and pillars, which caused delays and difficulties in testing. Many of our team resources continue to be absorbed addressing bugs that don’t end up being in our sphere of responsibility.
What we’ll do differently in the future
Future presentations will be significantly more straightforward in terms of the content we demonstrate, and we invested in visualization tools to be able to show high-level concepts on the Starmap quickly and easily.
We identified issues causing delays on new services like the high-speed AI service and are now more capable of dealing with cross-team initiatives like this going forward. With the groundwork of Quantum laid, we will be able to focus on the integration of other services.
We’re now better able to identify issues that don’t fall under the responsibility of our team and plan to re-route these issues to the appropriate teams, saving our team members much-needed time to develop services work.
Locations
Ian Leyland, Star Citizen Art Director
When went well?
Invictus Launch Week at the Tobin Convention Centre was fantastic to see, as were the new space-station docking modules and military docks for the event. Outside of what we released in Alpha 3.13, it allowed the team to focus on making solid progress on future locations for the game.
What didn’t go so well?
The docking feature caused some back and forth among the various teams involved, reducing efficiency. The trolley push/pull feature created a lot of bugs for the teams that could have been reduced too.
What we’ll do differently in the future
Internally, we follow a process of features and locations having a ‘go/no go.’ With regards to a feature like docking, the teams were very compressed in building the feature and creating the locations at the same time. In the future, to reduce the inefficiency this creates, we will look to have more of a buffer between a feature being made and the location being made that utilizes it.