The Vehicle Pillar consists of five teams, all of which had a field day with Alpha 3.10, releasing no less than seven features, making it one of our most impactful deliveries yet.

In summary, the key features the pillar worked on were:

• Thruster Efficiency Curves & Aerodynamics
• Turret & Gunnery Improvements
• New Targeting Methodology
• Ship HUD Rework
• Restricted Area Rework
• High-Speed Combat

Greycat Industrial ROC & Gathering Beam

I’ll go into detail for each of these features (some of which contain multiple smaller elements not shown on the roadmap) and break down what we did, what went well, what didn’t, and how we can improve in the future.

Players who have been with us for a while will remember ‘Hover Mode’, a concept we trialled back in Alpha 3.6 to try and make ships look and feel more believable in atmospheric flight by pushing them towards ‘helicopter-style’ handling. Ultimately, we didn’t pursue the idea beyond the initial release due to it causing handling quirks and confusing players when their ships automatically switched control modes.

Thruster Efficiency Curves were designed as an alternative to this by reducing the maximum amount of thruster available based on atmospheric density, in turn reducing the agility of ships the closer to the ground they are. Alongside this, we also introduced aerodynamic surfaces to ships so that they behave more akin to traditional aeroplanes with lifting surfaces.

Compared to some of the other features in Alpha 3.10, the release of these features was relatively smooth, with time scheduled in to react to any feedback from Evocati and PTU testing. The team pushed out multiple updates and tweaks to ship handling during those periods as bugs were found with specific ship setups.

The rollout of this feature required a significant time investment from both the Vehicle Feature Team (VFT) and Vehicle Experience Team (VET) due to the nature of simply having to redo the balance and tuning of the 120+ vehicles currently flyable in the PU alongside those in Squadron 42. So, it was only natural a few slipped into the early Evocati stages with a few issues (looking at you Hornet with your wings on backwards…).

As a feature, we’re happy with how the initial release went out and there are minimal plans for the future from the VFT side, with the exception of ongoing flight balance and tweaks to ship handling as needed. The sole remaining item left is to add input-driven control surfaces, such as elevators and ailerons, to add both visual and physical handling changes. The VFX Team is also looking at ways to improve the visuals of thrusters to make it clear they are in use when viewed from a distance. This will prevent ships from appearing in odd-looking positions, even with all the recent changes.

One of the persistent questions we had during development was, “Why should I have a player in my turret when it would be more effective for them to bring along a second ship?” With Alpha 3.10, we aimed to answer that once and for all. With a slew of improvements and a heavily rewritten codebase, turrets are now an extremely lethal option when manned and provide a force multiplier for the ship.

With a combination of work from the VET and VFT providing a new HUD for turrets, the overall experience has been improved from every measurable angle. The second side to this was leveraging some of the improvements applied to turrets and applying them to fixed weapons, which had fallen significantly behind in usage versus gimbals and auto-gimbals.

Early testing showed the promise of the vJoy-based movement method combined with fixed assist. However, this resulted in turrets becoming truly overpowered and we had to dial back some of the settings for the initial release. We hit a few challenges with the variety of turret setups in the game, in particular inverted turrets, which required additional work to make them behave as expected.

Remote turrets, such as the Super Hornet’s second seat, also benefitted from the changes but we found a few other issues regarding the synchronisation of projectiles that we’ll further improve in future patches.

Fixed weapons have once again returned to the top of the pecking order with these changes, showing a significant increase in lethality since Alpha 3.9.

The goal for New Targeting Methodology was to simplify the process of selecting targets along with cleaning up the onscreen ‘clutter’ that had increased over multiple releases. Of all the features that the Vehicle Pillar worked on for Alpha 3.10, this was the one that caused the most problems for a variety of reasons.

Ultimately, we feel the system released in Alpha 3.10.0 (and had minor updates in 3.10.1) provides a better solution to targeting objects. However, the path to that was particularly difficult and intense, with lots of feedback coming in from the Evocati phase that caused us to significantly deviate from the initial plan.

The core goal was to move the system back towards how it was in early Wing Commander games, where players could simply target and lock threats with two inputs. This would also allow us to remove the sea of triangles that were becoming a common sight in Star Citizen. Initial prototypes highlighted issues with a lack of situational awareness but, with the benefit of internal foresight alongside repeated exposure to the system, we could see this would be improved by the upcoming changes to 3D vehicle radar displays.

Other options we trialed during development included essentially splitting the targeting into four separate states:

• Select – Target is highlighted but has no gunnery information. Selection is lost when offscreen
• Marked – Target is stored in a list for later selection, regardless of position
• Locked – Target has gunnery information and is not lost when offscreen
• Pinned – Target is stored in a list with information and shared with the crew
  

