Touch controls: the fallacy of choice

Touch controls: the fallacy of choice

Touch controls: the fallacy of choice

Offering the player a choice of controls is a good thing, right? It means that all players can choose a method of interaction to suit their own preferences. On many iOS or Android games it’s common to see a range of control schemes available which, broadly speaking, can be split into several basic forms: tilt-based controls and the varying forms of touch – direct manipulation, virtual D-pads, steering wheels and twin-sticks.

But I’ve found this approach introduces a few problems. Firstly, the developer has to write the code to support each control scheme. This means they have to spend time to implement multiple different control schemes, and then spend further time refining the experience offered by each. 

Secondly, they have to choose which control scheme to make default. This may sound like a trivial issue – surely they can just select whichever and leave it to the user to find the one they like best? But while you’d like to think that all players would take the time to explore all possible control alternatives, the reality is the risk that many gamers may try out a game, not like the controls, and immediately dismiss it. Making control alternatives available does not mean the player will try them out.

You’d think, then, that developers would invest significant effort to get the default controls right. Some do – Real Racing HD’s default tilt control mode is the best of the five options on offer, although later we’ll discuss what ‘best’ actually means.

However, another iPad game, Reckless Racing HD, has virtual buttons as default. Although usable, they don’t feel satisfying or are designed to make best use of what a touchscreen can offer. Although touchscreens support the binary interaction method of finger down, finger up, it’s typically more satisfying to use gestures to indicate motion. For this reason, I feel that Reckless Racing’s Full Wheel control option, with some refinement, should have been the default. 

Some games offer only one choice: Need For Speed Hot Pursuit on iPad offers only tilt. And it’s good. It feels as if the developer made a conscious design decision about how its game should be experienced, then put all its effort into making sure it felt as good as it intended. It’s also possible that it implemented several control methods, evaluated them, then chose the one with the best experience.

But wouldn’t it be useful if there was a way of determining the best control scheme from a range of alternatives?

One easy-to-apply method that I sometimes use to assess alternative game controls can be used even before a game has been coded.  Recently I have been testing an upcoming iOS game called Battle Squadron ONE, a remake of Battle Squadron, a vertical scrolling shooter which appeared on the Amiga in 1989 to critical success. The version of the build I was evaluating had four different control schemes, and after trying all of them I ranked them in my order of preference. However I wanted to understand why I ranked them this way, could I replace my intuition with a more scientific method of analysis?