Skip to content

Draft and versions

This page is about how what you edit becomes a release that a party loads. It goes through the autosave, what a release needs, the packing, the release list and loading into the editor, the Builder’s most dangerous action.

Once a release is finished, making it public is a separate step with conditions of its own: Making it public.

Draft and version

In the Builder you always work on one draft. The draft is the live working copy: every set, item, size, rule text and details field goes into it. There is exactly one draft per game, and it never disappears, not even when you release a version in the meantime.

A release (Release in the interface, v1.3 on the rows) is a snapshot of the draft: at the moment of the release it copies the sets and the items, and nothing ever overwrites that copy. That is how a party can load exactly the content it got when it started, months later.

Two roads lead to the players, and they are not the same:

What you editHow it gets there
Details (title, description, cover, categories)on its own, on save
Ruleswith the Publish button, see Rules
Sets, items, images (the “components”)only in a release

The page’s most important sentence follows from that: not a single player sees the work you do on the components until you release it.

The draft saves itself

There is no save button. What you do on the set, item, details and rule pages goes out to the server by itself: the Builder gathers the changes up and sends them off after a short quiet spell. The save lands on the server, not in the browser: sign in on another machine and you find the same draft.

You see its state in the top bar, beside the breadcrumb:

What you see thereWhat it means
All changes savedthere is nothing pending
Saving…it is on its way to the server
Couldn’t save. Retrying.a save got stuck, the Builder is trying again
Couldn’t save. + Retryit did not get through; send it with the Retry button
Someone else changed this in the meantime… + Reloada conflict, see below

On a conflict your change was not saved. If somebody else has been working on the same game, the bar spells it out, and Reload brings their version in. On the rules page the Copy my text button sits in front of it, see Rules.

You can leave the page without worrying. If there is still an unsent change, the Builder saves it first and only then lets you on; a question only comes if the save failed, or a field on the details page is invalid.

One exception to the autosave: the images are not part of the draft. An uploaded image goes to the game at once, independently of any release.

What is still waiting for the players

At the right edge of the top bar, inside a game, sits the Changes button. Press it and a panel opens that gathers into one place what is waiting to reach the players:

  • Rules: how many unpublished changes there are, and the Publish button;
  • Components: whether they have changed since the last release, or whether there is no release yet, and the New release… button;
  • if nothing is pending: “Nothing is waiting. Players see your latest work.”

The button itself signals when there is something to take out.

Where you find the releases

The Releases page is in the sidebar’s Components group, under Images. It has three parts:

  • the title and the New release button at the top;
  • the list of releases on the left, the newest at the top;
  • the What a release does note and the Review card on the right, see Making it public.

On a brand new game, the words No release yet stand where the list would be.

When you can release

The New release button can always be pressed; the modal says what the situation is.

An item’s size is missing

If even a single item has no width and height, a red box stands at the top of the modal and the Start release button is greyed out. The box lists the trouble per set: how many items have no size, in which set, and clicking the row takes you there too.

An item counts as having no size if neither it nor the set’s default has a width and a height greater than zero. So filling in the set’s default is enough, you do not have to do every item one by one. See Items.

A required image is missing

It appears in the same red box, per set in the same way: how many items are missing the image on a required side. On a card, a board and a token the front is required, on a die the first face, see Items.

The same thing shows on the gallery’s tile: “No front image · Drop one here.”

Nothing has changed since the last release

If the draft’s components match the last release’s exactly, the modal says: “Nothing has changed since v1.3.”, and the button is greyed out.

That is not a fault: the system does not allow two releases with identical content in a row. If you do need a new release anyway (because the previous one’s package is missing or broken, say), switch on Repack anyway and the button becomes active at once.

Not everything is saved

If the save has just failed or there is a conflict, a red box stands in the modal: “The components are not saved yet. Everything has to be saved before a release.” Sort the save out and try again.

What is not an obstacle: the rules. The rules are not part of a release, and the modal spells that out separately.

The release’s name

The New release modal has a free text field labelled Release name, optional.

It affects nothing: it does not set the version number, and there are no rules about its shape. It does one single thing, it appears behind the version number on the release’s row. It cannot be changed afterwards: a release is finalised together with its name.

So it is worth writing something into it that will still say months later why you released it: Expo demo, Fixed dice faces, Winter harbour.

Repack anyway

The Repack anyway switch at the bottom of the New release modal turns off two things at once:

  1. The “nothing has changed” block. Switched on, you can release even if the draft is identical to the last release.
  2. Reusing the package. Without it, the system checks whether the images or the sizes have changed; if not, it takes over the previous release’s package unchanged. Switched on, it always repacks.

