PlayCanvas Games on Mobile Browsers

Implement Touch Input Controls

Mobile devices have no mouse or keyboard, so every interaction must work through touch. PlayCanvas provides a touch input API through this.app.touch that mirrors the mouse API's structure but handles the unique properties of touch interaction including multiple simultaneous contact points, variable pressure, and the absence of hover states.

For movement controls in action games, implement a virtual joystick. Create an invisible touch zone on one side of the screen (typically the left half). When the player touches within this zone, record the initial touch position as the joystick center. As the player drags their finger, calculate the offset from the center and normalize it to produce a direction vector with magnitude between 0 and 1. Use this vector to drive character movement. When the touch ends, reset the movement vector to zero. Display a semi-transparent joystick graphic at the touch position for visual feedback.

Action buttons (jump, attack, interact) use a simpler tap detection approach. Define button regions on the screen, typically on the right side, and check touch start events against these regions. You can implement buttons as screen-space HTML elements overlaying the game canvas, or as PlayCanvas UI elements rendered within the 3D scene. HTML overlay buttons respond more reliably to rapid tapping because they bypass the game's update loop timing.

Swipe gestures need a distance threshold and directional detection. Record the touch start position, then when the touch ends, calculate the displacement vector. If the displacement exceeds a minimum distance (around 50 pixels), determine the primary direction by comparing the absolute X and Y displacement values. The larger axis determines the swipe direction: left, right, up, or down. Add a maximum duration threshold (around 300 milliseconds) to distinguish swipes from drags.

Multi-touch gestures like pinch-to-zoom and two-finger rotation are important for camera control in strategy games, building games, and 3D viewers. Track two simultaneous touch points and measure the distance and angle between them. Changes in distance drive zoom, and changes in angle drive rotation. The PlayCanvas touch system provides touch identifiers that persist across frames, letting you track individual fingers reliably even when one lifts and re-contacts.

Configure Resolution Scaling

Modern phones have screen resolutions of 1080p or higher, with some flagship devices exceeding 1440p. Rendering at native resolution on these displays pushes many more pixels per frame than a typical desktop monitor, and mobile GPUs are not proportionally more powerful. Resolution scaling renders the game at a lower resolution and upscales the result, dramatically reducing GPU load with a modest reduction in visual sharpness that most players do not notice during gameplay.

PlayCanvas controls rendering resolution through the device pixel ratio setting on the application's graphics device. A ratio of 1.0 renders at the CSS pixel resolution, which is typically half the physical pixel count on high-DPI screens. A ratio of 0.5 renders at quarter resolution, and the maximum device pixel ratio (usually 2 or 3) renders at full physical resolution. Start with a ratio of 1.0 and adjust based on performance testing on your target devices.

Adaptive resolution scaling changes the pixel ratio dynamically based on framerate. Measure the average frame time over a rolling window of 30 to 60 frames. If the average exceeds your target (16.67ms for 60fps or 33.33ms for 30fps), reduce the pixel ratio by a small increment (0.1). If the average is well below the target, increase the ratio. Clamp the ratio between a minimum (0.5 to avoid unacceptable blurriness) and the device's native ratio. This automatic adjustment keeps the game smooth across the wide range of GPU capabilities found in the mobile market.

Be aware that some mobile browsers override the device pixel ratio when the user has system-level display scaling enabled or when the browser applies its own scaling for readability. Test your resolution scaling logic on actual devices rather than relying solely on emulators, and use window.devicePixelRatio as a reference for the device's actual scaling factor.

Detect GPU Capabilities and Adjust Quality

Not all mobile devices are equal, and a one-size-fits-all quality setting either underperforms on high-end devices or overwhelms low-end ones. Implement a quality tier system that detects the device's capabilities at startup and applies appropriate settings for shadows, draw distance, particle counts, texture quality, and post-processing effects.

GPU detection can use the WebGL renderer string, accessible through the WebGL context's WEBGL_debug_renderer_info extension. This string identifies the GPU model (for example, "Adreno 730" or "Apple GPU"). Maintain a lookup table that maps known GPU models to quality tiers (low, medium, high). For unknown GPUs, fall back to a benchmark test that renders a standardized stress scene for a few frames and measures the framerate to classify the device's capability.

