As Star Citizen has expanded, moving on from its early days as a Flight only space sim to bring in On Foot and EVA modes, the game’s control scheme has become more and more esoteric and disjointed – the intention then, with a redesign of the game’s default control mappings, was to re-evaluate the placement of the most important actions while also unifying them across all modes as much as possible.

Giving important actions more intuitive placement on each device was an obvious requirement – and this was what we tackled first – bringing MobiGlas for example, with its ever increasing usability, right to the fore. From then, we needed to delve into the unification. So how then do you start to bring things together across all 3 modes (Flight, On Foot and EVA)? For this we identified two very important factors to inform the design.

Firstly, we looked for commonalities between the three different modes of gameplay – this resulted in us viewing EVA as a possible cipher. EVA is the in-game bridge between On Foot and Flight – so we looked to see if it could also bridge the controls as well. From here the unification work was guided using the question of “When the player runs and jumps off a platform – should the jump button continue to push the player up?”. We said “yes” and developed on from there.

Secondly, we felt that the old mappings weren’t the best at utilising 6DOF, so we wanted to see if there was a way to improve in this area at the same time. Improving the ease in which a player could move between the 6DOF actions as well as making it possible for the player to layer these movements together (without too much trouble) were the key points we identified to improve 6DOF gameplay.

Before moving on to show what has been unified, let’s first dig down a little into what it actually means to unify the controls. As we worked through the unification process, we realised there were two different types of unification to consider: Global and Contextual. Breaking these two ideas down should hopefully explain our approach in more detail.

Global unification covers both the consistent placement of actions that exist in all modes – for example, previously, changing the camera view on gamepad was different for Flight and On Foot modes – and also the grouping of actions sensibly for the device across all modes – here the example is making all the keys used in movement always be the same in all modes.

Contextual unification carries this idea further getting sensible matching keys for similar actions that exist in the different modes. The best example here (that also demonstrates how much Global and Contextual overlap) is sprint from (On Foot) matching up with boost (Flight); two different actions that make perfect sense to go together and create a unified “go faster” movement key.

Expanding this idea further still, we have the grouping of keys in the same mode contextually. The example here being Free Look on [ Z ] and Look Behind on left [ ALT ] + [ Z ]. These actions were considered related because they activate different ways of viewing the game.

And also – carrying unification on to the very extremes – we wanted to explore the potential for keeping these contextual actions grouped between devices – so that when we paired actions together on the keyboard mapping we would consider, could they also be paired on the gamepad?

Clearly then, this was always going to be a complicated process – but one that if we could get right would help remove some of the control boundaries SC had created over the past year. Moving on then, lets outline the unification achieved.

Global Unification

These actions are consistent across all modes (per device):

• Movement

• Pause & MobiGlas

• Contacts, Chat and 2D UI Cursor

• Interact / Use

• Cycle Camera View

• Freelook / Orbit Cam

• Modifiers

Contextual Unification

The tables below show which actions have been paired up between each device.

Keyboard:

On Foot / EVA Flight Move Forwards / Backwards Throttle Up / Down Strafe Left Right Strafe Left / Right Aim Up / Down Pitch Up / Down Aim Left / Right Yaw Left / Right Lean Left / Right Roll Left / Right Jump, Strafe Up Strafe Up Crouch, Strafe Down Strafe Down Primary Attack Weapon Group 1 Weapon Stance / Walk IFCS mode shift Reload Reticle Focus Sprint Boost / Afterburner Use Item Launch Countermeasure Cycle Item Cycle Countermeasure Melee Missile Lock / Fire Force respawn Self-destruct Change Fire Mode Decoupled Mode Toggle EVA Brake Spacebrake



Gamepad:

On Foot / EVA Flight Move Forwards / Backwards Throttle Up / Down Aim Up / Down Pitch Up / Down Aim Left / Right Yaw Left / Right Weapon Stance / Walk IFCS mode shift Select Firearms Targeting Sprint Boost / Afterburner Change Fire Mode Automatic Landing Primary Attack Weapon Group 1 Use Item Launch Countermeasure Force respawn Self-destruct



As you can see by the tables, it was a lot easier to do the contextual unification with the keyboard than the Gamepad (due to its obvious limitations for a game as complex as SC). In fact, the Gamepad’s problems were essentially this fundamental clash between the unification we wanted and the potential detriment to player usability. And, as our revisionary design process went on, there were plenty of times where it felt like we were punishing QA with our unified schemes…

In the end then, compromises were made on the Gamepad. As mentioned earlier, on the keyboard we made sure that Freelook and Look Behind were on the same key – Look Behind being the modified version of the same key – as we felt like it made contextual sense to do so. However, it was determined that the Decouple Toggle was a more important action than the Look Behind – so we made the Decouple Toggle the modified version of Freelook instead (activated with the combined press of [ LB ] + [ R3 ]). The thumbstick clicks being better placement for important actions due to the player not needing to relax the sticks during a dogfight.

