Controls

This page only covers controls relating to movement, attacking, and blocking/dodging. Hotkeys are described on the slots page, and menus are described in their respective pages:

• Travel screen
• Inventory
• Character select
• Stats

Much of this page is liable to change in the near future. We assume many of our developers will be interested in taking ownership and providing input on game design, which we strongly encourage. Thus, the goal of this page isn't really to describe the game's controls; the top priority is to provide a list of design goals and principles for the controls, mostly downstream of the principles laid out in the readme. After that, we provide a tentative proposal/outline for a control scheme which meets those goals.

Goals

In order of importance, we want controls which are unambiguous; comprehensive; immediate; convenient; and intuitive.¹

Unambiguous

We are opposed to "context-sensitive actions" where the response to user input depends on the state of the game, particularly when the state is something continuous like your character's position or what you're looking at.

Certainly context-sensitive actions can make your controls "simpler" in the sense that you're using fewer buttons, but it'll also make them a lot more cumbersome than they have to be, and your player may end up quite surprised by what his character ends up doing in response to a given input. There are games with "simple" controls, enabled by context-sensitive actions, where no matter how much you play them, you can't perform these actions on instinct because you must always ensure the context is appropriate for them. That's not to mention anything with menus, which are worse for this on an entirely different level.

None of this for us! Space Station 13's controls are nowhere close to ideal, but what they have going for them is that once you get used to the controls, they're very good at becoming instinct: a quality very much worth replicating. Our contrarian view is that reliable beats simple every time.²

Comprehensive

You should be able to make your character do anything he or she could physically do which would be situationally advantageous.³

Immediate

In cases where a button does one thing if single-tapped but something else if double-tapped or held, some games will start an invisible timer after a first tap is registered, delaying the onset of the following animation until the player's intention is made clear (with a second tap/hold or lack thereof).

We will not be one of those games. It's a fair enough solution, but we want immediate feedback for the player, and we don't want any invisible timers to delay post-tap animation starts solely for the sake of single-/double-tap differentiation. Note this doesn't preclude all timers; we may certainly have two time-differentiated inputs which share the same starting animation. For instance, since jump and crouch animations begin the same way, it would be safe to use a hold or double-tap to differentiate the two.

Convenient

Buttons that you press often should be near your fingers. Buttons that you press often, like to grab an item, or need to be able to press immediately, like to dodge, should not use the same fingers as those needed to look and move.⁴

Intuitive

All else being equal, it'll be nice if the game's controls are intuitive and easy to learn, but this isn't a priority.

To the extent that the game's controls are complex, it'll be great if the complexity is optional, especially at the character level. Playing as an alchemist with a bandolier of different potions and doodads might require you to use more buttons than a naked barbarian with a big stick, and starter players may be encouraged to play characters more like the latter.

But ultimately, our contrarian view is that new players don't actually want "simple" controls; they want reliable controls. Insofar as that's true, following the previous guidelines should already get us where we want to be vis-à-vis accessibility.

Proposal

With our design goals established, we now suggest a tentative outline for the control scheme.

One feature we quite want in the game eventually is a split between direct and indirect controls. By default, the player has direct control of his character, and the game plays like an action game, but with a toggle, the player may relinquish control to an AI and direct it with RTS-like controls. You'd generally use this feature to navigate large, boring areas, to order around multiple characters, or simply because you don't like action games.

We posit control schemes for both modes below.

Direct controls

These are designed primarily for the first person, but we can add a third-person camera option after the MVP.

Halbe: I assume that first person is easier because with third-person cameras, you need to handle a lot of edge cases to avoid awkwardness in tight spaces or near thin obstacles like trees, not to mention smoothing out the motion or reconciling the shoulder offset when aiming. However, if I am mistaken in my assumptions, we should implement whichever is easier for the MVP.

This is somewhere between a real action game and an RPG wearing an action game's skin. We aren't actually simulating everything based on hitboxes and projectile trajectories, but we still want to use some of the player's mechanical skills, specifically accuracy and reaction time.⁵

