Verzweigte Geschichten ohne Spaghetti

Jede interaktive Geschichte fängt gleich an: mit einer sauberen Gabelung auf Seite drei. Spätestens in Kapitel vier sieht das Flussdiagramm aus wie ein Teller Pasta: Die Hälfte der Panels sind Kopien anderer Panels mit einer geänderten Zeile, und niemand traut sich mehr an den Graphen. In diesem Artikel geht es darum, gar nicht erst dorthin zu kommen. Er setzt die Editor-Grundlagen aus Erste Schritte mit dem PanelWave CMS voraus und springt direkt zu den Designfragen, an denen sich entscheidet, ob ein verzweigtes Werk bearbeitbar bleibt.

Die Kurzfassung: PanelWave gibt dir drei getrennte Werkzeuge, und Spaghetti entsteht, wenn du nur eines davon benutzt. Der Fluss steckt im Kapitelgraphen, der Zustand in Variablen. Der Inhalt reagiert über Panel-Varianten und Sichtbarkeitsbedingungen auf den Zustand. Halte den Graphen klein, lass Variablen die Konsequenzen tragen und die Panels sie widerspiegeln.

Muster 1: Für jeden Unterschied das richtige Werkzeug

Bevor du eine Gabelung zeichnest, frag dich, was sich zwischen den beiden Pfaden eigentlich unterscheidet. Es gibt drei Antworten, und jede gehört zu einem anderen Mechanismus im Format:

Die Doku fasst die Abwägung in einer Tabelle unter Variants vs. other conditional mechanisms zusammen. Die meisten Spaghetti-Graphen sind Varianten und Sichtbarkeitsbedingungen, die als Gabelungen gezeichnet wurden.

• Die Lesenden sehen andere Panels. Dann unterscheidet sich der Fluss. Nimm bedingte Verbindungen im Graph Editor; die Graph-Referenz beschreibt jede Eigenschaft.
• Die Lesenden sehen dasselbe Panel mit anderem Inhalt. Ein anderer Hintergrund, ein zusätzliches Overlay, eine geänderte Dialogzeile. Dafür gibt es die Panel-Variante: derselbe Knoten im Graphen, alternativer Inhalt, den eine Bedingung auswählt. Der Erzählfluss bleibt fest.
• Nur ein Element ändert sich. Etwa ein Hotspot, der erst erscheint, wenn die Lesenden den Schlüssel haben, oder eine Sprechblase, die erst nach einer Entscheidung auftaucht. Hier reicht eine Sichtbarkeitsbedingung an genau diesem Element, gesetzt mit dem Condition Builder; der Rest des Panels bleibt unberührt.

Muster 2: Den Zustand deklarieren, bevor du verzweigst

Variablen sind das Gedächtnis der Geschichte. Sie haben einen festen Typ und werden vorab deklariert. Gib ihnen IDs mit Namensraum und Punkt, die zeigen, wohin sie gehören: story.choice, stats.trust, inventory.hasKey, prefs.hints. Hat eine Entscheidung eine feste Zahl möglicher Ausgänge, nimm ein Enum. Dann fällt ein Tippfehler in einer Bedingung sofort auf, statt dass die Bedingung still nie greift.

Der Gültigkeitsbereich ist die Entscheidung, die viele überspringen. Er bestimmt, wann ein Wert zurückgesetzt wird: page, chapter, global, session oder persistent. Die Faustregel aus dem Variablen-Leitfaden: Entscheidungen, an die sich das ganze Werk erinnern soll, gehören in global oder persistent, kurzlebiger Rätselzustand in chapter oder page und Flags nur für diesen Besuch, etwa ein weggeklickter Hinweis, in session. Persistente Variablen bleiben über Besuche hinweg erhalten – erst das macht freischaltbare Inhalte und Abschluss-Flags möglich (Fortschritt im Player speichern).

