ECS Architecture
Entity-component-system that scales from a few dozen to thousands of entities. Change detection, hierarchy, and event batching built in — so you focus on gameplay, not plumbing.
DownDraft
AAA-class engine. WebGPU native. TypeScript-first.
A loosely AAA-class game engine built on a native runtime — winit + wgpu under Bun, Node, or Deno, no browser in the loop. TypeScript-first workflow, a modular plugin ecosystem, and a built-in MCP server for AI-assisted asset management.
Quick Start
Scaffold a new game in seconds
Bootstrap a project with the DownDraft CLI — templates, configs, and dev server all set up for you.
npx @downdraft/cli new my-game Capabilities
Everything you need to build games
WebGPU Rendering
Deferred pipeline with shadows, post-processing, and a render graph with automatic resource aliasing. Ships with an immediate-mode WebGPU UI system for HUDs and tooling, plus an offscreen-rendered surface mode for world-space UI.
Plugin System
Drop-in TypeScript and WASM plugins for water, terrain, physics, audio, networking, and more. Write your own in TypeScript — no native build tooling required.
MCP Server
Built-in MCP server lets AI assistants design scenes, spawn entities, manage assets, and debug — all through natural language prompts.
Physics
Rapier3D-powered physics with character controllers, collision detection, and multi-realm support. Swap backends without touching gameplay code.
Audio
Spatial audio powered by Kira (Rust FFI) with a full mixer, effects chain, and 3D listener tracking.
Architecture
Built for performance
DownDraft pairs a deferred WebGPU render pipeline with a modular plugin ecosystem in a single native process — Bun, Node, or Deno for the JS runtime, winit for windowing, wgpu for the GPU. Zero-copy SharedArrayBuffer keeps data flowing between threads with no serialization overhead.
Bun/Node/Deno + winit
WebGPU / WGPU
SurrealDB (SurrealKV)
Rapier3D physics
Kira audio (Rust FFI)
imui + PixiJS UI
MCP (JSON-RPC)
Runtime
Native all the way down
No browser, no renderer process, no IPC boundary. DownDraft games run as a single JS-runtime process (Bun by default; Node and Deno supported) driving a native window and the GPU directly.
One process, zero IPC
Windowing, rendering, assets, and the MCP server all live in one JS-runtime process. The host API is a direct function call — no IPC channels, no preload bridge, no message serialization between your game and the platform.
Threads where they matter
The simulation runs in a dedicated worker thread with SharedArrayBuffer — deliberate isolation, not browser constraint. Workers can even share the GPU device and encode command buffers in parallel.
A fraction of the footprint
Shipping Bun + a Rust cdylib instead of a bundled Chromium means smaller binaries, lower baseline memory, and no compositor in the render path. What your GPU does is what your code asked for.
Render Pipeline
How a frame gets built
Everything — simulation, rendering, and UI — runs inside one native process. The host owns the window and GPU device; workers handle simulation over SharedArrayBuffer. No IPC boundary to cross, no browser compositor in the way.
01
Simulation
Single-threaded scheduling for the ECS in a dedicated worker thread, with multicore work dispatched over SharedArrayBuffer — no locks, no serialization.
02
Render graph
wgpu drives the scene — compute shaders, explicit resource binding, and a Bevy-style render graph with automatic resource aliasing. Translated to Vulkan, Metal, or D3D12 depending on platform.
03
UI — flat path
An immediate-mode WebGPU UI (imui) rendered directly onto the render surface for HUDs, menus, and devtools panels — no DOM, no compositor.
04
UI — world-space path
Offscreen UI rendered to a GPU texture, imported into the render graph and drawn as geometry — for panels that need to exist inside the 3D scene.
05
Composite
One frame, one process — simulation, scene, and interface presented together on the native window. Built-in devtools and tracing profile any of it.
Status
Early, and still moving
DownDraft grew out of the engine work for To The Ocean and is now being built as a standalone engine. Architecture decisions are still being made in the open — feedback shapes what ships.
In active development