History
For those curious about the history of the directional pad, the Gaming Historian has you covered with this exquisite review of the input’s development and use over the years:
The D-pad was invented by Nintendo as a joystick alternative for use in a folding, handheld console. It was later popularized by the Famicom and NES.
For our purposes, it is important to note that the original use was as an input for locomotion. Over the years, many titles have found additional uses for the D-pad, including: quick-item selection and use, HUD element toggles, UI navigation, consulting tips/companion characters, menu and map access buttons, and social action bindings. Some of these implementations have worked great. Some have been the source of frustration. The goal of this article is to explore why and to offer advice to developers to help reduce the risk of D-pad related rage.
Hardware
In the video above, the Gaming Historian provides an good look at the different hardware underlying a variety of D-pads. Also, Digikey provides an excellent teardown of the XBox 360 controller where you can see the hardware discussed here.
The thing to notice in both of these sources is that underneath the D-pad lay four rubber membrane carbon contact buttons arranged in the four cardinal directions. These buttons are binary inputs, meaning they are either on or off, pressed or not pressed. They have no force sensitivity or any way to measure the degree to which they are pressed.
The property that differentiates the D-pad from four cardinal buttons is that the D-pad is capped by a solid piece of plastic while regular buttons are physically independent. This means that while buttons can be pressed in any combination, the pressing of one direction on the D-pad affects the other directions. For instance, pressing right rocks the cap so that it cannot be pressed left simultaneously.
The binary inputs and rigid rocking cap lead to eight possible inputs: up, up and right, right, down and right, down, down and left, left, and up and left. (And a ninth: no input)
Because the underlying hardware consists of binary switches, we can create a truth table for all combinations of inputs. Doing so, we would get something like this:
| ↑ | ↓ | ← | → | Direction |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 0 | 0 | 0 | 1 | → |
| 0 | 0 | 1 | 0 | ← |
| 0 | 0 | 1 | 1 | NA (0) |
| 0 | 1 | 0 | 0 | ↓ |
| 0 | 1 | 0 | 1 | ↘ |
| 0 | 1 | 1 | 0 | ↙ |
| 0 | 1 | 1 | 1 | NA (↓) |
| 1 | 0 | 0 | 0 | ↑ |
| 1 | 0 | 0 | 1 | ↗ |
| 1 | 0 | 1 | 0 | ↖ |
| 1 | 0 | 1 | 1 | NA (↑) |
| 1 | 1 | 0 | 0 | NA (0) |
| 1 | 1 | 0 | 1 | NA (→) |
| 1 | 1 | 1 | 0 | NA (←) |
| 1 | 1 | 1 | 1 | NA (0) |
There are 2 to the 4th, or 16, combinations, but only nine are possible with the fused rocking cap of a d-pad. The remaining combinations have been marked NA, but the sum of the directions is still included to illustrate what the result would be for separate buttons such as WASD or the arrow keys.
Looking at the table we see that there are eight possible directions that can be registered as unique. When developing for D-pad, it is important to keep this limitation in mind. It can be either a bad thing (few possibilities = less flexibility) or a good thing (few possibilities = more predictability and consistency).
Problems
Due to the fused cap of the D-pad, unintended input may be registered. For instance, pressing up on the D-pad may result in a left or right press being registered if the player inadvertently applies a bit of torque with their press. This only applies to directions that are orthogonal to each other, as directions on the same axis block each other.
This can lead to problems when using the D-pad as a secondary set of cardinal buttons. Because there is no way of measuring degree of depression, there is no way to resolve which of the registered directions was the intention of the player when multiple are registered accidentally. If the degree of depression were measured, it would be simple to determine which direction was pressed the most. But the underlying circuitry just does not support this.
This problem may occur more on different hardware. I have experienced it often on my Xbox 360 controller, which is regarded as one of the worst D-pads. Even if it is mainly a problem with this controller, it is important to keep in mind that it is one of the most supported controllers on PC.
Suggestions
With this in mind, if the D-pad is to be used as additional action buttons, it is best to limit the use to two actions, mapping them to opposite directions. This will avoid accidental presses of orthogonal directions. It also ensures that the two actions cannot be executed concurrently, useful if they are conflicting actions.
If all directions of the D-pad are used, there are two techniques that can make it work well: mapping inconsequential actions and state feedback.
Inconsequential Actions
When the possibility of erroneous input exists, it is important to make sure the player is not badly punished. When the input is misread, you don’t want to lock a full-health player into a three-second animation of them drinking their last potion in front of a charging enemy.
Actions of little consequence should therefore be mapped to the D-pad. Sea of Thieves maps its social interaction functions to the D-pad. Multiple Zelda games use it for consulting the companion character. Many games use it for cycling through, but not using, items.
Actions that can be quickly corrected, such as menu navigation and locomotion, also fall into this category. Recognition and correction relies on feedback, though. So you will need to consider the following if you choose this approach.
Feedback
Feedback is key to almost every realm of game design, and our current scenario is no different. In order to allow the player to correct errors before committing to an action, they have to be able to detect those errors. This comes naturally when working with locomotion or menu navigation, as the character or reticle are designed to respond to input in real-time. But this is often taken for granted and may be overlooked when designing a novel system.
A systems should pretty much always give feedback about its state. For example, a radial menu should let the player know whether the controller is registering the input as intended and wait for them to confirm. If the following menu selected an item the moment it detected input, it would fall out of harmony with the player.
A hybrid system could be created that allows players who are more confident in their use of the D-pad to issue commands with a quick tap, while allowing more care to be taken by showing a radial menu when the D-pad is held.
Unity Setup
There are two ways to set up the D-pad in Unity. To use the legacy system, set up the input axis in the Input panel. The joystick axis type should be used. The axis number can be looked up online. It will vary based on controller model.
If you are using the new input system, you do not need to set up the axes individually. If your action type is set to 2D Vector, it can be mapped to the D-pad as a whole. This is the fastest and least error-prone way. Using composite bindings can cause errors.
Valve’s Circle Pads
An exotic re-imagining of the D-pad, the circle pads of the Steam and Vive
controllers solve the main issue discussed above, but introduce a new problem. The circle pads use capacitive touch in combination with a binary button to determine where the pad is being touched and whether it is depressed. By measuring the former, it is possible to figure out which direction is mostly pressed when the later is registered. It also opens up the possibility to handle swipe gestures and to use the circle pad like a track pad.
Problem solved! …almost. The touch sensitivity of the circle pad does not extend reliably to the edge, meaning the button registers but the touch reads as centered instead of all the way to one direction. This can cause issues when using the circle pad in the way one uses the d-pad as cardinal buttons. Pressing down (south) on the circle pad of the Vive controllers is often the most problematic, because the positioning of the thumb tends to lead to edge presses at the bottom of the pad.
The Good
The D-pad would not have survived so long if it didn’t have a lot going for it. Its cap creates a unified button that is easy to identify and use by touch. It prevents conflicting inputs. Small travel times make it superior to the analog stick for rapid, repeated, discrete actions, such as scrolling to a specific item in a long list. Fewer input options means there is less noise or deviation in the signal compared to analog. There is lots to like about the D-pad. As long as you take care to think about how it is used, it can create a great experience for your players.