Dungeon Master

Why I built it

I wanted to explore how AI could help build a branching adventure. The challenge became keeping all the possible journeys coherent: what the player knows, what they have done, which routes remain open and how earlier decisions change the ending. A second run should offer a meaningfully different experience.

The product

Players read passages, choose actions and make visible dice checks. The game carries health, inventory, discoveries and relationships into later scenes, with different endings and the ability to save and resume.

The current adventure, Beneath the Monastery, is a dark-fantasy gamebook. AI assistance belongs to the authoring process; the playable application resolves the reviewed story, rules and state.

From AI ideas to a playable storyboard

The complexity grows quickly as the journey branches. Every route carries its own history: which characters are present, what the player knows, what they possess and which events have already happened. Keeping all of that in the AI's context proved unreliable. A convincing passage could still contradict an earlier choice or quietly lose a companion.

I had to develop an explicit story model alongside the AI-assisted authoring. Scenes, connections, character state, conditions and consequences give the adventure a structure that can be inspected and tested. When routes reconnect, their different histories remain part of the player's state.

The authoring approach gives AI a bounded task with the relevant story facts and constraints, then checks its suggestions against the wider structure. The mechanism around generation is part of the product: maintaining a coherent world, carrying consequences forward and identifying content that needs revision.

The engine validates story references and reachability, while automated playtesting explores combinations of choices and dice outcomes to find blocked routes and inconsistent state. Those checks give useful evidence within the routes explored; they complement editorial review of whether the adventure makes sense and is worth replaying.

How it’s built

The player interface uses Next.js, React and TypeScript. A separate TypeScript engine resolves choices, conditions, effects and dice outcomes, with Zod validating content and inputs.

Drizzle and Neon PostgreSQL store each journey and its turn history. Server-side checks prevent duplicate submissions from advancing a run twice.

Giving the story a voice

I use ElevenLabs to prepare spoken narration for the story. It adds a voice layer to the authored adventure while the game engine continues to own the rules and consequences.

The generated audio is stored in Vercel Blob and reused during playback. Narration is prepared separately, so playing a passage serves the existing recording rather than making a fresh text-to-speech request for every turn.

Keeping characters in the story

One of the problems I encountered was a secondary character accompanying the player along a route, then disappearing from the story without an explanation. The storyboard needs to account for people as well as places: who is present, when they leave and which later scenes depend on them.

Elara, the royal scout, makes that concrete. You can take her with you, leave her at the gates, or separate at the flooded stair. The game records those decisions, and character-dependent dialogue and actions require the appropriate state. Routes can reconnect without erasing how you got there.

The aim is to playtest every valid journey and check that its consequences and narration agree. Automated exploration checks combinations of choices, state and dice outcomes and reports reproducible failures. Its search is bounded, so a clean run is useful evidence alongside human story review, rather than a guarantee that every possible contradiction has been caught.

What I’m exploring

This is a learning project with a real playable result. I’m exploring how much AI can assist with story planning and authoring, and what structure, validation and human judgement are needed to turn its suggestions into meaningful choices and a consistent adventure. The wider authoring system is still developing.

Technology stack

ElevenLabs

Text-to-speech for prepared story narration.

Next.js · React

The browser gamebook and server endpoints.

TypeScript · Zod

Game rules, story state and validated adventure content.

Neon PostgreSQL · Drizzle

Saved journeys and an atomic record of each turn.

Vercel Blob

Storage and reuse of prepared narration audio.

Vitest · Playwright

Rules, adventure validation and player-journey checks.