Life & Logic · Research Project

The Narrative
Engine

A programmable dungeon master · generating structured, high-quality
interactive stories across any universe, in any genre, at any scale.

Team Andrea Doyon · Nathalie Lacoste
Status Sprint 1 · Research & Foundation
Project Life & Logic · L2
01 · Context

What Is the Narrative Engine?

The Narrative Engine is an AI-powered story generation platform that creates both replayable campaign books (D&D / Warhammer style) and real-time sandbox narratives (improvised dungeon-master style). It acts as a programmable DM capable of generating, rendering, and managing interactive stories across any universe.


The project emerged from EV2090 · a live space-trading game currently in beta, created by Andrea Doyon · where a working narrative engine already exists but lacks quality in its rendering layer. Content is generated without awareness of how it will be consumed. A bulletin board post reads like a narrator telling a story. A broadcast sounds like an NPC rant. This is the core problem the Narrative Engine solves.

2Core Modes
5Delivery Channels
10Design Pillars
5Sprint Phases
6Research Domains

Book Mode

Replayable

Like a Warhammer campaign book or D&D module. The story is pre-generated with a fixed spine · the conspiracy unfolds as written. Variable flesh means each playthrough discovers clues differently. Packagable and sellable as content packs.

Sandbox Mode

Real-Time

Like an improvised DM session. Beats are generated 1–3 ahead based on live world state. Player actions modify the spine · you can kill the queen, destroy the shipyard. Once played, content is disposable. Powered by fronts, clocks, and faction turns.

The #1 quality lever: Rendering context. The engine must know HOW content is consumed. Sonnet decides WHAT happens (narrative architecture). Haiku decides HOW it's presented (channel-specific voice, format, tone).

EV2090 · Structural Gaps to Fix

What the Existing Engine Is Missing

△
Arcs & bounties are disconnected · no shared characters, no cross-triggering between systems.
△
No player agency in narrative · arcs execute on fixed timelines regardless of what players do.
△
Stateless beat rendering · each beat has no awareness of player behavior or engagement.
△
Only 2 bounty types · locate_ship and locate_person. Missing escort, intercept, cargo, combat.
△
Single system lock · defaults to Sol with 4 hardcoded planets despite multi-system infrastructure.
△
NPC chat is bounty-only · rich dialogue system exists but arc characters can't be conversed with.
△
No story recap · players who missed beats have no way to catch up on the narrative.
△
Shallow economy integration · narrative events have limited lasting economic consequences.
02 · Research Foundation

What We Studied to Build This Right

Before committing to any design decision, we spent the first sprint researching six domains not to validate ideas we already had, but to discover what fifty years of tabletop design and the latest AI narrative research actually knows. Each domain answered a specific question the engine needs to get right.

Research · campaign books and code
Research 01
D&D Module Structure
We needed to know what a well-crafted authored experience looks like at the structural level · before AI generation ever enters the picture. D&D modules represent fifty years of iterative design on how to give players agency while ensuring a coherent story. The NPC model they landed on (trait / ideal / bond / flaw) has never been bettered.
Full Analysis →
Research 02
Warhammer: The Enemy Within
The Enemy Within is arguably the finest campaign book ever written · and understanding why it works reveals the blueprint for Book Mode. The concept of a fixed conspiracy spine with variable flesh means the same story can surprise different groups of players running through it years apart.
Full Analysis →
Research 03
Narrative Beat Theory
A beat is the smallest story unit that produces a change · but what counts as a change? This research gave us the vocabulary and structural rules for sequences that feel well-paced rather than mechanical. The five beat types became the classification system that every piece of generated content gets tagged with.
Full Analysis →
Research 04
Improv DM Techniques
Sandbox Mode is an improvised DM session at scale · which means we need to understand how the best human improvisers manage narrative coherence without a script. The Fronts / Clocks system from Apocalypse World gave us the passive timeline model; the Three-Clue Rule became non-negotiable.
Full Analysis →
Research 05
Procedural Narrative AI
The "sloppy" problem in EV2090 has a name: context-blind generation. This research mapped the state of the art in AI narrative generation from the coherence collapse of pure text models to the structured beat approaches that avoid it · and helped us understand precisely where an LLM needs constraints and where it needs freedom.
Full Analysis →
Research 06
EV2090 Code Analysis
We don't start from zero · there is a working narrative engine in production. A thorough analysis of its architecture, prompt design, and failure modes gave us a baseline to improve on rather than ignore. Eight structural gaps were identified; the prompt philosophy (no examples, anti-patterns, causality) was confirmed and will carry forward.
Full Analysis →
03 · Design Pillars

10 Non-Negotiable Decisions

These are the locked-in decisions that guide all design work. They are non-negotiable · any feature or schema that violates them gets pushed back.

