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, open the Menu at the top left of the game screen and choose Get updates. When the project has published a newer version than the one your game is on, the Menu button shows a dot and Get updates is marked New.
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. The world's GM Instructions,player options and tracker templates arrive together as one settings row, Game Options. 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.
Game Start files never sync in either direction — they only matter when a game is created. A game's tags and prelude are likewise game-local, and so are its pinned files: the world's Pinned Files only reach games started after you publish them.
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.
Changed in GM Harness 2
A game started before its world moved to GM Harness 2 shows a Move to V2 card. Pulling a version published on GM Harness 2 lists one more row, GM Harness, V1 → V2: the story so far is summarized for the GM, the world's GM Instructions come with it, and the game can't go back. Untick it to stay on the original GM for now; the move is offered again at the next pull. While the story is summarized, the game shows Getting your story ready and you can't send a turn. See the V1 → V2 migration guide.