Awaken
← All posts
#1webgpuwhyroadmap

Why build a browser-native game engine - and why WebGPU, not WebGL

Quick background: I've been writing graphics code since DOS mode 13h - poking bytes into VGA memory at 0xA0000 in Borland C++ - then DirectX, then OpenGL, and an engine called Decade I documented years ago. WebGPU pulled me back in recently (a procedural planet, BlockWorld - a voxel world with procedural terrain and procedural textures). Awaken is the result: a full 3D game engine and editor that runs in a browser tab.

This post is the why: why build it on the web at all, why WebGPU over WebGL, and where it's going beyond the browser.

The goal: one engine, every platform, zero install

The pitch is a URL. Open a tab, you're editing a 3D scene; export, and your game is a single file anyone can open. No SDK, no launcher, no 40 GB download, no platform gatekeeper. The whole toolchain - editor, renderer, physics, scripting, export - is client-side.

That only becomes interesting if it isn't limited to browsers, which is the roadmap below. But it starts by betting on the modern web GPU API instead of the legacy one.

Why WebGPU, not WebGL

WebGL is a wrapper over OpenGL ES 2.0/3.0 - a fixed, ~2007-era pipeline. WebGPU is a modern explicit API in the lineage of Vulkan, Metal and D3D12. The difference isn't cosmetic; it's a different class of GPU programming. Concretely, WebGPU gives you things Awaken depends on and WebGL simply doesn't have:

  • Compute shaders. Awaken frustum-culls every object in a compute pass and writes indirect draw arguments - the CPU issues zero per-object culling. WebGL has no compute at all.
  • Storage buffers. Large, shader-writable buffers hold per-object transforms and material params, so static batching and GPU-driven rendering are possible. WebGL is stuck shuttling data through textures and uniforms.
  • Indirect draws. The GPU decides how many instances to draw; the CPU never sees the visible count.
  • Explicit pipelines and bind groups. Validated up front, cheaper to switch at draw time, and far easier to reason about than WebGL's giant implicit state machine.

WebGL can draw a scene. It can't drive one the way a modern renderer wants to - culling, batching and shading on the GPU. WebGPU is also the direction the whole platform is moving; building on WebGL now would be building on a bridge that's already being decommissioned. The cost is reach (WebGPU is newer), and that cost is shrinking every release.

Beyond the browser: same engine, three shells

A browser-only engine would be a toy. The point of building on web tech is that a web app can be wrapped to run natively almost anywhere, so the plan is one codebase, three delivery targets:

flowchart LR
  E["Awaken engine
(TypeScript + WebGPU + WASM)"]
  E --> B["Browser
runs directly"]
  E --> D["Desktop
WebView in Electron/Tauri"]
  E --> M["Mobile
WebView in React Native"]
  B --> G["The same game,
everywhere"]
  D --> G
  M --> G
  • Browser - runs directly today.
  • Desktop - the engine hosted in a native WebView shell (Electron or Tauri), shipped as a normal .app/.exe. Filesystem, bigger memory, an installable icon.
  • Mobile - the same web build inside a WebView in a React Native container, shipped to the App Store / Play Store.

The gating factor is WebGPU availability in those embedded WebViews, which is arriving across the board. Once it lands everywhere, "write your game once in Awaken, ship it to web, desktop and mobile" stops being a slogan and becomes a build target.

📷 Screenshot needed: the Awaken editor open with a 3D scene loaded (hierarchy panel left, viewport centre, inspector right) - the "this all runs in a browser tab" hero shot.

The rest of this series is how the thing is actually built.

← All posts