Running Babylon.js Games in Mobile Browsers

Step 1: Scale Rendering Resolution

Modern phones have pixel densities of 3x or higher, meaning a 1080p phone screen actually has over 3000 pixels on its longer axis. Rendering at native resolution on a phone GPU is impractical for 3D games. The solution is hardware scaling: engine.setHardwareScalingLevel(2) renders at half resolution in each dimension, reducing the pixel count to 25% while still displaying on the full screen. The browser upscales the lower-resolution output to the native display.

A scaling level of 2 is a good starting point for mid-range devices. High-end phones can handle 1.5 or even native resolution. Low-end phones may need 3 or higher. Detect the device capability at startup by running a few frames and measuring performance, then set the scaling level accordingly. The engine.getFps() method reports the current frame rate, and if it drops below your target, increase the scaling level.

Anti-aliasing compensates for the lower resolution. FXAA (Fast Approximate Anti-Aliasing) is a post-processing effect that smooths jagged edges without the cost of MSAA (Multi-Sample Anti-Aliasing). Enable it through the DefaultRenderingPipeline with pipeline.fxaaEnabled = true. FXAA is cheap enough to run on mobile even at lower resolutions, and it significantly reduces the visual impact of downscaling.

Step 2: Implement Touch Controls

Mobile web games have no keyboard, no mouse, and no gamepad by default. Every input must come from the touchscreen. The most common pattern for action games is a dual virtual joystick layout: left side controls movement, right side controls camera or aiming. Create these with the VirtualJoystick class or build custom touch zones with scene.onPointerObservable.

Touch targets need to be large enough for comfortable use. A button smaller than 44x44 CSS pixels is difficult to tap accurately on a phone. Virtual joystick active zones should cover at least a quarter of the screen width. Place interactive elements away from screen edges where they conflict with browser navigation gestures. Test with actual thumbs on actual phones, not with a mouse cursor in a desktop simulator.

Gesture recognition adds depth to touch controls. A swipe can trigger a dodge roll, a pinch controls zoom, and a long press activates a special ability. Detect gestures by tracking touch start position, current position, duration, and the number of simultaneous touches. The math is straightforward: a swipe is a touch that moves more than a threshold distance in a short time, and a pinch is two touches whose distance changes.

Prevent the browser from interfering with game input. Call event.preventDefault() on touch events to stop the browser from scrolling, zooming, or showing context menus. Set the viewport meta tag to <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> to disable browser pinch zoom. Without these measures, the player's game interactions will trigger unintended browser behaviors.

Step 3: Manage GPU Memory

Mobile GPUs have far less memory than desktop GPUs. A budget Android phone may have 2GB of total RAM shared between the CPU and GPU. A single uncompressed 4096x4096 texture uses 64MB, and a game with ten such textures would consume most of the available memory. Texture compression with KTX2 and Basis Universal is not optional on mobile; it is required.

Reduce texture resolutions for mobile. If your desktop textures are 2048x2048, create 1024x1024 or 512x512 versions for mobile. Detect the device at runtime using navigator.userAgent or navigator.maxTouchPoints and load the appropriate texture set. The visual difference at mobile viewing distances is minimal, but the memory savings are substantial.

Polygon count matters more on mobile than desktop. Aim for scene totals under 100,000 triangles for mid-range phones. Use Level of Detail (LOD) systems to swap detailed models for simplified versions based on distance. Babylon.js supports automatic LOD with mesh.addLODLevel(distance, lowerDetailMesh). At 50 meters, replace a 5000-triangle character with a 500-triangle version. At 100 meters, use a simple billboard sprite instead of a 3D mesh.

Step 4: Handle Thermal Throttling

Mobile devices throttle CPU and GPU speeds when the processor gets too hot. A game that runs at 60fps for the first two minutes may drop to 30fps or lower after sustained play as the device heats up. This is not a bug in your code; it is a hardware protection mechanism. Your game needs to adapt to changing performance.

The Scene Optimizer is Babylon.js's answer to dynamic performance management. Configure it with BABYLON.SceneOptimizerOptions.ModerateDegradationAllowed() or create a custom optimization sequence. When the frame rate drops below the target (usually 30fps for mobile), the optimizer reduces shadow map resolution, disables post-processing, lowers particle counts, and reduces texture quality in order. When performance recovers, it restores quality.

Target 30fps on mobile rather than 60fps. Consistent 30fps is better than fluctuating between 40 and 60. Lock the target with scene.getEngine().setHardwareScalingLevel() adjustments and consider using engine.setTargetFps(30) to cap the frame rate. A stable frame rate avoids the perceptual jitter that variable rates produce.

Audio processing contributes to thermal load. The Web Audio API runs on the main thread by default, and complex audio effects like reverb and spatial processing add CPU overhead. Keep audio simple on mobile: use compressed audio formats (AAC or OGG), limit simultaneous sound channels to 8 or fewer, and skip expensive effects like convolution reverb.

Step 5: Package as a PWA

Progressive Web Apps allow mobile users to install your game on their home screen, play offline, and launch it like a native app. The requirements are a web app manifest file (JSON with app name, icons, and display mode), a service worker (JavaScript that caches assets for offline access), and HTTPS hosting.

The manifest sets the display mode to "standalone" or "fullscreen." Standalone hides the browser address bar, giving your game more screen space. Fullscreen hides everything, including the status bar. Set the orientation to "landscape" for games that work best in landscape, or "any" for games that support both orientations.

The service worker caches game assets (HTML, CSS, JavaScript, textures, models, audio) during installation so the game loads instantly on subsequent visits and works without an internet connection. Use a cache-first strategy for static assets and a network-first strategy for dynamic data like leaderboards. Update the cache version number when you deploy new content so returning players get the latest version.

Step 6: Test on Real Devices

Desktop browser device emulation simulates screen sizes and touch events, but it does not simulate mobile GPU performance, memory limits, thermal throttling, or real touch ergonomics. A game that runs perfectly in Chrome DevTools' mobile simulator may stutter on an actual mid-range Android phone because the simulator runs on your desktop GPU.

Test on at least three device tiers: a recent flagship (iPhone 15 or Samsung Galaxy S24), a mid-range device (Samsung Galaxy A series or Pixel A series), and a budget device (sub-200-dollar Android). If the game runs acceptably on the mid-range device, it covers the majority of the mobile market. If it only runs on flagships, you have lost most of your potential audience.

Use remote debugging for mobile testing. Chrome DevTools can connect to Android Chrome via USB, giving you the console, profiler, and memory inspector for a real device session. Safari Web Inspector connects to iOS Safari via USB for iPhone testing. These tools show actual frame times, GPU memory usage, and JavaScript heap sizes that reveal problems invisible in desktop simulation.