Controller Design: Terminology pt.6

part 1. part 2. part 3. part 4. part 5.

Controller design is all about ergonomics, a broad concept that includes the design of inter-working mechanisms, human anatomy, and psychology. To put things into perspective, controller design is a subset of mechanics design. Over three years ago I created a framework to break down and discuss gameplay mechanics (player actions). The four categories I create that seemed to cover all the key aspects of a mechanic are directness, dynamics, intuitiveness, and individuality. It’s time to evaluate this system with our new understanding of controller design to see if it needs to be updated.

"Ergonomics is the study of designing equipment and devices that fit the human body, its movements, and its cognitive abilities." ~Wikipedia

In all of my analysis of various controller input technologies, I frequently talked about the muscles and the methods gamers would typically use to manipulate the device. There really is little point in discussing a gaming controller without seriously considering how the player will use it. Will this grip make the analog stick easier to move or will it cut into the player's finger? Can the player even reach this button comfortably? Quickly? How will the player think this device will work before using it? Will these thoughts interfere with the player's expectations? Simple questions like these show that controller design is part mechanical and part psychological.

The psychology of game design is a rich subject that few tackle. Check out the Psychology of Games blog by Jamie Madigan for well written and researched articles on the topic. On a broad level, players use their experiences in life (especially with other video games) to shape their expectations. Without even considering what is good or bad game design, a player may like or dislike any particular feature based on their expectations. If you've ever instantly liked a sound effect or song because it sounds similar to one from a favorite game, you know what I'm talking about. In some cases, simply being familiar with another game in the same genre can result in the player having a very difficult time adjusting. And most of this process is unconscious. The player might not consciously understand that the reason they missed so many shots in a new FPS is because of a difference in the auto aim design. All they do know is that their shot is off, they're not winning, and therefore the game doesn't feel right. Because these expectations are made up of countless observations, experiences, and other factors (technical, environmental, personal, etc.) it is impossible to precisely design around the specific expectations of multiple gamers.

On a very close level, our expectations tint and shape our very perception before we consciously realize it. This means that all of our trial-and-error experiments we conduct to learn a game system have biased inceptions and biased results. Like with any experimental process, we can minimize the effect our biases have if we're careful. The problem is, most gamers looking for low work, low stress entertainment simply do not reach this metacognitive level of addressing the faults in their own thinking. Because most play games by feel, it is that much more important for designers and Critical-Gamers to be aware of how player expectations, ergonomics, and controller design affect gameplay mechanics, the foundation of our interactive medium.

To best understand how expectations (ergonomics) impact controller design, let's buckle down, establish clear terms, and look at cases in a technical manner. Throughout this article series I've been careful how I used the word "precise." It along with tight, smooth, responsive, and accurate have been used in a very vague or careless way in our community. Like "mechanics," a word that I use very specifically, these words will be the most useful only if we stick to very distinct and clear definitions. Fortunately, the scientific world has used some of these terms for measurements for a long time. If their definitions are good enough to launch a man into space, they're good enough for our purposes.

• Accuracy: the degree of closeness of an outcome to the declared target. Accuracy is only useful for comparing the ranges of input of different devices of the same type of input. e.g. the value range of pressing all the way up on the analog stick of a 360 controller versus a PS3 controller. 
• Precision: the degree to which repeated attempts under unchanged conditions produce the same outcome. (also reproducibility / repeatability). 
• Responsiveness: The time it takes for the system to respond (an expected output) after inputting.
• Sensitivity: the smallest change in the input method that produces a response in the system.
• Bias: the difference between the mean of the outcomes and the target value. Only relevant when discussing accuracy. 
• Error: random variability.

So let’s look at Mario JUMP as an example. It's precise; the button based input makes repeating attempts easy. It's responsive; Mario springs off the ground so quickly that the button press and the result are practically simultaneous. In terms of sensitivity, Mario's shortest JUMP is 2 bricks high. His highest JUMP is 5 bricks after getting a running start. In between these extremes Mario can hit a range of heights. Because the game and the input device is so simple, there's little error to consider. In other words, it’s hard not to hit the JUMP button correctly and consistently. In conclusion, Mario's JUMP is a very solid mechanic (both input and function).

Mega Man's JUMP is just as solidly designed as Mario's except it's more sensitive. Mega Man does not have a JUMP height minimum. If you tap the button for only a few hundredths of a second, Mega Man will rise for that time and fall immediately when you release. Mega Man does not softly float at the top of his JUMP arc either. This design matches well when mapped to a button. When pressed (on) Mega Man goes up. When release (off) Mega Man falls down immediately. 

In LittleBigPlanet, Sackboy and Sackgirl's JUMP mechanic is somewhat decisive. Some deal with it while others cannot stand it. This is a perfect opportunity to explain the mechanic with our new terminology. Because LBP is designed around user generated content and the ability to modify game elements in various ways, LBP mechanics were designed with more complexities to compensate for these possibilities. Where Mario and Mega Man only JUMP off of flat surfaces in their NES style games, in LBP a continuous range of angles are possible. This is inherently a more difficult challenge to design for. Media Molecule's solution was to make everything physics based. To clarify, the LBP system factors in the 2D vector momentum and other calculations to determine how the Sackpeople will JUMP. So, while Mega Man has no momentum, and Mario mainly has horizontal momentum, Sackpeople have 2D 360 degree momentum. Because the system is more complex, sometimes my Sackboy doesn't JUMP to the expected maximum height even when I hold the button down. Because the physics calculations vary slightly (error), when I think I'm inputting the same way Sackboy reacts differently. This makes the mechanic seem imprecise.

Because Sackboy doesn't have a minimum JUMP height, like Mega Man, and ascends slowly to various heights due to the imprecision, the LBP JUMP mechanic can seem quite unresponsive. Because of these results and how Sackboy doesn't JUMP very high (compared to his height) it's more difficult to see the range of sensitivity the JUMP. All of these problems stem from the physics based variability or error. Even if these background calculations are indeed consistent, what really matters is the action-reaction expectations of the player. A shaky foundation is a dangerous thing especially for core/primary mechanics.

To conclude this part I'll wanted to make another clarification. It seems that many use the words "controls" and "mechanics" interchangeably. (Remember when I explained how vague language breeds more vagueness?) These words do more harm than good if they share the same meaning. For when they do, it's hard to know whether someone refers to the physical controller or the way a gameplay mechanic is programmed to use the controller. So, to be clear, the word controls refers to input device hardware (including which moves are mapped to which devices), mechanics refers to the hardware and software combination of gameplay actions, and an individual reference to a mechanic (e.g. JUMP) refers to just the software side.

To illustrate the difference between controls, mechanics, and gameplay actions consider the following example. For our purposes, the target goal is successfully landing an attack. Imprecise controls would be a faulty button on the controller. When you press this button the gizmos inside will either send the signal properly or short circuit. For an imprecise mechanic there would be great difficulty in repeatedly hitting the target because, perhaps, of how sensitive the motion controls are (assume that the input device works properly). No matter how careful you are in attempting to repeat the same input, the results vary. The problem is the result of the input device/method and the programming of the move. And finally, an example of an imprecise attack is Fissure, the 1-hit-KO attack from Pokemon. Using this attack produces varied results purely because of how it's programmed. Even though the button or touch screen controls are 100% precise, Fissure only hits 30% of the time.

In part 7 we'll use the terminology to finish our evaluation of my four part mechanics criteria.