Star Citizen Live Q&A Covers Vehicle Gameplay, Design and Balance

DEVELOPER Q&A

VEHICLE GAMEPLAY, DESIGN & BALANCE — STAR CITIZEN LIVE Q&A BREAKDOWN

A special pre-taped Star Citizen Live brought together Vehicle Director John Crewe, Assistant Design Director Torsten, and Vehicle Experience Lead Designer Rich to work through community questions submitted by the Chinese Star Citizen community and the wider Spectrum thread. The session covered a lot of ground — TSG, fighter rebalancing, missiles, armor, the Odin, ground vehicles, careers, and more. We've broken it down in full below.

This is one of the more substantive vehicle-focused developer conversations we've had in recent memory. The team were candid about what's working, what isn't, and what they're holding back on intentionally. Worth reading in full if vehicle gameplay is what you're here for.

TSG is, by John Crewe's own account, the content drop he has been most excited about in Star Citizen's history — and by the time this episode aired it was already live in PTU. The timing alongside Fleet Week and a combat-focused sales event was coincidental rather than planned, but it works.

What sets TSG apart from most PvE content is the structure. These are not missions you can clear solo in one capable ship. They are layered, sequential operations where different ship archetypes each play a distinct role — fighters escort, support ships sustain, specialists contribute in ways pure combat hulls cannot. The concept of bringing fighters, repair ships, bombers, and capitals together for a coordinated strike has been on the drawing board since 2015. TSG is the first serious step toward making that a functional reality rather than a promise.

The team acknowledged this first iteration won't hit every cooperative gameplay goal they have in mind. But it is a genuine foundation, not a placeholder, and nothing currently in the game asks us to play our ships together quite like this.

The overlap between light, medium, and heavy fighters has been a long-running complaint, and the team addressed it directly: yes, it's being worked on. The current flight model is solid, but it lacks the tuning levers needed to make each class feel genuinely distinct. A light fighter doesn't fly dramatically differently from a heavy, and that's a problem the new flight model is specifically designed to solve.

Rich described the new flight model not as a parameter swap but as a complete rethink of the flight experience — from liftoff through quantum travel and into combat. It needs to arrive as a coherent package. The last time CIG dropped sweeping system changes all at once, during the engineering gameplay rollout, feedback was too scattered to be useful. The approach now is incremental, with each patch targeting one focused variable so data comes back clean.

In practical terms for the near term: Alpha 4.8 will bring reduced bullet speeds and extended weapon ranges, pushing combat toward the closer-quarters, cinematic style CR has long been after. Slower projectiles may sound counterintuitive, but the effect is more readable engagements — we can dodge, read trajectories, and fight at tighter ranges with genuine back-and-forth rather than near-instant exchanges. Further flight behaviour changes are planned for subsequent patches.

One point the team were firm on: fighter classes are not a progression ladder. A light fighter is not a stepping stone to a medium. They are different tools for different situations, and the goal is to ensure that each class has clear moments where it is the right call — right down to the content level, through TSG and what follows it.

Torsten was direct about the current armor system: it is a stop-gap. Energy weapons are already intended to be more effective against armor than ballistics, but the difference isn't pronounced enough — something Alpha 4.8 is set to address. A specific failure was called out by name: a Scorpius currently cannot meaningfully damage another Scorpius with guns, forcing those engagements into missile-only territory. That is not working as intended, and it is being fixed.

The approach to 4.8 armor changes is focused and deliberate — fix the inconsistencies between fighters that cannot damage each other, sharpen the distinction between weapon types against different hull classes, and close the hard gap between weight classes where heavy fighters are effectively immune to lights. The team are also being careful not to over-invest in a system they know will eventually be superseded.

That system is Maelstrom — CIG's long-planned physicalized damage model that replaces health bar mechanics with material-based, simulation-driven damage. Community feedback on the current armor implementation is being logged as direct input for Maelstrom's tuning. Some of the current armor logic already mirrors how Maelstrom is intended to work, which means adjustments made now carry forward. When Maelstrom eventually arrives in the PU, the iteration cycle will be shorter because of the work being done today.

