Das Netzwerk: Handbuch zur Visual Novel

Das Netzwerk ist eine spielbare Adaption der Novelle "Das Netzwerk": eine lineare, bebilderte Erzählung mit Entscheidungspunkten, kein Adventure. Du klickst dich durch Dialogboxen, siehst sechs Figuren als Tuschezeichnungs-Puppen auf einer Bühne und triffst an ausgewählten Stellen Entscheidungen, die den Tonfall und den Epilog beeinflussen.

Die Novelle selbst erzählt von sechs Mitarbeitenden eines fiktiven öffentlich-rechtlichen Auslandssenders, dem "Bundesrundfunk International" (BRI), die zwischen Januar 2026 und März 2030 heimlich ein föderiertes, zensurresistentes Sendenetzwerk aufbauen, weil die Zentrale den Journalismus nicht mehr schützen kann. Die Handlung bleibt in der Adaption vollständig erhalten: 30 Kapitel, vier Teile plus Epilog. Was du als Spieler beeinflusst, ist nicht ob die Geschichte passiert, sondern mit welcher Haltung die Figuren hindurchgehen, siehe Die Handlung.

Im Februar 2026 fragte ich mich, wie man die Mission einer Rundfunkanstalt vor zerstörerischen Absichten politischer Kräfte im eigenen Land schützen könnte. Wenn das Budget plötzlich wegbricht, verschieben sich die Schwerpunkte weg von Reichweite und "Wir sind die Größten" hin zu "Es gibt uns noch". Aber wie bringe ich Akteure im öffentlich-rechtlichen Rundfunk dazu, eine Dreijahresperspektive einzunehmen und anzufangen, sich auf den Ernstfall vorzubereiten? Ein ins Internet gestelltes Manifest wird niemand lesen. Also machte ich mich daran, ein Szenario als erfundene Geschichte zu spinnen. Herausgekommen war eine Novelle, eine Form im Umfang zwischen Kurzgeschichte und Roman mit ein paar interessanten Eigenschaften: Es gibt ein unerhörte Begebenheit und oft spielt ein Dingsymbol eine Rolle.

Diese Novelle mit ihren 30 Kapiteln diente als Vorlage für die Visual Novel. Die Handlung spielt von Januar 2026 bis März 2030. Aus der Prosa wurden die Spielszenen: gekürzt, in Dialog aufgelöst, mit Regieanweisungen versehen. Aus rund 19.000 Wörtern Prosa wurden etwa 12.000 Wörter Spieltext mit 32 Entscheidungspunkten. Der komplette Bauplan mit allen Entscheidungen und ihrer Begründung steht in plans/graphic-novel-plan.md, dem Ausgangspunkt fast aller Kapitel dieses Handbuchs.

Decker ist das Programm, mit dem man das fertige Spiel spielt und mit dem man Bilder, Karten und Knöpfe von Hand zusammenklicken kann, so ähnlich wie bei einem Karteikasten (daher der Name). Decker wurde von John Earnest erfunden und ist kostenlos. Lil ist die kleine Programmiersprache, die in Decker eingebaut ist. Für "Das Netzwerk" kommen noch drei fertige Decker-Module dazu, die die eigentliche Erzählmaschine bilden:

Diese Module sind nicht dafür gebaut, zusammen zu laufen, passen aber genau ineinander. Wie das zusammenspielt, ist das Kernthema von Software-Architektur.

Bei "Das Netzwerk" kommt außerdem hinzu: der komplette Erzählinhalt (jede Szene, jede Regieanweisung, jede Entscheidung, jede Bedingung) steht in einer einzigen Textdatei, game/data/szenen.twee. Ein Bauprogramm namens build_vn.lil liest diese Datei und baut daraus automatisch das fertige Deck. Das ist der Grund, warum du für die meisten Änderungen keine Programmiersprache lernen musst, siehe Bearbeiten und erweitern.

Software-Architektur und Das Datenformat sind die technischen Kernkapitel und setzen etwas Geduld voraus. Die Bilder erklärt, wie aus Python-Code Tuschezeichnungen werden. Die Handlung beschreibt die Geschichte selbst, ihre Struktur und ihre Variablen. Bearbeiten und erweitern zeigt dir konkrete Arbeitsabläufe zum Weiterschreiben. Lil für Ungeübte gibt dir gerade so viel Lil, wie du zum Ändern der Engine brauchst, inklusive der Fallstricke, in die beim Bau dieses Projekts tatsächlich jemand getreten ist.

Zwei Wege, "Das Netzwerk" zu starten:

Steuerung ist ausschließlich die Maus: Text weiterklicken, eine Antwortmöglichkeit anklicken. Es gibt keine Tastenkürzel, die du lernen müsstest.

Auf der Titelkarte stehen vier Knöpfe:

