Publishing & saves
When your adventure is ready, publish it free to the Adventure Store — and know that updating it later will never break a player who’s mid-run.
Publishing
Hit 🚀 Publish in the Studio. The server re-runs the full validator and an IP denylist, and you affirm three things: you own the content (or have permission), it’s SRD-clean (no protected third-party settings, characters, logos, copied text, or non-SRD monsters), and it’s free for everyone. On a clean pass, an immutable version is snapshotted and the adventure goes live in the store.
The publish surface is a full release center: a 🧪 dry publish runs every real gate (validation, denylist, compatibility, a content-loss check) and shows the verdict without publishing; the 📈 adoption panel shows how many runs sit on each of your versions; and 🕘 Recent activity is your story’s authorship ledger — who changed what, and whether it came from the Studio or an AI assistant via the API/MCP. If a publish would silently discard content players already have (say, art references), it’s blocked until you review the loss report and confirm on purpose.
Your listing
The Listing workspace is your store presence: a box cover and a wide hero image, a screenshot gallery, a maturity badge (Work in progress · Complete · Retired), and your creator profile (display name, bio, and socials shown on every adventure you publish). Pricing is captured but display-only for now — all content plays free.
The depth score
Each published adventure gets a transparent depth score (0–100) computed from word count, number of beats, branching, custom-vs-SRD content ratio, and art/audio. It tells players how much adventure they’re getting at a glance — and rewards real authoring over thin content.
How versioned saves work (and why they never break)
This is the standard live-service / SaaS save model, and it’s built in:
- Saves pin to a version. When a player starts your adventure, their run records the exact published version it began on.
- Published versions are immutable. A started run always resolves its story from the version it pinned to — so publishing a new version never rewrites someone’s in-progress save.
- New runs get the latest. Anyone starting fresh plays your newest version.
- Players are told. If a run is behind the latest, the player sees a non-blocking notice and can choose to play the latest in a new run — their old save is never silently overwritten.
When you publish an update, the Studio classifies it as compatible (purely additive — new nodes/variables) or breaking (a node or variable a running save could depend on was removed or moved) and tells you exactly which. Compatible updates let started games keep playing; breaking ones leave started games safely on their pinned version. The takeaway: edit fearlessly — you can’t corrupt a player’s game by improving your story.
In-run updates (optional, player’s choice)
When you publish a compatible release, players mid-run see a one-line offer at a calm moment: “a save-compatible update is available for this run.” Accepting moves that run to your new version with their progress intact; declining just keeps playing pinned — forever, if they like. Set expectations correctly: pinned runs never auto-upgrade; the update is optional; and an accepted update isn’t individually rolled back — a bad compatible release is corrected by publishing a newer version. Since a run only moves forward to something you classified compatible, that’s a publish away, never a support ticket.
Ready? Open the Studio →