WebXR Games: VR and AR Games You Can Play in a Browser

The rendering and game-logic layer is identical to any other Three.js game: scene graph, physics, collision, a render loop. What changes is the input and camera model: instead of a fixed camera driven by mouse/keyboard, WebXR hands you real-time head pose and (where supported) hand or controller pose every frame, and the renderer draws a stereo pair of frames instead of one.

Three.js's renderer.xr module handles most of the plumbing: requesting an XR session, getting controller objects with their own position/orientation, and running the render loop at the headset's native refresh rate via renderer.setAnimationLoop() rather than requestAnimationFrame.

Before designing a WebXR game, know the actual reachable audience. See the full breakdown in the WebXR guide:

• Meta Quest Browser is the strongest target: full immersive-vr support, hand tracking, controllers. Most browser VR games are realistically built for Quest first.
• Android Chrome supports immersive-ar, including hit-testing for placing objects on real surfaces: the largest reachable AR-in-browser audience.
• Safari on iPhone/iPad has no WebXR support at all. A WebXR game will not reach iOS users through the WebXR path. Plan a non-immersive fallback (a "play without VR" mode using the model in a regular 3D viewer) if iOS reach matters to your project.

Designing for "everyone" means the non-immersive mode is the actual product for most visitors, with the immersive session as a bonus for the minority who can enter it.

The core additions on top of a normal Three.js game loop:

1. Add an XR "Enter VR" button (Three.js ships a ready-made VRButton helper) that requests the XR session.
2. Read controller objects via renderer.xr.getController(0)/getController(1) and add visual representations (a simple cone or a loaded controller model) as children of the scene.
3. Handle selectstart/selectend events on each controller for the trigger button. This is your primary interaction input, replacing mouse click.
4. Switch renderer.setAnimationLoop() instead of requestAnimationFrame. This is required for XR, since the headset drives the frame timing, not the browser tab.