Darunter zeigt die Titelkarte deinen Fortschritt: "Noch nicht begonnen.", "Zuletzt: <Kapiteltitel>." oder "Durchgespielt.", je nachdem, was der gespeicherte Spielstand hergibt.

Der Kapitelindex listet jeden Kapitelanfang mit seinem Titel. Bereits gespielte Kapitel (und immer das erste) sind anklickbar und springen direkt dorthin; noch nicht erreichte stehen mit dem Zusatz "(noch nicht gespielt)" da und lassen sich nicht anklicken. Das ist keine separate Tabelle, die Liste entsteht aus den Metadaten der Szenendatei selbst, siehe Das Datenformat.

Ein Sprung aus dem Index setzt die Geschichte an diesem Kapitelanfang fort, mit denselben Variablen, die du bis dahin gesammelt hast. Es ist ein Sprung innerhalb derselben Geschichte, kein neuer Anfang.

Auf jeder Karte außer der Titelkarte selbst sitzt oben rechts ein Knopf Menü. Ein Klick darauf sichert deinen aktuellen Stand und bringt dich zurück zur Titelkarte.

Nach jeder einzelnen Passage schreibt die Engine deinen kompletten Spielstand (aktuelle Passage, alle Variablen, welche Passagen du schon gesehen hast) in ein unsichtbares Feld auf der Karte daten. Du musst dafür nichts tun, es passiert automatisch. "Weiterspielen" auf der Titelkarte erscheint deshalb genau dann, wenn dieser Stand existiert und die Geschichte noch nicht zu Ende gespielt wurde.

An den meisten Entscheidungspunkten stehen zwei bis drei Antwortmöglichkeiten. Über den Antwortknöpfen steht eine Frage, entweder die Standardfrage "Was tust du?" oder eine eigene, die in der Szenendatei mit einem ? eingeleitet wird.

Die meisten dieser Entscheidungen ("Haltungswahlen") führen nach ein bis zwei Passagen wieder in denselben Handlungsstrang zurück, verändern dabei aber eine der drei Haltungsvariablen (entschlossenheit, vorsicht, zusammenhalt). Diese Variablen färben späteren Text (siehe die {if …​ else …​ end}-Stellen in der Szenendatei) und am Ende den Epilog, ändern aber nicht, welche Ereignisse stattfinden: die Novelle bleibt in ihrem Verlauf kanonisch. Die einzige echte Verzweigung der gesamten Geschichte liegt in Kapitel 15, der Abstimmung. Mehr dazu, mit allen Variablen im Detail, in Die Handlung.

Auf einem Mac mit Homebrew installierst du die Kommandozeilen-Werkzeuge mit:

lilt prüfst du mit lilt -e '1+1' in einem Terminal; kommt 2 zurück, ist es gefunden und im Suchpfad.

Im Projekt-Ordner liegt bereits eine fertig gebaute Version unter game/build/netzwerk.deck, plus game/build/netzwerk.html für den Browser. Siehe Das Spiel spielen für die Details.

Wenn du an game/data/szenen.twee, game/data/emotes.csv oder den Zeichnungen etwas änderst, musst du das Deck neu bauen, damit die Änderung im Spiel ankommt:

Das liest game/data/szenen.twee, prüft die Daten (siehe unten) und baut daraus game/build/netzwerk.deck und game/build/netzwerk.html neu. Das dauert nur wenige Sekunden, solange sich an den Zeichnungen nichts geändert hat.

Kürzer geht es mit dem Makefile im Projekt-Wurzelverzeichnis:

build_vn.lil liest nicht nur die Szenendatei ein, es prüft sie auch mit, bevor überhaupt ein Deck entsteht: fehlende Sprungziele, unbekannte Puppen, unbekannte Emotes, unbekannte Bühnenpositionen, unbekannte Kommandos, überlappende Puppen und fehlerhafte {lil}-Fragmente. Ein fehlender Hintergrund ist nur eine Warnung. Welche Fehlermeldung was genau bedeutet und wie du sie behebst, steht ausführlich in Bearbeiten und erweitern.

Dieses Handbuch (das Dokument, das du gerade liest) ist AsciiDoc-Quelltext unter handbuch/src/ und wird per Docker zu HTML, EPUB und PDF gebaut, ganz unabhängig vom Spiel selbst:

Details dazu, inklusive wie du ein Kapitel oder ein Diagramm änderst, stehen in handbuch/README.md.

Die drei Decker-Module decken je eine Schicht ab:

Keines dieser Module wurde entworfen, um mit den anderen beiden zusammenzuarbeiten. Dass sie trotzdem genau ineinanderpassen, wurde vor dem eigentlichen Bau headless mit lilt geprüft, bevor überhaupt eine Zeile Engine-Code entstand (plans/graphic-novel-plan.md, Abschnitt 2). Zwei Befunde daraus tragen die ganze Architektur:

