Studio overview

The studio is where your organisation turns a game from the catalogue into its own version: your content, your rules, your brand, published at your own address.

Owners, admins and editors can use the studio. Multi-factor authentication is required for these roles.

The life of a fork

1. Fork a game from the catalogue, in the language of your choice. You get a private copy of its configuration, pinned to the current version of the game. See Fork a game.
2. Edit the draft in its source language: texts, rules, colours, logo and images. Every save is checked. See Edit your draft.
3. Translate the fork into other languages with a translation file. See Translate a fork.
4. Test the draft in preview mode, in each language, before anyone else sees it. See Test your fork.
5. Create a release: a numbered, frozen snapshot of the draft and its translations. See Releases.
6. Deploy a release to publish it at /{your-organisation}/{fork}. Deploying an older release rolls back. See Deploy and roll back.
7. Choose who can play: the public, your whole organisation, or specific groups and members. See Who can play.
8. Update to a new version of the game when you are ready. See Update to a new game version.

The forks list

Each fork shows its address, the release deployed ("Deployed · release 2"), a release created but not yet deployed, who can play (Public, Organisation or Restricted) and whether a new version of the game is available. If you can read reports, it also shows the games played and the completion rate over the last 30 days, however few people played it. The anonymity threshold only applies when a report is filtered by group (see player privacy).

Words we use

Every sensitive action (creating, releasing, deploying, rolling back, changing access, archiving, uploading an image) is recorded in your organisation's audit log.