Im CMS passiert das im Variables Designer: Öffne den Backstage-Bereich eines Werks, wähl Variables und deklariere jede Variable einmal mit ID, Typ, Gültigkeitsbereich und Standardwert. Der Dialog prüft IDs, Enum-Listen und Standardwerte, bevor etwas gespeichert wird. Dieselbe Liste fließt ins Manifest, in die Überschreibungen der Preview-Seite und in den Player. Pflegst du ein Manifest von Hand, liefert dir Export JSON die Definitionen als Fragment zum Einfügen; importierst du ein Manifest, bleibt sein Variablenabschnitt erhalten. Der Variablen-Leitfaden führt durch den Designer; das Variablen-Schema hat das genaue Format.

Muster 3: Jede Entscheidung als Dreiklang bauen

Eine Entscheidung in PanelWave ist nie ein einzelnes Objekt. Sie besteht aus drei Dingen, die auf eine Variable verweisen: einem Hotspot, der sie setzt, einer Verbindung pro Ausgang, die sie prüft, und einer bedingungslosen Verbindung als Fallback. Bau jedes Mal alle drei, dann bleiben die Lesenden nie stecken.

Zeichne auf dem Entscheidungspanel einen Hotspot pro Option und gib jedem eine Set-Variables-Aktion: story.choice auf left, story.choice auf right. Im Graph Editor ziehst du dann die Verbindungen: Quellpanel auswählen, C drücken, Ziel wählen, Enter. Danach wählst du jede Verbindung aus und tippst ihre Bedingung ein. Bedingungen sind in JSON Logic geschrieben: ein Operator, ein Variablenverweis, ein Wert. Der Abschnitt Edge conditions hat Beispiele zum Kopieren und Anpassen für Gleichheit, Größer-als und kombinierte Regeln.

Die dritte Verbindung ist das Sicherheitsnetz: Blättern die Lesenden weiter, ohne eine der Türen anzuklicken, nimmt der Player die bedingungslose Verbindung. Passen mehrere Verbindungen, legt das Feld priority die Reihenfolge fest (siehe Branching). Der Player wertet all das bei jedem Schritt aus; wie der Algorithmus genau arbeitet, erklärt How the player walks the graph.

Ein Benennungsdetail, über das viele stolpern: An einer Verbindung stehen Variablenänderungen in der Aktionsliste, an einem Hotspot dagegen in mutations. Die Graph-Referenz weist ausdrücklich darauf hin. Im CMS fasst du beides selten direkt an, aber beim Lesen eines exportierten Manifests ist es wichtig.

Muster 4: Verzweigen, dann bündeln

Die klassische Form einer wartbaren verzweigten Geschichte ist die Raute: gabeln, pro Pfad zwei oder drei Panels laufen lassen und auf einem gemeinsamen Panel zusammenführen. Jede Gabelung, die nicht zusammenläuft, verdoppelt die Menge an Artwork, die du zeichnen musst, und die Zahl der Pfade, die du testen musst. Führ früh und oft zusammen.

Doch das Zusammenführen wirkt wie Gedächtnisverlust, wenn die Geschichte vergisst, was passiert ist. Hier kommt der Zustand wieder ins Spiel. Die Entscheidung steckt bereits in story.choice. Die gemeinsamen Panels nach dem Engpass greifen sie mit einer Panel-Variante auf: Deren when-Bedingung prüft die Variable, deren overrides tauschen Ebenen oder Dialog aus. Ein Panelknoten, zwei Versionen des Moments, keine doppelten Panels im Graphen. Die Doku nennt das Choice Reflection und zeigt ein vollständiges Beispiel unter The choice pattern.

Zwei Regeln für Varianten, die dir später Fehlersuche ersparen. Erstens: Varianten werden in Array-Reihenfolge ausgewertet, und der erste Treffer gewinnt. Können sich Bedingungen überschneiden, ordne sie also von der spezifischsten zur allgemeinsten (Selection order). Zweitens: Ein überschreibendes layers-Array ersetzt den ganzen Stapel – wiederhole also die Basisebenen, die du behalten willst. Im Strukturbaum des Editors tragen Panels mit Varianten ein V-Badge, und über die Filterleiste lassen sich nur diese Panels anzeigen (Pages and Panels).

Muster 5: Hubs, Schleifen und Zähler