Define three or four quality presets that control multiple settings simultaneously. A "low" preset might disable shadows entirely, reduce draw distance to 50 meters, limit particles to 100 per system, use 512x512 texture resolution caps, and skip all post-processing. A "high" preset enables soft shadows, extends draw distance to 200 meters, allows 500 particles, uses full-resolution textures, and enables bloom and ambient occlusion. Store these presets as configuration objects and apply them at startup and whenever the player changes the quality setting manually.

Expose a quality menu in your game's settings screen so players can override the automatic detection. Some players on capable devices prefer maximum battery life over visual quality, and some on lower-end devices are willing to accept lower framerates for better graphics. A manual override also serves as a fallback when automatic detection classifies a device incorrectly.

Handle Orientation Changes and Screen Sizing

Mobile devices switch between portrait and landscape orientation when the player rotates the device. Your game needs to respond gracefully to these changes, adjusting the camera, UI layout, and control positions. PlayCanvas fires a resize event on the application when the canvas dimensions change, which you can listen for in your scripts.

Decide whether your game supports a single orientation or both. Many action and racing games lock to landscape for wider viewing, while puzzle and card games often lock to portrait for comfortable one-handed play. You can suggest an orientation using the web app manifest's "orientation" field or the Screen Orientation API, though not all mobile browsers enforce orientation lock for web content. Display a "please rotate your device" message when the player uses an unsupported orientation.

For games that support both orientations, adjust the camera's field of view based on the aspect ratio. A wider aspect ratio (landscape) might use a 60-degree horizontal FOV, while a taller aspect ratio (portrait) might increase the vertical FOV to keep important scene elements visible. Alternatively, use a fixed vertical FOV and let the horizontal view expand or contract with the aspect ratio, which works well for games where the ground plane is the primary play area.

UI elements need to reposition when the orientation changes. Anchor UI elements to screen edges (top-left, bottom-right, center) rather than absolute pixel positions. When the screen dimensions change, anchored elements automatically adjust to remain at their intended positions. PlayCanvas's Element component supports anchoring and pivot properties that handle this repositioning when used with the screen-space UI system.

Test orientation changes during active gameplay, not just on menu screens. Some subtle issues only appear when the game is running: physics objects may shift if the camera bounds change, touch input coordinates may need recalibration, and audio spatialization may sound different with a rotated listener orientation. Handle the resize event in gameplay-critical scripts to recalculate any values that depend on screen dimensions.

Optimize Memory and Battery Usage

Mobile browsers operate under tighter memory constraints than desktop browsers. When a web page exceeds the browser's memory allocation, the operating system may terminate the tab without warning, losing the player's unsaved progress. Stay within safe limits by reducing texture resolution for mobile builds, unloading assets that are no longer needed, and monitoring memory consumption during testing with the browser's developer tools.

Texture memory is the largest consumer in most 3D games. Reduce maximum texture dimensions to 1024x1024 or even 512x512 for mobile-targeted builds. Use texture compression (Basis Universal) to reduce GPU memory consumption by 4 to 8 times. Limit the number of unique textures by sharing materials between objects and using texture atlases that combine multiple small textures into single larger ones.

Audio contributes to memory pressure, especially if you load many sound effects as uncompressed PCM data. Use compressed audio formats (MP3 or OGG at 96 to 128 kbps) for all sound assets on mobile. Limit simultaneous audio channels to 8 or fewer, and implement a priority system that stops the least important sounds when the channel limit is reached. Stream long music tracks rather than loading them entirely into memory.

Battery consumption matters for the player experience even though you cannot control it directly from JavaScript. The primary battery drain in a game comes from GPU utilization. Reducing resolution, lowering the framerate cap to 30fps instead of 60fps for less action-intensive segments (menus, dialogue, inventory screens), and disabling post-processing effects all reduce GPU power draw. Pause rendering entirely when the game is in a minimized or backgrounded state by detecting the page visibility API events and stopping the engine's render loop.

Thermal throttling is a related concern. Mobile devices reduce CPU and GPU clock speeds when the processor temperature rises, causing framerate drops that worsen over time. A game that runs at 60fps for the first five minutes may drop to 30fps after fifteen minutes of sustained load. Test for extended play sessions (30 minutes or more) on actual devices with performance monitoring to identify thermal issues. Reducing the quality tier slightly below what the device can handle at peak performance prevents throttling-induced framerate instability during longer sessions.