Mechanics #2 - Interface Design

I know it's been a while - I've had a lot on my plate of late (more of that later no doubt). I've also had a couple of posts sitting in the Drafts section for a while now, so I figured it might be time to dust one off and see if anything can be done with it.

First up - Interface Design. Oh, and some caveats. This isn't going to be about how to make these things look pretty or swish about or whatever. This is also not just about having a HUD or the would-be Holy Grail of not having one. It's about the actual interface - a player's action and the game's reaction to it.

Looks awesome, but how does it play?

Whenever the player interacts with your game, several steps are taken. Depending on the game, these steps can take anywhere from a reactionary fraction of a second to a couple of days spent mulling over the options. Regardless, the sequence is pretty much the same.

Firstly, the situation is assessed and a course of action is decided upon. This section is always entirely dependant on your GUI and visual cues for the world. The aim here is to allow the player to make as informed a decision as possible and allow him to leave this phase knowing exactly what it is that he wants to achieve - rightly or wrongly.

Secondly, the player must attempt to use your interface in order to put his current plan into action. This means pressing the relevant button on the controller or keyboard, clicking on the right area on the screen, swiping the relevant surface or otherwise wrestling with a myriad of other potential input devices in order to make what he thinks should happen, happen.

Of the two steps, the second is by far the one filled with the most risk. Get the first bit wrong and the player will chalk it up to experimentation or bad luck. This is the sort of thing that he will usually be prepared to let slide, certainly during the early part of a game. That's not to say that you've got carte blanche to abuse this goodwill on his part - consider it a finite resource (which I shall henceforth refer to as Frustratium) that you're burning through every time he's not sure what to do and ends up doing the 'wrong' thing.

Get the second step wrong and it's a different matter. The player has already made his decision (rightly or wrongly) and for the game to do something unexpected is unacceptable. Sure, a particularly forgiving gamer may well give you a couple of chances and assume that it was him at fault, but this consumes Frustratium at an alarming rate.

Wrong Interface

There are two possible reasons for a player getting the second step wrong. The first one is that he used the interface incorrectly - he pressed the wrong button and is aware that he did so. Okay, fair enough. Mistakes happen. With any luck, he'll get over it.

The second reason is far more serious. He thought he was doing one thing but the interface interpreted his intentions in a different manner. Normally, this only happens if the interface is either context sensitive or in some way 'fuzzy'. That is to say, either the same action produces multiple results or it is possible to do two, very similar actions in order to perform two different tasks.

Fuzziness

Punch it Chewie!

I love buttons. Nice, tactile buttons. They are immediate and leave little room for ambiguity. Did you want to activate that button? If you pressed it, you clearly wanted it to do it's thing. The only question is whether or not you pressed it, and that's a pretty digital thing that can easily be confirmed. With a button assigned to a particular task and that task only, the chance of the player pressing it by mistake is now simply down to the number of buttons he has to deal with at once. Or possibly their size. Or layout. BTW, 'button' in this context refers to a nice, digital input device. It's not to be confused with a button that has degrees of being pressed. There's a reason why the move to Street Fighter II did away with the original's pressure-sensitive efforts and that's something you'll be able to work out why for yourself in a couple of paragraphs.

I do not like gestures. Gestures can be ambiguous and, as such, open to interpretation in many different ways. The guys behind Red Steel on the Wii summed this up very well in a talk at GDC a few years ago. Red Steel was a sword fighting game where each swing of the Wiimote corresponded to an in game slash. On paper, it seems like a great idea. But the problem is that there isn't a 1 to 1 mapping between controller and game - everything has to pass through a layer of interpretation. Basically, one swing in the game world is triggered by a particular type of swing in the real world. As there are no constraints to the way the Wiimote can be moved, the range of possible inputs and interpretations - both by the game and the person wielding the Wiimote - are vast.

Context Sensitivity

Context sensitivity, like so many things, is a tool. It can be used well and it can be used poorly. Someone can probably correct me, but I think we were one of the first people to try out context sensitivity with Syndicate. Originally, we had tried a fairly traditional, button-based approach. You'd click on the action icon then click on a target. We realised pretty swiftly that there was a whole level of complexity that could be removed (the Action icon) if the number of actions that we wanted to perform were nicely limited to the number of objects you could interact with. Therefore, clicking on the world moved your agent there. Clicking on an agent selected him. Clicking on an object picked it up. The most significant action - shooting - had a button all to itself.