Zyklen sind in einem PanelWave-Graphen erlaubt, und mit ihnen baust du Hubs: einen Raum, zu dem die Lesenden zwischen Erkundungen zurückkehren, eine Kartenansicht, ein Gesprächsmenü. Die Graph-Validierung meldet Zyklen zwar als Warnung, aber nur als Hinweis: Eine gewollte Schleife ist in Ordnung (Validation).

Was einen Hub davor bewahrt, zur Endlosschleife zu werden, ist ein Zähler. Gib jeder Nebenquest einen Hotspot, der stats.visits erhöht oder einen Boolean wie story.metCourier umschaltet, und knüpf die Ausgangsverbindung des Hubs an eine Bedingung wie stats.visits größer oder gleich drei. Die Mutationsoperationen sind set, increment, toggle, append und remove (Mutation). Die Lesenden erkunden in beliebiger Reihenfolge, der Ausgang öffnet sich, wenn sie fertig sind, und der Graph bleibt ein übersichtlicher Stern, statt jede mögliche Reihenfolge einzeln abzubilden.

Muster 6: Elemente steuern statt Panels duplizieren

Hängt auf einem Panel nur ein Element vom Zustand ab, setz die Bedingung genau an dieses Element. Hotspots und Sprechblasen haben im Inspektor einen Bereich Visibility Condition; klick auf Build Condition, und der Condition Builder schreibt den Ausdruck für dich: Variable, Typ, Operator, Wert, kombiniert mit AND oder OR. Der Klassiker ist eine verschlossene Tür: Hotspot A setzt an anderer Stelle der Geschichte inventory.hasKey auf true, und Hotspot B an der Tür wird erst klickbar, wenn inventory.hasKey true ist (Conditions on hotspots).

Hotspot-Mutationen gehen noch einen Schritt weiter: Ein Trigger When Variable Changes animiert Deckkraft, Skalierung, Position oder Farbe genau in dem Moment, in dem sich der Zustand ändert. So reagiert das Artwork auf eine Entscheidung, ganz ohne Panelwechsel. Im veröffentlichten Werk sehen die Lesenden Hotspots als Bereiche mit sanft pulsierendem Umriss, die sich vollständig per Tastatur bedienen lassen (die Ansicht der Lesenden); von deiner Bedingungslogik sehen sie nichts.

Muster 7: Die Karte lesbar halten

Was du nicht lesen kannst, machst du irgendwann kaputt. Mit ein paar Gewohnheiten bleibt der Graph lesbar, auch wenn das Werk wächst:

• Ein Kapitel, ein Graph. Jedes Kapitel hat seinen eigenen Graphen und sein eigenes Einstiegspanel. Behandle Kapitel als Einheit der Verzweigung: Ein Kapitel sollte eine vollständige Gabelung samt Zusammenführung enthalten, nicht die Hälfte davon.
• Benenne deine Panels. Vergib in den Basic Properties des Inspektors eine Friendly ID wie courier-door-left (Pages and Panels). Der Graph Editor beschriftet Knoten mit Paneltiteln, und für Kapitelübersichten kann das Manifest Knotenbeschriftungen für die Lesenden mitliefern.
• Überlass das Layout der Maschine. Auto-Layout (L) ordnet den Graphen von links nach rechts nach Erzähltiefe an und minimiert Überschneidungen; die Positionen werden pro Kapitel gespeichert. Der Schalter List zeigt denselben Graphen als verschachtelte, screenreader-freundliche Gliederung mit Badges für Einstieg und Ende (Moving around).
• Versteck, was versteckt bleiben soll. Wenn das Kapitel die unendliche Leinwand nutzt, setz geheime Zweige in den Reveal-Modi auf Hidden until visited, damit sie beim Herauszoomen nicht verraten werden. Dieselbe Einstellung empfiehlt sich für Panels hinter der Paywall.

Muster 8: Jeden Pfad testen, dann die echten messen

Verzweigungsfehler verstecken sich in dem Pfad, den du nicht angeklickt hast. PanelWave prüft auf drei Ebenen, und jede beantwortet eine andere Frage.

