A Really Good Press

Despite a recent flurry of invention, in general, the controller is either the primary or only way a player communicates with a game. And yet the way in which we approach control design is often in a “what feels good” way.

There’s nothing wrong with this approach but what I want to do is assemble my knowledge of control schemes and try to understand the process of creating one more explicitly. By making it explicit I hope to speed up the process of finding “what feels good”.

Naturally we need to make something that feels good but I think we can arrive at something that we can intuitively assess much more quickly if we apply explicit understanding, rules and considerations first.

There is an inherent danger in making tacit knowledge explicit. Much of what I write might seem obvious and even addressing problems that aren’t there. My purpose is not to “break new ground” but to help consolidate what is there and focus on it explicitly.

Coming up

For the purposes of this post I am going to focus purely on analogue button presses on a traditional game controller. I am also going to duck some of the mechanical issues e.g. dead zones, as they are reasonably well understood and more of an implementation detail.

In this post I am going to discuss three things:

  • the press of a button
  • considerations when selecting a button
  • pitfalls and suggestions for overloading


The Press

First let’s look at what we actually get back from an analogue button. With an analogue button we get a value (let’s say between 0 and 1) where 0 is not pressed and 1 is fully pressed. We get this every frame. This data is pretty noisy but there’s good information to be got. This is some real-world (smoothed) data taken from an analogue button of pressure over time.

Profiles

What I want to do now is have a look at what I am going to call a profile. A profile is a portion of this data that we consider to be the player trying to perform an action.

It could be a tap:

A hold:

Or something more exciting:

What I propose is that when we think about a button press we think about a profile as opposed to the binary representation “press” implies. If we only consider whether the button is on or off we are missing out on the vast majority of the information provided: How long was the button held, how hard was it pressed, is it still being pressed, what was the average pressure applied to the button over the hold. When we think about profiles we automatically consider the full range of information.

The most crucial thing to remember is that this is how the player communicates with the game. We cannot afford to idly throw this data away.

Let’s not be naive though. A lot of it will be noise. Since we are dealing with a lot of players we cannot rely too much on the specific patterns. We have to deal with the commonality of the input across many people. Having said that, there are a lot of control schemes out there that should make more use of the data that is there.

What I propose is that instead of asking “what button must a player press” we ask “what profile must the player provide”.

Sometimes even the simplest interaction can benefit by thinking about profiles. A simple implementation of a jump might be ‘jump when CROSS is pressed’. However what if the player presses CROSS hard? What if they hold it down? Through these presses the player may be trying to communicate. If we can interpret this communication we empower the player.

At this point it’s worth pointing out that is not implying anything about the implementation of the system. Profiles are a good way of thinking about input. They are a bit over-complicated when thinking about implementation.

When?

Once we’ve established what kind of profile the player needs to provide we need to work out when to trigger the action. There are three options:

  • before the profile has been completed
  • at the point of completion
  • some time after the profile has completed

Before

Triggering the action before the profile has finished gives us the most responsive controls possible. You hit the button, the avatar moves virtually immediately. The problem with this is that we have reverted to the binary view of a button press. We have not allowed ourselves time to gather the information. The best way to avoid this is have actions that can be modified. We initiate an action when we get the first bit of input but then modify the action over time as we get more data e.g. a jump can be triggered on the first press and then sustained by a hold.

On Completion

Triggering the action when the profile has finished is not advisable except in the following cases:

  • if the profile is very short (it is indistinguishable from triggering the action immediately)
  • if the controls do not need to be particularly responsive
  • if you are charging (e.g. a snooker game where you dictate power with your hold and then take a shot with release)

Arguably starting a charge action is initiating an action.

After

Triggering the action after the profile has finished is not an immediately obvious one. It’s also not something that you often want to do, but depending on the game context it can be useful. It’s most often used when you receive a button press but the avatar is not in a position to perform the action. Imagine a platformer where the player is trying to do consecutive jumps. Do we have to wait for them to land before we pay any attention to them pressing the jump button or do we allow them to press it slightly early and then enact it once they are in a position to do it? One approach provides a timing challenge to the player, the other is much more forgiving. Depending on your game either of these could be appropriate.

If you are going to cache data though. Don’t do it for too long. If the action doesn’t feel tied to the input you run the risk of the player not feeling in control.

The Button

Working out how the player needs to press the button and when to trigger the action is only part of the equation. We also need to figure out which button they press.

History

Each button has a rich history. When working out a control scheme it is important to remember this. People get used to certain buttons doing certain things. In order to invent we often have to “throw out the old” but never throw out the old for the sake of it. The more the player has to adapt specifically for your control system the less pick-up-and-play it is. However good the control scheme is there is a potential frustration penalty that the player has to pay every time they adapt.

Don’t be afraid to reinvent but understand the implications of your reinvention.

Morphology

The morphology of a button has a huge effect on the profiles they support. Most buttons on a modern controller are analogue and so theoretically you can get a detailed profile from the player. However certain buttons are bigger and have more freedom of movement than others. This has the simple effect of making it easier for the player to provide detailed information.

R2 (on the PlayStation SixAxis) for example supports much finer profiles than R1 because of its size and the amount of movement.

If you want fine control go for a big button with the most movement.

Geography

Buttons have a position relative to each other. Some buttons are above others, some are on the back of controllers, some on the top. This affects their accessibility but also affects more directly what functionality is tied to them. When you have some positional controls you may want to consider the position of those buttons on the controller. Having a left positional control on the left and right positional control on the right will appeal to the players intuition. Equally an up control above a down control. Some controls are even more explicitly directional (like the DPAD). The is a temptation to use the DPAD for all kinds of things but when using it I think it’s very important to consider how people will react to it.

