The Vehicle Pillar had a much lighter quarter with Alpha 3.11 compared to the bumper delivery in Alpha 3.10, but what we delivered hopefully had a big impact on the gameplay experience.

The Vehicle Content Team delivered the Origin 100 Series in Alpha 3.11, comprising of the 100i, 125a, and 135c. The 100 Series adds an alternative starter ship to the game as well as a light fighter and light cargo hauler. These are fantastic little ships for new players to start their Star Citizen journey with and provide the ability to tackle a wide range of missions and explore the far reaches of the ‘verse.

The missile and countermeasure gameplay had been in various states over the years and was never truly enjoyable from the aggressor or defender side. We’re aiming to ultimately fix that with Missile Operator Mode, but until that is delivered, we decided to spend the time implementing fixes and iterations to the gameplay to provide a taste of what that feature will deliver. The main issues with the missiles prior to Alpha 3.11 were as follows:

1. Countermeasures would act only on IR missiles (flares) and EM missiles (chaff)
2. Only flares worked (sometimes and highly server-dependant)
3. There were no countermeasures available to spoof CS missiles
4. Firing missiles was extremely easy, defending against missiles was extremely hard

First, we investigated why only flares would work and chaff wouldn’t. The issue was a combination of incorrect setup data in some ships, incorrect data in some countermeasures and missiles, and a now-redundant workaround originally created for a specific SQ42 level that had knock-ons game-wide.

Once we fixed those issues, we recognized that the signature system has two distinct ways of modifying signals – either creating a strong signal or dampening all signals around. We decided to embrace that difference instead of requiring pilots to play “whack-a-mole” by choosing the “right” countermeasure for the “right” missile type whilst under the stress of having a few seconds to decide before impact. With that in mind, we did some playtests with the following changes:

1. Flares would act on all missile types
2. Chaff would be turned into a noise field, dampening all signatures around the field
   

Right away, the first gameplay tests proved that this was a much more engaging way to defend against missiles. We then went ahead and updated the HUD elements of the missile warning system, re-added a countermeasure widget, and updated the keybinds to allow direct launching for each countermeasure type. The UI and VFX teams then jumped in and beautified everything, replacing the effects and also fixing a couple of VFX related bugs (like countermeasures being invisible in the PU).

One future addition that we couldn’t do in time for Alpha 3.11 was to change the names of “flares” and “chaff”. Both names are very common for flight sim communities, but we still want to rename them to make it clear that Star Citizen uses different concepts for defending against missiles. This will require us to record new VO lines to update ship computer voices.

1. Each vehicle is only allowed four locks at a time
2. Only one missile can launch per rack at a time
3. Only one missile type (IR/EM/CS) can launch at a time
4. Missiles lose lock outside of their locking angle
   

Once we had these measures in, the missile experience notably improved in early testing. The spamming of missiles was significantly reduced, and the meta shifted towards ships getting very close to each other and firing missiles at distances where the defender would not even get a missile warning before impact. As a result of this undesirable change, we introduced minimum and maximum lock ranges. This notably stretched the missile gameplay out of gun range, allowing missile-focussed ships to loiter at the edge of combat as designed while dedicated gunfighters would get in closer. This also allowed us to increase the locking angle of smaller missiles so that ships like the Constellation (that do not fire missiles forward but slightly off-angle) were viable to use missiles again.

A lot of these changes (especially to the missiles) are temporary to give a better experience until Missile Operator Mode is ready, which will change the behaviour again and/or remove certain aspects when it is implemented.

The overall goal we want to achieve in the missile gameplay loop is to make both employing missiles and defending against missiles deeper and more rewarding, with its own “slot” in the combat environment. Missiles are not supposed to be an alternative to guns but tactical weapons, and the use of them should be a conscious decision with consequences. We also want to give special missile boats, like the Talon Shrike or Freelancer MIS, an edge when it comes to employing ordnance for the same reason. Those ships will excel in offensive missile gameplay though have obvious drawbacks in other categories. So, there will be more iterations on countermeasures and missile gameplay in the next couple of releases. For the time being though, we’re quite happy the missile experience stepped away from the frustrations of previous releases.

John Crewe
Vehicle Director

For Alpha 3.11, the Graphics Team delivered underlying rendering tech to help power the ‘canvas decal’ system, which leverages the Building Blocks system to create decal textures at runtime. These decals can be used for signposting, on clothing, or even the signage on vehicles. The advantage of the decals being created at runtime is that we can use game data such as the player’s name or even have the content translated to the language the game is being played in.

