Hello! This is my inaugural post on The Relay, but I’ve actually been around here for a while – I edit the weekly podcast The Relayside the Verse, and I’m also the creator of KTDM.shipWorks, a ship loadout engineering tool hosted on The Relay.
Being a huge geek about the in-game engineering side of Star Citizen, I had a natural fascination with last Friday’s design post on weapon mounts, and I’d like to share some of my thoughts on it. First, though, there are some big, confusing terms to clear up:
A place on a ship’s hull where any given piece of equipment is attached, from engines to power plants to seats to avionics motherboards
The intermediary item that connects a weapon to a hardpoint; up until 1.1, these were almost universally required
A mount that is mostly static and cannot be aimed independently of the ship – it always faces directly forward, e.g. the 300’s default wing mounts in 1.0.3
These terms all refer to a weapon mount that can rotate and aim independently of the ship, e.g. the Super Hornet’s ball turret
A turret station manually operated by a person sitting inside it, e.g. the Retaliator’s turrets
A turret operated automatically by a targeting computer, e.g. the Freelancer’s side guns
A ship equipped with weapons that all have the same projectile speed, thus allowing them to all converge on a moving target the same point and inflict huge damage
Formerly, hardpoints were differentiated by type, size, and class.
There was some known confusion about the class system, though; in Arena Commander, it is possible to take a gimballed mount from a Class 2 hardpoint and plop it on a supposed Class 1 hardpoint and vice versa… but I’ll get to that soon.
In any case, while the mount system itself wasn’t previously perceived to be a huge problem – mostly because it was nebulous and temporary anyway – there were some popular, valid community concerns related to gimbals in Arena Commander:
On top of those current issues, the developers would have been faced with more down the road using this mount system:
So while a mount system on its own sounds inconsequential, I think its implications can reach out into gameplay, economy, customizability, design, and the game’s development. Here’s what the designers have done.
From the perspective of Arena Commander’s current gameplay, the major takeaways from the design post and the second 1.1.0 PTU’s game files are that gimballed mounts can hold items one size smaller than before, and that fixed weapon mounts no longer exist. For instance, the Origin 300i now has:
Here are a few more examples of how things have changed so far:
The implementation isn’t yet complete, but the system is starting to make sense! To round out this data, here are some excerpts from Chris Roberts’s follow-up post on the RSI forums:
You can think of the size of a hosting item being available points to be spent on itemports on the hosting item minus the two modifiers we’ve specified;
-1 being a host
-1 to be a manned turret (as you need room for the gunner)
…there could be a Size 4 Remote Turret / Gimbal with a Size 2 weapon slot and a Size 1 Targeting Computer slot. If you plug in a weapon and the targeting AI module it would allow the Turret to be a remote auto aiming turret that could fire independently of your control…
Emphasis: -1 being a host. There may be special mounts that don’t carry this penalty, but this will be the general rule. In accordance with this rule, as of PTU 1.1.0 v2, fixed mounts have been outright phased out of Arena Commander! Instead, for the wing mounts on ships like the 300i, Avenger, and Cutlass, the weapons are mounted directly onto the hardpoint.
In any case, here’s a cheat sheet that breaks it all down:The three numbers in each cell represent how many items of a given size (along the top) can be placed on a mount of a given size (along the left). The cell’s first number is without a mount, the second is if it’s gimballed, and the third is if it’s either manned or automated.
So, as an example, suppose we have a Size 5 weapon hardpoint and want to evaluate our options for Size 5 mounts. We’d start by finding 5 on the Mount Size axis (on the left). In the first column beside that (Weapon Size 1), we see 5,4,3. This means that:
But how big is a Size 1 weapon? Well, that question can be answered definitively now!
In the design post, we are given a few tidbits of information on the physical size of mounts:
…we still need to differentiate clearly between a Size 1 (0.25m^3) and a Size 2 (0.73m^3). That Size 10? A whopping 1394.5m^3!
…(volume is preserved through ratios, which are capped at 7:1 and 2:1 – but there’s still every number in between)
As it happens, that was pretty much the perfect amount of information needed to interpolate the other sizes! Using exponential regression, I made a rough formula to interpolate the weapon sizes for Sizes 1-10, as well as their maximum lengths and widths/heights. The equation they used to generate these numbers might not have been exponential, but this is probably close enough.Note: These volumes are not the actual displacement of the weapon, but rather the volume of a bounding box around the weapon.
Some things to observe from this:
So, that’s pretty cool, but aside from allowing for some fun comparisons, how does all this stuff affect the game?
In Arena Commander, all ships’ default weapons appear to be the same as before, but there are some other changes of note:
For now, then, the changes to customization are effective but straight-forward. However, once we start thinking in terms of ship customization and the Persistent Universe, it all gets a lot more interesting! Size permitting, most weapon hardpoints will be able to hold fixed, gimballed, or automated weaponry of any quantity; some crazy idiot can bolt a single fixed Size 5 weapon on top of a Hornet, and it will work! But at the same time, things will remain immersive, rule-based, and still visually reasonable:An 8-metre Omnisky on a 22-metre ship
The hardpoint class system has been removed entirely as a result of all this, which is fine by me – it really only ever pigeonholed ship functionality and confused newcomers.
Finally, all this will require less labour and backtracking from the developers, as artists now have standardized size constraints to work within, and people at all stages of the pipeline can agree on the meaning of “Size 3” and agree on where a weapon of that size and firepower would be appropriate.
I think that while a short-term goal of this redesign was to alleviate backers’ frustration with Arena Commander’s apparent favour towards mouse and keyboard players, it has a far further-reaching effect on the creation for future content – both for the development of the game and for players customizing their ships. This weapon mount system introduces reason to a system previously governed by arbitrary rules and exceptions, making players feel like they are operating and tweaking a system that makes intuitive, logical sense, rather than fighting restrictions that merely exist because the game was artificially balanced that way.
The ships in Star Citizen combine art and engineering with a level of intricacy that has never been explored before in a video game. Each recent design post – on mounts, damage, and shields – has illustrated the incredible amount of creative and technical consideration that has gone into each of these systems, and those are only a few of many, many ship systems that have yet to be developed and unveiled in full.
Star Citizen’s development teams across the world still have the bulk of their work ahead of them, and to see the game to completion and beyond, they have to do everything they can to streamline their processes for adding content. Much like how the new damage system was created because damage models took too much time to make by hand, this standardized mount system eliminates ambiguity and reduces the time required at multiple stages of ship development – but these systems can require a significant initial time investment in order to ensure cohesiveness and balance in Arena Commander and in the Persistent Universe.
In face of the agonizing delays of AC 1.1 and Star Marine, then, it’s important to consider that these decisions are all made in the name of delivering the best game possible in the end; stopgap measures are sometimes necessary, but it’s ultimately much more rewarding to create a lasting solution that will benefit the development cycle down the road. And really, while a missed deadline is forgettable, a great product isn’t.
Thanks for reading, everyone!
aka “Mr. White”