Missile gameplay has needed attention for a while, and the team acknowledged it without hedging. The core problem is not balance — it's predictability. Missiles currently move fast enough and behave erratically enough at terminal approach that neither the firing nor the receiving player can reliably read what is happening. Countermeasure outcomes feel arbitrary. Incoming missiles are hard to locate and track. Dedicated missile boats feel like a side option rather than a compelling playstyle, and that needs to change.

The planned rework addresses this by slowing missiles down, regularising their flight paths, and redesigning their terminal approach so both parties can understand the outcome. The team also noted that missiles currently bypass armor checks entirely due to their raw damage output, which at least gives them a situational role against heavily armored targets in the interim.

On UI: the absence of a clear lock completion indicator was specifically called out as a known gap being actively addressed. Engineering gameplay already influences EM and IR signatures — and in a recent patch, cross-section detection was moved to active-ping-only, which tightens stealth interactions with missiles but introduces visual indicator gaps the team are working to close.

Point defense turrets are also in line for improvements. The current PDT system auto-engages threats in a fixed internal priority order with no player override. The plan is to change that — allowing us to set threat priority, exclude specific target types, adjust engagement timing, and push that same control layer down to drone-based turrets when that technology arrives. When it does, ships like the Nautilus move from conceptually interesting to operationally viable.

The team used the RSI Perseus to explain how ships change between concept and flyable. Older concepts were produced in rough 3D with detailed 2D paintovers — none of that painted-on detail survives into production. Artists build interiors from scratch, and flat corridor sections without additional detailing look bad at any scale. The Perseus went through a deliberate detail pass to avoid the repetition issues that drew criticism from Polaris owners, and that RSI interior language carries forward into the Galaxy as well.

On what qualifies a ship for a rework versus a Mk2: a gold standard update brings a ship to current technical standards and makes it competently playable without changing its core identity. A Mk2 is for situations where the visual language of a ship needs a radical overhaul while the role stays intact — the Hornet Mk1 to Mk2 and Aurora Mk1 to Mk2 transitions were both cited as examples. Ships are prioritized based on whether they can still fulfill their intended role, whether staff resources are available, and whether community investment justifies the work. The 2027 ship schedule is already substantially planned, which reflects how far in advance these decisions are made.

For the Caterpillar specifically: the team's preference is not a Mk2 but a comprehensive modernization of the existing asset alongside finally delivering the modular payload system that was always part of its design brief. Recent limited work on the ship for the command module feature made clear how dated the asset has become. Cargo and combat modules were both referenced as obvious starting points. John Crewe expressed genuine enthusiasm for a broadside cannon configuration — opening the payload doors, running a broadside pass, turning like something out of age-of-sail combat in space. That is not a roadmap commitment, but it is a strong signal of intent from the person who oversees vehicle production.

The Anvil Odin Battlecruiser was confirmed as announced alongside or just before this broadcast — described as twice the volume of a Javelin and the largest ship CIG has ever attempted to put in players' hands. That context made the multi-crew coordination question feel especially pointed.

The team acknowledged that current tooling for pilot-to-gunner communication and tactical target-sharing does not meet the requirements of a ship at that scale. Marker and target-sharing improvements have been on the list for two years. The nearest-term version is cleaner visual target designation and easier sharing between crew members. The longer-term vision, referenced in Road to 1.0 material, is a dedicated tactical station where a crew member can assign targets to all turrets simultaneously, set engagement priorities, and coordinate full ship operations — the capital ship command role that has been described since the project began.

On getting crews assembled in the first place: the team discussed a teleport-to-party leader feature currently in prototype. This has not been approved and may never ship. The idea is to allow players to quick-travel to a party leader's location or hangar under specific circumstances, dramatically cutting the time it takes to crew up for a capital ship operation. The team were transparent about the tension between this and Star Citizen's core ethos of meaningful travel, noting that manual travel would still carry advantages if the feature were implemented. The discussion is happening because the time cost of crewing up has become a real problem heading toward 1.0 — and the team said outright that any solution which gets players into the game and playing faster has to be considered.

