Cross-Platform Game Controls: Touch, Keyboard, Mouse and Gamepad for Web Games
In This Guide
Why Input Is the Hardest Part of Web Games
Web games have an enormous advantage over native games: they run everywhere a browser runs. A single URL can reach desktop monitors, laptops, tablets, phones, and even TVs running browser apps. But that universality comes with a problem native developers rarely face. A phone has no keyboard. A laptop often has no touchscreen. A console controller has no mouse cursor. The same game code must handle all of these gracefully, or large segments of the potential audience simply cannot play.
The browser provides four separate input APIs, each with its own event model, timing behavior, and browser-specific quirks. Touch Events give you multi-finger tracking on mobile devices. Keyboard Events report key presses and releases. Mouse Events handle cursor positioning, clicks, and scroll wheels. The Gamepad API polls connected controllers for button states and analog stick positions. None of these APIs are aware of each other, and none of them speak the same language. A touch drag and a mouse drag mean the same thing to the player, but they arrive through completely different code paths.
Desktop game engines like Unity and Unreal abstract this away behind their own input systems. Web game developers working with raw APIs or lightweight frameworks like Phaser, PixiJS, or Babylon.js often need to build this abstraction themselves. The effort is worth it. Players expect controls to just work on whatever device they pick up. A web game that shows a "use a keyboard" message on a phone has already lost that player.
Cross-platform input also affects game design decisions. A real-time strategy game that relies on precise mouse clicks needs a completely different interaction model on a touchscreen. A platformer designed for a d-pad feels sluggish with swipe gestures. The best web games design their controls from the ground up to support multiple input methods, rather than bolting touch support onto a keyboard-first design as an afterthought.
The Four Input Methods
Every web game needs to consider four categories of input, each with distinct characteristics that affect game feel and player experience.
Touch
Touch is the primary input on phones and tablets. The Touch Events API provides multi-touch tracking through the touchstart, touchmove, touchend, and touchcancel events. Each event carries a list of active touch points with coordinates, identifiers, and target elements. Touch input is imprecise compared to a mouse cursor, since a fingertip covers a larger area than a pixel-precise pointer. It also lacks physical feedback, which is why most mobile games overlay virtual buttons, joysticks, or gesture zones on top of the game canvas. Multi-touch allows simultaneous actions like moving and shooting at the same time, but managing multiple touch identifiers adds complexity.
Keyboard
Keyboard input is the desktop baseline for web games. The KeyboardEvent interface fires keydown and keyup events with information about which key was pressed. The event.code property identifies the physical key location (like "KeyW" or "ArrowLeft") regardless of the user's keyboard layout, making it the right choice for game controls. The event.key property returns the character produced by the key, which is better for text input but wrong for WASD movement on non-QWERTY keyboards. Keyboard input is discrete and binary, meaning a key is either pressed or not, with no analog range.
Mouse
Mouse input provides continuous two-dimensional positioning through mousemove events, binary button states through mousedown and mouseup, and scrolling through the wheel event. For games that need first-person camera control, the Pointer Lock API captures the mouse cursor and reports raw delta movement instead of screen coordinates. Mouse input is extremely precise, supports right-click and middle-click for secondary actions, and is almost always paired with keyboard input on desktop. The combination of mouse aiming with keyboard movement is so standard in PC gaming that many players consider it the default.
Gamepad
The Gamepad API lets web games read input from USB and Bluetooth controllers, including Xbox, PlayStation, Switch Pro, and generic HID gamepads. Unlike the other three input methods, the Gamepad API uses a polling model rather than events. The game calls navigator.getGamepads() on each animation frame and reads the current button and axis states from the returned Gamepad objects. Controllers provide analog input through thumbsticks and triggers, giving players variable-speed movement and pressure-sensitive actions that keyboards cannot replicate. The standard mapping layout assigns consistent indices to buttons across different controller brands, though non-standard controllers may report buttons in unexpected positions.
How Touch Input Works in the Browser
Touch input in the browser operates through two overlapping APIs: Touch Events and Pointer Events. Touch Events are the original mobile input API, supported everywhere, with fine-grained multi-touch control. Pointer Events are a newer unified API that handles touch, mouse, and pen input through a single set of events, but they flatten multi-touch into separate pointer IDs, which can be harder to manage for complex gestures.
The core Touch Events are touchstart, touchmove, touchend, and touchcancel. Each event object contains three lists: touches (all active touch points), targetTouches (touch points on the same element), and changedTouches (the touch points that triggered this specific event). Each individual Touch object has properties including clientX and clientY for viewport coordinates, pageX and pageY for page coordinates, identifier for tracking a specific finger across events, and target for the element that was initially touched.
Preventing default behavior is critical for game controls. Without calling event.preventDefault() on touchstart and touchmove, the browser will attempt to scroll the page, zoom on pinch, or trigger the pull-to-refresh gesture on mobile Chrome. The CSS property touch-action: none on the game canvas is the modern way to disable these behaviors declaratively, and it also eliminates the 300-millisecond tap delay that older mobile browsers introduced to distinguish single taps from double-tap-to-zoom gestures.
Ghost clicks are another common pitfall. When a touch event fires and the browser also generates a synthetic mouse click about 300 milliseconds later, games that listen to both touch and click events will register two actions for a single tap. The simplest fix is to handle touch events exclusively on touch devices, or to use a flag that suppresses mouse events for a brief window after any touch event fires.
Touch coordinates need translation for canvas-based games. The clientX and clientY values are relative to the browser viewport, not the canvas element. Developers must subtract the canvas bounding rectangle's position and account for CSS scaling if the canvas display size differs from its internal resolution. Getting this wrong produces controls that are offset from where the player's finger actually lands, which feels broken instantly.
Virtual Controls for Touchscreens
Since touchscreens have no physical buttons, mobile web games must render their own controls on top of the game view. The most common virtual controls are joysticks for directional movement, buttons for discrete actions like jumping or shooting, and gesture zones for swipes or taps in specific screen regions.
A virtual joystick consists of a base circle and a movable thumb that the player drags with their finger. The game reads the angle and distance of the thumb from the center to determine movement direction and speed. Static joysticks stay in a fixed screen position, which is familiar but can be awkward if the fixed position does not match where the player's thumb naturally rests. Dynamic joysticks appear wherever the player first touches the screen, which feels more natural but can interfere with other touch targets if the spawn zone is not carefully restricted.
Sizing matters enormously for virtual controls. Apple's Human Interface Guidelines recommend a minimum touch target of 44 by 44 points, but game joysticks typically need to be larger, in the range of 100 to 140 pixels in diameter, to allow comfortable thumb movement. The controls should be semi-transparent so they do not obscure the game world, but opaque enough that players can see where their thumbs are relative to the control boundaries. A common approach uses 30 to 50 percent opacity for the base and a slightly higher opacity for the thumb.
Dead zones prevent jittery input when the player's thumb is near the center of the joystick. A dead zone of 10 to 15 percent of the joystick radius means the game reads zero input until the thumb moves past that threshold. Without dead zones, a player's thumb resting on the joystick will produce tiny, unwanted movements. Sensitivity curves (also called response curves) control how joystick displacement maps to game speed. A linear curve means 50 percent deflection gives 50 percent speed. A quadratic curve makes small movements slower and large movements faster, which gives players more precision at low speeds.
Virtual buttons should provide visual feedback on press, typically by changing color, scaling slightly, or increasing opacity. Without feedback, the player cannot tell whether their tap registered, which leads to frantic repeated tapping and frustration. Some implementations also use the Vibration API to provide a brief haptic pulse on button press, though this API is only available on Android and should always be optional.
Canvas-based virtual controls render directly into the game's drawing surface, which avoids DOM overhead and keeps everything in a single coordinate system. DOM-based virtual controls use positioned HTML elements overlaying the canvas, which makes styling easier but can introduce layout complications on different screen sizes and orientations. Both approaches work well, and the choice usually depends on whether the game already uses a canvas rendering pipeline or an HTML-based UI layer.
Keyboard and Mouse Input
Keyboard input for games differs from keyboard input for text fields. Game controls need to track which keys are currently held down, not just which key was pressed. The standard approach is to maintain a Set or object of active keys, adding entries on keydown and removing them on keyup. This allows the game loop to check the current state of any key at any time, rather than reacting to events as they arrive.
The KeyboardEvent.code property is the correct choice for game controls because it identifies the physical key position on the keyboard, regardless of the user's language layout. When a French player presses the "A" key on their AZERTY keyboard, event.key returns "q" (since Q is in the A position on AZERTY), but event.code returns "KeyA" consistently. Using event.code means WASD movement works correctly on any keyboard layout without remapping. The older event.keyCode property is deprecated and should not be used in new code.
Some key combinations conflict with browser shortcuts. Ctrl+W closes the tab, F5 reloads the page, and Ctrl+S opens the save dialog. Games should avoid using these combinations for gameplay actions. If a game must use F-keys or modifier combinations, calling event.preventDefault() on the keydown event can suppress the browser behavior, but this should be done sparingly and only when the game has focus. Overriding browser shortcuts frustrates players who use them intentionally.
The keydown event fires repeatedly when a key is held down, with a delay set by the operating system's key repeat rate. For games, this repeat behavior is unwanted. The event.repeat property is true for these synthetic repeat events, and game input handlers should ignore them. Only the initial keydown (where event.repeat is false) and the keyup matter for maintaining the active keys state.
Mouse input in games typically combines movement tracking with button state. For top-down or strategy games, the mouse position on the canvas determines where the player is aiming, selecting, or placing objects. Canvas coordinate translation is required, just as with touch input. For first-person games, the Pointer Lock API (document.requestPointerLock()) captures the cursor inside the game element, hides it, and reports movementX and movementY deltas on each mousemove event instead of absolute screen coordinates. This allows unlimited mouse rotation without the cursor hitting screen edges.
Pointer Lock requires a user gesture to activate, which means the game must prompt the player to click the canvas before locking. The lock can be lost if the player presses Escape or switches tabs. Games should listen for the pointerlockchange event and display a "click to resume" overlay when the lock is released. The pointerlockerror event handles cases where the browser denies the lock request, which can happen if the game attempts to lock too quickly after a previous unlock.
For games that need both mouse aiming and keyboard movement simultaneously, the input system must be able to read the current mouse position and the current set of held keys on every frame. This is why the polling approach (reading state each frame) is preferred over the purely event-driven approach (reacting to each event individually). The event handlers update the state, and the game loop reads it.
The Gamepad API
The Gamepad API enables web games to read input from game controllers connected via USB or Bluetooth. It is supported in all modern browsers including Chrome, Firefox, Safari, and Edge. The API uses a polling model: there are no events for button presses or stick movements. Instead, the game calls navigator.getGamepads() on every animation frame and reads the current state from the returned array of Gamepad objects.
Two connection events are available: gamepadconnected and gamepaddisconnected, both fired on the window object. The gamepadconnected event provides the Gamepad object as event.gamepad, which includes the controller's id string (like "Xbox Wireless Controller"), its index in the gamepads array, and its initial button and axis states. These events are useful for showing UI prompts like "Controller connected" but not for reading input during gameplay.
Each Gamepad object has a buttons array and an axes array. Buttons have a pressed boolean and a value float between 0.0 and 1.0, which matters for analog triggers that report partial depression. Axes are floats from -1.0 to 1.0 representing stick positions, where -1 is left or up and +1 is right or down. A standard-layout controller has 17 buttons (face buttons, shoulders, triggers, thumbstick clicks, d-pad, start, select, and home) and 4 axes (left stick X, left stick Y, right stick X, right stick Y).
The mapping property indicates whether the controller uses the standard layout. When mapping equals "standard," the button and axis indices follow the W3C specification, and the game can use consistent indices across controller brands. When mapping is empty, the controller reports buttons in a manufacturer-specific order, and the game may need a remapping UI or a controller database to handle it correctly.
Analog stick dead zones are essential for gamepad input. Even when the player is not touching the stick, most controllers report small non-zero values due to manufacturing tolerances. A dead zone of 0.15 to 0.25 (on the 0 to 1 scale) is typical. The dead zone should be applied radially for thumbsticks, meaning the game computes the stick's distance from center and only registers input when that distance exceeds the threshold. Applying dead zones per-axis instead of radially creates a square dead zone that feels unnatural.
Haptic feedback is available on some controllers through the GamepadHapticActuator interface. The vibrationActuator property (when present) exposes a playEffect() method that can trigger dual-rumble vibration with separate strong and weak motor intensities. Browser support varies, and haptics should always be optional since not all controllers support them and some players find vibration distracting.
Building a Unified Input System
A unified input system is an abstraction layer that sits between the raw browser APIs and the game logic. The game never asks "is the spacebar pressed?" or "did the player touch the screen?" Instead, it asks "is the jump action active?" The input system maps hardware events to game actions, and the game code only knows about actions.
The core concept is an action map: a configuration that binds game actions to one or more physical inputs. A jump action might be bound to the spacebar, the A button on a gamepad, and a tap on the right side of the screen. A move-left action might be bound to the A key, the left arrow, the left d-pad button, and a left deflection on either a gamepad stick or a virtual joystick. The action map makes it straightforward to add gamepad support later, since the game logic does not change at all.
Digital actions like jump or shoot are either active or inactive. Analog actions like movement direction need a float value. The input system should normalize all sources to the same range, typically -1.0 to 1.0 for directional axes and 0.0 to 1.0 for triggers or buttons. A keyboard press maps to 1.0 (or -1.0 for the negative direction), while a gamepad stick provides the analog value directly. This normalization means the game can use the same movement code regardless of whether the player is using a stick or a keyboard.
Hot-swapping input methods is important for a smooth experience. When a player connects a gamepad mid-game, the UI should switch to show gamepad button icons instead of keyboard prompts. When the player starts typing on the keyboard, the icons should switch back. The input system can track which input source last produced a non-zero value and use that to determine the "active" input method for UI purposes.
Conflict resolution handles cases where multiple inputs fire simultaneously. If the player presses both left and right on the keyboard, the game might cancel them out (zero net movement) or prioritize the most recent press. If a gamepad and keyboard are both active, the game typically uses whichever produced the most recent input. These decisions are game-specific, but the unified input system should make them easy to configure.
Responsive Control Layouts
Web games must adapt their control scheme to the player's device, and that means detecting what input methods are available and adjusting the UI accordingly. The most reliable detection method is to check for touch support using window.matchMedia('(pointer: coarse)').matches, which returns true on touch-primary devices. The hover media query (pointer: fine) identifies mouse-primary devices. Checking 'ontouchstart' in window detects touch capability but returns true on some laptops with touchscreens, where touch controls would be unnecessary alongside the keyboard.
When touch is the primary input, the game should display virtual controls (joystick, buttons) on the screen. When keyboard and mouse are primary, virtual controls should be hidden. If a gamepad is connected, the game may hide virtual controls and show gamepad-specific UI. The transition between these states should be seamless: if a tablet user connects a Bluetooth gamepad, the virtual controls should fade out and the gamepad should take over immediately.
Orientation changes matter significantly for mobile games. Landscape mode provides more horizontal space, which is standard for action games and platformers. Portrait mode is common for casual games and puzzle games. The game should listen for orientation changes via window.matchMedia('(orientation: landscape)') or the resize event, and reposition virtual controls accordingly. In landscape mode, joysticks typically go in the bottom-left and action buttons in the bottom-right. In portrait mode, controls might stack vertically or the game may restrict to landscape-only and display a rotation prompt.
Modern phones with notches, rounded corners, and gesture bars have safe areas that content should avoid. The CSS environment variables env(safe-area-inset-top), env(safe-area-inset-bottom), env(safe-area-inset-left), and env(safe-area-inset-right) report these insets. Virtual controls positioned at the very edge of the screen may be partially hidden by the notch or unreachable due to the system gesture zone at the bottom of the screen. Applying safe area insets to control positioning ensures they remain fully visible and usable on all devices.
Input Latency and Frame Timing
Input latency is the delay between the player pressing a button and the game reacting on screen. In web games, this latency comes from several sources: the time for the browser to fire the input event, the time for the game loop to read and process it, and the time to render the next frame. At 60 frames per second, each frame lasts about 16.7 milliseconds. If an input event arrives just after the game loop finishes processing for the current frame, it will not be read until the next frame, adding up to 16.7 milliseconds of latency on top of the inherent event delivery time.
The standard game loop pattern using requestAnimationFrame() processes input, updates game state, and renders in sequence on each frame. Input events that fire between frames are queued by the browser and dispatched before the next requestAnimationFrame callback. The game's event handlers should update input state variables immediately, and the game loop should read those variables at the start of each frame. This pattern minimizes latency because the state is always as fresh as possible when the game loop runs.
Input buffering is a technique where the game records the most recent input event and its timestamp, then processes it on the next frame even if the processing deadline for the current frame has passed. This prevents dropped inputs in situations where the frame rate dips and events pile up between frames. For fast-paced action games, missing a jump or attack input because the frame took too long to render is unacceptable.
Touch input on mobile browsers tends to have higher latency than keyboard or mouse input on desktop, partly due to the touch hardware and partly due to the browser's compositor handling touch events for scrolling. Using touch-action: none on the game canvas and marking touch event listeners as { passive: false } ensures the browser does not delay touch events to check for scroll gestures. On modern mobile browsers, these optimizations can reduce touch latency by 50 to 100 milliseconds.
Making Controls Accessible
Accessible game controls let more people play, including players with motor impairments, limited mobility, or situational disabilities like a broken arm or a one-handed hold on public transit. Accessibility is not a niche concern: the Xbox Adaptive Controller and PlayStation Access Controller exist because millions of players need alternative input methods.
Remappable controls are the single most impactful accessibility feature. Every game should let players rebind any action to any input. If the default jump key is spacebar, a player who cannot reach the spacebar should be able to move it to any other key. If the default virtual joystick is on the left, a left-handed player should be able to move it to the right. The unified input system described earlier makes this straightforward: the action map is a configuration, and changing it requires no code changes.
One-handed play modes rearrange controls so that all necessary actions are reachable with a single hand. On mobile, this might mean placing both the joystick and action buttons on one side of the screen, or combining movement and action into a single tap-and-drag control. On keyboard, it means offering a layout where all actions are bound to keys reachable with one hand, such as using the number row and nearby keys instead of spreading across WASD and spacebar.
Button size and spacing affect players with motor impairments. Virtual touch controls should meet or exceed the 44-by-44-pixel minimum from the Web Content Accessibility Guidelines, and ideally be larger (60 to 80 pixels for primary actions). Spacing between buttons should be at least 8 pixels to prevent accidental presses. The game should offer a control sizing option so players can increase button sizes beyond the default.
Reduced motion options matter for players with vestibular disorders. While this primarily affects visual effects rather than input, the controls UI itself should not rely on rapid animations or visual effects that could be disorienting. Keeping virtual control animations subtle (a slight opacity change on press rather than a bounce or shake) benefits everyone and is essential for players who have enabled the prefers-reduced-motion media query.