Touch, keys, or thumbs: designing controls that work everywhere
Most of our players arrive from a phone, tap a link, and are in a game three seconds later. A good number of others play on a laptop over lunch. A control scheme that only serves one of those people throws the other one away â so every game in this arcade has to answer the same question before it ships: how does this feel on a phone, and how does it feel on a keyboard?
Touch is the first-class citizen
The biggest mistake touch ports make is treating a finger like a mouse cursor. A finger is attached to a hand, and the hand covers the screen. That's why Neon Breaker doesn't ask you to touch the paddle â you drag anywhere on the play field and the paddle follows, so your hand stays out of the ball's way. It's a small decision you stop noticing immediately, which is exactly the point.
Circuit Serpent has the opposite problem: a snake wants four crisp directions, and a casual brush of the thumb isn't a direction. So the swipe detector insists on a minimum distance and a clear axis before it commits â what we call honest swipe detection. A gesture either clearly means "left" or it means nothing. Guessing would feel responsive right up until it kills you.
One button is a control scheme too
Star Hopper takes the purist route: the entire game is one input. Tap the screen or press a key, get one fixed pulse of thrust. Because a tap can't be held or mashed into an advantage, the phone player and the keyboard player are competing on exactly the same physics â which is the quiet fairness rule behind every control decision here.
When a game needs a D-pad, draw one
Sky Runner wants continuous steering in two axes, and that's the one job a bare touchscreen does badly â there's nothing to rest your thumb against. Our fix is an on-screen D-pad drawn below the play area, not floating over it. Your thumb gets a home, the sky stays visible, and nothing important ever hides under your hand. Keyboard players never see it; they get the arrow keys they already expected.
The checklist we actually use
Before a game goes live it has to pass three sessions: one on a mid-range Android phone held in a hand, one with a mouse or trackpad, and one on the keyboard alone. Any input that needs explaining gets redesigned â the only tutorial a browser game gets is its first three seconds. The same rule carried into our first 3D game, Iron Shore, which reads touch and arrow keys through one shared input layer: the camera work is new, but the promise is the same. However you found the arcade, the controls were already waiting for you.