To make this feature scalable for wider use in the PU, the system is tightly coupled with the texture streaming system, such that the dynamic textures are ‘streamed in’ using the same logic as standard textures, which ensures we always maintain a fixed memory budget. This streaming logic ensures we can automatically run the same feature set on low-spec machines by carefully load-balancing texture resolutions on the fly, but also allows us to push the texture resolution as high as possible on more powerful machines. Integrating the canvas decals into texture streaming resulted in several crashes in the PTU that were very difficult to track down and took a lot of time to resolve. As a result, we wrote some documentation to help future programmers understand the complexities of the texture streaming system, which will be especially important as we plan to generalize the code and use it for mesh streaming too.

On the planet-tech side, we added several features, including improvements to planet tools. This includes new painting brushes, revamped UI, and merged ground layer and object presets to make it even faster to paint planets. Utilising the new planetary painting tools, the Environment Art Team went through all planets and moons in the Stanton System and repainted the ground surfaces and object presets. This also futureproofs us and allows us to take advantage of new tech in existing locations. On a per-object basis, we are now able to support HW tessellation displacement on geology distributed across terrain to give it a more detailed and organic appearance. There were also several ocean and water related improvements, including ground cover buoyancy, which we will continue to expand upon in the future, as there wasn’t enough time during this release cycle to introduce larger floating objects.

A lot of time in the past few months was dedicated towards continued research and development of the atmosphere and cloud renderer, including the planet atmosphere unified raymarcher. We will go into more detail once the system becomes available. For now, let’s just say we worked on various algorithms to allow raymarching at lower-than-screen resolution and denoise and upsample the results to full resolution to improve the performance of costly raymarching operations. These are combined with reprojection techniques and the bundling of raymarch requests for pixels to be updated each frame to further improve performance. Additionally, our existing multiscatter solution now supports a significantly higher number of scattering orders, which will be important for very dense atmospheres. BTW, we’re now in the very early days of volumetric cloud rendering R&D…

Almost a byproduct of this work, we made various improvements to the existing atmosphere rendering technology. First and foremost several long-standing artifacts, such as false color rendering in twilight near the atmosphere top along with very prominent halos around the silhouette of a planet’s dark side, have been addressed. The generation of lookup tables now uses a better-suited method to generate sample locations for numerical integration over (hemi)spheres. That and other numerical precision improvements led to more accurate results in those tables at reduced computational overhead. We didn’t stop there, however, and implemented additional visual improvements for you to hopefully enjoy soon. One of them includes evaluating how much of the sun’s disc is visible when computing how much sunlight reaches point x in-atmosphere. This evaluation is fully integrated into the entire atmosphere lighting system and impacts direct and indirect lighting. Moreover, we added support for an absorption layer. Among other things, this allows us to add an ozone layer to Earth-like planets that emphasizes the blueness of the sky and enables better shading in twilight (removing yellow tint). We now also incorporate IRL extraterrestrial sun radiometry data when running the light simulation instead of assuming a “pure white” light source as well as an approximate conversion from spectral radiance (the result of the atmosphere lighting simulation) to luminance (used to light the scene in a traditional sense). Lastly, we improved the evaluation of sun radiance received by points outside the planet’s atmosphere. It now casts twilight due to atmospheric scattering and the impact of the sun’s angular radius onto objects in a planet’s penumbra region. This should add a nice touch to capital ships or moons orbiting planets.

On the engine side, several improvements were made. We updated our compiler toolchain to VS 2019, which will allow for faster compile and link times. Moreover, we’ve added support for Intel SPMD Program Compiler (ISPC). This will allow us to write target-agnostic SSE optimized code (think HLSL) for heavy duty CPU compute jobs and will fully utilize CPU capabilities on each individual machine that the code runs on. Several code paths in physics, the 3D engine, and the zone system are in the process of being ported. And, we have another compiler optimization in store for you. AVX code generation support for clients was previously enabled and should hit the public servers in the coming Alpha 3.12 release.

Regarding server and client memory usage, we spent a good deal of time further refining our tracking tools to ensure we have good visibility on where we spend memory. We’re now also able to properly track memory usage in third-party libraries that either don’t allow us to reroute memory allocation through our system or haven’t been updated yet to do so. We still plan to get a bit more visibility on client-side video memory allocations on the driver level (below the level we can currently track as an application using the GPU). As a result of these improvements, ongoing investigations, and tracking, a few critical memory leaks were fixed for release.

