Controller Design: Buttons pt.1

Before we consider genre. Before emergence. Before gambits, strategy, and tactics. And before level design we consider mechanics (player actions). This is why early in the life of this blog I did a series titled Mechanics & Abstractions. In it I broke down the foundation of gameplay. Now, I want to take a step back and analyze the foundation of interactive design; controller input devices. From buttons to analog sticks, touch screens to motion controls, and mics to mice we'll take a detailed look at how input design shapes all player actions and expectations.

Click to enlarge. Image by Ev Turn

The series will be broken up into articles each examining a particular input device. In each article I’ll discuss the pros and cons of the digital information the device can transmit, various examples of the device, how designers have commonly worked with and around the device limitations, and any notable accomplishments.

“Whenever we make a new game console, we’ve done it without throwing away buttons and the directional pad. The reason for that... it’s better to have them, because buttons and directional pads benefit gameplay response.” ~ Satoru Iwata

ButtON - ButtOFF

We begin with buttons, a staple in the world of machines both analog and digital. Buttons are so simple that it’s easy to overlook why they are so effective. Buttons are a bridge between man and machine. On the one side we have man; an infinitely complex and variable being who interacts and responds to the world with his/her squishy organics. And on the other side we have machine. Cool. Clean. Functionally oriented yet also capable of intricate and complex tasks. These two sides do not speak the same language. To bridge this gap so man and machine can communicate, we can use buttons.

The simplest button is a one way communication line with only two states; on and off. It’s hard to get lost in translation over such binary potential. This button is squishy (like us) yet transmits a clean signal to the machine. If using a machine is like working as a team, then clear communication is key (read more about team skills here). Between humans verbal, written, and body languages are effective yet they introduce possible communication errors. However, with buttons between humans and machines, it's clear what messages get through to the machine. When the machine only looks for a button to be on or off we can significantly narrow down variables in our learning experiments. This simplifies the process of understanding the functions of the entire system (man + machine).

Visit the orignal artists' page. 

Clear communication is the nature of the "gameplay response" that Iwata referred to. Basically, trial and error is the most widely used learning method. When we learn game systems we observe actions, form hypothesis, conduct experiments, analyze the data, and repeat as necessary. The less confusion about the input (experimental variables) and the feedback (data/results), the better we learn.

Controller Examples 

I don't think it's necessary to go over examples of video game controllers that feature conventional buttons. Almost all of them do. So I present examples of gaming buttons that are less obvious. 

• Gamecube/Wii Classic Controller L/R Shoulder Buttons. Deep within each shoulder trigger is a shoulder button. Though it is strange that you have to completely depress the analog shoulder triggers to reach these buttons, because of the distinct snappy feel and independent on/off state, they are still buttons. Super Mario Sunshine, Luigi's Mansion, and Super Smash Brothers Melee use the shoulder trigger/buttons well. 
• PS3/360 Controller L3/R3. Similar to the previous example, underneath the analog stick of these controllers is a button. If you press into the sticks you'll hear and feel a distinct click. Though these buttons are generally within reach, they're typically mapped to infrequent actions like crouching (Halo) or knife attacks (Call of Duty).
• D-pad. The direction pad and nearly all of its variants are actually a collection of at least 4 individual buttons resting under the plus shaped pad. The D-pad was designed to control movement. Because of this, the pad doesn't allow players to press buttons on opposite sides simultaneously. By rocking the pad around you can only press a maximum of two adjacent buttons at a time, thus allowing 8 total directions.
• Arcade Stick. Like the D-pad, the arcade stick is a clever construction of buttons. Instead of 4 sub-buttons like with the D-pad, some arcade sticks have 8 individual buttons, one for each cardinal and intercardinal direction. Instead of the diagonal directions being the combination of two buttons the arcade stick clicks into the "diagonal chamber" distinctly and easily.
• Guitar Hero Controller. The strum bar and the colored buttons are all buttons with springy releases. Like the arcade stick, the strum bar has a distinct click feel helping players know exactly when the internal button is pressed. The Rock Band guitars do not feature this click. 
• PS3 Pressure Sensitive Buttons. The 4 face buttons on the PS3 controller probably cannot be classified as buttons. Though they look and feel like normal buttons, instead of just an on and off state, these buttons respond to hundreds of different degrees of pressure. This makes them analog which means they're more like triggers than buttons. More on triggers in part 2. 
• Virtual Buttons. All touch screen, on screen, or motion based buttons are not true buttons because they do not have the shape/physicality or the spring action.

