Building Bedrock Add-Ons with Rust
The standard Bedrock add-on workflow is rough: hand-edit JSON, zip files manually, cross your fingers that the schema is right. We wanted something better, so we built it.
The Problem with JSON-First Development
Bedrock’s scripting API is entirely JSON-driven. Entity definitions, loot tables, recipes, block behaviours — all JSON, all validated at runtime. Mistakes surface when a player loads a world, not when you save the file.
Existing tools help, but they’re slow. A TypeScript-based build pipeline for a medium-sized pack can take 30–60 seconds to produce a .mcaddon. That’s painful in a tight iteration loop.
Our Approach
We define add-on content in a typed Rust DSL and compile it to valid Bedrock JSON. The compiler:
- Validates all schemas at compile time — if your entity definition references a missing texture, it’s a compile error
- Runs in parallel — each subsystem (entities, items, recipes) compiles independently
- Produces deterministic output — the same source always produces the same
.mcaddon, byte for byte
A full rebuild of Kinetic — 200+ entity variants, 80 items, 400 recipe entries — takes under 400ms on a modern laptop.
What We Don’t Do
We don’t generate the Rust DSL from JSON or try to round-trip existing packs. This is a forward-only workflow: write Rust, ship Bedrock. If you have an existing pack, migration is manual. We think that trade-off is worth it for the reliability guarantees.
Try It
All of our products are compiled with this toolchain. Check out Kinetic, Luminary, and Vortex to see what comes out the other end.