Spark Engine

Overview

Spark Engine is a WebGPU-first game engine that runs in a browser tab. The pitch is that the hard parts are already there: a renderer with a post stack, an entity system, physics, skeletal animation, particles, world streaming, navigation, audio and UI, with one consistent way to write a scene against all of it. It ships with a demo game, a launcher of scenes that each isolate one system, and a starter app small enough to read in a sitting.

Try the Engine ↗Play the Demo ↗Source on GitHub ↗

Highlights

• A demo game, not a spinning cube. A night street in the rain: a character with an aim layer and ragdolls, hostiles that hunt on a navmesh and take cover, hitscan gunplay, objectives with checkpoints, and a generated soundscape.
• One scene per system. Eleven launcher scenes, from clustered lights over instanced props to a district streamed in chunks around a flying camera, a seeded pile of rigid bodies, and a blend tree driving a crowd.
• Deterministic by construction. A fixed physics step, a seeded random source, and URL flags that pin the clock and the seed, so the same run reproduces. Reaching for the language’s own random is a lint error.
• Quality that scales to the machine. Five presets from low to cinematic, a render scale and a pixel-ratio cap, all settable from the URL so a weak GPU and a strong one can both be handed a link.
• Built to be handed over. A starter app, a generator that copies it into a new project, an asset pipeline from glTF to optimized GLB, and Blender scripts that build the levels and characters.

How It’s Built

A TypeScript monorepo with a boundary that holds: the engine never imports from an app, apps import only its public surface, and each subsystem owns its own dependency. A scene is a small contract, a create function returning a scene, a camera and update hooks, and whatever it builds it releases on dispose. Rendering runs on three’s WebGPU build with node materials and falls back to WebGL2 with a reduced effect set. Decisions that were hard to reach are written down as architecture records next to the code they explain.

Process

Planned around measurement rather than impressions. A headless harness boots every scene on both backends and captures a screenshot and a stats file, visual goldens catch rendering regressions, a probe suite drives the demo game on a fixed clock and seed to assert its mechanics end to end, and a benchmark records whether a change cost frame time. Anything the demo taught the engine goes back into a lessons document next to the change that came of it.