On the surface, this seems like the perfect solution and, due to the simplicity of possible interactions, it worked very well in Syndicate. But before you go off and abandon buttons or detailed controls in favour of all-out context sensitivity, there's a warning.

It's fine up until the point where it isn't and then it's very, very bad indeed.

Now that must seem like a very obvious thing to say, so I'll elaborate. Each time you use context sensitivity, you're essentially guessing what it is the player wants to do. This is a very dangerous game, because you get no reward for doing it right. Instead you merely do what the player expected. Bear in mind that the player expects this to happen 100% of the time. The first time you guess wrongly, the player will be livid. Possibly even rage quit. Largely because the game has got it wrong. It has cheated him. Chances are it has cost the player something and the perception is that it wasn't his fault - he'd made his decision to do a thing, thought he was entering the correct control input and the game has gone and done something different. This contravenes my number one rule of game design - ensuring that the player always accepts responsibility for a failure and the game wasn't just being mean. As such, this is very likely to consume all remaining Frustratium and possibly even accrue some kind of Frustratium debt, whereby the player cannot actually play the game for a period of time until his resources have replenished.

So I suppose we could just add another rule: Don't Second Guess The Player's Intentions.

Going back to the Red Steel example, you can see how, with the wide range of interpretation available, the chance of the game guessing the player's intention for each swing was always going to be small.

Of course, this isn't me telling you to abandon context sensitivity like so much sewer alligator. There are ways of mitigating the risk involved. One tip for dealing successfully with context sensitivity would be to keep similar actions grouped together. That is to say if you had a click meaning either walk to a location on the map or shoot at an interactive feature, the potential level of frustration could be pretty high when a vital click gets misinterpreted. Again, in Syndicate we were lucky in that even if we guess wrong, the agent would still do something vaguely similar - moving towards an item to pick it up, which is similar enough to a standard move as to not worry the player too much. Another mitigation was the cursor - it would change according to the action about to be performed, thereby allowing the player to make the informed decision. That is, assuming he went slowly enough to notice that the cursor had changed and was able to parse what the new cursor actually meant - GUI design!

Voice Control

Is there a reader here that actually likes Voice Control? With the finest will in the world, the tech just isn't there for practical gaming application. I mean, it's a lot better than it ever has been, but it still either registers false positives or simply doesn't get what you're trying to say and guesses instead. As such, it's one of the most frustrating interfaces imaginable.

Consequence. A hallmark of the ME series

But with that in mind, occasionally something does it right. Not 100% right, but righter-er than everyone else. I'm looking at you, Mass Effect 3. No, not for the seamless squad commands which are anything but, but for the conversations. Here you are given plenty of time to make your decision and the voice control is given plenty of chance to differentiate between which thing you wanted to say and something else that you didn't want to say, giving it the best possible chance of getting it right.

I played ME3 with my ever-watchful Kinect sitting there in the background. I tried the voice commands in combat. They sucked. I tried them in conversations. They were brilliant. Not for any particular gameplay reason - it's still an order of magnitude easier to simply press a button - but for the fact that it added weight to my decisions. It's easy to think of a particular character trait you'd like to employ and press a button. There's an anonymity to it - like posting on a forum. When you have to say the actual words, it's like you're ratifying it in real life. You're saying something to which you will be accountable for. As such, it made it very hard for me to play as any particular character other than myself. Turns out, in real life, I'm not as much of a Renegade as I would have otherwise hoped for.

Touch Screens

In these enlightened times, you may well find yourself working on a title for either a smart phone or tablet. This means Touch Screens.

Touch Screens are a fantastic invention. You simply tap or swipe wherever you want and cool shit happens. It's like we're living in the future or something.

Well, provided people suss out how to design stuff for them that is.

Virtual Joystick

I'm fairly sure there's a rung of hell dedicated to people who get their hands on a touch screen device and try to shoe-horn a joystick into it. If your game absolutely must have a joystick, I put it to you that you're not really making the correct sort of game for the device.

There are several problems with Virtual Joysticks. I would say the most obvious is the fact that it's just not a physical joystick. That is to say that, without the haptic feedback of the joystick's current position, it's quite hard to tell what input you're actually giving the game - or at least you have to concentrate on joystick positioning a lot more than you would.

The second problem is one of obscurity. Thumbs and fingers on a screen that is both an conveyor of information and input device is troublesome. Tapping the screen tends to be okay, but forcing the player to permanently hold a particular area can lead to all sorts of issues. At the very least, you should design the joystick to be out of the way, but that's not always possible, especially not on a phone-sized object, as you just might not have the real-estate to pull it off. I know some people with pretty massive thumbs. After all, didn't Tom Hanks use his to cover the whole moon one time?

