Eine forensische Untersuchung des Produktionsnarrativsystems · was es im großen Maßstab als funktionstüchtig beweist, wo die Architektur die Decken schafft, durch die wir jetzt brechen müssen, und was acht strukturelle Lücken über die Engine aussagen, die wir als nächstes bauen müssen.
Jedes andere Dokument in dieser Forschungsreihe schöpft aus externen Quellen: veröffentlichten Tabletop-Modulen, akademischer Beat-Theorie, KI-Narrativforschung, Improvisationspädagogik. Dieses hier ist anders. EV2090 ist ein Produktionssystem. Es läuft kontinuierlich. Es generiert alle fünfeinhalb Stunden Story-Arcs. Es führt Beats in Echtzeit aus, verarbeitet Live-NSC-Gespräche, prozessiert Wirtschaftssignale und persistiert Weltzustand über Sitzungen hinweg. Es ist kein Proof-of-Concept.
Dieser Unterschied ist von enormer Bedeutung. Theoretische Forschung sagt uns, was funktionieren sollte. Produktionscode sagt uns, was es tatsächlich tut · und, genauso wichtig, was die Kosten jeder Architekturentscheidung letztlich sind, sobald das System lang genug gelaufen ist, um seine eigenen Grenzen zu enthüllen. Ein Design, das auf einer Whiteboard-Skizze elegant aussieht, entwickelt oft Reibungspunkte, die nur unter Last, Zeitdruck oder wenn die Problemdomäne sich als geringfügig größer herausstellt als der ursprüngliche Umfang angenommen hat, auftauchen.
Die EV2090-Narrative-Engine wurde gebaut, um ein spezifisches Problem für ein spezifisches Spiel zu lösen. Sie wurde nicht als allgemeines Narrativplattform konzipiert. Ihren Quellcode zu lesen ist daher nicht primär eine Übung in Kritik · es ist eine Übung in Archäologie. Wir lesen die Beweise echter Entscheidungen unter echten Einschränkungen und extrahieren aus diesen Beweisen sowohl die Muster, die sich bewährt haben, als auch die Einschränkungen, die jetzt den Umfang dessen definieren, was wir anders bauen müssen.
Die Kerndateien sind narrative-engine.ts (das Durable Object, das den Arc-Lebenszyklus und die Beat-Ausführung verwaltet), narrative/prompts.ts (alle LLM-Prompts), narrative/types.ts (das Typsystem), narrative/validation.ts (Ausgabe-Validierung), bounty-generator.ts (die separate Missionspipeline) und bounty-npc-chat.ts (das interaktive Charaktersystem). Die Architektur liest sich als System, das in Schichten gebaut wurde, wobei jede Schicht das dringendste Problem vor ihr zum jeweiligen Zeitpunkt löste.
Die wichtigste strukturelle Entscheidung in EV2090s Narrative-Engine ist die Mehrphasen-Pipeline. Statt einen vollständigen Arc in einem Aufruf zu generieren, zerlegt das System die Narrativgenerierung in fünf verschiedene kognitive Operationen, jede mit eigener Modellkonfiguration, eigenem Token-Budget und eigener Temperatureinstellung. Das ist keine Leistungsoptimierung. Es ist eine Qualitätsarchitektur.
Die dahinter liegende Erkenntnis ist, dass verschiedene Stadien der Narrativkonstruktion grundlegend verschiedene kognitive Modi erfordern. Eine Storyidee aus dem Nichts zu generieren (hohe Temperatur, uneingeschränkt, kreativ) ist eine völlig andere Aufgabe als diese Idee auf Kontinuität gegenüber früheren Arcs zu prüfen (niedrigere Temperatur, analytisch, vergleichend). Beide Modi in einen einzigen Prompt zu mischen produziert Ausgaben, die weder besonders kreativ noch besonders rigoros sind · das Modell mittelt zwischen den beiden Drücken und erfüllt keinen davon. Sie zu trennen lässt jede Phase genau eine Sache gut machen.
Die fünf Phasen: Konzept (Sonnet, Temp. 0,85, 2000 Tokens) → Audit (Sonnet, Temp. 0,7, 2500 Tokens) → Choreografie + Zeitliches Audit (Sonnet, Temp. 0,8, 5000 Tokens) → Pro-Beat-Schreiber (Haiku × N, Temp. 0,8, 400–800 Tokens pro Beat). Jede Phase hat eine eigene kognitive Rolle, empfängt nur den Kontext, den sie braucht, und produziert eine validierte Ausgabe, die die nächste Phase freigibt.
Die Konzeptphase bei Temperatur 0,85 ist die kreative Phantasie der Engine. Sie empfängt den reichhaltigsten Kontext · eine Wirtschaftsübersicht, die Arc-Geschichte, Weltzustandsnotizen, zeitliche Tempo-Signale und die Wiederkehrende-Charakter-Registry · und produziert daraus eine rohe Storyidee: Titel, Thema, Prämisse, Charaktere (drei oder vier, mit Name, Rolle, Fraktion, Ort, Stimme und Motivation), betroffene Planeten und Rohstoffe sowie eine Welt-Veränderungs-Aussage. Die hohe Temperatur ist bewusst. Hier lebt die Originalität. Zu stark einzuschränken produziert Wiederholung; zu locker lässt Inkohärenz entstehen. 0,85 ist ein eingestellter Wert, kein willkürlicher.
Die Auditphase bei Temperatur 0,7 ist das Kontinuitätsgewissen der Engine. Sie empfängt die Konzeptausgabe neben der vollständigen Arc-Geschichte und führt eine strukturierte Überprüfung durch: Wiederholt dieses Thema etwas kürzlich Aufgelöstes? Sind die Wirtschaftsreferenzen im tatsächlichen Spielzustand geerdet? Sind die Charaktereinsätze spezifisch genug, um zu zählen? Die etwas niedrigere Temperatur spiegelt den analytischen Charakter der Aufgabe wider · das Modell erfindet nicht, es bewertet. Diese Phase fungiert als internes Qualitätstor, das den häufigsten Fehlermodus in der LLM-Narrativgenerierung abfängt: thematische Wiederholung, die das Weltgefühl von Konsequenz erodiert.
Die Choreografiephase bei Temperatur 0,8 und 5000 Tokens ist der Ort, wo der Arc konkret wird. Sie entwirft zehn bis vierzehn Beats über 330 Minuten verteilt, weist jedem Beat einen Lieferkanal zu, etabliert Kausalitätsverbindungen zwischen Beats (jeder Beat muss deklarieren, worauf er reagiert und was er andeutet), und spezifiziert Dateneinjektionsanforderungen · welche Wirtschaftsfelder der Beat-Schreiber zum Renderingzeitpunkt benötigen wird. Das kombinierte Zeitliche Audit in dieser Phase prüft, dass die Beat-Sequenz als Zeitlinie Sinn ergibt: dass Ursachen Wirkungen vorausgehen, dass das Tempo angemessen variiert, dass der Arc einen echten Anfang, eine Mitte und ein Ende hat statt einer flachen Ereignisabfolge.
Die Pro-Beat-Schreiber sind Haiku zum Ausführungszeitpunkt. Nicht zum Generierungszeitpunkt · zum Ausführungszeitpunkt. Der Arc wird im Voraus choreografiert, aber der Beat-Inhalt wird gerendert, wenn der Beat auslöst. Das bedeutet, jeder Haiku-Aufruf empfängt Live-Daten: aktuelle Wirtschaftswerte, aktueller Weltzustand, die bereits gefeuerten Beats und die vollständige Rendering-Spezifikation des Beats. Das Ergebnis ist Inhalt, der narrativ kohärent mit dem Arc-Design, aber wirtschaftlich im gegenwärtigen Moment geerdet ist.
Die Infrastrukturwahl, die all das trägt, sind Cloudflare Durable Objects mit alarmbasierter Planung. Das NarrativeEngine Durable Object ist eine einzige global-einzigartige Instanz mit eigenem persistentem SQLite-gesichertem Speicher. Es weckt sich selbst auf einem Fünf-Minuten-Alarm-Tick auf, um zu prüfen, ob ein Beat ausgelöst werden muss, die Arc-Zeitlinie voranzurücken oder einen neuen Arc zu generieren, wenn der aktuelle abläuft. Das Alarmsystem bietet garantierte Mindestens-einmal-Ausführung mit exponentiellem Backoff-Retry · was bedeutet, ein Beat, der nicht gerendert werden kann, verschwindet nicht still von der Zeitlinie, er wiederholt automatisch, bis er erfolgreich ist oder seine Versuche erschöpft.
Das Fünf-Minuten-Tick-Intervall ist eine überlegte Designwahl. Es ist kurz genug, um narrative Dynamik aufrechtzuerhalten · ein Spieler, der regelmäßig eincheckt, wird die Welt sich bewegen sehen · aber lang genug, um die Latenz eines LLM-Aufrufs zu absorbieren, ohne Druck zu erzeugen, Phasen zu überspringen. Es bedeutet auch, dass das System Beat-Fenster elegant verarbeiten kann: Wenn ein Beat für Minute 47 geplant war und der Alarm bei Minute 50 auslöst, wird der Beat noch ausgelöst statt verpasst. Die Arc-Dauer von 5:30 (330 Minuten) über 10–14 Beats produziert einen durchschnittlichen Beat-Abstand von etwa 25–33 Minuten, was dem Temporhythmus entspricht, den menschliche SLs in Live-Sitzungen natürlich annehmen.
EV2090s Rendering-Schicht verwendet drei verschiedene Lieferkanäle, jeder als separater Schreiber instanziiert: der Feed-Schreiber (Stationsbroadcasts, 150–400 Zeichen, institutionelle Stimme), der Chat-Schreiber (NSC-Funk-COMMS, 3–6 Zeilen, persönliche Stimme im Charakter) und der Board-Schreiber (Pinnwandnotizen, 60–180 Zeichen, handgeschriebenes Gefühl). Das sind keine stilistischen Variationen desselben Prompts. Es sind echte separate Schreiber-Instanzen mit separaten System-Prompts, separaten Anti-Muster-Listen und separaten Erfolgskriterien.
Der Qualitätsunterschied, den das produziert, ist nicht subtil. Ein einziger Allzweck-Schreiber, dem Kanalführung als Parameter gegeben wird, produziert Inhalt, der die Stile mittelt · etwas zu formal für Chat, etwas zu persönlich für Broadcast. Die kognitive Last, einen Stil beizubehalten und dabei einen anderen zu vermeiden, erzeugt eine Art Prompt-Interferenz. Separate Instanzen eliminieren diese Interferenz vollständig. Der Feed-Schreiber weiß nicht, dass der Chat-Schreiber existiert. Er weiß nur, wie eine Stationsansage klingt und wie sie niemals klingen darf.
150–400 Zeichen. Institutionell, unpersönlich, deklarativ. Die Stimme von Systemen und Infrastruktur · nicht von Menschen. Anti-Muster: keine erste Person, kein emotionales Register, keine Spekulation. Erfolg: liest sich als offizielle Mitteilung einer Behörde, der Ihre Gefühle gleichgültig sind.
3–6 Zeilen. Persönlich, im Charakter, emotional präsent. Die Stimme einer spezifischen menschlichen Person in einer spezifischen Situation. Anti-Muster: keine Allwissenheit, keine saubere Exposition, keine Information, die der NSC tatsächlich nicht hätte. Erfolg: Man fühlt, als hätte man eine echte Übertragung belauscht.
60–180 Zeichen. Knapp, praktisch, handgeschrieben unter einem gewissen Druck. Anti-Muster: keine vollständigen Sätze mit Subjekten und Verben, keine formale Grammatik, kein Erzählerrahmen. Erfolg: liest sich, als hätte jemand das angeheftet und ist dann gegangen.
Die ElevenLabs-v3-Integration erzwingt eine Disziplin, die alle Kanäle verbessert: kurze Sätze, keine visuelle Formatierung, Emotions-Tags wo nötig. Die Einschränkung, für Ohren statt Augen zu schreiben, produziert straffere, aktivere Prosa. Eine Designregel, die aus Audioqualitätsgründen übernommen wurde, verbessert als Nebeneffekt die Textqualität.
Die 4-Pass-Generierungspipeline des Auftragssystems erweitert diese Logik auf Audio. Nachdem die Kern-Auftrag-Narrative von Sonnet generiert wurde (Temperatur 0,9, 4096 Tokens · höhere Kreativität für Missionsszenarien), generiert ein Haiku-Pass atmosphärische Feed-Einträge für die Spielwelt, und dann synthetisiert ElevenLabs Audio-Briefing- und Abschlussdateien, die neben den strukturierten Auftragsdaten in R2 gespeichert werden. Die Pipeline behandelt Audio als erstklassigen Lieferkanal, nicht als Nachbearbeitungsschritt. Die TTS-bewusste Schreibeinschränkung · kurze Sätze, keine verschachtelten Klauseln, im Text eingebettete Emotions-Tags · wird zum Generierungszeitpunkt erzwungen, nicht nachträglich bearbeitet.
Das ist eine bedeutungsvolle Architekturlektion. Wenn eine Rendering-Einschränkung zum Zeitpunkt der Generierung statt zum Zeitpunkt der Lieferung angewendet wird, verbessert sie den zugrunde liegenden Inhalt statt seine Präsentation zu flicken. Für das Emotions-Tag-System von ElevenLabs v3 zu schreiben produziert Prosa, die von Natur aus rhythmischer und ausdrucksvoller ist, weil es den Schreiber (in diesem Fall das Modell) zwingt, über emotionales Register explizit zu sein statt darauf zu vertrauen, dass der Leser es inferiert.
EV2090s Prompt-Design spiegelt eine Reihe hart erkämpfter Prinzipien wider, die nicht sofort aus ersten Prinzipien offensichtlich sind. Sie entstanden durch das Betreiben des Systems, das Beobachten von Fehlermodi und deren Korrektur. Jedes Prinzip adressiert eine spezifische Klasse von Ausgabeverschlechterung. Sie sind es wert, einzeln zu untersuchen.
Die einzige kontraintuitivste Regel im System. Beispiele sind für menschliche Lernende pädagogisch effektiv. In LLM-Prompts funktionieren sie anders: Sie werden gleichzeitig zur Untergrenze und zur Obergrenze. Das Modell verankert sich am bereitgestellten Beispiel und produziert Variationen davon statt frei innerhalb der definierten Einschränkungen zu generieren. Das Ergebnis ist eine Art narrative Monokultur · technisch akzeptable, aber strukturell identische Ausgaben. Beispiele zu entfernen und durch Einschränkungen (was vorhanden sein muss) und Anti-Muster (was niemals erscheinen darf) zu ersetzen, produziert Ausgaben mit höherer Varianz, was in einem Erzählgenerierungssystem dasselbe bedeutet wie höhere Qualität.
Jeder Schreiber-Prompt in EV2090 enthält einen „DAS NIEMALS TUN"-Abschnitt. Die Liste ist spezifisch und empirisch abgeleitet: nicht „Klischees vermeiden", sondern „einen Stationsbroadcast nie mit dem Namen einer Person beginnen." Nicht „natürlich schreiben", sondern „das Wort ‚plötzlich' nie in einer Board-Notiz verwenden." Diese Spezifizität ist wichtig. Vage negative Führung („zu formal vermeiden") gibt dem Modell wenig handlungsfähige Einschränkung. Spezifische Anti-Muster („eine COMMS-Zeile nie damit beginnen, dass ein Charakter seine aktuelle Situation jemandem erklärt, der sie bereits wissen würde") schließen präzise Schlupflöcher. Die Anti-Muster-Liste ist ein Diagnose-Artefakt · jeder Eintrag repräsentiert einen in der Produktion beobachteten und korrigierten Fehlermodus.
Kein Prompt im System ist statisch. Jeder Aufruf assembliert seinen System-Prompt zum Generierungszeitpunkt aus aktuellem Weltzustand, aktuellen Wirtschaftsdaten, der Arc-Geschichte und dem relevanten Entitätsregister. Das bedeutet, das Modell arbeitet nie auf veraltetem Kontext. Es bedeutet auch, dass die Prompts selbst Funktionen sind · ihre Ausgabe ist eine Eigenschaft ihres Eingabe-Zustands, kein festes Artefakt. Das ist für ein lang laufendes System, wo die Welt sich kontinuierlich verändert, architektonisch solide. Hartcodierte System-Prompts, die spezifische Spielfakten referenzieren, werden falsch, wenn sich die Welt entwickelt; dynamische Injektion stellt sicher, dass der Kontext des Modells „was ist gerade wahr" stets korrekt ist.
Jeder Beat in der Choreografie muss sowohl einen reactsTo-Wert (die Beat-ID oder das Ereignis, auf das er antwortet) als auch einen foreshadows-Wert (den Beat oder die Konsequenz, auf die er hinweist) deklarieren. Das wird nicht durch einen Validator erzwungen · es wird durch die Prompt-Struktur selbst erzwungen, die diese Felder als erforderlich statt optional behandelt. Der praktische Effekt ist, dass das Modell gezwungen wird, relational statt sequenziell zu denken. Es kann keinen Beat generieren, der isoliert existiert. Jede narrative Einheit muss in das kausale Gewebe des Arcs eingewoben sein. Das Ergebnis sind Arcs, die sich wie Geschichten anfühlen statt wie Ereignisprotokolle.
Während der Choreografie generiert das Sonnet-Modell keinen Wirtschaftsinhalt · es spezifiziert, welche Wirtschaftsfelder jeder Beat beim Auslösen benötigen wird. Der Beat-Schreiber (Haiku) empfängt dann die tatsächlichen Live-Werte zum Ausführungszeitpunkt. Diese Trennung bedeutet, dass narrative Struktur (weit im Voraus geplant) und wirtschaftliche Erdung (notwendigerweise aktuell) nie in Konflikt stehen. Ein Beat über einen Rohstoffpreisanstieg ist als narrativer Moment während der Arc-Generierung entworfen, aber die spezifischen Preise im gerenderten Inhalt spiegeln wider, was der Markt tatsächlich sagt, wenn der Beat auslöst, nicht was der Markt 5 Stunden früher sagte, als der Arc geplant wurde.
Die anspruchsvollste Komponente des EV2090-Narrativsystems ist auch die am wenigsten sichtbare: der NSC-Informanten-Chat-Handler in bounty-npc-chat.ts. Er ist anspruchsvoll genug, dass seine Architektur es wert ist, im Detail untersucht zu werden, weil er ein Problem löst, das das breitere System nicht löst · das Problem der aufrechterhaltenen Charakterkonsistenz über einen mehrstufigen Dialog mit einem Live-Spieler.
Das System verwendet Haiku bei Temperatur 0,8 mit maximal 120 Tokens pro Antwort. Das Token-Limit ist bewusst: Es verhindert, dass NSCs expositiv werden, zwingt Antworten, gesprächsmäßig und im Charakter zu bleiben, und hält die Kosten pro Austausch niedrig genug, dass ein Spieler einen vollständigen Untersuchungsdialog führen kann, ohne dass das Kostenmodell prohibitiv wird. Ratenlimitierung auf 10 Anfragen pro Minute und ein 40-Austausch-Cap pro Sitzung verhindert Missbrauch, gibt echten Ermittlern aber genug Spielraum.
Die Speicherarchitektur ist ein rollendes 8-Austausch-Fenster, das in R2 gespeichert ist. Das ist eine pragmatische Wahl, die ein echtes Problem löst: Das Kontextfenster, das benötigt wird, um eine vollständige Gesprächshistorie zu halten, wächst unbegrenzt, aber die letzten 8 Austausche enthalten praktisch alle Informationen, die ein NSC braucht, um gesprächliche Kohärenz aufrechtzuerhalten. Frühere Austausche werden in die Persönlichkeitskarte und das Faktenregister des NSC komprimiert statt wörtlich aufbewahrt zu werden. Das rollende Fenster ist der Unterschied zwischen einem System, wo NSCs sich an das letzte erinnern, was man gesagt hat, und einem System, wo sie sich an alles erinnern, was teurer und nicht notwendigerweise kohärenter ist.
Jede NSC-Informanten-Chat-Sitzung hat eine Persönlichkeitskarte (Eigenschaft, Stimme, Fraktion, Wissensumfang, was sie vom Spieler wollen, was sie nie enthüllen werden), ein rollendes Erinnerungsfenster (letzte 8 Austausche), einen Faktenextraktions-Pass (nach jedem Austausch werden Schlüsselaussagen zum Weltzustand extrahiert) und eine Wissensgrenze (dem Modell wird explizit gesagt, was der NSC nicht weiß, nicht nur was er weiß). Das ist die richtige Architektur für Charakterkonsistenz im großen Maßstab.
Der Faktenextraktions-Pass ist das architektonisch interessanteste Element. Nach jedem Austausch führt das System einen zweiten Haiku-Aufruf aus, der die Antwort des NSC liest und faktische Aussagen, die der NSC gemacht hat, extrahiert · erwähnte Preise, enthüllte Orte, fallen gelassene Namen · und sie im Weltzustand speichert. Das bedeutet, NSC-Chat ist nicht nur interaktiver Inhalt; es ist Weltzustandsgenerierung. Ein Spieler, der einen Informanten korrekt verhört, verändert den Zustand der Welt auf kleine, aber bedeutungsvolle Weise. Die Engine weiß, was enthüllt wurde, an wen und wann.
Was dieses Design wirklich beeindruckend macht, ist, dass es gebaut wurde, um ein Auftragssystemproblem zu lösen · Spieler zu Hinweisen zu bringen · und am Ende ein Charakterinteraktionsmodell produzierte, das ausreichend anspruchsvoll ist, um die breitere Engine anzutreiben, die wir jetzt entwerfen. Die Tragödie ist, dass es im Auftragssystem begraben ist. Arc-Charaktere in EV2090 können nicht mit ihnen gesprochen werden. Die NSC-Chat-Infrastruktur existiert nur für Auftrags-Informanten, die für eine einzige Mission gebaut und danach verworfen werden. Die Verallgemeinerung dieser Architektur auf alle Arc-Charaktere ist eines der wertvollsten Dinge, die die Narrative Engine tun kann.
Eine strukturelle Lücke ist kein Bug. Ein Bug ist ein Implementierungsfehler · etwas, das das System tun sollte, aber nicht tut. Eine strukturelle Lücke ist eine Designgrenze · ein Ort, wo die Architektur wie konzipiert etwas nicht leisten kann, nicht weil sie falsch implementiert wurde, sondern weil sie nie dafür entworfen wurde. Die Grundursache jeder Lücke zu verstehen ist wichtiger als die Symptome zu katalogisieren, weil Grundursachen aufzeigen, was auf architektonischer Ebene überdacht werden muss statt auf Implementierungsebene geflickt zu werden.
NarrativeEngine-DO und das BountyRegistry-DO sind Peers, keine Kollaborateure. Ein Arc-Charakter, der ein Verbrechen bezeugt, kann nicht zum Ziel eines Auftrags werden. Ein Auftragsergebnis kann keine Arc-Front voranbringen. Die Systeme, die am engsten gekoppelt sein sollten, sind vollständig voneinander isoliert.
NarrativeEngine-Alarm-Tick rückt die Zeitlinie basierend auf vergangenen Minuten vor, nicht auf Spieleraktionen. Es gibt keine API-Oberfläche, durch die Spielerverhalten in das Narrativsystem eintritt. Spieler beobachten die Geschichte; sie können sie nicht modifizieren. Die Architektur hat kein Konzept einer Spielerentscheidung, die das Ergebnis eines Beats ändert, eine Front vorzeitig voranbringt oder den Arc verzweigt.
locate_*-Muster herum entworfen · ein Schiff finden, eine Person finden. Die Hinweisstruktur, das NSC-Informantenmodell und die Auflösungslogik gehen alle davon aus, dass die Aufgabe des Spielers Entdeckung statt Aktion ist. Missionstypen, die erfordern, etwas zu tun (ein Konvoi abfangen, Ladung bergen, ein Ziel eskortieren, einen Kampf gewinnen), erfordern grundlegend andere Schemastrukturen. Das aktuelle Schema kann sie nicht repräsentieren, also wurden sie nie implementiert.
system-context.ts. Das Sol-System mit vier Planeten ist keine Konfiguration · es ist eine Konstante. Trotz teilweise aufgebauter Infrastruktur für Mehrsystemspiel an anderer Stelle in der Codebase setzt die Narrative Engine standardmäßig Sol ein, weil der Kontext, der die Arc-Generierung formt, nicht konfigurierbar ist. Die Planetennamen, ihre Wirtschaften, ihr politischer Charakter · alles ist in eine Datei eingebaut, nicht in ein Schema, das mit der Geografie jedes beliebigen Universums gefüllt werden könnte.
persistent_facts-Speicher, aber diese Fakten werden nie Spielern präsentiert. Sie existieren, um die Konzeptphase des nächsten Arcs zu informieren · Sonnet Kontinuitätskontext zu geben, wenn die nächste Geschichte generiert wird. Der Mechanismus, um Spieler, die Beats verpasst haben, auf den aktuellen Stand der Narrative zu bringen, existiert nirgends im System. Die Fakten sind da; die Rendering-Schicht für diese Fakten nicht.
trigger_disruption, adjust_stock, post_board_note · die auslösen und vergessen werden. Sie produzieren transiente wirtschaftliche Ereignisse, aber keine dauerhaften wirtschaftlichen Mutationen. Ein Beat über einen Handelsroutenkollaps modifiziert das zugrunde liegende Wirtschaftsmodell tatsächlich nicht auf eine dauerhafte Weise, die zukünftige Arcs erben. Narrative und Wirtschaft laufen parallel statt sich gegenseitig bidirektional zu beeinflussen.
bounty-npc-chat.ts wird pro Auftrag instanziiert. Es ist ein Auftrags-Feature, kein Narrativ-Feature. Arc-Charaktere · die Protagonisten, Antagonisten und Zeugen der Hauptgeschichte · sind einmalig gerenderter Inhalt. Die reichhaltige Persönlichkeitskarte + rollendes Erinnerungsfenster + Faktenextraktions-Architektur existiert, hat aber kein Äquivalent auf Arc-Ebene. Das System, das die interessantesten Spielerinteraktionen antreiben könnte, ist nur mit dem Missionssystem verdrahtet, das den am meisten in sich abgeschlossenen Inhalt generiert.
Die Lücken zusammengelesen ergibt sich ein Muster. Die meisten von ihnen teilen dieselbe Grundursache: Das System wurde als zwei separate Pipelines (Arcs und Aufträge) gebaut, die eine Laufzeitumgebung, aber keine Architektur teilen. Die Entscheidungen, die jede Pipeline in Isolation gut funktionieren ließen · separate Durable Objects, separater Zustand, separate Entitätsmodelle · sind genau die Entscheidungen, die sie daran hindern, zusammenzuarbeiten. Die Narrative Engine muss diese Lücken nicht einzeln beheben. Sie muss die architektonische Trennung adressieren, die sie hervorgebracht hat.
Das Kostenmodell der EV2090-Pipeline ist im Prinzip unkompliziert: Sonnet-Aufrufe sind teuer und selten (einmal pro 5,5-Stunden-Arc, ungefähr 4–5 Aufrufe für die vollständige Pipeline), und Haiku-Aufrufe sind günstig und häufig (einer pro Beat, 10–14 pro Arc). Die Wirtschaft begünstigt diese Architektur stark. Ein vollständiger Arc-Generierungszyklus kostet einen Bruchteil dessen, was ein naiver Ansatz · ein Sonnet-Aufruf pro Beat · kosten würde, und produziert höhere Qualität, weil die Planungs- und Rendering-Verantwortlichkeiten sauber getrennt sind.
Das Auftragssystem fügt ElevenLabs-Synthese zu diesem Modell hinzu, was eine andere Kostenstruktur einführt: Audiogenerierung wird pro Textzeichen berechnet, was die Länge von Briefing- und Abschlussinhalt zu einem echten Kostentreiber macht. Deshalb ist die TTS-bewusste Schreibeinschränkung · kurze Sätze, kein Polster · keine bloße ästhetische Präferenz. Sie ist Kostendisziplin. Jedes Wort, das in einem Briefingtext nicht existieren muss, kostet Geld zur Synthese. Die Einschränkung, die Audio besser klingen lässt, macht es auch günstiger.
Der claude-client.ts-Wrapper enthüllt etwas Wichtiges über Produktionszuverlässigkeit. Er implementiert Retry-Logik mit exponentiellem Backoff und pflegt Generierungsversuchszähler pro Phase. Das Retry-Muster ist keine defensive Programmierung · es ist eine Reflexion beobachteter Realität. LLM-API-Aufrufe scheitern. Sie laufen in Timeout, geben fehlerhaftes JSON zurück oder produzieren Ausgaben, die die Validierung nicht bestehen. In einem System, wo ein fehlgeschlagener Arc-Generierung fünf Stunden Stille in der Spielwelt bedeutet, ist das kein akademisches Anliegen. Die Validierungsschicht in validation.ts ist der eigentliche Kostentreiber, wenn die Generierung scheitert: Ein Validierungsversagen in der Choreografiephase bedeutet, dass die drei Sonnet-Aufrufe, die ihr vorausgingen, versunkene Kosten sind, und die Phase muss regeneriert werden.
Das macht die Validierungsarchitektur zu einer Kostenarchitektur. Je präziser die Validierungsschicht partielle Fehler identifizieren und ablehnen kann · die guten Teile einer Generierung behalten, während nur die Phase, die scheiterte, erneut ausgeführt wird · desto geringer die Kosten der Kohärenzwiederherstellung. Das aktuelle System hat keine partielle Wiederherstellung; ein Validierungsversagen in Phase 4 startet von Phase 1 neu. Das ist bei aktuellen Arc-Volumina akzeptabel, würde aber im großen Maßstab teuer werden.
Die echte Kostenerkenntnis aus EV2090 ist, dass die Kosteneinheit nicht der API-Aufruf ist · sondern der kohärente Arc. Ein System, das fünf günstige Arcs mit hohen Fehler- und Retry-Raten generiert, kann mehr kosten als ein System, das drei teurere Arcs mit nahezu null Fehlerrate generiert. Für Generierungsqualität zu entwerfen bedeutet auch, für Generierungskosten zu entwerfen, weil Qualität die Fehlermodi reduziert, die teures Recovery erfordern.
Die Bewegung von 0,85 (Konzept) zu 0,7 (Audit) zu 0,8 (Choreografie) ist keine Sammlung willkürlicher Tuning-Entscheidungen · es ist ein Modell dafür, wie Narrativkonstruktion sich in jeder Phase anfühlen sollte. Hohe Temperatur für den kreativen Sprung, niedrigere Temperatur für die kritische Überprüfung, mittlerer Bereich für das strukturelle Design, das sowohl erfinderisch als auch kohärent sein muss. Dieser Gradient ist es wert, in der Designspezifikation der Narrative Engine formalisiert zu werden statt als implizites Wissen in einer Konfigurationsdatei zu verbleiben.
Die Entscheidung, NSC-Chat-Antworten auf 120 Tokens zu begrenzen, sieht wie eine Kosteneinschränkung aus. Es ist tatsächlich eine Charakterdesign-Einschränkung. Bei 120 Tokens ist eine NSC-Antwort ungefähr 2–4 Sätze. Das reicht aus, um im Charakter zu sein, eine Information zu vermitteln und Neugier auf den nächsten Austausch zu erzeugen. Bei 400 Tokens werden NSCs zu Monologen. Sie erklären zu viel, brechen den Charakter durch schiere Wortmenge und geben Spielern alles in einem Zug statt fortgesetzes Engagement zu belohnen. Das Limit macht die Charaktere besser, nicht nur günstiger.
Wenn Spieler-Austausche mit NSC-Informanten extrahierte Fakten produzieren, die in den Weltzustand eingehen, hört das NSC-Chat-System auf, ein Inhaltsliefermechanismus zu sein, und wird ein Weltaufbaumechanismus. Der Spieler empfängt nicht nur Informationen · er generiert sie, in dem Sinne, dass seine spezifischen ermittlerischen Entscheidungen bestimmen, welche Fakten im Weltzustand kanonisch werden. Das ist eine bedeutsame Fähigkeit, die das EV2090-System hat, aber nicht vollständig ausschöpft, weil die extrahierten Fakten auf den Auftrag statt auf den breiteren Arc- und Weltkontext beschränkt sind.
EV2090 ist eine Geschichte zweier Systeme, die parallel gebaut wurden und ein System aus einem gemeinsamen Kern hätten sein müssen. Die Anspruchlichkeit des Auftrags-NSC-Chat-Systems und die Anspruchlichkeit der Arc-Generierungspipeline sind ungefähr vergleichbar · aber sie teilen nichts. Kein Entitätsregister, kein Weltzustandsprotokoll, kein gemeinsames Kausalitätsmodell. Das Teuerste am Narrative-Engine-Projekt sind nicht die LLM-Kosten. Es sind die Kosten für das Entwerfen einer einheitlichen Architektur von Anfang an statt für das Zahlen der Refactoring-Kosten für das Zusammenführen zweier ausgereifter Systeme, die nie dafür entworfen wurden, miteinander zu kommunizieren.
Der Wert dieser Analyse liegt nicht darin, zu katalogisieren, was EV2090 falsch macht. Er liegt darin, was wir gelernt haben, in konkrete Architekturentscheidungen für die Narrative Engine zu übersetzen. Jede Schlussfolgerung unten ist direkt auf Beweise aus dem Produktionscode zurückführbar.
Die Fünf-Phasen-Pipeline-Struktur ist bewiesen · wir entwickeln sie, ersetzen sie nicht. Die Konzept → Audit → Choreografie → Pro-Beat-Rendering-Sequenz ist durch Produktion validiert. Die Narrative Engine erweitert diese Struktur (fügt eine Konsequenzverarbeitungsphase und eine Kontextassemblierungsphase vor Konzept hinzu), gestaltet sie aber nicht neu. Die kognitive Trennung von Phasen, der Temperaturgradient und die Sonnet/Haiku-Aufteilung werden alle beibehalten.
Das Drei-Kanal-Modell wird zu fünf Lieferkanälen. Feed, Chat und Board sind bewiesen. Die Narrative Engine fügt NSC-Dialog (direkte Konversation im Charakter, die Verallgemeinerung des Auftrags-Informanten-Modells) und Umwelt (diegetische Dokumente, abgefangene Übertragungen, gefundene Objekte) hinzu. Jeder Kanal behält seine eigene Schreiber-Instanz, Anti-Muster-Liste und Rendering-Spezifikation. Kein Allzweck-Schreiber. Keine Kanalparameter.
Die NSC-Chat-Architektur wird das Standardmuster für alle NSC-Interaktionen. Persönlichkeitskarte + rollendes Erinnerungsfenster + Faktenextraktion ist kein Auftrags-Feature · es ist das grundlegende NSC-Interaktionsmodell. Jeder Arc-Charakter, mit dem ein Spieler interagieren kann, erhält diese Architektur. Die einzige Variation ist der Umfang: Auftrags-Informanten haben enges Wissen, Arc-Charaktere haben arc-weites Wissen, wiederkehrende Weltcharaktere haben Weltzustandswissen. Der Mechanismus ist identisch.
Arc- und Auftragsgenerierung teilen dieselbe Pipeline · sie sind Modi, keine separaten Systeme. Es gibt ein Entitätsregister, einen Weltzustand, ein Kausalitätsmodell. Arcs und Aufträge sind beide narrative Strukturen, die Entitäten referenzieren, Beats auslösen, Weltzustand modifizieren und spielerseitigen Inhalt produzieren. Der Unterschied zwischen ihnen ist eine Frage des Umfangs und der Dauer, nicht der Architektur. Sie auf derselben Pipeline zu bauen eliminiert Lücke 1, Lücke 3, Lücke 8 und den Großteil von Lücke 6 gleichzeitig.
Der Weltzustand wird die einzige Wahrheitsquelle. Planetenbeschreibungen, Wirtschaftszustand, Entitätspositionen, Arc-Geschichte, Spielerzustand · alles lebt im Weltzustand, versioniert und abfragbar. Nichts ist in einer Kontextdatei hartcodiert. Kontextassemblierung zu Beginn jeder Generierungspipeline liest aus dem Weltzustand; Konsequenzverarbeitung am Ende schreibt in ihn. Die Schleife ist geschlossen.
Validierungstore sind explizite Pipeline-Phasen, keine Fehlerbehandler. Das aktuelle System behandelt Validierung als try-catch um Generierung. Die Narrative Engine behandelt Validierung als benannte Pipeline-Phase mit definierten Eingaben, Ausgaben und partiell-Wiederherstellungs-Semantik. Eine Choreografie, die die Konzeptvalidierung besteht, aber das zeitliche Audit scheitert, löst einen partiellen Neustart von Phase 3 aus, keinen vollständigen Neustart von Phase 1. Das reduziert sowohl Latenz als auch Kosten für die häufigsten Fehlermodi.
EV2090 konvergierte auf feste Spine / variables Fleisch, NSC-Persönlichkeitskarten und Hinweisknotennetzwerke ohne das Tabletop-Design zu studieren · es entdeckte sie durch Bauen und Scheitern. Diese Konvergenz validiert die Forschung: EV2090 ist nicht nur eine Codebase, die verbessert werden muss; es ist eine unabhängige Bestätigung, dass diese Strukturprinzipien notwendig sind.
Die EV2090-Choreografiephase generiert eine typisierte Beat-Sequenz (arc_start, development, climax, resolution), aber das Typsignal erreicht den Renderer nie. Haiku empfängt den Beat-Brief, aber nicht den Beat-Typ · also werden ein Charakter-Beat und ein Story-Beat mit demselben Register gerendert. Beat-Theorie benennt die Lücke und liefert die Lösung: Das Typfeld gehört in das Rendering-Brief.
EV2090 hat keine Fronts, keine Drei-Hinweis-Durchsetzung und keine passive Zeitlinie. Der Arc wird auf einem Timer ausgeführt; die Welt bewegt sich nicht. Die Improv-SL-Forschung beschreibt genau diese drei Mechanismen als nicht verhandelbar für narrative Kohärenz. Ihr Fehlen erklärt, warum sich EV2090-Arcs wie geplante Sendungen statt lebendige Geschichten anfühlen.
Die fünf in der ACL-Übersicht katalogisierten Fehlermodi · Kohärenzkollaps, Charakterinkonsistenz, Temposcheitern, Kontextblindheit, Handlungsmacht-Illusion · bilden sich direkt auf die acht strukturellen Lücken in EV2090 ab. Kontextblindheit ist das Rendering-Schicht-Problem. Charakterinkonsistenz ist das fehlende Persönlichkeitsmodell. Handlungsmacht-Illusion ist das Fehlen echter Spieler-Feedback-Schleifen.