Why touch controls fail, and what to do instead
Most touch controls fail for the same handful of reasons. Here is each failure, the fix, and the games on this site that use it.
By Aayush Kumar · Interface design · 9 min read
A game pad has edges you can feel. A touchscreen has none. Every failure of touch controls traces back to that: your thumb cannot find anything without looking, and looking is what you cannot spare while playing. Most fixes remove the need to look.
The thumb only reaches so far
Hold a phone one-handed and your thumb sweeps an arc, not a rectangle: the bottom third and the side nearest your thumb are comfortable, the far top corner needs a change of grip. Two-handed, you get two arcs in the bottom corners and a dead band up the middle. Everything follows from that map. Controls belong in the bottom corners, information at the top where the eye goes and the thumb does not, and anything that must be hit under pressure belongs where the thumb already rests rather than where the layout looks tidiest.
Drive Mayhem is the clean case because it needs two inputs: large thumb pedals in the bottom corners, brake left and gas right, with Retry beside them. Nothing else to hit, nothing to learn. Ridge Rally uses the identical layout. Both are about modulation rather than precision, so a large forgiving target in the right place is the whole interface.
On-screen D-pads are the wrong answer
A D-pad drawn on glass is a bad control, and it is worth being blunt about why. It has four zones with hard boundaries you cannot feel, so your thumb drifts across one mid-movement and the character stops. It sits at a fixed position, so a thumb landing two millimetres off is pressing nothing. And diagonals are either impossible or produced by hitting a corner you cannot locate.
The replacement is the floating stick: the moment your thumb lands anywhere in its half of the screen, that point becomes the stick's centre, and the direction and distance of your drag from it is the input. There is no fixed position to miss, because the control moves to you. Twenty-six games here use one.
let origin = null;
zone.addEventListener('pointerdown', e => {
origin = { x: e.clientX, y: e.clientY };
zone.setPointerCapture(e.pointerId);
});
zone.addEventListener('pointermove', e => {
if (!origin) return;
const dx = e.clientX - origin.x, dy = e.clientY - origin.y;
const len = Math.hypot(dx, dy) || 1;
const mag = Math.min(len, MAX_RADIUS) / MAX_RADIUS;
input.x = (dx / len) * mag;
input.y = (dy / len) * mag;
});
zone.addEventListener('pointerup', () => { origin = null; input.x = input.y = 0; });
Two details there matter more than the maths. setPointerCapture means that once your thumb is down, every move event goes to that element even if the thumb wanders off it — without it, dragging past the edge of the stick's box silently drops the input, which feels like a freeze. And clamping the magnitude to a maximum radius stops a wild drag producing a wild speed.
Hole Eater and Ball Eater both raise a stick under your thumb wherever you press. Space Rock Breaker makes it absolute: the ship turns towards wherever you push and thrust scales with how closely it already faces that way, so it cannot fire its engine while pointing backwards. That has a real cost — the phone version is easier to steer and useless for the classic retro-burn.
Tap-to-aim against drag-to-aim
The other big split is how you point at something. Tapping is fast and imprecise, because your finger covers the target. Dragging is slower and far more precise, because the result updates while you adjust and you commit by lifting rather than by touching.
Anything requiring accuracy should drag. 8 Ball makes you pull the cue back from the white like a catapult, so aim and power come from one gesture, with a guide line running out to a hollow circle marking where the white will sit at contact, a second line for the object ball and a fainter one for the tangent. Carrom Clash uses the same pull-and-release. Doodle Duel sets barrel angle and power together with one drag back from your tank, and tells you to drag well past it, because short drags cancel rather than fire — the alternative, treating a tiny drag as a tiny shot, wastes turns by accident.
Tapping belongs to games where the target is large or the decision is discrete. Four in Line taps a column. Ludo taps the dice and then a glowing token — two taps for a whole turn. Chess taps a piece to light its legal squares, then a destination; the two-stage form works because the first tap is reversible and the lit squares tell you what the second can be.
Slime Shooter is the hybrid, because its launcher slides continuously and cannot be parked. A finger recalculates the angle from wherever the launcher currently is, so the shot tracks your target as it slides; the arrow keys hold a fixed angle that travels with it, which is what you want for repeated wall bounces. Neither is better.
Kill scroll, zoom and everything the browser does helpfully
The browser is trying to help. Left alone it will scroll the page when you drag, zoom when you pinch, bounce at the edges, select text when you hold, show a magnifier, flash a grey highlight on tap, and fire a synthetic click 300 milliseconds after your real one. Every one of those is wrong inside a game. The fix is a short block of CSS that appears, in some form, in all 78 games here:
html, body { margin: 0; width: 100%; height: 100%; overflow: hidden; }
body {
touch-action: none; /* no scroll, no pinch-zoom, no double-tap zoom */
overscroll-behavior: none; /* no rubber-band at the edges, no pull-to-refresh */
user-select: none;
-webkit-user-select: none;
-webkit-touch-callout: none; /* no long-press menu on images and links */
-webkit-tap-highlight-color: transparent;
}
touch-action: none is the important one, and it needs discrimination: correct on the game surface, wrong on a settings panel that genuinely needs to scroll. Use none on the playfield and manipulation on buttons and panels — manipulation keeps scrolling and pinch but drops the double-tap-to-zoom delay, so a button responds the instant you touch it.
The viewport tag does the rest:
<meta name="viewport" content="width=device-width, initial-scale=1,
maximum-scale=1, user-scalable=no, viewport-fit=cover">
user-scalable=no is hostile on a web page and correct in a game, because a two-finger pinch in a two-player game is not a zoom request, it is two players. viewport-fit=cover lets the page paint under the notch and home indicator, which is only safe alongside the next item.
Safe-area insets, or why your fire button is under the home bar
Modern phones have a notch, rounded corners and a home indicator bar. Paint edge to edge and put a button in the bottom-left corner, and that button sits under a system gesture area where the operating system takes your touch and swipes the browser away instead.
The browser exposes the physical intrusions as environment variables, and every game here uses them:
.hud-top { padding-top: calc(12px + env(safe-area-inset-top)); }
.controls { padding-bottom: calc(16px + env(safe-area-inset-bottom)); }
.left-stick { margin-left: env(safe-area-inset-left); }
On a phone without a notch these resolve to zero and nothing changes. On one with a notch, held sideways, the left inset can be 44 pixels, which is exactly the difference between a usable thumbstick and one half-buried under the rounded corner. Landscape is where this matters most, and landscape is how most of these games are held.
The 60fps question on a mid-range Android
Sixty frames per second means 16.7 milliseconds per frame for everything: input, simulation, and drawing. On a flagship that is generous. On a four-year-old mid-range Android with a 1080×2400 screen it is not, and the single biggest cost is usually resolution rather than logic.
A canvas scaled naively to a high-density display renders at the device pixel ratio, which can be 3 or 4. At ratio 3 you are filling nine times as many pixels as at ratio 1. The standard fix is to clamp it:
const dpr = Math.min(window.devicePixelRatio || 1, 2);
canvas.width = Math.round(cssWidth * dpr);
canvas.height = Math.round(cssHeight * dpr);
canvas.style.width = cssWidth + 'px';
canvas.style.height = cssHeight + 'px';
ctx.setTransform(dpr, 0, 0, dpr, 0, 0);
Clamping at 2 is the sweet spot: text and curves still look sharp, and you have thrown away more than half the pixel work compared with ratio 3. This appears in around ninety places across the 3D games here, which need it most.
The second fix is to stop assuming you got your frame. Fix the simulation to elapsed time and clamp that elapsed time, so a dropped frame slows the game briefly instead of teleporting objects through walls — the game loop is covered in more detail here. The third is to stop drawing entirely when nobody is looking: every game listens for visibilitychange and pauses, which saves battery and stops a phone in a pocket from rendering an invisible match.
When the honest answer is that touch cannot do it
Some control schemes do not survive the translation, and saying so is better than shipping a bad version of them.
Bike Rush 3D has two steering pads and a gas button on touch, and no brake at all — releasing the gas is how you slow down. That is a deliberate removal: a fourth control would have crowded the bottom of the screen, and at the speeds involved the brake was barely used. Stick Fighter and Sumo Fighter both have good touch controls for one player and simply cannot do two players on touch; their second player needs a keyboard. Bumper Kart Arena is the same.
And some games are better on touch than anywhere else. Emoji Drawer wants a finger, not a mouse. Perfect Circle is a different game with a trackpad, and a worse one. Voxel Vault treats short taps as swipes, so a flick is enough to roll the block, which is faster than any key. The question is never whether touch is worse than a keyboard. It is which of the two the game was shaped for — and for two people sharing one handset, there is no keyboard in the conversation at all.
More from ARTHIS.space
- Local multiplayer The best two-player games when you only have one phone Three genuinely different answers to the problem of fitting two players onto one handset, what each one costs, and the games on this site that get it right.
- Party games Games for a group standing around one screen Six games that put one phone in the middle of a room, what each needs from the group, and an honest note about which are really one-player games with an audience.
- How it works How a whole game fits in a single web page A tour of what a browser hands you for free, why canvas and requestAnimationFrame are enough to build on, and the four places this approach genuinely runs out.