Another example of this on the gamepad was the choice to make Roll the primary action on the [ LS ] X-axis instead of Strafe Left / Right – which would have matched with on foot and EVA. The decision ultimately was that Roll was more useful in Flight – relegating Strafe Left / Right to the modified version of the [ LS ] X-axis.

As for the keyboard, while it clearly had more real-estate to play with, there were still limitations to find ways around. For us, the importance of not having to move the keyboard hand away from the movement keys was pivotal. And it was this that the keyboard placement was built around; what do we need to fit around WASD to make SC easier to play?

We believe the new Keyboard and Mouse layout makes it easier for the player to potentially strafe up/down, strafe left/right, roll left/right, yaw left/right, pitch up/down, fire weapons, fire countermeasures, boost and more simultaneously… without shifting the keyboard hand position. A big factor in this improvement was to bring in [ SPACEBAR ] and left [ CTRL ] as the strafe up and down keys – so that the thumb and pinkie fingers could be used as part of the movement controls.

Obviously, allowing the pinkie and thumb to come into play in this manner was done to match things up with the on foot and EVA modes, but there was more to it than that in the end. Selecting these keys, freed up some more keys near to WASD for other actions – allowing us to rethink which pivotal controls should be within easy reach.

Clearing other actions off of the [ F ] key has allowed us to pin this key down as a contextual “interact” action. This means that in all situations the player can think of the [ F ] key as the only way of initiating or activating – clearing up another problem we had with our old USE key being used to strafe down. Also, in the long term, we’re going to need to lean on this key even heavier as we expand upon the player interactions via the Inner Thought system.

We then chose to utilise the [ R ] key for the reticule focus action – meaning the closet targeting action was the one that allowed the player to lock onto the thing they were looking at. Hopefully simplifying things on that front too.

These changes did pose one fairly complicated issue; what to do with spacebrake? Since we had opted to move it off of the space key for the strafe up action. I think it’s interesting to walk through the problems this created, and the controversial way in which we looked to fix it that we ended up dropping.

The functions of spacebrake are first to slow the ship throttle to 0 and then second to return to the starting throttle when released. Trouble was, double tapping [ S ] would set the throttle to 0 as well, so the only thing spacebrake was adding that was unique was the return to previous speed functionality. After considering this, we wondered if it was not better to place the action behind a modifier to free up space for other actions. However, when we tried putting it behind the modifier on [ X ], the feedback was overwhelmingly negative – due to how often the key is used by SC players. Here’s the feedback from our QA:

“This is such an awkward and counter-intuitive key combination to press, for something that a player would expect to be able to do instantly and in the heat of combat maneuvers. It discourages the use of space brake. And it is much more difficult to press in intense situations such as maneuvering and combat.”

Community feedback also confirmed this strong dislike! So we were left with no option but to look at installing the action back as a non-modified key press. The problem now of course, was that we didn’t have a place for it. Thus, another round of key juggling was needed. This actually resulted in the moving of the freelook key to [ Z ] and the landing mode back it its original place on [ N ].

I think it’s also worth addressing our decision to put the Gamepad throttle on the on the [ LS ] too. While some might point to this as an example of the unification going too far, we think that would be overlooking the benefits of the unification and of having an analog control of the throttle. Using the relative analog control on the [ LS ] means we have more granularity over the control of the throttle. As it was, the gamepad used a digital throttle the same as the keyboard – which we felt was not really making the best use of the anaolg controls at our disposal. Some have likened this new setup to be like a “mini HOTAS” which we are pleased with.

Leaving [ CAPSLOCK ] empty was, at first, something we didn’t think would be possible – giving up a key so close to the movement actions. We wanted [ CAPSLOCK ] to be free since SC is a game, that as it grows, will rely more and more on in-game communication. We really wanted to avoid the frustration of the “accidental shout” if it was possible.

Those that peaked ahead to the mappings might have spotted the Tab key being empty – this was done with a view to new control features coming soon. We definitely didn’t want to get stuck without a place for something we’ve deemed to be so important to S42…

Hopefully then this report has helped to explain just how much work has gone into this controls revision process as well as highlighting the improvements we’ve made to make the controls in SC unified for 2.4.0.

However, if you’re really reluctant to change then we’ve still got you covered with our new legacy mapping profiles. So as part of this redesign we made sure to include the old control schemes as loadable profiles – we’ve created layout_gamepad_Legacy and layout_keyboard_legacy mappings that can be loaded in in the Advanced Controls Customisation menu or by using the command pp_rebindkeys in the console. Just press [ ` ] and then type in pp_rebindkeys layout_keyboard_legacy or pp_rebindkeys layout_gamepad_legacy to revert back.