The explanation stands under the switch: “Pack the sprite sheets again even when the images have not changed.”

When you need it:

  • when the previous release’s images are wrong or incomplete in a party;
  • when you have to release something with unchanged content under a different name;
  • when you have to release the same content as a fresh release after loading an old release.

When not to: after ordinary editing. The packing can take minutes.

What happens on a release

After Start release, the progress appears where the modal was, with four steps:

  1. Check items and sizes
  2. Pack images into sprite sheets
  3. Build the release file
  4. Make it available to players

Under it the estimated time left, and the most important sentence: “You can close this and carry on working.”

The packing runs on the server, not in your browser. Close the modal or navigate away and the release carries on, and a bar at the top of the Releases page shows the progress, with a Show progress button. When it is finished you get a notice: “Release v2.0 is available to players.”

If a minor release is being made, the packing is skipped and the whole thing runs in a moment.

If the release fails, the interface says so (“The release failed.”), and the version list is left unchanged: a half-finished release does not get into the list.

Which version number you get

The version number has the shape major.minor, and it decides itself. You cannot give it, and the modal tells you in advance which it will be:

What changed in the draftWhat the modal saysPackage
an image or a size on any itemMajor, v2.0, “Images or sizes changed, so the sprite sheets are packed again. This takes a few minutes.”repacked
anything else: quantity, order, subset, container, titleMinor, v1.4, “Nothing to repack, so this is instant.”the previous one’s, unchanged
Repack anyway switched onalways majoralways repacked

A major release always lands on x.0, a minor one steps to the next tenth. The first release is always 1.0, and the modal says that too: “This is the first release of your components.”

The package

The package (the sprite sheets) is the handful of large image sheets onto which the system packs every item image, so that a party loads them all at once. That is why a major release takes minutes, and why a minor one is instant.

When it is done, the interface says how many images went onto how many sprite sheets.

The note in the Releases page’s side column says the same: “A release packs your images into sprite sheets so players’ phones load them fast. Rules never wait for a release.”

The release list

The releases line up with the newest at the top. What a row holds:

PartWhat it shows
Version numberv2.0, say, with the release name under it, if you gave one
Datewhen you released it
Major / Minorwhat kind of step it was
Public / Playtest / Not publicwho can reach it, see Making it public
Deprecatedif you have deprecated it
The review’s tagonly on the newest live row, see Making it public
Visibility and ”…“the two menus, see below

What actions a row has

In the Visibility menu:

  • Public: only live after an approved review, and one version at a time can be it;
  • Not public: takes it off public.

At the bottom of the menu the explanation is always there: “A public version needs an approved review.”, or after approval “One version at a time can be public.”

In the ”…” menu:

  • Request review, see Making it public;
  • Load into editor, see below;
  • Deprecate, see below. Greyed out on a public version, and the help text says why: “Make it not public first.”

On a deprecated version the Visibility menu disappears. Request review and Load into editor stay, but it can never be made public again.

Load into editor

This is the Builder’s most dangerous menu item. Read this before you press it.

Load into editor copies the chosen release’s components into the draft, in place of the current draft’s components. The confirming question spells it out: “This overwrites your current components draft with v1.0. Game details and rules stay as they are.”

What it overwrites: every set and every one of their items, so the frames, the sizes, the quantities, the subsets, the order and the magnetic dots.

What it does not overwrite: the game’s details page, the rules, and the uploaded images. The images stay where they are, only nothing refers to them any more.

The action cannot be undone. The system does not keep what was in the draft beforehand. Every piece of component editing you did not put out as a release ceases to exist in that second.

There is one safety catch, and you have to do it yourself: before you load an old release, put the current draft out as a release, with Repack anyway if need be. Then the current state survives as a release, and can be brought back in exactly the same way at any time.

Nothing happens to the releases: loading only writes the draft. Afterwards the draft’s content matches the source release’s, so the Nothing has changed since v… message shows up at once.

Deprecating

Deprecate puts a release into the Deprecated state. It does not delete it: its content survives and it stays in the list, but no new party starts on it.

The confirming question reads: “Players cannot start a new game on this version. Running parties keep working.”

A public version cannot be deprecated: take it off public first. The Making it public page covers running parties and what all of this means from the player’s side.

Who sees the release list

Not everybody sees the same list:

  • You, the game’s owner: everything, the deprecated releases too.
  • Whoever reaches it through a group or an organisation: what the group’s ceiling allows; never the draft.
  • Anybody else: the public release only, if there is one. If there is not, nothing.

That does not show in the Builder’s interface: your list is always the whole list.