Refining is confirmed as a full standalone profession with depth comparable to crafting — not a sub-process of mining, not a background operation. Ship-based refineries, base refinery modules, and station refineries will all draw from the same underlying gameplay framework. Working on one unlocks the foundation for all of them, which is good news for owners of ships like the Expanse.

Player-run shops were also flagged as a high priority. The Merchantman was used as the shorthand example: a ship that cannot reach its purpose until the economic infrastructure around it exists. Both refining and player shops are being sequenced after crafting reaches a more complete state, but both are understood as necessary to making the verse's player-driven economy actually function.

The nearest-term addition to career loops is refueling missions, confirmed for Alpha 4.8. Stranded NPCs who run out of fuel will post missions that Starfarer owners — and at least one other fuel-capable ship that was referenced without being named — can respond to for extrinsic reward. This is the first time refueling has had a direct incentive structure attached to it, which has been a gap since the gameplay loop launched. A fuel-capable ship teased in a recent weekly newsletter is expected to accompany the feature.

Repair ship gameplay was acknowledged separately. Torsten confirmed he is holding space for dedicated repair ship gameplay but wants the crafting loop closer to completion first. Alpha 4.8 brings onboard repair functionality for capital ships as an incremental forward step. Full dedicated repair ship gameplay remains further out.

Functional suit lockers are in active development. The vehicle content team is auditing ships to ensure locker volumes and interaction points are correctly configured, with a focus on making the interaction fast and clean — not door-animation gated. Ships that currently have suit lockers are expected to support the feature at launch; ships without them will not be retrofitted, as that absence was intentional for those designs. The connection to G-force resistance mechanics means suit swapping mid-flight will carry real gameplay weight when the new flight experience matures.

On alien ships: the Railen, a Xi'an vessel, leads an alien-focused promotional week in June. The team confirmed that additional non-combat alien ships are planned for later in the year, expanding a segment of the lineup that has been almost entirely combat-oriented until now.

Ground vehicles got an unusually candid assessment. The team acknowledged that they have been sidelined — not by intent, but because functional ground vehicle gameplay depends on terrain, physics, and game infrastructure that hasn't caught up. A tire and suspension physics update introduced several years ago improved handling but also introduced edge-case problems: more realistic simulation interacting with terrain that wasn't built for detailed vehicle traversal produces unexpected behaviour. Cyclone pilots know this well.

A ground vehicle 1.0 planning meeting was described as imminent at the time of recording. The stated goals include improved tire and suspension physics, better terrain collision handling, and — notably — converting ground vehicles to use the same engine and power plant systems as spacecraft. That last point matters: it means ground vehicles would gain the same component-level depth as ships, and their interaction with engineering gameplay would become coherent rather than separate. Combined with base building and combined-arms content, there is a real case that ground vehicles could become as central to a player's career as their ship.

Nested vehicle spawning — storing and deploying ground vehicles from inside a ship cleanly — was flagged as a known priority with work confirmed underway. Getting a ground vehicle into play right now involves enough friction that most of us don't engage with it consistently. That is the problem the team are trying to solve before they build meaningful ground-vehicle-centric content around it.

For pilots who prefer controller input: significant work has been done on the Squadron 42 side to improve gamepad compatibility, and that work will inform Star Citizen improvements — but it cannot be directly ported. The flight systems differ, the input mappings differ, the quantum experience differs. Adaptation is required, not just file transfer.

The broader commitment from the team is to support as wide a range of input devices as possible — gamepads, full HOTAS, VR, eye-tracking — without any of them becoming a second-class option. That remains the stated direction, and the team noted that as long as key people with strong personal interest in peripheral support remain at CIG, it stays a priority.