Editor-Feinschliff und Abschluss des Release-Workflows

Aufbauend auf den jüngsten Refactors am Editor und der Bereinigung der Workflows konzentriert sich dieser Eintrag darauf, das Tool so zu formen, dass es in echter Story-Produktion standhält. Ich habe begonnen, kleine Beispielgeschichten für die ersten Teaser und Trailer zu erstellen, und dieser Prozess hat sofort aufgezeigt, welche Teile des Editors noch Reibungspunkte haben und welche Randfälle in der Praxis noch fehlschlagen.

Das Ergebnis ist eine robustere Szene-Bearbeitungserfahrung mit mehreren Komfortverbesserungen, einer Reihe von Fixes, die direkt aus der Produktion der Trailer-Geschichten entstanden sind, und zwei wichtigen Meilensteinen auf der Veröffentlichungsseite: Der grundlegende Release-Workflow ist jetzt abgeschlossen, inklusive Stornierung und Einsprüchen, und der erste Steam-Build wurde als Ausgangspunkt für die Distribution erstellt.

Version: App: v0.8.5 - API: v0.10.8-0b34cb9cfb

Ich habe begonnen, kleine Beispielgeschichten für die ersten Teaser und Trailer zu erstellen. Das Ziel ist nicht, fertige Inhalte zu präsentieren, sondern den Editor in einen echten Produktionskontext zu stellen und zu sehen, wie er sich verhält, wenn er so genutzt wird, wie Bards ihn tatsächlich nutzen werden.

Die Arbeit an diesen Geschichten hat sofort offengelegt, wo der Editor noch Reibung erzeugt, wo Workflows unintuitiv wirken und wo Randfälle auftauchen, die in isolierten Tests nicht sichtbar werden. Diese praktische Nutzung erwies sich als die effektivste Methode, um die jüngsten Refactors zu validieren und herauszufinden, was noch Arbeit benötigt.

Unten ist eine kurze Vorschau aus einer dieser Beispielgeschichten, direkt aus dem Editor aufgenommen.

Die Arbeit an echten Beispielgeschichten führte direkt zu einer Runde fokussierter Verbesserungen im Szeneneditor. Ziel war es nicht, neue Features hinzuzufügen, sondern Reibung zu reduzieren und bestehende Workflows vorhersehbar, schnell und sicher nutzbar zu machen.

Der Szeneneditor wurde optimiert und um mehrere Komfortfunktionen erweitert. Ein grundlegendes Verlaufssystem wurde ergänzt, das Änderungen an Szeneelementen rückgängig machen und wiederherstellen lässt. Szeneelemente werden jetzt außerdem als klare Hierarchieliste dargestellt, was das Auswählen, Organisieren und Nachvollziehen komplexer Szenen vereinfacht. Zusätzlich können Elemente sowohl im Editor als auch während des Spiels als verborgen markiert werden, was die Arbeit mit Enthüllungen, Bedingungen und geschichteten Szenen vereinfacht.

Während dieser Verbesserungen traten eine Reihe von Bugs auf, die nur während längerer Bearbeitungssitzungen oder bei komplexeren Story-Setups sichtbar werden. Diese Probleme wurden auf dem Weg behoben, was insgesamt zu einer spürbar stabileren Editor-Erfahrung geführt hat.

Mit einem stabileren Editor habe ich den grundlegenden Release-Workflow finalisiert. Dieser definiert den Weg, den eine Geschichte vom internen Entwurf bis zur eingereichten Veröffentlichung nimmt, und macht den Zustand einer Geschichte in jedem Schritt explizit.

Geschichten können jetzt zur Prüfung eingereicht, bei Änderungsbedarf storniert oder im Falle einer Ablehnung angefochten werden. Jede Aktion aktualisiert den Release-Status klar, sodass jederzeit sichtbar ist, wo eine Geschichte aktuell steht und welche nächsten Schritte möglich sind. Das reduziert viel Unsicherheit rund ums Veröffentlichen und verhindert, dass Geschichten in undefinierten Zuständen stecken bleiben.

Das ist zwar noch die Grundlage und nicht die letzte Instanz für Moderations- oder Veröffentlichungsregeln, aber es schließt die zentrale Schleife ab, die nötig ist, um Geschichten kontrolliert und transparent zu veröffentlichen.

Mit dem Release-Workflow an Ort und Stelle habe ich den ersten funktionierenden Build für Steam erstellt. Das ist noch keine öffentliche Veröffentlichung, aber es markiert einen wichtigen Schritt: Talescape existiert jetzt als eigenständige Anwendung in der Form, in der sie später auf Steam ausgeliefert wird.

In dieser Phase liegt der Fokus darauf, den Build-Prozess selbst zu validieren, sicherzustellen, dass Editor und Player außerhalb des Browsers zuverlässig laufen, und plattformspezifische Probleme frühzeitig zu identifizieren. Einen konkreten Steam-Build zu haben hilft außerdem, die verbleibende Arbeit klarer zu strukturieren, besonders in Bezug auf Distribution, Updates und Plattformintegration.