Touch before keyboard: designing controls for a thumb

The default assumption in desktop game development is that the pointer is precise, that it can hover, and that it is always somewhere on the screen. On a phone, none of those is true. A finger is large, imprecise, opaque, and absent until it touches something.

Designing for touch is therefore not a matter of making buttons bigger. It is a matter of not relying on anything a finger cannot do.

The finger is not a small mouse

There is no hover state, so anything that reveals itself on hover does not exist. The touch point is the centre of a contact patch several millimetres across, so a target has to be sized for the patch rather than the point. And the finger covers whatever it is touching, so a control placed under the action it affects will hide the very feedback the player needs.

The practical target size used throughout these games is around forty-four pixels, with generous spacing, and nothing important within a few millimetres of the screen edge — where the operating system's own gestures live.

One gesture, learned in a second

A browser game has a few seconds to teach its control, and it cannot rely on a tutorial being read. The controls here are therefore one of two shapes: a tap anywhere, or a directional swipe. Both are self-evident the first time, which means the game can start without explaining itself.

Tap-anywhere is the stronger of the two when it works, because it removes the question of where to press. Where direction is needed, a swipe is a better fit than dragging a virtual joystick: it is a single gesture with a clear end, it needs no on-screen furniture, and it does not require the player to keep a finger down to hold a direction.

Input belongs to the stage, not the page

These games sit above ordinary page content, and the page continues below them. If keyboard events were handled globally, a player scrolling the text beneath the game with the arrow keys would be steering the game at the same time. If touch were handled globally, a finger-drag on the article below would tile the game instead of scrolling the page.

So input is scoped: the game only consumes events while its stage is actually on screen, and once the player has scrolled past it the page behaves like any other page. That one guard is the difference between a game embedded in a document and a game that fights the document.

Stop the browser from helping

Left alone, a mobile browser will double-tap-zoom, pull-to-refresh, and rubber-band the page when a gesture reaches an edge — all of which interrupt play. The stage declares its own touch behaviour and disables text selection and the tap highlight, so a swipe that reaches the top of the screen does not reload the page mid-run.

Keep the keyboard working anyway

Touch first does not mean touch only. Arrow keys and space cost a few lines and make the games usable on a laptop, which is where a lot of people will first open them. The rule is simply that the keyboard is a bonus and never a requirement: if a game cannot be played with one thumb, it is not finished.