delvewright

English · 简体中文

Delvewright

Delvewright is an AI Minecraft adventure map generator: it turns a creative prompt into a story-driven RPG dungeon for one to four friends — a vanilla datapack with quests and NPCs — and proves by machine that it can be finished before it is handed over.

The pictures are renders of the built world, path-traced with Chunky; in the game it looks like vanilla Minecraft unless you add a shader or a resource pack of your own.

Inside Vesperhold — the approach, the ward, the garden, the cloister, the chapel, the pool under it, the bell tower and the throne hall. More campaigns: The Treehouse Camp and Doune Castle.

Delvewright automates the tedium and the verification, not the design: it stops and waits for you to approve the design, hands you the finished delve to play, and when it refuses something it names what to change instead of changing it.

Play it now: join minecraft.stellarfeline.ca from a Minecraft Java 1.21.11 client, and accept the resource-pack prompt when you join. The server runs Vesperhold, the castle in the picture.

Get started

In Claude Code:

/plugin marketplace add stellarfeline/delvewright
/plugin install delvewright@delvewright
/delvewright:new-delve a guided tour of a real castle, nine rooms, no combat

The first run sets up its own toolchain. After that it asks you two things — where to get the Minecraft client jar, and whether the design is right — and does the rest. The first time you play it is the finished first version. What arrives is the campaign's documents, a spoiler-free storybook, and one command that builds, checks and serves the delve on localhost:25565. It needs git, Python 3.11 or newer, Java 21 or newer, and Docker with Compose v2 (everything the first run checks).

How it works

flowchart TD
    P(["your prompt"]) --> S["world · NPCs · classes · quest plan<br/>schema-checked JSON documents"]
    S --> G{{"the design gate<br/>you say yes"}}
    G --> Q["quests · dialogue"]
    Q --> B["delvec build<br/>validate · analyze · compile"]
    B -->|"refused: a DW code names what to change"| Q
    B --> L["the ladder<br/>PackTest · a bot plays it"]
    L -->|"red goes back to the documents"| Q
    L --> I(["a delve image<br/>one docker run, and friends join"])

The whole line, box by box, with every tool it runs: how it works, end to end.

The agent writes documents, never commands: every line of the datapack comes from the compiler, and nobody edits its output. The documents are the artifact of record — the same documents and the same seed rebuild the same bytes. What each check printed for the castle above.

Why you can trust it

Every rung below ran on Vesperhold v1.0.0, the castle in the picture, in its release run (delvec 1.7.1, engine revision 90433f2, Minecraft 1.21.11). What each printed is quoted.

• Static analysis. Inside delvec build, before a byte is written: every document validates against its schema, every quest and dialogue path is walked, and a failure is a refusal with a named DW code. Vesperhold: the build exited 0, having walked 5 state paths over 185 steps and examined 37 objectives, with five advisories — three DW0351, a character who appears or leaves without being seen to move; DW0781, the piece-mating check had nothing to judge, because the whole castle is one piece; and DW0810, the generated PackTest suite drives one member of a family of objects and not its siblings.
• Every command checked. Every emitted .mcfunction line is parsed against the pinned 1.21.11 command tree inside the same build. It prints no count.
• PackTest. The datapack's mechanisms, tested on a real server: 338 GAME TESTS COMPLETE IN 1.586 min — All 338 required tests passed :).
• A bot plays it. A mineflayer bot joins the shipped server and plays the critical path to the end, dying on purpose at every fight and walking back from the fire: critical path 'vesperhold' PASSED (45 steps, 18 scripted death(s) survived, 2 advisory finding(s)). One advisory is wave members found already wounded when the bot walked back; the other says this run drove no story branch. Before the release, on the same compiler, each of the four story branches was played to its ending in a fresh world: branch branch/halvard-kept-oath+branch/ring 'vesperhold' PASSED (45 steps, 18 scripted death(s) survived), and the other three printed the same 45 steps and 18 deaths.
• The server log. shipped server log is error-free.
• Determinism. Same documents and same seed, byte-identical output. The published image, ghcr.io/stellarfeline/delve-vesperhold:v1.0.0, carries its datapack's digest as a label, datapack-sha256=e0f79e0522708526cea976e735547042567b032abe87dbb425f8495365f796ec, so anyone who rebuilds can compare. On every pull request that changes the engine, CI builds a generated campaign on Linux and on macOS and refuses if one byte differs.

What each rung proves, and what it does not: what each gate actually proves.

The map

Every map is a site plan, designed whole-first — a geometry brief, a layout graph, then every place's box, datum and seams, and what fills the ground between them — and walked as a blockout before any place is detailed. Each place is then one piece that draws its own walls, roof and ground inside the frame the plan hands it, written by the box-split grammar from a rule program; a map that is one building is a plan of one box. Vesperhold, the castle above, is a single grammar piece holding the whole site, 172 × 104 × 292 blocks. Light is placed while a room is designed, and the build refuses reachable floor that measures dark (DW0210). Every scene is rendered with Chunky and reviewed against the concept image it answers.

Read on: placing the map · one map route · the map is planned before it is built · the grammar · admitting a piece · interior lighting · visual review

The story

A campaign is written in stages, each a schema-checked JSON document conditioned on the ones before it: the world, its NPCs, the classes and their gear, a quest plan, then quests and dialogue. Dialogue is written as branching options when the delve is made; nothing in a shipped delve calls a model. A campaign that declares story forks has every branch proven on its own path and played in its own fresh world. Player-facing text is written in English, and translations ship beside it and follow the player's client language.

Read on: the DSL, stage by stage · writing the story · what a quest can do · branch-complete verification · translation

Design decisions

• Architecture decision records — why everything is the way it is.
• Specs — one per feature, each with machine-checkable acceptance criteria.
• The constitution — the rules every change to this repository obeys.
• The gallery — the engine's own campaign: one instance of every surface the DSL declares, built on every pull request that can reach it.
• The tool inventory · the compiler reference · the roadmap

Licence

Code: GPL-3.0-or-later. Campaigns ship separately, from the content repository, under CC BY-SA 4.0. Every adopted library and ported algorithm: acknowledgements.

NOT AN OFFICIAL MINECRAFT PRODUCT. NOT APPROVED BY OR ASSOCIATED WITH MOJANG OR MICROSOFT.