Sobald das Werk live ist, zeigt dir Analytics, welche Zweige die Lesenden tatsächlich nehmen. Der Lesetrichter zeigt Sitzungen pro Panel in Lesereihenfolge. Bricht die Kurve direkt nach einer Gabelung steil ein, war die Entscheidung meist unklar. Die Klick-Heatmap zeigt, wohin die Lesenden tippen – ob auf einen Hotspot oder daneben. Häufen sich Klicks außerhalb aller Hotspots, haben die Lesenden eine Wahl erwartet, die du nicht angeboten hast. Beides ist billiger als Raten.

• Struktur: Der Simulate-Modus des Graph Editors geht den Graphen vom Einstieg aus durch, listet unter Where to next jede ausgehende Verbindung mit ihrer Bedingung auf und meldet Sackgassen. Er prüft nur die Struktur und wertet keine Bedingungen aus (Simulating the flow). Mit V startest du die Validierung neu. Sie markiert unerreichbare und isolierte Knoten sowie fehlende Einstiegspanels und behebt die häufigen Fälle mit einem Klick.
• Logik: Preview zeigt jede Variable mit einem passenden Eingabefeld. Setz story.choice nacheinander auf jeden Wert und lies das Kapitel jeweils neu; speichere die Kombination als Szenario für die nächste Runde (Variable overrides). Laut Doku ist der häufigste Verzweigungsfehler eine Bedingung, die nie wahr werden kann, weil nichts die Variable setzt. Teste beide Seiten jeder Verzweigung.
• Release: Vor dem Veröffentlichen untersucht die Preflight-Prüfung das ganze Werk, auch auf Flussprobleme wie Panels, die vom Kapiteleinstieg aus unerreichbar sind, oder kaputte Verweise in Verbindungen (Validation and Preflight). Fehler blockieren das Veröffentlichen.

Ein durchgespieltes Beispiel: der Kurier

Hier ein vollständiges Kapitel nach diesen Mustern: sieben Panels, eine Gabelung, ein Hub, kein doppeltes Artwork.

Drei Verbindungen aus Panel 3 inklusive Fallback, drei Schleifen durch den Hub, ein Ausgang. Der Graph passt auf einen Bildschirm, Simulate geht ihn in unter einer Minute durch, und alles, was die Entscheidungen der Lesenden bewirken, steckt in drei Variablen, die du in der Vorschau prüfen kannst.

• Variablen: story.choice (Enum: left, right, none; Bereich chapter), stats.visits (Integer, Bereich chapter), inventory.hasKey (Boolean, Bereich global).
• Panels 1 bis 3: linear. Panel 3 ist die Entscheidung: zwei Tür-Hotspots, jeder mit einer Set-Variables-Aktion auf story.choice und einer Navigate-Aktion zu Panel 4.
• Panel 4: ein Panel, zwei Varianten. Die linke Variante fügt ein Overlay und die Zeile „Du hast die linke Treppe genommen“ hinzu; die rechte Variante tauscht den Hintergrund. Das Basispanel ist der Fallback für Lesende, die weitergeblättert haben, ohne zu wählen.
• Panel 5: der Hub, ein Innenhof mit drei Hotspots. Jeder führt zu einem Nebenpanel (6a, 6b, 6c), dessen Rückverbindung stats.visits erhöht; das Panel mit dem Schlüssel setzt außerdem inventory.hasKey auf true. Der Ausgangs-Hotspot des Hubs hat die Sichtbarkeitsbedingung stats.visits größer oder gleich zwei.
• Panel 7: das Ende. Die Verbindung vom Hub dorthin ist bedingungslos, und eine Variante prüft inventory.hasKey, um die aufgeschlossene Version zu zeigen.

Weiterlesen

• Graph Navigation: warum ein Graph statt einer Seitenreihenfolge und wie der Player ihn durchläuft.
• Variables: das Zustandsmodell hinter jeder Bedingung.
• State and conditions in the player: wie die Laufzeit JSON Logic auswertet und Zustand speichert.
• Hotspots im Format: die Aktionen goTo, setVariables, openExtras, openModal und pluginEvent.
• Monetization: wo eine Paywall-Grenze in ein verzweigtes Kapitel gehört und wie du die Vorschau mit Gratis- oder Premium-Zugang testest.