Ultimately, we found the Marked state to be an unnecessary step in the initial implementation; while it could be useful down the line with multi-crew roles, it hampered usability in the short-term. The initial push to Evocati went with the other three states but the overwhelming feedback was the prerequisite Selected state was an unnecessary step. So, in further patches, we streamlined the process to essentially automatic selection with the ability to lock and pin.

Another contentious issue that came to light during Evocati testing was the removal of the cycle keybinds. As stated, we wanted to try and simplify the selection process via view direction input but, in conjunction with the removal of onscreen markers, players had been using cycle targets as a quick way to get situational awareness. Long-term, we’ll be improving this with better information on the 3D radar display alongside having selected targets show on the Target Status MFD. Those players who want to solely use automatic selection can still do so and those who want manual cycling for everything can find a wealth of bindable options in the control section, so there should be something for everyone.

The final piece of the feature was all the visual changes that were implemented to solve the aforementioned sea of triangles and help bring clarity and focus to locked targets. Early blockouts of the feature had a 2D element for distant targets that transitioned to a 3D bracket at mid-distance before finally transitioning to a silhouette shader. During development, we trialled combinations and variations of this including a purely silhouette-based outline that was in early Evocati patches. The feedback was clear that this wasn’t visible, so we returned to 3D geometry and re-implemented the forward direction cone alongside contextual displays, including distance and closing rate. A very late addition was the ‘known contact’ chevron markers that we were originally trying to avoid in order to reduce visual clutter. Ultimately, we decided they were useful in a fight for situational awareness. Zane Bien came up with a more elegant 3D implementation than the previous 2D triangles that also helped draw the eye to new contacts coming into range, so we were happy with the result.

In the future, we’ll improve the visibility of these 3D elements on the HUD by enabling them to use the same dynamic brightness feature we have on the 2D HUD elements to help them be more appropriate to the scenario.

The primary goal of this feature was to replace the flash-based central HUD element in vehicles with our Building Blocks UI, improving on some of the features in the process. Converting the ships was a relatively quick task, although a few slipped through the net despite repeated testing and were cleaned up in subsequent PTU patches.

Between this and New Targeting Methodology, there were a lot of tweaks and changes that could be considered as being in one or either of these two features, such as:

• Improved Autogimbal display – Now displays the progression of the gimballed weapons to target to give feedback on how ‘locked’ players are.
• New 3D reticules and pips – Provides more integrated visuals to other visor elements. Animations provide feedback on the state of weapons, such as ‘over target’ or ‘out of range’
• Velocity indicator adjustments and thrust meter – Velocity tape bar is now displayed logarithmically rather than linearly. Thrust meter added to reflect the thrust capacity of the player ship.
  

During the Evocati and PTU phases, we trialled a variety of HUD elements and took onboard feedback specifically around the scale and amount of visual noise, adjusting it until we were happy with the clarity and visual identity.

Like the elements for New Targeting, one area we want to improve on in the future is the readability in bright environments. Enabling dynamic brightness on visor/lens elements will achieve this.

In retrospect, this was probably the most contentious feature of the patch and one that very nearly made it into Alpha 3.9. However, it was held back due to technical issues with the setup that required more testing. The goal was to provide a more realistic entry method to landing locations (like a real-world ATC system), remove the imposing visual element highlighting the area, and provide simpler mark-up for Art and Design to control it over the previous setup.

Compared to the previous version, the mark-up is a lot simpler and more flexible. Now, alongside single meshes that often resulted in huge and complex brushes, it can utilise primitive shapes and apply priorities to them to dictate which areas are restricted (or kill zones) and tie them to splines if desired.

The addition of navigation splines had problems like other HUD elements with readability in various lighting states. Unlike other aspects, it uses a different shader to control it, which is currently unable to react based on the overall brightness of the screen. We aim to fix this in a future patch as well as ‘theme’ the geometry to ship manufacturers because, in lore, the projection is from within the ship rather than the landing location. During the initial Evocati release, it was clear that players were using the system in a much more aggressive way than internal testers, often flying right up to the zone first before calling ATC. This resulted in the tunnels being drawn behind them and the icon for landing luring them into kill zones. With the change to brightness, improved hints and screen tips, and the addition of the marker being shown at the entrance to the tunnel, we feel this system is in a much better state though we are not happy with where it currently is in gameplay terms.

We’re looking at doing another pass to the system to try and remove some of the heavy-handed restrictions and let players go where they want, instead punishing misbehaviour with the Law System (impounding, fines, crimestats, etc.) rather than with autopiloting and destruction of property.