Obscurity

In fact, this is worth a bit of expansion itself. When you're designing your touch screen game, bear in mind where the player's input device (fingers) will be and for how long. If they happen to be over a place where significant gameplay things occur, this is going to be a problem. There's an interesting example in Dead Ahead - an otherwise charming little zombie infinirunner. It features both virtual buttons on the left for shooting or boosting as well as a virtual joystick on the right for moving up and down. Your bike travels from left to right, dodging obstacles whilst shooting at chasing hordes of zombies.

The problem is that, with the default setting, the fingers you use to move the bike get in the way of the obstacles that you're trying to avoid. You can swap the controls around with a judicious swipe so that the joystick is on the left and buttons on the right, but all that does is make it harder to see where the horde is coming from. Again, this is probably only a concern on a smaller screen, like that of a phone, which makes me think that the developer only really cared about what the tablet version looked like.

Tap, hold, swipe and variants thereon

Another example would be DJ Max Technica - a touchscreen arcade rhythm action game. A pulse sweeps across the top half of the screen one way before returning along the bottom half of the screen the other way. Notes appear and must be tapped, swiped or otherwise as the timing pulse passes over them. A fairly early evolution for the player to make to his style is to ensure that he is tapping notes using whichever hand opposes the timing beam's direction of travel - beam moving to the right? Use your left hand. That way your arm doesn't obscure the notes you're trying to hit.

I also came across this problem whilst dabbling with a touch-screen combat prototype that played out like the old Final Fantasy battles. You'd have a party of characters on one side of the screen and a bunch of enemies on the other. Tap on a character to select them or their ability then tap on a target monster. With all of the stuff I've just talked about, I put the player's characters on the right of the screen, facing monsters on the left. This may seem unnatural to some people - your dudes are facing the 'wrong' way - but it ensured that your arm was never in the way of the targeting process. Even though moving your arm out of the way would only add fractions of a second to the input speed, decent interface design needs to flow and be as responsive as possible. The amount of time between the information being parsed and, once a decision has been made, the resultant course of action being implemented should be as short and frictionless as possible.

BTW, this obscurity thing isn't just about limbs or digits - consider your HUD, or whatever you use for a control panel or the like. If you have a panel of buttons along one edge of the screen and it has a nice and straight, solid edge, there's no problem. Back on older machines, this sort of thing was born out of necessity - the device didn't particularly like drawing things behind other things and you could save time by only drawing something once if stuff didn't have to be drawn behind it. Thing is, it looks a bit dull, so as machines got more powerful, artists would come up with ever more intricate or organic shapes to build control panels out of. Then you end up with this ironic situation where, although you can actually see more of the game area through the gaps or interesting shapes of the interface, you actually feel more claustrophobic - as if the instrumentation is actually encroaching on the view. Weird, huh?

Making It Work

Sadly, there's no silver bullet for interface design. It's an iterative, evolutionary beast. It relies on technology and the preconceptions of the people holding the controller. As such, it's also highly subjective.

As with so many things in game design, a decent knowledge of what's gone before can be invaluable as you'll be able to shortcut quite a few decisions. Check out the competition and see what they've done, then use the bits that you like as your starting block. Play it. A lot. Get your friends to play it. Get people who have never played it to play it. Listen to what they have to say, identify common problem areas and find solutions to those.

Some Cool Interfaces

Ever seen Pushing Tin? How about Breaking Bad season 2?

• Flight Control, iOS. Simple to understand. Whenever the planes crash, it's entirely your fault.
• RUSE, XBox 360, PS3. Best joypad-driven RTS controls I've seen.
• Fruit Ninja, iOS. Still one of the simplest, cleanest interfaces around.
• DJ Max Technika, arcade. Very elegant and still allows for plenty of player expression.
• Steel Batallion, XBox. Want to feel like you're actually piloting a mech?
• Extreme Road Trip II, iOS. Okay, it's buttons, but each one is invisible and the size of half the screen.
• Skate series, XBox 360, PS3. Making skateboarding feel less like a beat-em-up and more like, well, skateboarding. A curious case of analogue feeling somehow better than digital.
• JS Joust, PS Move. Great use of a motion controller.
• Beyond Good And Evil, PS2. Innovative text entry FTW.
• Total Annihilation, PC. Simple but very modular for layers of complexity. Still the benchmark.