Publishing a game

Publishing is an artifact workflow. The bundle you verify locally should be the same bundle that reaches review and, eventually, the public catalog.

Prepare the bundle

Run the complete project contract before upload:

npm run typecheck
npm run test
npm run bundle

Inspect the generated manifest and confirm that every declared surface exists in the bundle. Check host, controller, and spectator paths independently when your game declares them.

Sign in from the CLI

For normal local development, approve a scoped CLI session in your browser:

tpgames login
tpgames whoami

The CLI saves the session for the exact registry origin. It never prints the credential. Run tpgames logout when you want to revoke it.

Use TPG_API_KEY only in CI and other unattended environments. Keep it in the environment or a CI secret; the CLI deliberately does not accept credentials as arguments or project configuration.

Upload through the CLI or creator portal

register means delivering a built game version. It does not create an account. The default mode only uploads the bundle:

tpgames register

Use tpgames register --mode submit when the version is ready for review. Use tpgames register --mode publish --yes only when you deliberately want the complete upload, submit, and creator-publish flow. The production registry is the default; pass the same --registry-url to login, whoami, and register for a staging or loopback registry.

You can also open the creator portal to inspect and manage versions.

Open the creator portal, create or select the game, and upload the version bundle. The portal keeps the upload and its metadata together so reviewers can inspect the exact candidate.

Use a version description that tells a reviewer what changed in player terms. “Controller answer buttons now remain usable after reconnect” is more useful than “misc fixes.”

Test the draft

Before requesting review:

1. Launch the draft on a host display.
2. Join from at least one phone controller.
3. Exercise the primary loop.
4. Refresh one surface and confirm the room recovers.
5. End the game and return to the lobby.

Games that support spectators, privileged browser capabilities, or more than one display should test those declared paths too.

Submit for review

Review evaluates the manifest, browser policy, bundle shape, and actual room behavior. A reviewer may reject a version without changing the published version players already use.

Once approved and published, verify the catalog path in a clean session. That final check catches assumptions that were accidentally satisfied by local storage or creator credentials.

Keep the release reproducible

Tag the source revision that produced the bundle, retain the command used to build it, and record any required environment inputs. Never commit package tokens or embed registry credentials in game assets.

For a complete detached-repository example, follow the external game workflow.