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.
Thruster Efficiency Curves & Aerodynamics
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.
Turret & Gunnery Improvements
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.
New Targeting Methodology
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.
Ship HUD Rework
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.
Restricted Area Rework
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.
High Speed Combat
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
- 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.
Greycat Industries ROC & Gathering Beam
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.