It’s a misnomer calling this feature High-Speed Combat, as it’s really all about discouraging combat at high speeds. We completed a lot of preliminary work on this during the Alpha 3.9.0 patch cycle but, due to various factors, held it to go alongside other changes in Alpha 3.10.

The goal was to reduce the ability for players to engage in easy dogfights at top speeds via a combination of restrictions that slowly become stronger above Space Combat Manoeuvring (SCM) speeds:

• Increased missile lock time
• Decreased auto gimbal slew rate
• Restrictions on firing missiles above certain speeds
• Decreased weapon accuracy
• Decrease shield strength
  

Through testing both internally and in the early Evocati phase, we decided that only the first two in the list were suitable for release. The remaining options were not followed through due to a combination of the UI not being able to clearly communicate what was going on and it feeling like arbitrary gameplay limitation.

In the future, we plan to impart more restrictions like this by using capacitors on weapons, thrusters, and shields to make players consider which of these three ‘resources’ they want to use for maximum effect. The power triangle will manage this.

The premier vehicle of Alpha 3.10 was the Greycat Industrial ROC, our first ground-based mining vehicle. We also planned two features to go alongside it, one of which made the release.

The first feature was the Gathering Beam, which on the surface looked like all our existing mining vehicles’ extraction mode. However, it was different in that it physically moved the split chunks of rock rather than playing a particle effect to simulate it. This feature is something we want to ultimately expand into the other mining vehicles as it lays the groundwork for other vehicle tech, such as tractor beams and salvage.

Having the Gathering Beam in the first place was the result of something identified in early planning by the Vehicle Tech Team (VTT) – the actual mineable deposits were physical and couldn’t simply vanish on collection. So, the ROC needed new rocks between the existing hand-mineables and those the larger ships extract. The Art Team diligently made new assets that split into the harvestable assets usually extracted from the smaller hand-mineables rather than simply larger chunks of rock that the Prospector and MOLE utilise.

The biggest issue the feature faced was one bug that appeared late in the push for Alpha 3.10.0 live. The rate at which items could be processed (the rocks were transferred to the ship’s physical inventory like food into a spacesuit) was limited due to a fix for another issue, resulting in the ROC only being able to collect around 20% of assets from a rock. This was subsequently fixed for 3.10.1 due to the additional time needed to QA the change.

The second feature the ROC was due to launch with was an External Inventory, as it was always planned that the crate on the back would accept rocks from a player’s own inventory, allowing the ROC to behave as an extended backpack. This feature wasn’t quite ready for Alpha 3.10 and will come online in 3.11 instead.

I hope the above has given you an insight into the development of the features the Vehicle Pillar delivered for Alpha 3.10. We’re excited for lots of our upcoming work to be experienced in future patches.

John Crewe
Vehicle Director

When we started to develop cover and the way we set-dress environments, it became very clear that we needed more flexibility in the system. Before, cover for AI was limited to 1.25 meters and higher, so how the environment was built had a big impact on how the AI acted and navigated. In most cases, this caused a non-realistic scenario to play out. We didn’t want to always have 1.25-meter objects spread throughout the room, so the AI Team made key adjustments that allowed the markup of cover to be easier to set up, and adjusted the NPCs to use a range of cover from 0.5 to 1.25 and above. However, there are still some minor issues that pop up in specific situations that we are ironing out.

This was our third weapon-type addition to Combat AI, after assault rifles and pistols. With this addition, we wanted to create some behavioral changes in the way the AI acted towards the player based on what weapon they have. We also overhauled AI interruption mechanics and made it more reactive compared to the previous version. AI also have a better understanding of the combat environment and situation through behavior adjustments. One of the more noticeable additions we made for the shotgun was that the AI will be more aggressive in closing the distance to the player, which we call “pushing.”

There were also adjustments made to the AI where sometimes they will be a bit more cautious depending on the weapon and distance to their target. We did a good amount of polishing and updated the animations and behaviors to make them more deadly. And with the coming addition of Forced Reaction on the player, if you are near the Shotgun AI, you will be knocked down and could be put in a compromised situation. As always with the addition of new features, there will need to be another polishing pass on the AI that will allow us to tune the time to kill and behaviors even more.

We were able to go back to one of the oldest locations in the game and introduce some of the key elements required to make it a fully-fledged landing zone, the biggest being the introduction of hangars, giving the player the ability to request ships of all sizes. Also, as part of this process, we refactored a section of the interior to incorporate future racing and betting events, which includes a generous viewing gallery to the exterior, a makeshift bar and seating area, and most notably the future space for mission-giver Luca Brunt. The team worked through these updates quite quickly and we were happy to bring more usability and flavor to this location. In the future we’d like to see content drops releasing in parallel with specific mission gameplay for a complete experience, but for now, we are laying the foundations for future mission content.

