Editor Refinements and Release Workflow Completion

Building on the recent editor refactors and workflow cleanup, this entry focuses on turning the tool into something that holds up under real story production. I started creating small example stories for the first teasers and trailers, and that process immediately highlighted which parts of the editor still had friction, and which edge cases still broke in practice.

The result is a more robust scene editing experience with several quality-of-life improvements, a batch of fixes that came straight out of trailer story production, and two major milestones on the publishing side: the basic release workflow is now complete, including cancellation and appeals, and the first Steam build has been created as the starting point for distribution.

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

I started creating small example stories to use in the first teasers and trailers. The goal here is not to showcase finished content, but to put the editor into a real production context and see how it behaves when used the way Bards will actually use it.

Working on these stories immediately exposed where the editor still had friction, where workflows felt unintuitive, and where edge cases appeared that do not show up in isolated testing. This kind of hands-on use turned out to be the most effective way to validate recent refactors and identify what still needed work.

Below is a short preview from one of these example stories, recorded directly from the editor.

Working on real example stories led directly to a round of focused improvements in the scene editor. The goal here was not to add new features, but to reduce friction and make existing workflows feel predictable, fast, and safe to use.

The scene editor was optimized and extended with several quality-of-life features. A basic history system was added, allowing scene element changes to be undone and redone. Scene elements are now also represented as a clear hierarchy list, making it easier to select, organize, and reason about complex scenes. In addition, elements can be marked as hidden, both in the editor and during gameplay, which simplifies working with reveals, conditions, and layered scenes.

While making these improvements, a number of bugs surfaced that only appear during longer editing sessions or more complex story setups. These issues were addressed along the way, resulting in a noticeably more stable editing experience overall.

With the editor in a more stable place, I finalized the basic release workflow. This defines the path a story takes from an internal draft to a submitted release, and makes the state of a story explicit at every step.

Stories can now be submitted for review, canceled if something needs to be changed, or appealed if a release is rejected. Each action updates the release state clearly, so it is always visible where a story currently stands and what the next possible steps are. This removes a lot of ambiguity around publishing and prevents stories from getting stuck in undefined states.

While this is still the foundation and not the final word on moderation or publishing rules, it completes the core loop required for releasing stories in a controlled and transparent way.

With the release workflow in place, I created the first working build for Steam. This is not a public release yet, but it marks an important step: Talescape now exists as a standalone application in the form it will eventually ship on Steam.

At this stage, the focus is on validating the build process itself, making sure the editor and player run reliably outside the browser, and identifying any platform-specific issues early. Having a concrete Steam build also helps frame the remaining work more clearly, especially around distribution, updates, and platform integration.