Eine Entscheidung zählt, wenn die Geschichte sie sich merkt. In diesem Einsteigerprojekt entscheiden zwei erwachsene Kollegen, wie sie ein Studio eröffnen wollen. Dafür nutzt es einen kleinen Passagengraphen, eine gespeicherte Entscheidung und zwei Enden. Es braucht nur wenige Grafiken. Deine erste Aufgabe ist, jede Entscheidung zum vorgesehenen Ergebnis führen zu lassen und dann dafür zu sorgen, dass dieses Ergebnis auch nach dem Speichern und erneuten Laden erhalten bleibt.
Der Download enthält Twee-Quellcode für SugarCube. Kompiliere ihn mit Tweego und einem installierten SugarCube-Storyformat zu spielbarem HTML oder erstelle die Passagen der Geschichte manuell in Twine nach. Das Beispiel wurde hier nicht in einer Twine-Laufzeitumgebung ausgeführt. Führe daher vor der Veröffentlichung die unten beschriebenen Tests durch.
Wähle zuerst das Format
Erstelle in Twine eine Geschichte, wähle SugarCube 2 als Storyformat und notiere die verwendete Version. Halte die offizielle Dokumentation zu Makros, Variablen und Spielständen griffbereit. Harlowe-Beispiele verwenden eine andere Syntax; sie direkt nach SugarCube zu kopieren, macht aus einer einfachen Szene schnell eine Fehlersuche.
Im heruntergeladenen Quellcode leiten Zeilen, die mit :: beginnen, Passagen ein. StoryTitle und StoryData enthalten Angaben zur Einrichtung. Lege im Twine-Editor den Titel der Geschichte und das SugarCube-Format fest und erstelle dann StoryInit sowie die sechs Storypassagen mit ihren exakten Namen. Kopiere jeweils den Inhalt ohne die ::-Kopfzeile und wähle Start als Startpassage. Eine .twee-Datei ist bearbeitbarer Quellcode; veröffentliche HTML für die Spieler.
Baue den Passagengraphen auf
Das Beispiel initialisiert $sharedPlan mit false. Start bietet zwei Antworten: SharedPlan setzt den Wert auf true, SeparatePlan auf false. Beide führen zu Discussion. Dort wird der Wert geprüft und der Link zu SharedEnding oder IndependentEnding angezeigt. Das ist der gesamte Graph: eine Entscheidung mit einer sichtbaren Konsequenz.
Gib den Passagen beständige, unverwechselbare Namen und prüfe jedes Ziel sowohl im visuellen Graphen als auch im veröffentlichten Build. Ein reizvoller Linktext kann einen Tippfehler im Zielnamen nicht retten. Trenne den internen Passagennamen vom Text, den du möglicherweise umschreibst oder übersetzt, damit eine neue Formulierung den Pfad nicht unterbricht.
Halte Zustandsänderungen vorhersehbar
Verwende eine benannte Variable für eine bestimmte Entscheidung. Hier hält $sharedPlan fest, ob der Spieler einen gemeinsamen Plan gewählt hat; sie muss nicht für jedes Gefühl zwischen den Figuren stehen. Setze sie dort, wo die Entscheidung fällt, und lies sie dort aus, wo die Konsequenz erscheint. Wenn dieser Zusammenhang klar bleibt, lässt sich eine kleine Geschichte leichter erweitern.
Prüfe, was passiert, wenn ein Spieler eine Passage erneut besucht. Wenn ihre Anzeige einen Punkt hinzufügt, kann ein weiterer Besuch unbeabsichtigt noch einen Punkt vergeben. Gib einmaligen Ereignissen in größeren Projekten eigene Regeln und entscheide, ob das Zurückgehen im Verlauf der Geschichte ihre Auswirkungen rückgängig machen soll. Teste auch das erneute Laden, statt anzunehmen, dass es sich wie ein erster Besuch verhält.
Gestalte eine gut lesbare Seite
Beginne mit der Standardoberfläche des Storyformats. Gib dem Text eine angenehme Lesebreite, verwende eine gut lesbare Schrift und mache den Tastaturfokus auf Links deutlich sichtbar. Prüfe Absätze und Auswahlmöglichkeiten auf einem schmalen Bildschirm. Eine dekorative Überlagerung hilft wenig, wenn der Spieler die nächste Zeile nicht findet; füge aufwendige Hintergründe erst hinzu, wenn der Lesefluss funktioniert.
Sorge dafür, dass Einstellungen sowie Bedienelemente für Neustart und Speichern leicht zu finden sind. Kennzeichne verfügbare Links oder wichtige Zustände mit mehr als nur Farbe, damit die Seite verständlich bleibt, wenn ein Farbhinweis übersehen wird. Wenn du Ton oder Bewegung hinzufügst, biete Bedienelemente an und beginne zurückhaltend. Lass die Spieler entscheiden, wann Musik oder Animation die Szene ergänzen.
Veröffentliche und teste die dauerhafte Speicherung
Veröffentliche über Twine oder kompiliere den Quellcode mit dem gewählten SugarCube-Format zu HTML und stelle die Datei anschließend über den vorgesehenen Hostinganbieter bereit. Teste sie im Browser und unter dem Origin der Website, den die Spieler nutzen werden. Browserspeicher ist an seinen Kontext gebunden. Ein erfolgreiches lokales Speichern klärt daher noch nicht, wie sich die gehostete Version verhält.
Speichere vor der Entscheidung und noch einmal danach. Schließe die Seite, öffne sie erneut und lade jeden Spielstand. Prüfe dabei, ob die gespeicherte Entscheidung und das verfügbare Ende stimmen. Wiederhole den Test in einem neuen Browserprofil und erstelle dort neue Spielstände. Prüfe privates Surfen, gelöschten Speicher und die Einbettung in andere Seiten jeweils separat. Beschreibe die gefundenen Einschränkungen; Browsereinstellungen und das Verhalten des Hostings können verhindern, dass Spielstände dauerhaft erhalten bleiben.
Bereite einen Weg für Updates vor
Verwalte den bearbeitbaren Quellcode mit einer Versionsverwaltung und archiviere jede veröffentlichte HTML-Version. Halte die SugarCube-Version, Änderungen an Passagen und repräsentative Spielstanddateien fest, damit du ein Update mit dem vorherigen Build vergleichen kannst. Entscheide, ob Updates vorhandene Spielstände unterstützen werden. Falls die Spieler neu beginnen müssen, erkläre diese Anforderung, bevor sie die neue Version laden.
Spiele jedes Ende von einem Neustart aus durch und prüfe jeden Link mit der Tastatur und, wo relevant, mit Touch-Bedienung. Verwende die Testmatrix für Pfade, um erwartete und tatsächliche Ergebnisse festzuhalten. Du kannst weitermachen, wenn die Geschichte verständlich zu lesen ist, ihr Zustand sich vorhersehbar verhält und du den Veröffentlichungsprozess wiederholen kannst. Lies den Leitfaden zu Pfaden und Zuständen, bevor du ein großes Netz von Verzweigungen aufbaust.
Wichtige Entscheidungen
- Wähle SugarCube 2, bevor du SugarCube-Makros schreibst.
- Bewahre den Twee-Quellcode auf; veröffentliche spielbares HTML.
- Teste wiederholte Besuche, Spielstände und erneutes Laden beim vorgesehenen Hostinganbieter.
- Halte Passagennamen beständig und archiviere veröffentlichte Versionen.
Dateien zum Leitfaden
Twee-Beispiel für SugarCube ↓Testmatrix für Pfade ↓Externe Modell-Communitys und Veröffentlichungsseiten können explizite Inhalte enthalten. Links zu den Quellen öffnen sich in einem neuen Tab; dieser Leitfaden lädt deren Vorschauen nicht.
Quellen und weiterführende Lektüre +
- Twine ↗
- Twine Cookbook ↗
- Offizieller SugarCube-Quellcode und offizielle Dokumentation ↗
- Tweego-Compiler ↗
Zuletzt geprüft 5. Oktober 2026.