01
Separate What from How
Sonnet generates WHAT happens (narrative structure). Haiku generates HOW it's presented (rendering). Completely separate pipelines, separate prompts, separate concerns.
02
Delivery Channel Is King
A bulletin board must read like a bulletin board. A broadcast must sound like a broadcast. Wrong rendering makes great narrative feel sloppy, regardless of its quality.
03
Fixed Spine, Variable Flesh
Book mode: spine is pre-authored and immutable. Flesh varies per playthrough. Sandbox mode: spine adapts to player actions, flesh is generated per-beat.
04
Stories Work Without Players
Every arc has a passive timeline. The world moves forward regardless. This creates urgency, immersion, and the feeling of a living world.
05
NPCs Are Not Dialogue Machines
Every NPC has personality, knowledge limits, agendas, emotional state. A guard doesn't know what the faction leader knows. A merchant cares about trade, not politics.
06
The Three-Clue Rule
Any critical information needs 3 independent discovery paths. Players will miss clues, misinterpret clues, and ignore clues. This is non-negotiable.
07
No Examples in Prompts
Examples become ceilings. Use constraints, rules, anti-patterns, and voice direction instead. Proven in EV2090's prompt engineering over production cycles.
08
World State Is Truth
All narrative generation derives from world state. All consequences modify world state. The loop is: State → Narrative → Action → State.
09
Budget-Conscious AI Usage
Sonnet for planning (expensive, infrequent). Haiku for rendering (cheap, frequent). Never call LLMs inline · always use queues or alarms.
10
Genre-Agnostic Core
Arc structure, beat sequencing, and world state work for any genre. The rendering layer is genre-specific. This enables commercialization across different games and universes.
04 · System Architecture

Working Hypothesis · Sprint 1

⚗
This is a scaffolding, not a blueprint. We know the layers exist and the separation is right. We don't yet know exactly what data flows between them, where the expensive decisions live, or how Book and Sandbox modes branch inside this structure. That is the work of Sprint 2.

What we do know with confidence: the single biggest quality failure in EV2090 is that narrative generation and rendering happen in the same model call with the same context. The engine decides what happens and how it sounds at the same time, producing content that serves neither goal well. The architectural hypothesis is therefore a hard separation of those two concerns · not as an abstraction preference, but as a quality mandate.


We also know the direction of cost optimization. The narrative spine is generated rarely and expensively (Sonnet, full context). Beat rendering happens frequently and cheaply (Haiku, narrow context). Any architecture that inverts this · calling Sonnet to render, or calling Haiku to plan · is wrong by definition.

Architecture layers · hypothesis
Layer 1 · Input · Context Assembly
Everything the engine knows before it generates anything
World State Entity Registry Recent Events Player Activity Active Fronts & Clocks Genre Constraints
↓ Sonnet reads this and generates the narrative spine
Layer 2 · Sonnet · Story Generation (expensive, infrequent)
What happens · the decisions a DM makes before anyone sits down to play
Concept · temp 0.85 Continuity Audit · temp 0.7 Beat Choreography · temp 0.8 Consequence Planning Passive Timeline
↓ Haiku receives a beat brief and its channel context · nothing more
Layer 3 · Haiku · Rendering (cheap, frequent)
How it sounds · the DM's voice as it changes for each table, each moment
Feed Writer · 150–400 chars Chat Writer · 3–6 lines Board Writer · 60–180 chars NPC Dialogue · personality-bound Environmental · diegetic
↓ Consequences feed back into world state · closing the loop
Layer 4 · Output & Consequence Processing
What the player sees · and what changes in the world because of it
Book Mode Packages Live Sandbox Events NPC Conversations World State Mutations Audio & Text Renders

Open questions for Sprint 2: What is the exact contract between Layer 2 and Layer 3? How does a beat brief specify what the Haiku writer needs without over-constraining it? Where does world state mutation happen · before or after rendering? How do Book and Sandbox modes diverge in this pipeline, and where do they rejoin?

05 · Roadmap

Five Phases to a Shippable Engine

The roadmap is structured in two-week sprints, each with a clear "done when" definition that feeds directly into the next phase. Progress is tracked in Linear under the Life & Logic team.

Roadmap phases visualization
Phase 1 · In Progress
Research & Foundation
  • 6 research domains completed and reviewed by the team
  • Canonical glossary established and agreed upon
  • Entity, Beat, and Arc schemas drafted (first pass)
  • Delivery channels defined with rendering rules per channel
  • System architecture overview documented as working hypothesis
  • 3 gold-standard beat examples hand-written (not AI-generated)
Phase 2
Schema & Architecture
  • Entity / Beat / Arc / World State schemas finalized and validated
  • Rendering pipeline fully designed with per-channel voice rules
  • Input / output contracts defined between all pipeline layers
  • Prompt templates designed for each generation phase
  • Book vs Sandbox mode branching points formalized
Phase 3
Prototype · Book Mode
  • Can generate a complete 5+ beat mission from a brief
  • Same beat content renders correctly across 3 different delivery channels
  • NPC interaction works within character knowledge bounds
  • Generated book is replayable · same spine, variable flesh across runs
  • Quality bar: a human tester can follow the story without confusion
Phase 4
Prototype · Sandbox Mode
  • Beats generated from live world state · not pre-authored
  • Fronts and clocks tick and advance the passive timeline autonomously
  • Player actions feed back into world state and modify upcoming beats
  • Story remains coherent over 10+ beats with full player interaction
  • NPC chat works for arc characters, not just bounty informants
Phase 5
Integration & Quality
  • Arc and bounty systems connected · shared characters, cross-triggering
  • Rendering passes the delivery channel test: content unmistakably matches its channel
  • Story recap system works for players who missed earlier beats
  • Full loop proven: generation → rendering → interaction → consequence → generation
  • Demo-ready for potential commercial partners
06 · Team

Who's Building This

AD
Andrea Doyon
Project Lead · Technical Architect
System design, AI pipeline, implementation. Andrea brought the EV2090 experience that seeded this project and is responsible for engineering decisions, cloud infrastructure, and the Sonnet / Haiku orchestration pipeline.
NL
Nathalie Lacoste
Narrative Designer · Game Designer
Story structure, beat design, content quality. Nathalie brings the game design eye that ensures the engine produces stories worth playing · not just technically correct narratives. Responsible for quality bar, design pillars, and gold-standard examples.