build_vn.lil baut das Deck deshalb aus drei fertigen Modul-Decks zusammen, ganz ohne die Module selbst anzufassen:

Der eigentliche Klebstoff zwischen den drei Modulen ist game/lil/vn.lil, gut 650 Zeilen Lil. build_vn.lil setzt diese Datei als Skript des gesamten Decks ein:

Decker verkettet Deck-, Karten- und Widget-Skripte: jede Karte und jeder Knopf im fertigen Deck sieht deshalb alle Funktionen, die in vn.lil definiert sind (vn_spiele, vn_kommando, vn_sprecher, und so weiter). Ein Klick auf "Neu beginnen" auf der Titelkarte ruft am Ende nur vn_start[1] auf.

Das ist die zentrale Entwurfsentscheidung der Engine: es gibt eine einzige Funktion, vn_spiele, die die komplette Erzählung von der Startpassage bis zum Ende (oder bis zum Abbruch über den Menü-Knopf) durchläuft, in einer while-Schleife. Möglich ist das, weil dd.say[] und dd.ask[] synchron sind: sie kehren erst zurück, wenn die spielende Person geklickt hat. Ein kompletter Spieldurchlauf passt damit in einen einzigen Skriptaufruf.

Während dd.say[] oder dd.ask[] intern warten, schickt Decker trotzdem weiterhin animate-Ereignisse an die aktuelle Karte, sodass Puppen weiter blinzeln und Regieanweisungen greifen, ohne dass die Hauptschleife dafür etwas Besonderes tun muss:

Genau dieser Nebeneffekt macht auch den Menü-Knopf möglich: solange die Hauptschleife läuft, blockiert Decker die normale Klick-Zustellung, aber animate kommt weiter durch. vn_heim_geklickt liest deshalb Zeigerposition und Klickstatus direkt aus pointer.pos und pointer.down und setzt nur einen Merker (buehne.widgets.abbruch), den die Hauptschleife zwischen zwei Textboxen prüft und dann sauber abbricht.

Der Kern der Hauptschleife rendert eine Passage und trennt das Ergebnis in zwei Teile:

twee.render[] liefert für eine Passage mit Text und zwei Links eine Tabelle mit den Spalten text, font, arg und pat. Zeilen, deren arg-Spalte leer ist, sind normaler Fließtext oder Regie und gehen an dd.say[] bzw. an die eigene Kommandoerkennung. Zeilen mit gefülltem arg sind Ply-Links: text ist die Beschriftung des Knopfes, arg ist der Name der Zielpassage.

Danach unterscheidet die Schleife drei Fälle, je nachdem wie viele Auswahlzeilen es gibt:

Keine Auswahl heißt: Ende der Erzählung. Genau eine Auswahl ist keine Entscheidung, sondern eine reine Fortsetzung, und wird als letzte Textbox gezeigt statt als sinnloser Ein-Knopf-Dialog (deshalb tragen Fortsetzungslinks in der Szenendatei sprechende Beschriftungen wie "Es klopft." statt Platzhaltern wie "Weiter."). Erst ab zwei Auswahlzeilen erscheint die Frage mit echten Knöpfen über dd.ask[].

Wie eine Passage im Detail zu Prosa und Regie wird, inklusive Sprechererkennung, steht in vn_prosa:

Kommandos werden hier absichtlich selbst erkannt, nicht dd.say[] überlassen: Dialogizer prüft beim Kommando-Erkennen nur das allererste Zeichen eines Absatzes. Ein Lil-Fragment davor, das nichts ausgibt (etwa {vorsicht:vorsicht+1 ""}), hinterlässt einen Zeilenumbruch, und die Regieanweisung dahinter wäre dann stillschweigend zu Fließtext geworden. Deshalb schneidet vn_ohne_rand führende Leerräume selbst ab, bevor geprüft wird.

Der komplette Spielstand ist ein einziges Dictionary (passage, vars, gesehen, beendet) und wird nach jeder Passage in ein unsichtbares Feld auf der Karte daten geschrieben:

"%J" format wandelt ein Lil-Dictionary in eine JSON-Zeichenkette, "%J" parse liest sie verlustfrei zurück, auch mit Umlauten im Text. Weil dieses Feld ein gewöhnliches Widget des Decks ist, überlebt der Spielstand das Schließen und Wiederöffnen von Decker, obwohl die Erzählschleife selbst niemals unterbrochen wird, sondern nur zwischen zwei Textboxen sauber endet.

build_vn.lil legt folgende Karten an:

Hintergründe werden zur Laufzeit nicht als Kartenwechsel behandelt, sondern als Kopie eines Canvas in das Bühnenbild:

Das vermeidet jedes Nachladen von der Platte, was die interaktive Decker-App aus Sicherheitsgründen ohnehin nicht dürfte.

Eine Passage ist eine Szene an einem Ort. Kapitel mit Ortswechsel werden auf mehrere Passagen aufgeteilt, Kapitel ohne auf eine. Der Passagenname folgt dem Muster k<NN>-<kurzname>, zum Beispiel k01-buero oder k15-abstimmung. Der Name ist ausschließlich der Sprungziel-Bezeichner, er wird nie angezeigt.

Kopf einer Passage aus der echten Szenendatei:

Das ist: der Passagenname, in eckigen Klammern die Tags, in geschweiften Klammern ein JSON-Objekt mit beliebigen Metadaten.

Tags tragen Metadaten für Werkzeuge und den Kapitelindex, nicht für die Darstellung selbst: kapitel-01, teil-1, pov-sarah, datum-2026-01. Die Darstellung (Hintergrund, Stimmung, welche Figur wo steht) steuern stattdessen Kommandos im Fließtext, weil die dann an genau der richtigen Stelle im Text stehen und nicht nur passagenweit gelten.

Ein Kapitelanfang trägt seinen Titel im JSON-Objekt:

Die Engine baut daraus den kompletten Kapitelindex (vn_kapitel in game/lil/vn.lil, siehe Software-Architektur): sie liest jede Passage mit einem titel-Schlüssel im Metadaten-Objekt und merkt sich Name und Titel. Zu welchem Kapitel eine beliebige andere Passage gehört, ermittelt vn_kapiteltag über den kapitel-NN-Tag, nicht über die Reihenfolge in der Datei, damit Rücksprünge (etwa die frei wählbare Reihenfolge in Teil II) nichts durcheinanderbringen. Twee 3 erlaubt beliebige Schlüssel in diesem Objekt, und twee.write[] gibt sie unverändert zurück, Twine behält die Angabe beim Bearbeiten also bei.

Passagennamen, Kommandonamen, Puppen- und Emote-Namen, Hintergrund-Namen und Variablennamen sind ASCII (k01-buero, !rueckblende, goerlitz-kinderzimmer). Das gilt nur für Bezeichner. Jeder Text, den die spielende Person zu sehen bekommt, hat selbstverständlich Umlaute, und lilt, twee.read[] und twee.render[] reichen sie verlustfrei durch.

Eine Zeile, die mit ! beginnt, ist für Ply gewöhnlicher Fließtext, für die Engine aber eine Regieanweisung. Kommandos stehen als eigener Absatz, durch Leerzeilen von der Prosa abgetrennt; mehrere Kommandos dürfen innerhalb eines Absatzes mit einfachem Zeilenumbruch gruppiert werden.

Es gibt bewusst kein !talk-Kommando mehr: wer spricht, ergibt sich aus dem Sprecherpräfix im Text selbst, siehe unten.

Sprecher stehen als kurzer Vorspann vor einem Doppelpunkt im Text:

Erzähltext bekommt kein Präfix. Erkannt wird ein Sprecher an einem Vorspann, der wie ein Name aussieht: höchstens drei Wörter, höchstens 24 Zeichen, jedes Wort großgeschrieben. So bleibt Dr. Hartmann: …​ ein Sprecher, während Sie las: der Bescheid war da. Erzähltext bleibt, weil "las" klein anfängt. Das ist die einzige Quelle dafür, wer spricht:

Eine Prosazeile, die mit ? beginnt, ist die Frage, die über den Auswahlknöpfen erscheint:

Fehlt sie, nimmt die Engine den Standardtext "Was tust du?".

Auswahl entsteht über Ply-Links am Ende einer Passage:

Genau ein Link ist keine Auswahl, sondern eine Fortsetzung. Die Engine zeigt dann die Beschriftung als letzte Textbox und springt weiter, statt einen Knopf mit nur einer Möglichkeit anzubieten:

Beschriftungen von Fortsetzungslinks sollten deshalb sprechend sein ("Es klopft.", "Zwei Monate später."), keine Platzhalter wie "Weiter.". Erst ab zwei Links erscheint die Frage mit echten Knöpfen.

Variablen werden über {lil}-Fragmente gesetzt. Sie bleiben über Passagen hinweg erhalten (twee.render[] gibt r.vars zurück, die Engine reicht es an den nächsten Aufruf weiter) und werden nach jeder Passage gespeichert:

Das abschließende "" ist kein Stilmittel, sondern notwendig: ein {…​}-Fragment, das nur eine Variable setzen soll, muss mit "" enden, sonst erscheint der Wert der Zuweisung selbst als Text im Spiel.

Bedingter Text entsteht genauso als Fragment, das einen Wert statt eines leeren Strings zurückgibt:

Der Anfang von Kapitel 1, wörtlich aus game/data/szenen.twee:

An dieser Passage lässt sich fast das ganze Format ablesen: !clear räumt die Bühne, !bg setzt den Hintergrund, !zeit die Ortsmarke, !dunkel die Stimmung. !show sarah neutral center bringt die Puppe auf die Bühne, spätere !show sarah <emote>-Zeilen ohne Position wechseln nur den Ausdruck und behalten die zuletzt gültige Position bei (siehe vn_aktive in Software-Architektur). Der Absatz ohne Sprecherpräfix ("USAGM workforce…​") ist Erzähltext (in diesem Fall ein wörtliches Zitat), Sarah: …​ ist Rede. Die ?-Frage und die zwei Links am Ende von k01-buero bilden die erste Entscheidung der Geschichte; die Antwort k01-konzept erhöht entschlossenheit und führt über einen Ein-Link-Übergang ("Es klopft.") weiter zu k01-michael.

Das zentrale Stilmerkmal ist die variable Strichbreite: ein echter Federstrich setzt haarfein an, schwillt an, wo Druck auf der Feder liegt, und läuft spitz aus. Ein SVG-stroke mit fester stroke-width kann das grundsätzlich nicht, deshalb zeichnet tools/ink.py jeden Strich als gefüllten Umriss entlang einer Mittellinie mit einem Breitenprofil:

Pen.stroke() nimmt eine Liste von Stützpunkten, glättet sie mit einem Catmull-Rom-Spline (catmull()), tastet sie in gleichmäßigen Abständen ab (resample(), wichtig, damit das Breitenprofil sauber sitzt) und legt zusätzlich ein niederfrequentes Zittern quer zur Laufrichtung darüber (wobble()) — "die Hand ist keine CNC-Fräse", wie der Kommentar im Code sagt. outline() baut daraus den geschlossenen Pfad mit runden Endkappen. Auf dieser Basis bietet Pen eine kleine Zeichen-API:

Auch die Kopfdrehung für die drei Blickrichtungen steckt in ink.py, als Zylinderprojektion um die Hochachse (Pen.set_turn): Punkte auf der Kopfrundung wandern über die Silhouette hinweg, während deren Rand fast stehen bleibt, genau wie bei einem wirklich gedrehten Kopf. !flip wird dafür bewusst nicht benutzt, eine gespiegelte Tuschezeichnung sähe falsch aus (der Nasenhaken zeigt dann in die falsche Richtung).

tools/portraits.py zeichnet die sechs Figuren. Haare, Kleidung, Silhouette und Tuschespritzer sind figurenspezifischer Code (die Funktionen sarah(), michael(), jamal(), kat(), lena(), tom()). Augen, Brauen, Nase und Mund dagegen sind Daten: jede Figur deklariert ihre Gesichtsgeometrie als Dictionary in GEO, zum Beispiel Sarah:

Wie ein Emote diese Geometrie verändert (Mundbogen, Brauenneigung, Lidstellung, Pupillenversatz, Mundöffnung, Augengröße), steht als Tabelle in game/data/emotes.csv, nicht im Python-Code:

braue() verschiebt das innere und das äußere Ende eines Brauenstrichs gemäß braue_innen/braue_aussen, die Punkte dazwischen linear interpoliert. mundzug() baut den Mund aus den Eckpunkten der Figur und einem Bogen, der aus figureneigener Grundkrümmung und Emote-Abweichung gemeinsam entsteht:

Diese eine Funktion löst ein Problem, das erst im Bildvergleich auffiel: eine gemeinsame Emote-Tabelle für alle sechs Figuren hätte Kats warmes Lächeln (Grundbogen 15) und Toms Dauergrinsen (21) verschwinden lassen, weil neutral für alle denselben Wert setzt. Die Dämpfung sorgt dafür, dass Tom auch besorgt noch etwas freundlicher wirkt als Lena, ohne dass sorge bei ihm zum Lächeln wird.

Jede Figur liegt in drei Ansichten vor: frontal, _r (Kopfdrehung +0.30, Gesicht nach rechts, die Puppe steht also links auf der Bühne) und _l (Drehung -0.30, steht rechts). Sprechen zwei Figuren miteinander, wenden sie sich dadurch einander zu. Technisch sind das drei eigenständige Puppen mit eigenen Zeichnungen, weil Puppeteer eine Puppe über den Namen ihrer Karte anspricht; in der Szenendatei steht trotzdem immer nur der schlichte Name, die Engine wählt die passende Variante zur Laufzeit aus der Bühnenposition, siehe Software-Architektur.

Pro Figur und Blickrichtung entstehen 14 Canvases:

_blink ist dabei keine eigene Tabellenzeile in emotes.csv, sondern ein Schalter in der Zeichenfunktion selbst: das Auge wird durch einen einzelnen geschlossenen Bogen statt Mandel plus Pupille ersetzt. _open ist einfach die Emote-Zeile mit mund_offen=1. Macht man die Rechnung über alle sechs Figuren und drei Blickrichtungen, kommt man auf 6 Figuren mal 14 Bilder mal 3 Richtungen, also 252 Einzelzeichnungen, generiert in wenigen Sekunden.

18 Hintergründe decken alle 30 Kapitel ab. tools/szenen.py baut sie aus demselben ink.Pen wie die Portraits, aber mit einem eigenen Formenschatz, abgeleitet aus den Urmel-Vorlagen: Kasten, Tisch, Stuhl, Fenster, Regal, Serverschrank, Apparat, Kolben, Pflanze, Papierstapel, Mikrofon, Sofa. Drei Grundregeln aus den Vorlagen bestimmen jede Szene:

Ein Kasten zum Beispiel:

Warum die Bildmitte frei bleibt: dort stehen im Spiel die Figuren, und was hinter ihnen liegt, sieht man ohnehin nicht. Ein Gegenstand in der Mitte wäre also Arbeit, die niemand zu Gesicht bekommt, und bei einer einzelnen Figur auf center säße er genau hinter ihrem Kopf. Deshalb stehen die Gegenstände in szenen.py konsequent am linken und rechten Rand (LINKS, RECHTS = 150, 874 bei 1024 Pixel Breite), und die Mitte bleibt Papier. Das ist keine Notlösung, sondern genau der Aufbau der Urmel-Vorlagen selbst: dort stehen die Dinge neben der Figur, nicht hinter ihr.

Zwei Fallen, die beim Zeichnen der Formen immer wieder auftauchen:

lilt (und damit Decker) liest keine .svg- oder .png-Dateien, nur .gif. tools/render_art.py liest dafür game/data/art.csv, ein Manifest mit den Spalten svg, gif, breite, hoehe, transparent, und führt für jede Zeile dieselbe zweistufige Kette aus: zuerst rsvg-convert, dann magick.

Für Hintergründe (transparent=0 im Manifest) ist damit schon Schluss, das Bild bleibt einfach deckend schwarz-weiß. Für Figuren (transparent=1) kommt ein Schritt dazu, und der beginnt schon in der Zeichnung.

Die Novelle bleibt in ihrem Verlauf verbindlich: das Team stimmt zu, das Netzwerk entsteht, die Kürzung kommt, das Netzwerk hält. Der Spieler kann diesen Verlauf nicht kippen, das wäre eine andere Geschichte, keine Adaption. Was der Spieler stattdessen tut: er entscheidet, mit welcher Haltung die Figuren durch die Geschichte gehen. Genau das ist auch der eigentliche Stoff der Vorlage, und es passt zu einem Medium, das aus Dialogboxen besteht.

30 Kapitel, von Januar 2026 bis März 2030, sechs wechselnde Erzählperspektiven (POV), keine erfundene siebte Spielerfigur:

Teil I (Kapitel 1 bis 8) und Teil IV (Kapitel 24 bis 29) sind streng linear, je ein Kapitel nach dem anderen. Teil III (Kapitel 16 bis 23) ist ebenfalls linear, in Abständen von etwa drei Monaten: die Kausalität lässt keine andere Reihenfolge zu, Toms Fehler in Kapitel 21 (Januar 2029) muss vor seiner Entdeckung stehen, nicht danach.

Nur Teil II hat eine frei wählbare Reihenfolge, weil seine sechs Kapitel tatsächlich am selben Abend spielen: jede der sechs Figuren bereitet sich für sich auf die Abstimmung vor. Umgesetzt ist das über eine Übersichtspassage, t2-runde, mit bedingten Links:

Jedes der sechs Kapitel setzt beim Verlassen ein eigenes Flag (g09 bis g14) und kehrt zur Übersicht zurück. Die Übersicht zeigt dabei nur noch die Kapitel, deren Flag noch nicht gesetzt ist, als Auswahlmöglichkeit an. rtext.make[text schrift ziel] erzeugt dafür eine Zeile mit Sprungziel, die die Engine genau wie einen gewöhnlichen [[…​]]-Link behandelt. Erst wenn alle sechs Flags stehen (gesamt erreicht 6), erscheint überhaupt der Weg zur Abstimmung selbst.

Kapitel 15 ist die einzige echte Verzweigung der gesamten Geschichte. Der Spieler wählt zunächst, für welche der sechs Figuren er den Zettel schreibt (Variable figur):