If you have things that affect an area on the screen (say a HUD) it’s good to match the controller position to the screen position. If you are dealing with HUD on the left do it with the left of the controller. The reason it helps is because it sets up reinforcement between the controller and the screen. The information you have of the controller helps you understand the screen, the information you have on screen helps you understand the controls.

Another thing to consider is the neighbourhood the button is in. If you have similar controls; clustering them in one area of the controller is often a good idea. This is more of an art than a science. Clusters on a controller are quite subjective. In the following diagram I have circled my suggestions of some clusters.

Keeping similar controls together helps the player get an intuitive feel for the controls.

Last but not least is considering what else the player needs to be doing and (perhaps more importantly) needs to not be doing when they trigger an action. In the former case, you want to make the buttons that the user needs to access simultaneously as accessible as possible. In the latter case, you want to consider how easy it is to accidentally press a button. L3 and R3 are great buttons but are often hit accidentally by less experienced gamers – especially when faced with a myriad of button presses.

A lot of this you will pick up in testing but if we apply a bit of rigour and explicit understanding early on we can identify and rectify these issues up front.

Overloading

Often there comes a point where you run out of buttons, or run out of suitable buttons before you’ve got all your functionality onto the controller and this is where overloading comes in.

Overloading is putting more than one function on one button and then separating it either by context (e.g. a button that does different things depending on what your avatar is near) or by profile (e.g. tap means one thing, hold means another).

Overloading is a great way to get extra functions from the limited buttons of the controller.

The issue with overloading is the potential for misinterpretation. This is when the player presses a button to do action A and instead does action B. There are two causes for this:

  • profile similarity
  • context ambiguity

Profile Similarity

This is when the game identifies an input as one profile when the player intended to provide the other. This is caused by two profiles that are too similar.

In working out how different profiles need to be you should consider how much the player will be affected by a misinterpretation. Misinterpretation might change the action from a low jump to a medium jump which is probably not too serious whereas ‘pickup’ instead of ‘reload’ might mean the difference between life and death.

In general the similarity of the profiles should reflect the similarity of the actions e.g. if SQUARE is used to pickup an item and to reload you want quite different profiles. Whereas low jump, medium jump and high jump benefit from having similar profiles.

Context Ambiguity

Context-overloading is when a button does different things depending on the context of the player. There can we quite hard lines between contexts: like game and menus. You don’t expect CROSS to shoot in menus. It selects. But some of these lines can be much softer.

I played a game recently where a button (I won’t say which one) was used to pick up and reload. There was no profile distinction. If your gun was not full you would reload. If you were within a range of an item you would pick it up. ‘Reload’ was prioritized above ‘pickup’. But this meant it was impossible to pick up an item unless your clip was full. I could approach an item, press my ‘pickup’ button and reload my gun. My avatar would wildly misinterpret my intentions. I could be desperately wanting to pick up a rocket to deal with the attack helicopter but the rules of the system meant that I couldn’t because my pistol only had 14 bullets in the clip.

This is quite an obvious mistake. There are some others that are much more sophisticated.

‘Gears of War’ fairly aggressively overloads one button. It uses a variety of profile and context based overloading to make this as good as it can be and 99% of the time it works great. But the error it makes is in making 2 near opposing actions (enter cover and leave cover) context-overloaded on one button. This would be ok if the context-overloading was rock solid. unfortunately it provides a few circumstances where it is difficult to detect the context.

In the earlier levels of the game I found myself pressing the combination of buttons I thought would heroically spin to nearby cover where I would have a better angle on a sniper. Instead I did a Butch Cassidy and jumped from cover to run at him screaming.

This is one of the dangers of overloading. Because of that one error my sense of immersion was shattered. I did not feel in control of Marcus Fenix. I was frustrated with myself and I was frustrated with the game.

When overloading consider the penalty the player will have to pay for misinterpretation of their input and do whatever you can to mitigate it.

Prompts

A simple method for mitigating it is with on-screen prompts (simply rendering prompts on-screen telling the player what the buttons do). Prompting is used quite a lot in modern games – particularly when there is a shift to a less common context.

There’s nothing wrong with this approach. In a lot of games it acts as an unobtrusive reminder to the player (on the rare occasions they forget the controls). Unfortunately because it’s so effective it is often used, in quite a heavy-handed way, to paste over the cracks of unclear context-overloading.

Prompting (for me) is a support mechanic for good context-overloading.

Combined Overloading

Lastly I would like to talk about using context and profile overloading together e.g. SQUARE normally reloads however if the avatar is near an item and the player inputs a particular profile then they pickup the item. This has the advantage of making it harder to misinterpret the player’s intention.

If you do this though, make sure you have distinct profiles. There is a temptation to have two similar, quite loose profiles so the player can put in any old input when not in the specific context e.g. any press of SQUARE reloads when there’s nothing to pick up and any press of SQUARE picks up when there’s nothing to reload but when there are both, one action has a more demanding profile. The problem with this is that when the player is presented with a situation where both are valid simultaneously they are completely unprepared. They haven’t had the training. They either are totally unaware of the two different profiles or have quite a tough job in providing their chosen one. If the player doesn’t know about them or can’t provide them they may as well not exist. Make the profiles clearly distinct whether in or out of context.

Conclusion

When working out how a player interacts with the game we should consider the range of information available to us explicitly. Any information that can be used to improve the game should be used.

And when we make a control scheme we have to consider it has a whole: how each button relates to each other in position, in function and in context. We have to look at the history of each button.

A control scheme is the player’s way of communicating with the game. We should listen to the player a bit more. This is, after all, what makes a game a game.

Further Reading

One Button Games – Berbank Green