Engineering case study · AI & TypeScript · 2026

A book becomes an adventure.
The player gets a say.

Book RPG turns a source book into a playable story. Choose a character, act and talk from their perspective, and follow the original story or take a different route. The engineering challenge is making those choices matter while keeping the world coherent.

Explore the design

EPUB → playable storySource-backed book analysis

Player-controlled actionsChoices, dialogue and free text

State across turnsStory progress, world rules and saves

01 · Problem

Generating prose is only one part of a story engine.

A scene can read beautifully and still be wrong. A character might know something too early, act from the wrong perspective, or complete a decision before the player makes it.

The core problem is coordinating source material, player agency and persistent state. The engine needs to distinguish what has happened, what can happen now, and what still belongs to the future.

The original book provides a canonical route. It is a reference for progression, while the interactive timeline can diverge when the player makes a different choice.

02 · Design

Analyze the book once.
Reason about each turn in context.

Build a source index
Extract chapters from an EPUB, resolve character identities and organize source events into ordered story beats.
Generate the next moment
Use the selected character, current story progress and game history to create a scene with meaningful actions.
Review and save
Validate generated output and review continuity, presence and choices before accepting the next game state.

A story beat records an actor, action and agency. That distinction helps the engine separate automatic events from intentional actions that should wait for the player.

03 · Engineering choices

Put structure around the creative part.

Explicit player agency

The scene should set up a meaningful decision. Perspective and agency checks guard against narrating an unchosen player action or treating the player as a separate character.

Source progression as state

Completed beats are tracked for the active event. The engine tracks which source actions are still in the future and checks whether they remain compatible with the interactive timeline.

Dialogue has its own flow

Conversation choices open a separate dialogue state. The browser also supports free-text actions, turn history, undo and persistent world rules.

Provider-independent engine

OpenAI and xAI adapters sit behind one engine layer. Structured responses are validated before acceptance, with bounded generation attempts and retries.

04 · Runtime

One application, local development and Azure storage.

The current implementation uses Node.js and TypeScript, with a responsive browser client and a terminal client sharing an HTTP API.

Local development uses file-backed repositories. The Azure configuration uses Blob Storage for analyzed books and Cosmos DB for user-scoped game saves. A Docker image and Bicep infrastructure support deployment to Azure Container Apps.

KOReader remains a longer-term device-side target. The repository includes a Kindle-oriented data package; the Node web game is the main actively tested runtime.

05 · Validation & limits

Inspect the decisions behind the story.

The repository includes regression tests and a Playwright endurance flow that runs repeated choices across characters. Per-game logs record source progression, AI inputs and outputs, rejected generations and saved turns.

These tools help reproduce failures such as premature dialogue suggestions, perspective drift and scenes that do not make the next action possible.

This is an evolving implementation. AI-generated continuity still needs review, EPUB parsing has boundaries, and successful runs do not establish that every book or sequence of choices will work. No aggregate reliability or latency benchmark is claimed here.

Technical descriptions on this page are based on the project’s implementation documentation, reviewed in September 2026. The source repository is currently private.

06 · Explore the work

Explore another engineering challenge.

Amsterdam 750 explores a different set of constraints: high-demand registration and personal data protection. Its case study includes a public implementation and published load-test evidence.

Amsterdam 750 case study Back to portfolio

A book becomes an adventure.The player gets a say.