How to Make a 3D Browser Game with WebGL in 2026

Game DevWebGLTutorial · 11 min read

Building a game that runs in a browser tab sounds limiting until you realize that WebGL can render 3D worlds at 60fps, Web Audio can mix spatial sound in real-time, and localStorage can save game state without a server. Here's what it actually takes to build a 3D browser game in 2026.

The Stack

You don't need a game engine. A modern browser game can be built with:

Three.js — The standard library for WebGL 3D rendering. Handles cameras, lighting, materials, shadows, and scene graphs.
Cannon-es or Rapier — Physics engines compiled to WebAssembly for fast collision detection and rigid body simulation.
Howler.js — Cross-browser audio with spatial positioning, pooling, and format fallbacks.
Vanilla JavaScript — No framework needed. React and Vue add overhead you don't want in a game loop.

Step 1: The Game Loop

Every game starts with a loop. In the browser, that's requestAnimationFrame:

let lastTime = 0;
function gameLoop(timestamp) {
  const dt = (timestamp - lastTime) / 1000;
  lastTime = timestamp;

  update(dt);  // game logic
  render();    // draw frame

  requestAnimationFrame(gameLoop);
}
requestAnimationFrame(gameLoop);

The dt (delta time) parameter is critical — it ensures your game runs at the same speed regardless of frame rate. A 30fps phone and a 144fps desktop should see the same gameplay speed.

Step 2: Scene Setup

Three.js makes the basics easy:

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(60, w/h, 0.1, 500);
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(w, h);
renderer.shadowMap.enabled = true;
document.body.appendChild(renderer.domElement);

From here, you add meshes (your game objects), lights (directional for sun, ambient for fill), and materials (standard PBR for realistic surfaces or toon for stylized looks).

Step 3: Input Handling

Browser games need to handle three input sources:

Keyboard — keydown/keyup events, stored in a key state map so you can check multiple keys per frame.
Touch — Virtual joystick using touchstart/touchmove/touchend. Calculate angle and magnitude from center point.
Gamepad — The Gamepad API gives you axis values and button states. Poll once per frame with navigator.getGamepads().

The key insight: never tie game logic to input events directly. Update a state object in event handlers, then read that state in your game loop. This decouples rendering from input and prevents dropped inputs on slow frames.

Step 4: Game State and Saving

Browser games save to localStorage. The trick is being smart about what you save:

Save JSON-serializable state only (positions, inventory, progress flags).
Auto-save on a timer (every 30 seconds is a good default) and on visibilitychange (tab hidden/closed).
Version your save format so you can migrate saves when you add new features.
Keep save data under 5MB — that's the localStorage limit in most browsers.

FarmHeart saves 800+ game variables (crops, animals, weather, economy, achievements) in under 200KB of compressed JSON. Smart serialization matters more than raw storage.

Step 5: Performance Optimization

The browser is not forgiving about performance. You don't get the luxury of a native game engine's optimization pipeline. Here's what matters:

Draw Call Batching

Every unique material + geometry combination is a draw call. 100 draw calls is fine. 1,000 will stutter. Merge static geometry with BufferGeometryUtils.mergeGeometries() and use instanced rendering for repeated objects (crops, tiles, particles).

LOD (Level of Detail)

Objects far from the camera don't need full geometry. Three.js has built-in LOD support — swap high-poly meshes for simpler ones based on distance.

Object Pooling

Never create and destroy objects in the game loop. Pre-allocate a pool of particles, projectiles, or effects and reuse them. Garbage collection pauses are the #1 cause of frame drops in browser games.

Texture Atlasing

Combine multiple small textures into one large atlas. Fewer texture binds = fewer draw calls = smoother performance. Tools like TexturePacker automate this.

Step 6: Mobile Support

If you're building a browser game in 2026 and it doesn't work on mobile, you're leaving 60%+ of your audience behind. Key considerations:

Touch controls — virtual joystick (left thumb) + action buttons (right thumb). Size them with vmin units so they scale correctly.
Safe area insets — iPhones have notches and home bars. Use env(safe-area-inset-*) to keep UI away from system chrome.
Performance scaling — detect mobile via navigator.maxTouchPoints and reduce shadow quality, particle count, and draw distance.
Prevent pinch zoom — add touch-action: none to your canvas and user-scalable=no to the viewport meta tag.

Step 7: Sound Design

Sound makes or breaks immersion. The Web Audio API is powerful but quirky:

Audio won't play until the user interacts with the page (browser autoplay policy). Add a "Click to Start" splash screen.
Use AudioBufferSource for short effects (footsteps, clicks) and HTML5 Audio for long tracks (music).
Spatial audio (panner nodes) adds depth — a cow mooing sounds different from the left vs. right.

Lessons from Building FarmHeart

After 800+ features and 1,200+ development passes, here are the hard-won lessons:

Start with the game loop, not the graphics. Get a cube moving before you worry about shaders.
localStorage is your friend — but JSON.parse/stringify is slow. Cache parsed state and only serialize on save.
Mobile-first is a myth for games. Build for desktop, then adapt to mobile. Touch controls are fundamentally different, not just smaller.
Players will do things you never imagined. Edge case testing matters more than feature count.
Performance budgets are real. Set a target (16ms per frame = 60fps) and profile every feature against it.

See These Techniques in Action

FarmHeart uses every technique in this article. Open it, poke around the source, and see how a production browser game works.

Play FarmHeart