• Precision is the value between 0 and 1 representing how close to the center of any of the target's hitboxes the player placed the aiming reticle. The exact formula for this number will have to come about through testing.
• Reflex is the value between 0 and 1 representing how quickly the defender pressed the dodge/parry button after the attack began. Like with precision, we aren't sure exactly how to derive this, but a value of 1.0 would correspond to pro gamer reaction time (0.1s) and ~0.75 would correspond to old person reaction time (0.25s).
  • There is no need to "time" your input to correspond with when an attack will actually hit as is convention in most action games. As soon as an enemy begins its attack animation, you should press the button.

For CPU-controlled characters (NPCs or indirect mode), the server... usually... randomly samples these parameters from a normal distribution with some mean and variance of our choice.

Indirect controls

We may have some version of this concept in the MVP if only because much of the underlying behavior is shared with NPCs controlled by the server. You are essentially giving NPCs orders through the same system that the AI uses to give them orders.

The following outline gives an idea of how things might work when controlling an army with a recursive chain of command, but as we aren't actually doing any RTS stuff for the MVP, it's more here as a distant if (hopefully) attainable aspiration, or in case an implementer is a passionate RTS/RTT enthusiast. The recursive nature of the system means that the controls should still make sense for small parties or individuals.

Universal

These inputs would theoretically find use in both direct and indirect modes.

Halbe: I have not thought too hard about their mapping. They should be remapped so that the most commonly pressed buttons are the most convenient to move your finger to.

Bruno: It'll likely be the case that these inputs are unavailable when a grab or select button is held due to overlapping with slots. When you hold RB, X is a slot/group button representing a holster on your left hip; if you aren't holding RB, X can be used for one of the menu inputs below.

• Toggle inventory menu.
• Toggle logout/character menu.
• Toggle quest menu.
• Toggle rest menu.
• Toggle direct/indirect control.
• Skip time.
  • In normal use, this toggles between real time and sim-time. When camped, it skips straight to the end of your rest. Either way, it's automatically interrupted if the party spots an enemy or encounters difficult terrain.
  • In the strategic layer (GSG mode), you continue to see the map at a consistent speed. In the direct camera or tactical layer (RTS mode), we can display a cinematic montage of travel or night passing. Not in MVP.

1. Also, as a broad note, we would rather follow operating system conventions than video game conventions wherever we can, especially for menus and any RTS-like controls. Video game conventions are designed for people who've played a lot of video games; OS conventions are designed for people. ↩

2. By "every time", we mean it. We believe that given enough playtime, someone who's never played a game in his life would prefer a game with SS13-like unambiguous controls to a game with Hitman's. You can generally compare our view on mass appeal to that of Stanley Kubrick:

   Kubrick likened the understanding of his films to popular music, in that whatever the background or intellect of the individual, a Beatles record, for instance, can be appreciated both by the Alabama truck driver and the young Cambridge intellectual, because their "emotions and subconscious are far more similar than their intellects". He believed that the subconscious emotional reaction experienced by audiences was far more powerful in the film medium than in any other traditional verbal form, and was one of the reasons why he often relied on long periods in his films without dialogue, placing emphasis on images and sound... When deciding on a subject for a film, there were many aspects that he looked for, and he always made films which would "appeal to every sort of viewer, whatever their expectation of film".

   In short, contrary to popular belief, if you want to best appeal to the masses, you don't actually want to simplify things. 2001: A Space Odyssey is the highest-grossing film of 1968 in the United States and Canada. There's a Pareto frontier of artistic merit and mass appeal, on which sat Kubrick and the Beatles, and we're aiming right for it. ↩

3. That's an important caveat. There are situations where you might want to go prone, but dedicated yoga position buttons are not a priority. (This may sound like an argument for context-sensitive actions, and in some cases it may be; as stated above, our primary opposition is to continuous-state context-sensitive actions, which leaves things open for contexts depending on discrete states, say in yoga class vs. not in yoga class.) ↩

4. Thus, grabbing and dodging shouldn't use the thumbs on a controller. ↩

5. This is trivial to cheat, but since combat is still (largely) based on stats and (entirely) mediated by the server, it's not a huge deal. ↩

6. This is a bit awkward, but you shouldn't normally be skipping the chain of command anyway. ↩