Game and Project Sync

Every game is its own copy of a project, made from one specific release (see Starting Your First Game). That copy is what makes play safe — the GM can rewrite files mid-session without touching your project, and you can keep building without breaking anyone's campaign. But it also means the two drift apart: the project gains new content the game can't see, and edits made inside the game live only there. Sync is the bridge, and it runs in both directions.

Where sync lives

In a game, the sync button (the circular arrows) sits in the control rail at the top left. A red dot on it means the project has published a newer version than the one your game is on. What the dialog shows depends on who you are: players get the pull view; the project's owner also gets a second tab, so the dialog splits into Pull Updates and Push Updates.

Pulling project updates

The pull view shows the project's latest version — with its release notes — and every change it contains since the release your game last synced to: files, file types, folders, music, and settings, each as a checkbox. Additions and updates are pre-selected; deletions are opt-in, so a pull never quietly removes something from your game. Apply to game copies the selected changes into your game's files.

A pull overwrites the game's copy of whatever you select, so risky rows are flagged instead of silently applied. Anything that also changed inside the game since the last sync is marked as a conflict and left unchecked — select it only if you want the project's version to win. File type and folder deletions are blocked entirely during sync; if you want those gone from a game, remove them in the game by hand.

Your story is never part of a sync. Messages, rolls, and the campaign so far stay exactly as they were — sync only moves the workspace-shaped things listed above. If the game is already on the newest version, the dialog just tells you you're all caught up.

Pushing game changes back

Pushing is for the project owner, and it's what makes building while you play practical. Playtesting is where you actually notice the missing shopkeeper, the broken stat, the location that needs a better description — and the natural place to fix them is right there in the game's editor. Those edits improve only that one game until you push them.

The Push Updates tab shows everything your game changed relative to the project, with the same per-change checkboxes and the same conflict flags when the project moved on in the meantime. Give the release a title and notes, then choose with the Set as latest version toggle:

• On — the push publishes: players see this version when viewing the project, and new games start from it.

• Off — the version is saved as a draft in the project's release history without changing what players get. Promote it later from Version History when it's ready.

Either way the result is an ordinary project release — it appears in Version History and behaves exactly like one created from the workspace (see Publishing and Releases).

Together the two directions make a loop: play, fix what play exposed, push a release, and let your other long-running games pull it in when they're ready.