When we released New Babbage, we were not able to complete the hangars in the new Hi-Tech art style in time. So, rather than sacrificing quality, we decided to release with the existing Utilitarian art style hangars with microTech branding. For this release, we were excited to be able to showcase the new art style hangars, which fit the location much better. Plus, with the Aeroview brand, this is the first time we are seeing this look outside the hangar module and in the PU. Expect more hangar brands coming in the future.

After the major releases of New Babbage were completed, there were still some elements that we wanted to include before we moved onto the next location, the biggest being microTech’s flagship store - The Factory Line. The vision for the store was something very sleek and exclusive; something that reflected the campus-vibe seen in other areas of New Babbage. Several elements were stress-tested and resolved, such as large animated Building Block screens, how AI and the player interacted with curved stairs, and how the mobiGlas could be changed as an inventory item.

Right now, not everything in the shop is interactable to the player. However, we wanted to build the space with all items in mind to give an idea of what will be coming in the future, so expect to see the shopping experience updated as and when products come online. Plus, keep your eyes out for microTech Field Rep mission-givers in this location in the future.

Also, we introduced the new novelty items store in the New Babbage spaceport interior. The idea is to have shops that sell items unique to specific locations that players can collect and personalize their own spaces with. For New Babbage, we introduced Pico the Penguin. This is something we want to expand on so expect more elements like this in the future.

As part of the planet tech improvements we were able to increase the resolution of the heightmaps used on the planets and moons. Previously, this was simply increasing the resolution of the original maps. By re-authoring the heightmaps in the new resolution, we were able to utilize each pixel more effectively, creating more detail and data for us to take advantage of. As part of the process we needed to re-drop all ground locations currently in-game; this was everything from landing zones to derelicts. This is the first step in a multi-stage initiative to implement planet tech features as they come online. Expect more exciting improvements soon.

With the release of the ROC mining vehicle, we created a new size of minable for it to use. Essentially, we took the functionality of the FPS-scale minable item and increased the size to the requirement of the vehicle. Also, with the Quantainium ship minable item, we wanted to create a new shader that improved the readability to look more dangerous and volatile, reflecting the properties of this material.

Body Dragging is an important systemic addition to the game as it’s one of those features that underpins so many future core gameplay loops, including dragging a captured bounty to your ship, moving a dead body out of an AI patrol path, and even the heroic moment of you dragging a fallen teammate out of the line of fire.

At its foundation, the feature allows you to move dead or unconscious bodies around the play space. While this may sound simple, the implementation is fairly complex. We didn’t want Body Dragging to feel constricted and we endeavoured to make sure that when you’re dragging a body, the controls and actions of the character remain the same, so you can still look around and walk in the direction that you are looking and the body will follow you.

This meant we had to use a hybrid-driven ragdoll solution to allow the body to react to other objects in the world while still being constrained to the left hand. This also meant that we could leave the right hand free so you can use one-handed objects, like pistols, or interact with the game world. Some of you may be wondering why we added Body Dragging before the above gameplay loops. The answer is we wanted to get it live and into your hands so we could get feedback from a live environment. This means we can address any issues, like the body disconnecting too often (which we have analytics on), before the really fun stuff goes live.

The team is happy with the first implementation of Body Dragging, but that doesn’t mean we are finished working on it. We still want to improve several aspects, including the stickiness of the body attaching to your hand and the overall visuals, as the entire animation set was hand-keyed instead of using motion capture due to the pandemic lockdown.

Electron Damage is the first of many exotic damage types we want to add to the ‘verse, and we went live with the Lightning Bolt Co. Aztkav sniper rifle and Yubarev pistol. This damage type is a mixture of electrical, distortion, and stun damage. Electrical damage by itself is self-explanatory – it causes damage. Distortion and stun though are more about disabling their targets using non-lethal damage, with distortion affecting machines and stun affecting organics. The split of damage is not 1:1:1 across the three types and can be tweaked to provide different end results.

The two weapons we shipped electron damage with are specifically lethal weapons and have unique cooperative gameplay. The Aztkav is a high-powered, bolt-action sniper rifle that releases a huge electrical discharge that can jump to nearby enemies, giving snipers their first area-of-effect weapon in the game. Both the Aztkav and Yubarev also leave their targets electrically charged for a small period, which allows players to follow up with a second shot to cause a small area-of-effect detonation.

We were excited to see the new weapons go live, but this is just the beginning for the electron damage type, with future additions already being worked on for non-lethal gameplay.