Don't Surprise Me! or, Preventing Input-Related Frustration

Hello, Evan here, designer and programmer on Failsafe. I'm going to talk about various design challenges related to the contextual input scheme on our first-person platformer, and principles that we have employed to overcome these challenges. 

The following guidelines are related to a design principle that I find extremely useful, known as the Principle of Least Astonishment. This is famously used as the guiding tenet behind the Ruby programming language. According to this principle, a program should generally behave in a manner that is least astonishing to the user. This is by no means an exhaustive list, but hopefully will serve to illustrate certain elements of our approach.

1) Inputs should never be contextually useless.

When we design a game, we are training the player to expect certain things to happen when they perform certain inputs. Imagine, for example, that you are playing Super Mario Bros. The game trains you to expect Mario to jump when you are on the ground and press the jump button. Now imagine that whenever Mario got too close to a ledge, the jump button no longer caused him to jump. When you pressed the jump button, and nothing happened, you would immediately become confused, and probably frustrated by the lack of reaction. This is a violation of the PoLA - the player has been astonished by the behavior of the game. 

To illustrate this in our own game: originally, our grapple hook feature was purely context-sensitive. If there weren't any targets in range, Isra simply would not throw the grapple hook. Players found this very confusing, often not even realizing there was a grapple hook at all. Once we made it so that Isra could throw the grapple hook during any action, the use of the feature became much clearer. To perhaps rephrase this principle: inputs should always have immediate and clear feedback (even if that feedback is negative!) to avoid confusing the player. 

2) Inputs should be consistently themed.

Metal Gear Solid V is a brilliantly complex game, with a complex control scheme to match. For the most part, it didn't give me too much trouble. However, one particular situation surprised me quite a bit. When I climbed into a tank for the first time, I found myself unable to figure out how to fire it. When playing with a controller, pressing the Right Trigger, or R2, causes Snake to fire his weapon, and the Left Bumper, or L1, causes Snake to call his support team on the codec and gain information about the surroundings. However, when you are in a tank, R2 triggers acceleration, and L1 fires the tank's weapon. By the time I figured this out, I had been blown up by a rival tank. This input change was incredibly surprising and therefore frustrating, since L1 is never used for anything weapons-related in any other context. 

In Failsafe, we want the input scheme to be as simple as it can possibly be without compromising gameplay possibilities. To this end we have developed a fairly unique control scheme. We conceptualize the bumpers on the controller as being mapped to the legs. When the player holds down the bumper for a short duration and then releases it, Isra jumps. When the player is running and the player holds down the bumper for a longer duration, Isra begins to slide along the ground. If she isn't moving while the player holds down the bumper, she crouches. It seems crazy, but testing has shown that most players become used to the system quite rapidly, and the distinction is intuitive enough that the player's intention is not miscommunicated by the inputs. We take care to never violate the expectation that 'bumpers = legs' in any context. 

"But, Evan!" you reply. "This is not an established platforming input scheme, and players don't expect something like this. Doesn't this violate the PoLA?" Actually, no, the PoLA is not a mandate to always work within established conventions. We can avert astonishment by teaching the player about this input style, and then maintaining internal consistency. If, even after teaching, the players found this scheme confusing, then we would have a problem, but so far we have not found this to be the case.

3) Avoid binary distinctions between same-context actions. 

When we first implemented wall running, we implemented it as a binary distinction between vertical wall running and horizontal wall running. If the player was facing directly or almost directly towards the wall, they would run straight up. If they were angling into the wall, they would run across horizontally. Upon testing, we found this feature to be incredibly frustrating - often the player's intention to run up a wall turned into a horizontal wall run, or vice versa. The first problem with binary contextual actions is that the distinction between the two is often arbitrary. In many instances players getting used to one type of wall running wouldn't even realize that the other kind of wall running even existed. Here lies the second problem with binary distinction - if a certain type of interaction behaves entirely differently with two different conditions, triggering one type of behavior does not necessarily communicate that another behavior is possible. 

Our solution was to implement wall running as a gradated action instead. When the player initiates a wall run, we take the angle the player is facing relative to the wall and their initial velocity at the start of the run to create a trajectory along the wall. Instead of dividing wall running arbitrarily into "vertical" and "horizontal" flavors, there is simply a range of different trajectories of wall running that the player can produce. After implementing wall running this way, we now see that players experiment with wall running, naturally feeling out how the different starting conditions affect the run. It feels smoother and easier to handle, and also gives the player much more control over the action. The major advantage of avoiding binary distinction is twofold: it gives the mechanic a greater degree of complexity to master, making the action more satisfying to perform, and it also encourages experimentation, allowing the player to learn the behavior more naturally.

"But Evan!" you astutely point out. "Let's say the player throws the grappling hook, but there isn't anything for it to hook on to within range. Isn't that a binary distinction?" You are correct, there is a binary between being able to grapple and not being able to grapple. The difference here is that there is an innate justification for not being able to grapple something - it was too far away, and the rope couldn't reach. In contrast, there is no intuitive reason why running into a wall at 19 degrees would produce a wildly different outcome from running into a wall at 21 degrees.

Final Thoughts

The Principle of Least Astonishment is ultimately about respecting your players. Don't force them to memorize confusing and arbitrary contextual behaviors, and they will reward you by enjoying and appreciating your design. And remember, this isn't a hard-and-fast rule - sometimes, surprising your player with the unexpected can actually be a good thing in the right context. Rules are made to be broken... as long as there is a good reason for doing so.

Failsafe is now on Kickstarter. Please consider checking out the campaign, or following us on Twitter.

Until next time,

Evan