Touch needs redesign rather than porting
Aliases: mobile adaptation · touch interaction · direct manipulation · touch-first
What it is
Touch-first design starts from the real constraints of a touchscreen itself — direct touch, a limited number of simultaneous inputs, finger occlusion, varying grip postures, and sessions that are frequently interrupted — and reorganizes a game's actions, information, and pacing around them, rather than simply drawing controller buttons or keyboard shortcuts as icons on glass. This builds on the two previous entries: both the virtual joystick's positioning problem and finger occlusion are, at bottom, specific consequences that "porting" is bound to run into on a touchscreen. Porting keeps the source device's operation grammar and just changes the skin; redesign keeps the original gameplay intent and finds a genuinely executable path to the same intent on touch as a device.
Why it happens
Touch lacks physical tactile landmarks and cannot support many keys held down at once the way a keyboard can, but it excels at a different category of interaction: directly selecting a specific object, dragging, recognizing gestures, and short, one-off interactions. Porting a complex chord scheme designed for a controller or keyboard-mouse straight onto touch typically forces the thumb to travel a long distance across the screen, has that movement itself obscure the game world, and requires the player to memorize a virtual button layout they cannot even see — these costs stack up and consume a large share of the player's attention on pure operation. Combining a set of previously separate high-frequency actions into one, turning a continuous hold-to-control input into a one-time contextual choice, or letting a triggered state sustain itself automatically for a while instead of requiring the player to keep holding it down — these approaches reduce the operational burden that comes purely from the difference in input method, rather than from anything intrinsic to the game, and give that attention back to genuine strategic judgement.
Where it stops holding
Not every genre of game is suited to becoming a touch version: if a game's core experience is itself built on simultaneous high-precision multi-input — precisely controlling view, movement, and several ability keys all at once, say — the more honest approach is to openly acknowledge the touch version will fall short there, or to design a touch version with a somewhat different experience goal altogether, rather than promising players a touch version delivers identical performance to the original — a promise that, once broken, damages trust in the whole product. Redesign also never means automating away every judgement a player would otherwise make: core decision points, choices that carry risk, and the space for a player to express their own personal operating style should all still survive the redesign — what gets automated away should be pure operational friction, not the gameplay's own depth along with it.
Applying it
- For each specific input on the source device, work backward to identify the player intent it actually serves, then reorganize that intent into whatever touch is good at — a tap, a drag, a gesture, a contextual button, or an adjustable assist — rather than keeping the original input's form.
- Build and test prototypes of the core gameplay loop under real one-handed grip, two-handed grip, and while the player is actually moving, rather than validating the layout only in a desktop simulator — a simulator cannot surface the problems that only appear under real grip and real movement.
- How to check: compare a directly ported version against a redesigned one on target visibility, misoperation count, task success rate, and the strategy players actually adopt. If the ported version's failures trace mainly to operation rather than to the player's own strategic judgement going wrong, that is the signal this game genuinely needs a redesign, rather than incremental patching of the ported version.