Throughout Alpha 3.11 production, the Core Engine Team was mostly focused on features for later releases, like the Gen12 Renderer. However, a very large bug was fixed, which caused all our objects on clients to unload way earlier than we intended. Objects on clients should now stay streamed for noticeably larger distances.

For audio tech, we updated the Wwise version to 2019.2.4, which fixed several issues. As part of this endeavour we reworked memory management within the audio system, going from a group of memory pools to a single pool. This allows us to deal more easily with the many different situations that Star Citizen presents by allocating memory where it is needed, when it is needed. We spent a lot of time revisiting our voice budgets to improve the overall experience and to allow players to hear more of what’s going on in the game. Weapon fire support, particularly at long distance, was improved and several issues with audio fire rates and weapon volumes were fixed.

This quarter the UI-Tech team has been working on a system called the Canvas Slicer. This is a sub-system of Building Blocks which will allow the UI designers to place slices of 2D UI in 3D space. Normally, when we draw 2D UI, it gets rendered to a texture and then that texture is applied to geometry such as a monitor panel or data-pad. With the Canvas Slicer, we create the geometry at any position in 3D-space at runtime and draw the 2D UI directly onto it. This means we will be able to produce interesting layered UI, such as holographic ship HUDs and helmet displays.

We have also started designing our tooltips system for Building Blocks. On the surface, this looked like a simple system to implement but the requirements to ensure it is super flexible have meant we’ve got quite a lot to think about before we start implementation.

External Inventory is the first iteration of our grid-based inventory interface that allows players to manage their FPS commodities between their backpack, chest, and leg pockets. As it says in the name, the External Inventory also allows players to directly interact with other storage containers in the world and drag and drop items between them. In Alpha 3.11, this is only enabled for the Greycat ROC storage compartment so players can manage their FPS mineables. But, in the future and once we realise true item storage (underpinned by iCache), this will allow players to store items in compartments, crates, and other such external inventories.

While on the face of it, a new inventory UI and being able to drag and drop items between storage containers may sound simple, we had to overcome several creative and technical challenges. The main creative challenges revolved around having an interface that felt tactile and accessible to use without just feeling like a standard 2D interface that you see in most RPGs. This wasn’t because those inventories are bad, more that we didn’t want players performing inventory Tetris to manage their items; we wanted players to freely move items between storage containers without having to worry about where they dropped the item or if another item was in the way. We were able to achieve the first iteration of this using our Building Blocks technology, which stores the items as a list rather than a 2D grid. This means items fluidly move around your cursor as you drag objects between containers. We still want to further improve on the overall feel, but the team is happy with the initial outing.

While Building Blocks allowed us to deliver on the creative aspects of the design, it also provided the main technical challenge. As the technology is still being developed, it means it doesn’t always support things that you need to deliver a feature. In the case of External Inventory, we wanted the UI to feel diegetic and 3D even though it is not. This meant we wanted all the icons to be holographic, like they were being displayed in AR directly in front of your eyes. Unfortunately, our 3D icons could only support a limited shader which meant we lost a lot of material detail from the items being displayed. At this point we could have delayed the feature, but the team and I felt it was important for us to go live and get as much feedback as we could between now and a true physical inventory. We will definitely be upgrading that shader in an upcoming patch.

At its core, Force Reactions is a system developed to simulate what a character would do when impacted by a force, whether that is a strong gust of wind or a bullet penetrating their shoulder. It can be split into three levels of impacts:

• Low impact: twitches, flinches, and leans
• Medium impact: staggers
• High impact: knockdowns

Throwing grenades or other objects has always been a bit inconsistent and is even more disappointing when you think you have that perfect multi-kill opportunity for the grenade to just whimper a few feet from you. So, the first thing we wanted to achieve with T1 was to make throwing much more reliable, so that the object you throw (whether a grenade or other object) goes where you expect it to go. The second biggest objective, which is a critical pre-requisite for the physical inventory, was for the throw system to be able to interact and co-exist with the carriable system.

In Alpha 3.10, if you picked up a grenade from the floor and then tried to throw it, there was no way for you to pull the pin. Also, if you pressed the ‘Throw Grenade’ hotkey, you would drop the grenade in your hand and pull a new one from your suit. Obviously, this is not the intended behaviour and was a major reason why we changed throwing to come from an equipped state (i.e. holding the grenade in your hand) rather than directly from your suit. This system will also allow us to deliver gadgets and deployables in the future.