Danach folgt Ja oder Nein. Die Novelle verlangt Einstimmigkeit ("Wenn auch nur einer Nein sagt, ist das Projekt vorbei."). Ein Nein könnte die Geschichte an dieser Stelle beenden, und genau das soll es nicht, denn die Novelle bleibt kanonisch. Gelöst ist das nicht durch Ignorieren der Wahl, sondern indem die Gruppe ihre eigene Regel unter Druck neu verhandelt: die Figur des Spielers legt kein Veto gegen das Projekt ein, sondern gegen die eigene Beteiligung.

Fünf machen weiter, einer geht. ausgestiegen bleibt für den Rest der Geschichte gesetzt und färbt Schwur, Teil III und den Epilog, etwa im Schwur am Ende von Kapitel 15:

Beide Wege (k15-ja und k15-nein) führen anschließend wieder in k15-konsequenzen und damit zurück in die Hauptlinie zusammen: es ist die einzige Stelle im ganzen Spiel, an der eine Spielerentscheidung den Bestand der Gruppe ändert, und sie kostet etwas, ohne die Handlung strukturell zu brechen.

Diese Variablen bleiben absichtlich wenige: mehr Variablen würden die Kombinatorik der Textvarianten schnell unübersichtlich machen. Ein zweiter Wendepunkt liegt in Kapitel 21: Tom entdeckt seinen eigenen Fehler und entscheidet, ihn zu gestehen oder zu verschweigen (tom_gestanden), was den Ton der Entdeckung in Kapitel 23 und den Prozess in Kapitel 28 verändert, ohne dass die Handlung selbst abzweigt.

Textvarianten aus diesen Variablen entstehen direkt im twee, wie in Das Datenformat gezeigt:

Suche die passende Passage in game/data/szenen.twee (der Passagenname verrät Kapitel und Ort, zum Beispiel k07-vorschlag), ändere den Text zwischen zwei Regieanweisungen oder Leerzeilen, speichere und baue neu:

Öffne danach game/build/netzwerk.deck in Decker neu, siehe Das Spiel spielen.

Eine neue Passage braucht mindestens Kopfzeile, Regie, Text und einen Ausgang. Minimalbeispiel, angehängt an eine bestehende Passage:

Verlinke die neue Passage von irgendwo aus (ein bestehender Fortsetzungslink oder eine neue Auswahl), sonst ist sie zwar vorhanden, aber unerreichbar. Baue neu; build_vn.lil meldet am Ende eine Zeile wie

die auch unerreichbare Sackgassen mit auflistet, falls du eine Passage versehentlich ohne Ausgang lässt.

Aus einer Fortsetzung wird eine Entscheidung, sobald du einen zweiten Link ergänzt und eine ?-Frage davor setzt:

Beide Zielpassagen müssen existieren. Willst du damit auch eine der Haltungsvariablen beeinflussen, setze sie am Anfang der jeweiligen Zielpassage, mit abschließendem "" (siehe Das Datenformat):

Ein siebtes Emote braucht drei Schritte:

Bis das Emote gezeichnet ist, ist es im Spiel trotzdem benutzbar: build_vn.lil erzeugt für ein in szenen.twee referenziertes, aber noch nicht vorhandenes Emote automatisch einen Platzhalter aus neutral und meldet das als Hinweis, nicht als Fehler:

Neue Orte entstehen in tools/szenen.py: eine neue Zeichenfunktion nach dem Muster der bestehenden (siehe Die Bilder, Formenschatz aus Kasten, Tisch, Stuhl, Fenster und so weiter), eingetragen im SZENEN- Dictionary am Ende der Datei. Dann:

Referenziere den Namen danach mit !bg <name> in der Szenendatei. Fehlt das Bild noch, bricht der Bau nicht ab, sondern warnt nur:

Ein zum Test zusammengesetztes Beispielbild (Hintergrund plus Figuren) lässt sich jederzeit mit tools/szenenbild.py erzeugen, ohne das ganze Deck zu bauen:

build_vn.lil prüft die Daten, bevor überhaupt ein Deck entsteht. Eine Auswahl der Fehlermeldungen und ihrer Ursache:

Ein fehlender Hintergrund ist, wie oben gezeigt, nur eine Warnung, kein Fehler: das Deck bleibt spielbar, auch bevor alle Zeichnungen fertig sind.

beobachtet game/data, game/lil und game/build und baut bei jeder Änderung automatisch Tests und Deck neu (braucht entr, brew install entr). Das ersetzt nicht das erneute Öffnen in Decker, siehe Das Spiel spielen.

Ein Doppelpunkt weist einer Variable einen Wert zu, nicht das Gleichheitszeichen:

Funktionsaufrufe benutzen eckige Klammern, Argumente stehen ohne Kommas nebeneinander. on …​ do …​ end definiert eine Funktion, ihr letzter Ausdruck ist automatisch ihr Rückgabewert, ein eigenes return-Wort wie in anderen Sprachen gibt es nicht:

In den meisten Programmiersprachen gilt "Punkt vor Strich". In Lil gibt es diese Regel nicht. Alles wird strikt von rechts nach links ausgewertet, egal welche Operatoren beteiligt sind:

Die ersten sechs stammen aus einem früheren Decker-Projekt derselben Werkstatt, die übrigen kamen beim Bau dieser Visual Novel dazu. Die ausführliche Fassung mit Fundgeschichte steht in plans/graphic-novel-plan.md, Abschnitt 13.

1. In where-Klauseln gehört = hin, nicht ~. where spalte~"x" ist ein stiller No-Op-Filter, where spalte="x" filtert richtig. In der Engine hätte die naheliegende, aber falsche Form where 0<count arg sogar bei richtigem Vergleichsoperator nicht funktioniert, weil count eine ganze Spalte aggregiert statt zeilenweise zu zählen, siehe Software-Architektur.

2. each v k i in dict liefert zuerst den WERT, nicht den Schlüssel. Beim Durchlaufen von deck.cards oder card.widgets führt die falsche Reihenfolge zu leeren Namen und einer stillen Fehlsuche.

3. Funktionsaufrufe vor einem Komma in einer Liste immer klammern. Ohne Klammern verschluckt der Aufruf sonst den Rest der Liste als eigenes Argument, ohne Fehlermeldung.

4. Verkettung ist "" fuse (a,b,c), nicht "praefix" fuse (a,b). fuse benutzt sein linkes Argument als Trennzeichen zwischen den Elementen rechts. "praefix" fuse (a,b) ergibt also a+"praefix"+b, bei einem zusammengesetzten Pfad einen gültigen, aber falschen String.

5. Ein Modul-.value, das mit einer nackten Tabelle endet, wird zu einem flachen Spalten-Dict gecastet. Tabelle vorher in ein Dict-Feld einbetten.

6. Zuweisungen in einer Funktion sind NICHT automatisch lokal. Ohne local schreibt x:…​ in den umgebenden Gültigkeitsbereich, nicht in einen neuen, funktionslokalen. vn_ohne_rand in game/lil/vn.lil zeigt deshalb explizit, wie man es richtig macht:

In build_vn.lil traf genau dieser Fehler einmal die Prüffunktion selbst: eine Hilfsvariable ohne local überschrieb dort die globale Liste aller Passagennamen, woraufhin der Bau plötzlich jedes Sprungziel als fehlend meldete. Das Symptom zeigte dabei nicht im Entferntesten auf die Ursache. Hilfsvariablen in Funktionen deshalb immer mit local deklarieren.

7. by ist ein reserviertes Wort und als Variablenname nicht erlaubt. vn_heim_geklickt in game/lil/vn.lil benennt deshalb, was sonst naheliegend bx/by hieße, um:

Reservierte Wörter lassen sich auch nicht als Funktionsparameter benutzen, und die Fehlermeldung dabei ist nicht immer eindeutig (format als Parametername ergibt zum Beispiel 'format' is a keyword…​, table als lokale Variable ein rätselhaftes Expected name, but found :). Im Zweifel kurz mit lilt -e 'wort:1 show[wort]' testen, ob ein Wort als Variablenname geht.

8. Ein fehlerhaftes Lil-Fragment in der Szenendatei verschwindet spurlos. Ply führt {…​}-Fragmente aus und schluckt Fehler dabei stillschweigend. Siehe Das Datenformat für die Ausweichlösung (eval[] mit Fehlerfeld error).

9. readcsv[] auf einer kopfzeilenlosen Zahlen-CSV kann lilt segfaulten lassen (Exit 139). In diesem Projekt weniger relevant, weil game/data/emotes.csv und game/data/art.csv eine Kopfzeile tragen und ohnehin per Python gelesen werden, nicht per Lil.

10. x.paste[bild pos] behandelt Pattern 0 nicht automatisch als transparent. Dafür ein drittes, wahres Argument nötig: x.paste[bild pos 1]. Das benutzt zum Beispiel vn_hintergrund beim Kopieren des Bühnenbilds nicht, weil Hintergründe deckend sind, wohl aber Puppeteer intern beim Zeichnen der Puppen-Canvases.

So liest vn_sprecher in game/lil/vn.lil aus einem Textabsatz heraus, ob und wer spricht:

Das zeigt mehrere Bausteine auf einmal: rtext.find[] sucht eine Teilzeichenkette, first first treffer holt die Position des ersten Treffers, extract where count@value from …​ split kopf filtert eine Liste über eine Bedingung auf jedem Element, und ein Dictionary wird mit r:() feldweise aufgebaut statt in einem Ausdruck, genau damit die Rechtsassoziativität aus Fallstrick 3 keine Überraschung erzeugt.