Mechanics Examples

Let's look at how various developers have designed mechanics around buttons. This will showcase the versatility of the button as well as its limitations. I've explained above why the button is such a great interface device. The buttons is as black and white as you get. But while solely having an on and off state is ideal for doorbells, for anything more complicated the software side of mechanics design must compensate.

Pac-Man is about as simple as it gets. When you move the arcade stick , Pac-Man moves. When you release, he stops. From what I remember, the arcade stick is a 4-way stick for the cardinal directions. Likewise, Pac-Man can only move in those 4 directions. As long as Pac-Man lives, this interactivity remains consistent.

Mario is more complicated. Even looking at just the horizontal motion, there is momentum. Run right and then try to move left and Mario will skid, stop, and then move left. This design isn't too complicated. Instead of thinking that left/right on the D-pad makes Mario WALK left and right, we automatically make the adjustment mentally and think of the left/right buttons as Mario willing himself to move in a particular direction. Sometimes this makes Mario skid to a stop. Other times he can just start running. Still, the most important part about moving Mario is that players can do it at almost all times while Mario is playable whether in the air or on the ground.

Mario's JUMP mechanic is more complex still because the system looks to Mario's position to determine if Mario can JUMP or not. After all, how can Mario JUMP if he isn't standing on anything? It makes sense to us in our heads because we can tell the story and relate to virtual Mario using our real world experiences. But knowing this doesn't explain what happens when we press the JUMP button while Mario is in the air.

If you do press the JUMP button mid air, nothing happens. In fact, a lot of mechanics are designed to give the player no feedback when the mechanic doesn't activate. This is because of the expectation we have of buttons and mechanical/digital systems. Because electricity is so fast we commonly expect immediate actions to follow a button press. Videogames are generally designed with a fast action-reaction combination as well. So, in an odd way the instant lack of feedback can work as a clear indication that the button did not work. For this reason games tend to keep their feedback design quick and clear. 

It would be neat if the physical controller had a mechanism that prevented the JUMP button from being pressed when Mario was airborne. That way we would never have to make up an excuse/special case to explain why the JUMP button doesn't always make Mario JUMP when pressed. It may seem like I'm making a big deal over this minor limitation. However, understanding why this minute design detail is potentially troublesome is the key to understanding controller design. In other words, controller design takes into account player expectation, input devices, gameplay/mechanics design, and gameplay feedback.

Because developers sought to make increasingly complex gameplay interactions and mechanics button design has been thoroughly experimented with. On the complex end we have games like Poto & Cabenga. In the middle there's the game One Button Bob. And on the extremely simple end there's Linear RPG and Super PSTW Action RPG. Notice the different ways these games use taps, holds, and releases. With these designs along with button combinations (e.g. A + B), mechanics can be designed with a wide variety considering their limited vocabulary, so to speak.

In Melee, performing a short jump with Fox requires players to hit the jump button and release in about 3/60th of a second. The Street Fighter games are designed with a feature called "negative edge." Basically, when you press a button in this game your character can do an action. However, if you release the button your character can also do certain actions. So even if you think you're letting go of all the buttons and therefore turning all potential actions off, you may be turning them on. Read more about the disconnect between player input and game output here. 

And it only gets more complicated from here. This is why I've always stressed clean design from the mechanics upward. When buttons are cleanly design, the added clarity of the gameplay feedback helps the player learn and relax. When the disconnect between input and action is large, players resort various technqiues like button-mashing or double-tapping. Basically, when in a stressed situation where there's no time to learn mechanical intricacies, players commonly mash buttons hoping that some actions do come out and that they're the right ones. Such players probably think it's better to survive blinding than to die learning. A similar thing happens when players don't know the exact timing of an action. They increase their chances by inputting the desired input (generally a button) multiple times quickly in succession so that if the first one is too early, the second one might do the trick.

To close, it's important to understand that as great as buttons are, they cannot do it all. The more complex a button based game is the more complex the software side of the mechanics design must be to compensate. The more complex mechanies are on the digital side, the more important feedback is to the player experience. In part 2 we'll look at analog sticks.