As part of T1, we also added a UI ‘throw arc’ that allows you to see the trajectory of the grenade. While currently this is enabled for all helmets, it will only be accessible from combat helmets once we start to define different armor archetypes in the ‘verse.

Ever since I have been directing weapons, we have been trying to make sure that every weapon we add to the game has a unique purpose or playstyle that it suits. Currently, we already have several live shotguns that are deadly when up-close-and-personal but ineffective beyond that. With Behring being a manufacturer that we have identified as being middle of the road when it comes to damage, fire rate, and accuracy, we felt the BR2 was our first opportunity to push the range out for a shotgun to provide a bit more oomph in mid-quarter combat without it dominating at close-quarters. While we were happy with the BR2, we are not necessarily happy with shotguns as an overall class as they are outgunned by SMGs and outranged by assault rifles. We will be doing an update to all the shotguns in an upcoming patch to give them greater identity.

The Behring grenade launcher on the other hand presented entirely different problems. A 40mm grenade in real life has a kill radius of about 5m with a casualty radius of about 15m. These are big numbers when you look at our interior spaces and, considering that you can fire several of these over a short space of time, you are left with a pretty powerful weapon. On the one hand we wanted to deliver a weapon that felt heavy and designed to rain down destruction, but on the other hand we didn’t want to massively wreck the balance of FPS combat.

With that aim, we made sure the numbers were slightly less than that of a normal frag grenade for both kill and injury radius. But if I’m being totally honest, I would say the grenade launcher is slightly too powerful in the current game. The main reason is that players have access to an infinite amount of ammo using the PMA, so we had to choose between releasing the weapon as intended or massively nerfing it until the physical inventory comes online. As a team we felt it was more representative of an experience to release the weapon as it’s supposed to work and wait for the other systems, such as physical inventory and physical damage, to balance out its sheer power. Then, players will have to consider how much space they allocate to ammunition and physical damage will cause weapons and armor to lose integrity when they are hit. This means if someone gets blown up by an explosion, a lot of their equipment will be damaged, which lowers the overall value. I have also seen the feedback regarding arming distance and it’s something that we will be working on.

If I look back across all the features that the Core Gameplay Pillar delivered for Alpha 3.11, I am happy with the results. However, this doesn’t mean everything went well or if I had that time again, I would do everything the same.

The main thing I think I would change would be how we implemented Force Reactions in the ships. Rather than treat it the same as all the other forces in the game (wind, bullets, etc) – which on the face of it makes sense – I would have designed it specifically around the gravity generator inside the ships. Currently we take the force that is applied to the ship and then directly apply it to the actor through filters depending on the force so that they react accordingly. Instead, I would have rather had the gravity itself react to the force, which would then cause the actor to react. While there would be no difference to the player, I think it would have been a cleaner implementation and be easier to extend the system in the future. For example, when we add gravity generator items, etc.

In the last two quarters we have also delivered two features (Body Dragging and Knockdowns) that would have really benefited from driven ragdoll. Unfortunately, that feature is not being delivered by someone on my teams, so I wouldn’t have necessarily been able to change anything. But looking back, I would have raised more visibility on the benefits of trying to push that feature forward. That is obviously a challenge with working on a 600-person team that is spread across multiple continents and has different priorities across multiple projects. Everyone is trying to deliver the best features/content/tech that they can to the highest possible quality and sometimes the stars don’t align when it comes to priorities. In this case, it is purely on my shoulders due to a lack of communication. As developers, we don’t always get it right when we’re in the thick of things, but hopefully this gives some insight into our processes and how we are always giving it 100% to try and create the best experiences for you to enjoy.

For this release we were able to introduce the next step in adding complexity to our space stations. The idea for the major stations located around planets is that they would be more than just rest stops; they would have their own facilities dedicated to other services, like cargo.

For the exterior, we introduced new addon components that describe the infrastructure and large racks of containers implying the capacity of the location (which right now is purely visual, in the future we would like to include more interactive elements).

Inside, we wanted to expand the traversal routes. For this, we introduced the idea of a station having a main transit network that connects the various elements of the station together – commercial decks, cargo decks, etc.

For the interior of the cargo deck, there were a few elements we wanted to include. Firstly, for the hub area we wanted to describe a themed logistical experience for the player. This includes a section of a shipping warehouse that, in the future, will be a sandbox for mission content. For the main shopping space, we wanted to incorporate a few elements into one larger shop. Now we can see the cargo drop-off and pickup counter located within a mini logistic sorting office, the ship rental space is located off to the side, and the guild and supplies area is in the corner. Overall, this gives a more diverse experience for the player rather than separating all these elements into separate stores..

