Touch Controls for Mobile Web Games

Set Up the Canvas for Touch Input

The first step is telling the browser that your game canvas handles its own touch input. Apply the CSS property touch-action: none to the canvas element. This single declaration prevents the browser from intercepting touches for scrolling, pinch-to-zoom, double-tap-to-zoom, and pull-to-refresh. Without it, a player dragging their thumb to move a character will scroll the entire page instead.

In your CSS, add touch-action: none to the canvas selector. If your game canvas is full-screen, also apply it to the html and body elements to prevent any residual scroll behavior at the document level. Then, when registering touch event listeners on the canvas, pass { passive: false } as the third argument. This tells the browser that the listener may call preventDefault(), which is necessary for suppressing any remaining default touch behaviors. A passive listener cannot call preventDefault(), and the browser will log a warning if you try.

You should also set user-select: none on the canvas to prevent the browser from trying to select text or images when the player long-presses during gameplay. On iOS Safari, adding -webkit-touch-callout: none prevents the context menu that appears on long press. These CSS properties combined create a canvas element that behaves like a native game surface rather than a web page.

Translate Touch Coordinates to Canvas Space

Touch events report coordinates relative to the browser viewport (clientX, clientY) or the page (pageX, pageY). Your game logic needs coordinates relative to the canvas element, accounting for both the canvas position on the page and any difference between the canvas display size and its internal resolution.

Call canvas.getBoundingClientRect() to get the canvas element's position and size in viewport coordinates. Subtract rect.left from clientX and rect.top from clientY to get coordinates relative to the canvas display area. Then scale these values by the ratio of the canvas internal resolution to its display size. If the canvas internal width is 1920 but it displays at 960 pixels wide, multiply the canvas-relative X by (1920 / 960) to get the correct internal coordinate.

Cache the bounding rect at the start of each frame or whenever the window resizes, rather than calling getBoundingClientRect() on every touch event. This function triggers a layout recalculation in some browsers, and calling it dozens of times per second during rapid touch movement can introduce measurable overhead. A single cached value updated on resize and orientation change is sufficient.

Track Multiple Touch Points

Multi-touch is what allows a player to move with one thumb while shooting with the other. Each Touch object in a touch event has an identifier property, an integer that stays constant for that finger from touchstart through touchend. Store active touches in a Map keyed by identifier, updating positions on touchmove and removing entries on touchend and touchcancel.

Use the changedTouches array on each event, not the touches array, to process only the fingers that changed. On touchstart, iterate changedTouches to register new fingers. On touchmove, iterate changedTouches to update positions. On touchend and touchcancel, iterate changedTouches to remove fingers. The touches array gives you all active touches, which is useful for counting fingers but less efficient for event processing.

A common pattern is to assign each new touch to a game function based on where it started. If the touch starts in the left half of the screen, it controls movement. If it starts in the right half, it controls aiming or firing. The assignment is locked to that touch identifier for its entire lifetime, so even if the player drags their movement finger across the screen midline, it still controls movement. This zone-based assignment is the foundation of dual-stick virtual controls.

Eliminate Ghost Clicks and the Tap Delay

Historically, mobile browsers added a 300-millisecond delay between a tap and the resulting click event. This delay existed so the browser could wait to see if the user was double-tapping to zoom. For games, 300 milliseconds of input lag is unacceptable. The touch-action: none CSS property from step one eliminates this delay in modern browsers, because when zooming is disabled, the browser no longer needs to wait.

Ghost clicks are a related problem. When a touch event fires, the browser may generate a synthetic mousedown, mouseup, and click event about 300 milliseconds later, aimed at the same coordinates. If your game listens to both touch events and mouse events (as it should for cross-platform support), it will process two inputs for a single tap. The cleanest solution is to set a flag when any touch event fires, and ignore mouse events for the next 500 milliseconds. Reset the flag when the timer expires. This approach lets the game respond to genuine mouse clicks on desktop while filtering out synthetic clicks generated from touch events on mobile.

An alternative is to check the event type at the start of your input handler. If the event is a TouchEvent, process it as touch. If it is a MouseEvent, check whether a touch event fired recently and skip if so. Both approaches work, but the flag-based method is simpler to reason about and less prone to edge cases.

Define Touch Zones for Game Actions

Most action games divide the screen into zones. The left side controls movement (usually with a virtual joystick), and the right side controls actions (fire, jump, interact). Some games use the bottom third for controls and the top two-thirds as a pure display area. The zone layout depends on the game genre and the controls it needs.

Define zones as rectangles or circles in canvas coordinates. When a new touch starts (touchstart), check which zone contains the touch point and assign that touch identifier to the corresponding game action. Update the game state on touchmove as the finger moves within or across zones. Release the action on touchend. If the touch starts outside any defined zone, ignore it or assign it to a default action like camera panning.

For games with virtual joysticks, the movement zone is where the joystick base appears (or spawns dynamically). The joystick thumb tracks the finger's position relative to the base center, producing a direction vector and magnitude. For games with virtual buttons, each button is a zone that triggers on touchstart and releases on touchend. Buttons should be large enough (at least 44 by 44 pixels per accessibility guidelines, ideally 60 to 80 pixels for game controls) and spaced apart to avoid accidental presses.

Orientation changes (portrait to landscape or vice versa) require recalculating zone positions. Listen for the resize event or the orientationchange event and update zone boundaries when they fire. Many games lock orientation to landscape using the Screen Orientation API or a prompt asking the player to rotate their device.

Optimize for Low Latency

Input latency is the total delay from the player's finger press to the game's visible response. On mobile browsers, this includes the touch hardware scanning interval (usually 60 to 120 Hz), the browser's event delivery pipeline, and the game's own processing time. You cannot control the hardware, but you can minimize the software side.

Mark touch event listeners as { passive: false } so the browser does not defer them. Update your internal input state directly inside the event handler, rather than queuing events for later processing. Use requestAnimationFrame for the game loop, and read the input state at the very start of each frame so the data is as fresh as possible when you apply it to game logic.

Avoid doing heavy work inside touch event handlers. The handler should update coordinates and flags, nothing more. Any game logic, physics, or rendering should happen in the game loop. Heavy handlers delay the browser's event pipeline and increase latency for subsequent events.

On high-refresh-rate mobile displays (90 Hz or 120 Hz), requestAnimationFrame runs more frequently, which naturally reduces the worst-case input latency. If your game can maintain the higher frame rate, the controls will feel noticeably snappier than at 60 Hz. Profiling with the browser's performance tools can reveal whether your frame budget allows it.