Mechanics & Interface: The Third Hand

When I was in elementary school, I watched a program on the Discovery channel on the Alien Hand Syndrome (AHS). Wikepedia describes it well....

An alien hand sufferer can feel normal sensation in the hand and leg, but believes that the hand, while still being a part of their body, behaves in a manner that is totally distinct from the sufferer's normal behavior. They lose the 'sense of agency' associated with the purposeful movement of the limb while retaining a sense of 'ownership' of the limb. They feel that they have no control over the movements of the 'alien' hand, but that, instead, the hand has the capability of acting autonomously — i.e., independent of their voluntary control. The hand effectively has 'a will of its own.' 

Imagine what it's like to have a limb of your body acting on its own. Interestingly, if you're a seasoned gamer you've probably experienced something very similar to AHS. Remember when I talked about how gamers recall events in video games? To recap, if someone retells the events in a game and uses the word "I" they feel like they had some control over the events. If they refer the characters or objects by their name, then they are acknowledging a lack of control. In a similar way, when the characters we play in video games do things that we don't want, command, or think we command, the experience can seem like the characters are acting out on their own. It's almost like there's a third hand on the controller that you can't see or feel trying to play the same game in a very different way. 

We're exploring what makes controls work... and not work.

Think even farther back when I covered mechanics and abstractions on this blog. One of the four qualities to describe gameplay mechanics is how individual it is. When a button/input is only mapped to a single mechanic, that mechanic is completely individual. The simplest games have the best chances of featuring individual mechanics. Moving in Pong. SHOOT and BOMB in Geometry Wars. And Mario's JUMP mechanic are individual. However, in Super Mario Bros. the RUN button is also the SHOOT FIREBALL button making both of these mechanics non-individual. Why bother designing individual mechanics? What makes individual mechanics better than non individual or grouped mechanics? These are very good questions.

The answer is grouped mechanics inherently add potential kinks in the player-game interaction through the emergent criss crossing of function and input. In other words, the more mechanics use the same input, the more likely it is for a range of things to happen when the player intends to do one thing. Let's look at Super Mario Brothers for a simple example. You can RUN by holding the B button. And you can SHOOT a fireball by pressing the B button (one fireball per button press). Because of the input design of these grouped mechanics, you cannot continually RUN and SHOOT fireballs. This isn't too big of a problem for a dexterously skilled player. With a rapid release and press of the B button players can RUN and SHOOT fireballs without dropping in speed very much at all.

On the flip side, player's can't RUN without SHOOTing a fireball as Fire Mario. Normally this isn't a big deal. Mario has infinite ammo so players can waste as many fireballs as they want. There are times, however, when the fireball you SHOOT inadvertently kills an enemy when you only wanted to RUN. Though rare, I've died after SHOOTing a flying Para Koopa when I intended to RUN and JUMP on it. I've also accidentally killed a Koopa I intended on kicking into incoming enemies for a 1up combo. It's like Mario decides to throw a fireball every time I decide to run. Mario either has a mind of his own, or he's controlled by "the third hand." 

Grouped mechanics can complicate the interface between the player and the game by combining and limiting mechanics. Understanding a game's interface becomes much more difficult when dealing with anything other than individual mechanics. With that said, grouped mechanics aren't the only kind of design that can complicate the interface of a game. Take the following design features for example...

• State Change = Mechanics Change: In some games, different avatar/game states inherently change one's mechanics. In Smash Brothers hitting the A button while lying on the ground, standing up, hanging on the ledge, while holding a character, or while in the air each produces a different attack. Sometimes, when you want to do one kind of attack, the opponent or the stage forces your character into a state change that turns your input into another kind of attack. Ike players with their back to the ledge fear this especially. If they try to do a standing jab and get pushed off the stage, the jab can turn into an air attack which causes Ikes to fall to their death. 

• Buffered Inputs: Some games increase the window of input timing for their mechanics. With buffered inputs if you input a command slightly early, the game will sustain that input. Even if the buffer window is only 8/60th of a second, the difference is clear. Instead of living on the edge trying to execute moves at the earliest opportunity and no earlier, you can relax and still play at an air tight level of precision. Unfortunately, input buffering can sustain your inputs when you don't mean or expect them to. Depending on how the game buffers the frames, your inputs can be dropped, combined, or shuffled creating very unexpected results. 

• Negative Edge: In the Street Fighter Series, special moves can be executed with a string of directions and a button press. Most people don't know that these same moves can also be executed with a button release as well. Outside of charge mechanics, we normally don't think of releasing a button as a way of doing an action. Combine the negative edge design with frame buffering and it's possible to input special moves simply by letting go of the controller.   

• Time Sensitive Mechanics: When actions or a string of actions are time sensitive, an additional layer of complexity is added to the interface. For these mechanics, if you don't input the command(s) with the right timing, the move you want to make won't happen, and you may get a different move instead. Devil May Cry 4, Smash Brothers, FF:Crystal Chronicles, and Street Fighter all have timed mechanics. Ultimately, knowing exactly when the window of opportunity opens/closes for these moves is very hard to learn. Because of this, players tend to play as safely as possible by timing their inputs well within the windows. Playing on the edge of these timing windows can result in unintended moves. 

• Analog/Speed Sensitive Mechanics: Like time sensitive mechanics, some games use analog input devices to design mechanics that are activated from specific ranges of input. For example, the Smash Bros. series makes a distinction between tilting the control stick and smashing it. The difference here is one of speed. Tilts require a slow speed or a held direction while smashes require a fast stick motion. As a veteran of competitive Smash, I can't tell you exactly where the line is between a tilt and a smash. All I know is how to execute each when I want to. Still, there are times in a match when I swear I input a tilt and a smash comes out. 

• Snap To/Auto Aim: Mechanics that are designed to snap to or auto aim to specific game elements increase the interface complexity of a game. Depending on how well the snap/auto aiming is designed, there can be a disconnect between the way the game seems like it'll act and what it actually does. For example, Nathan Drake likes to snap to ladders, ropes, and the edges of surfaces as he maneuvers around in Uncharted 2. When any of these environmental objects are arranged too closely together, Nathan may snap to the closest object or freak out and leap out of his way to snap to a farther away object. Normally Drake will snap to the closest object within range, but because of emergence, the unexpected is bound to happen. This can be fatal. It's the same with the Thiefs rope in Trine. According to the players position, the game will automatically aim the rope to the nearest wooden surface. Unfortunately, what the game thinks the nearest surface is may not be what the player sees as the nearest surface. The way the auto aim is designed, you'll spend time fighting what the game wants and what you want.

• Net Code/Lag: The internet is an unstable place for a video game. When playing online, you take everything you know about a game's interface and add at least one layer of uncertainty. Because every action you make must be transfered through the net to your opponent(s) and every action your opponent makes must be transfered to you, it's possible for data to be lost in the process. When playing online, it's hard to tell whether some mistakes were your own, or if your actions were lost in the net. Whether your timing was perfect, or if the lag caused your timing to falter. 

Adding complexities to a game's interface design usually makes playing and understanding the game harder. So the next time something happens to you that you don't expect, consider why you couldn't make it happen. Is it your fault? The game's fault? Or does the blame land somewhere in the middle, on some third party (interface)?