Un maître du donjon programmable · générant des histoires interactives structurées et de haute qualité
dans n'importe quel univers, dans n'importe quel genre, à n'importe quelle échelle.
Le Narrative Engine est une plateforme de génération d'histoires propulsée par l'IA, capable de créer à la fois des livres de campagne rejouables (dans le style D&D / Warhammer) et des récits sandbox en temps réel (dans le style d'un maître du donjon improvisateur). Il agit comme un MJ programmable capable de générer, de rendre et de gérer des histoires interactives dans n'importe quel univers.
Le projet est né d'EV2090 · un jeu de commerce spatial en direct actuellement en bêta, créé par Andrea Doyon · où un moteur narratif fonctionnel existe déjà, mais souffre d'un manque de qualité dans sa couche de rendu. Le contenu est généré sans conscience de la façon dont il sera consommé. Un message sur un tableau d'affichage sonne comme un narrateur qui raconte une histoire. Un bulletin de station ressemble à un monologue de PNJ. C'est le problème central que le Narrative Engine résout.
Comme un livre de campagne Warhammer ou un module D&D. L'histoire est pré-générée avec une trame fixe · la conspiration se déroule telle qu'elle a été écrite. La chair variable signifie que chaque partie découvre les indices différemment. Conditionnée et vendable sous forme de packs de contenu.
Comme une session de MJ improvisé. Les beats sont générés 1 à 3 à l'avance selon l'état du monde en direct. Les actions des joueurs modifient la trame · vous pouvez tuer la reine, détruire le chantier naval. Une fois joué, le contenu est éphémère. Animé par des fronts, des horloges et des tours de faction.
Le levier de qualité n°1 : Le contexte de rendu. Le moteur doit savoir COMMENT le contenu est consommé. Sonnet décide CE QUI se passe (architecture narrative). Haiku décide COMMENT c'est présenté (voix spécifique au canal, format, ton).
Avant de prendre le moindre engagement de conception, nous avons consacré le premier sprint à la recherche dans six domaines — non pas pour valider des idées que nous avions déjà, mais pour découvrir ce que cinquante ans de conception de jeux de rôle sur table et les dernières recherches en narration IA savent réellement. Chaque domaine a répondu à une question précise que le moteur doit traiter correctement.
Ce sont les décisions verrouillées qui guident tout le travail de conception. Elles sont non négociables · toute fonctionnalité ou tout schéma qui les viole est renvoyé à la case départ.
Ce que nous savons avec certitude : le principal échec de qualité dans EV2090 est que la génération narrative et le rendu se produisent dans le même appel au modèle avec le même contexte. Le moteur décide ce qui se passe et comment ça sonne en même temps, produisant un contenu qui ne sert bien ni l'un ni l'autre objectif. L'hypothèse architecturale est donc une séparation stricte de ces deux préoccupations · non pas comme préférence d'abstraction, mais comme impératif de qualité.
Nous connaissons également la direction de l'optimisation des coûts. La trame narrative est générée rarement et à grand frais (Sonnet, contexte complet). Le rendu des beats se produit fréquemment et à faible coût (Haiku, contexte restreint). Toute architecture qui inverse cela · appeler Sonnet pour le rendu, ou appeler Haiku pour la planification · est incorrecte par définition.
Questions ouvertes pour le Sprint 2 : Quel est le contrat exact entre la Couche 2 et la Couche 3 ? Comment un brief de beat spécifie-t-il ce dont le rédacteur Haiku a besoin sans trop le contraindre ? Où se produit la mutation de l'état du monde · avant ou après le rendu ? Comment les modes Livre et Sandbox divergent-ils dans ce pipeline, et où se rejoignent-ils ?
La feuille de route est structurée en sprints de deux semaines, chacun avec une définition claire de « terminé » qui alimente directement la phase suivante. La progression est suivie dans Linear sous l'équipe Life & Logic.