INTRO
Particlr is a particle-effect editor that runs in the browser, paired with an MIT-licensed runtime that plays the effects back inside a game. You build an effect against emission rates, curves and gradients, velocity, gravity, drag, noise, blend modes, and collision, then export a single versioned `.prt` JSON file. `@particlr/runtime` on npm loads that file and renders it in PixiJS. It is a tool for game developers rather than a generative-art toy, and the output is meant to ship.
The thing I cared about most was parity. The editor does not approximate what your game will show, it previews through the exact same runtime your game links, so the preview and the shipped frame are the same computation. The README calls that an invariant, not a feature, and it is held in place by golden-frame tests that run in CI at pixel tolerance zero, headless through Playwright and SwiftShader. Everything else, the presets, the free and premium split, the Pixi v8 and v7 adapters, sits on top of that one guarantee.
SECTION
The parity invariant
Game effects are unforgiving about small differences. A muzzle flash that is a few pixels brighter or a frame slower in-game than it looked in the tool is a bug you find late, usually after the effect is already wired into ten places. The usual particle editors preview with their own renderer and hand you data for a different runtime, so 'looks about the same' is the best they can promise. Particlr refuses that gap. The editor's preview canvas is the runtime. What you scrub in the timeline is the code path your game executes.
That only holds if it is enforced, so it is. A golden-frame suite renders reference effects and compares them against committed baselines at pixel tolerance zero, running headless in CI through Playwright and SwiftShader. If a change to the runtime shifts a single pixel, the build fails. The landing page itself is rendered live by the shipped runtime, so the ember field and the bursts on it are not a video, they are the same code that plays your exported file.

SECTION
One JSON file between the editor and your game
The contract between the editor and the game is a single versioned `.prt` document, plain JSON. The editor writes it, the runtime reads it, and nothing else crosses the boundary. The runtime core is framework-agnostic; the Pixi integration sits on top as an adapter. PixiJS v8 is the first-class target, and there is a v7 adapter at full feature parity for projects that have not moved yet. The core is held to a budget of 25KB gzipped, because a particle runtime that costs more than the effects are worth does not get adopted.
The bar for the whole thing is a time. Slice One is done when a person with no prior context can open the URL, tweak an explosion, and get it running in the sample game in under ten minutes. The sample is a small integration harness: click to spawn explosions, fire a projectile that sheds a trail, and watch a host parameter retune the ambient effect at runtime, all driven by exported `.prt` files. Same seed, same result.

SECTION
The editor
The editor is a Preact and signals app, a static Vite build deployed on Vercel, held under 200KB gzipped without counting Pixi. The authoring surface covers the parts that actually shape an effect: emission rate and bursts, curves and gradients over a particle's life, velocity and gravity and drag, noise, blend modes, and collision. Each layer stacks into the effect, and a parameter can be exposed as a host knob so a game tunes it per instance without editing the file.
Nobody should start from an empty canvas, so there are 57 presets and every one is CC0. They are not screenshots or locked demos; each opens in the editor as a real, editable starting point. Arc weld, ember field, blast anim, dissolving smoke, confetti, comet, and the rest are there to be pulled apart and reassembled into whatever you actually need.

SECTION
Premium forces without a hostage runtime
The runtime is MIT and free forever, and so is the core of the editor: emission, curves and gradients, velocity, gravity, drag, noise, blend modes, collision, host parameters, and unlimited import and export. That is enough to build and ship real effects without paying anything. One optional lifetime key adds the heavier authoring tools: sub-emitters, trails and ribbons, attractors, texture masks, dissolve, a sheet packer, and baked-image export.
The part I was careful about is that the runtime never holds your work hostage. A free user can open, play, and re-export an effect that was built with premium features, because those features are authoring conveniences that resolve down into the same `.prt` the free runtime already knows how to read. Buying the key gets you the tools, not a license to keep playing your own files.
OUTCOME
Live at particlr.com, with the runtime public on GitHub and published as `@particlr/runtime` on npm, and actively developed. The monorepo is TypeScript strict with Vitest and Playwright, and the parity guarantee is the thing the whole test suite exists to protect. The short version of what I was building toward is the Slice One test: no context to a tweaked explosion running in a real game in under ten minutes.