For this quarter we were able to keep momentum in updating the planets and moons in the Stanton System with the latest tools and tech we’re using to build out the Pyro System. The start of this was doing a global repainting pass to all planets and moons. Fundamentally, this painting process drives a lot of the latest features in how we’re unifying objects, so to get this into the game we needed to bite the bullet and do the first pass over everything. In the last patch, we introduced the new heightmaps, and now the new painting pass will take advantage of all this new data.

The second element we were able to introduce was a global improvement to all our geology packs. We now have the ability to specify terrain colour pickup for assets which will enable them to procedurally match the colour of the terrain or bedrock. Also, we were able to add asset tessellation and displacement on a per-object basis, which means we can assign heightmaps to assets that drive the displacement parameters. In a nutshell, this means when the player gets close to an asset it should be considerably higher in geometry resolution, giving a complex silhouette read.

Lastly, we replaced all of our terrain shaders with scanned data. This is something we’ve been looking into for some time as the quality of the results was extremely high, but with some of the latest tech, we were able to implement it into our pipeline. We recreated over 70 base shaders by combining and mixing the scanned data together to get the results we wanted. In the future, we have ambitions to set up dedicated scanning equipment to process our own data, which we’ll gather from field trips. We want to ensure we can create a diverse and wonderful palette for future Star Citizen locations.

We were able to introduce a lot of new tech in this release, as well as start to show the second round of polish updates on the planet surfaces. Also, with the introduction of scanned data for our surfaces, we saw a substantial jump in quality. However, some of the global painting passes were not as detailed and involved as we would have liked. This is mainly due to time restraints in the quarter. Some of the geology surfacing with the new libraries could be more appropriate to the biome/region also.

For cargo decks, we should have foreseen the disconnect between the interior and exterior when separating out the commercial decks. To improve the experience and help give context to the player we would like this transit network to be physicalized in the future. This will provide visibility out from the transit cab to the exterior of the station as it moves towards its destination.

The Armistice Zone relaxations are the first step in removing all arbitrary restrictions from the game, as and when we have the capability to properly defend and police the various areas of the game. This was possible at the rest stops because as well as reusing the existing size-4 turrets and size-6 sentries, we created an all-new size-10 turret. Together, these are capable of dealing with any ship planned to be in the game. And rather than impose yet another arbitrary restriction, we made the defenses fully destructible, though their respawn time is very swift at 5 minutes. This respawn system will be developed further in the future to likely rely on repair.

In concert with the defenses, we added the first iteration of a security response system which, while still quite simplistic, adds up the CrimeStats of all players in the area (known internally as “heat”) and spawns security ships of increasing numbers and strength in response. The system responds quickly to increases in an area’s heat by spawning in new ships and despawning out weaker ships they replace. The system responds slower to the killing of its members (should the heat not be raised by this) and slower still to decreases in heat. We will develop this system further in the future to also take into account the ships that players are using and the aggression shown.

We will roll this out across other locations like outposts, though Grim HEX will need a more complex solution as the defenses there should only respond to crimes committed in its jurisdiction and not in others. Olisar will remain an aberration as it is a legacy location that cannot support an Armistice Zone of the radius required.

The Live Team had to be extremely vigilant and quick to react to issues given the short time that Alpha 3.11 was running in the PTU. One example of an issue we noticed was players stealing the sentries by swallowing them in the cargo bay of their 890 Jumps and flying off with them. We rectified this by self-destructing sentries taken away from the area and respawning them. Another example is that while the security response was capable of quickly spawning ships on local severs, on a live server it was not. To try and improve this we reduced the thresholds that the system responded to in order to reduce the number of spawns requested.

We have seen videos of many players teaming up to overrun a rest stop and hold it for a long time despite the defenses and security response. Because of this, the moment the Idris became available, we added it to the top level of the response system, so we’re hopeful that those players would struggle to replicate this in the not too distant future.

Moving forward, we also plan to relax the arbitrary limitations found in interiors, again starting at the rest stops. We are already well underway with a spawn closet system that will allow us to spawn the guards necessary to police the area. As well as this, we are working on a security network that will know whether players have the right to be in certain areas and enable cameras, turrets, and guards to respond to trespassers, those with CrimeStats, or those in the process of committing crimes.