Publish on Playmos. Use the hosted platform by default.

Share a playtest before release#

Studio builds and uploaded browser games use Share preview. In Agent Studio, share the version you are viewing. For an uploaded game, open Upload & test → Browser build and share the latest build or choose an exact older build. Select 24 hours or 7 days, create the link, then copy it. Anyone with the link can play and leave feedback without an account. Revoke it from the same dialog.

The link stays pinned to that build. Shared previews are unlisted, expire automatically and do not publish a game. Upload previews serve bundled files from an isolated origin; external backend access and paid transactions are not enabled. Feedback is unverified playtest input. Your normal hosting and payment configuration is unchanged.

Publish a complete browser game for public free play from the publisher workspace. No repository checkout is needed. The mode name practice means no paid contest or IAP; it does not limit the game to QA builds. Sign in and create a studio immediately, then configure your game. Playmos reviews the exact submitted build before publication. Game details stay editable; there is no separate listing approval.

Find your next publishing task#

Open Publisher → My Games and choose Continue setup or Open publishing plan on your game. Games with requested changes or unread feedback appear first. The game card shows build review and live publication status; open the game for details.

The Overview shows a confirmed requirement count, your next action and the full publishing plan. Completed requirements have a check mark. Your action means your studio can continue; Waiting for Playmos means a reviewer owns the next step. Unavailable means the status could not be confirmed. Refresh or retry rather than treating it as complete.

If the upload says Uploads are busy, keep the selected ZIP in the form. Wait for active uploads to finish, or use Cancel interrupted upload beside one of your own interrupted transfers, then retry. A teammate must finish or cancel their own transfer. This recovery keeps completed builds and published games.

From My Games → Add a game, enter the name and description, select the ZIP and choose Create & test game. Playmos saves one private draft, uploads the build for review and opens that exact build in Developer Console. To upload later, choose Create draft, then use Upload & test. Awaiting build review means the ZIP has been received and is ready for private testing. Publication is confirmed only by the active build and its receipt; the overview keeps those states separate.

Clear unwanted projects: In Your games, select Archive on a game project. Use the Archived view and Restore to bring it back. Editing permission is required. Archiving preserves builds and review history; it does not cancel reviews, withdraw published games or cancel unfinished uploads. Cancel unfinished uploads in Upload & test to free their slots.

Manage an existing game and launch an update#

On the publisher dashboard, Apps & versions is always visible. Select a game name or Manage game to open its dedicated management page. This page serves ongoing operations; the separate game-project page guides a new submission.

Overview identifies the active version and any candidate waiting for review. Choose Launch a new version, enter a unique version name, the build URL on the game’s configured runtime and its exact SHA-256 fingerprint, then select Send version for review. The dashboard’s New version action opens this form directly.

Read review decisions under Version history. A submission or approval does not activate a hosted version; Playmos must complete release verification. The current version remains selected until activation. To restore an older version, it must have been approved and active previously. Use Game details for the listing, artwork, sharing and availability. A game hidden by Playmos remains hidden until Playmos restores it.

For an existing managed ZIP release, upload a replacement through that game project’s Upload & test tab and follow the exact-build review and publication steps. The existing-runtime version form does not upload a ZIP.

Share a temporary Studio preview#

In Agent Studio, choose Share preview on the version you want tested. Create a link that expires in seven days (default) or 24 hours, then copy it for friends, family and contributors. Anyone with the link can play without a Hub account and leave notes for that exact build. The link stays pinned when a new build is pushed.

Revoke it from the same dialog. Expiry blocks new loads and retires the shared playable copy on access or the next one-minute cleanup batch; revocation removes it immediately. Feedback and version history stay in Studio. This is unlisted free practice, with no catalog listing, score verification or release approval. The session MCP exposes playmos_create_preview, playmos_get_previews, playmos_get_preview_feedback and playmos_revoke_preview. Agents read full version-pinned notes through MCP and incorporate them under the selected coaching setting. Read live sharing capabilities; local URLs work only on that computer. Sharing uses the managed game origin and does not enable the separate Studio HTML publishing track.

From draft to playable listing#

1. Create a draft and choose Free practice · no contest required. Add the name, description and preview art, then save before uploading the build. Use the shared 1200 × 630 preview, with artwork contained rather than cropped.
2. ZIP your browser build with a root index.html and relative asset paths. In Upload & test, upload it, declare the entry HTML, optional practice query and public HTTPS score/API origins.
3. Save your game details, upload the ZIP, and preview that exact build at Phone and Desktop sizes. The build manifest binds the saved details and ZIP bytes; these fingerprints have different scopes from contest terms.
4. Playmos reviews the submitted build, including its saved game details. An independent reviewer records security scan evidence, both playtests, any implemented backend score calls and lifecycle signals, and free-only behavior. For external studios, the reviewer must be a different staff actor from the uploader. The configured first-party studio may use the explicit internal-review path for free, no-IAP builds, retaining scan and playtest evidence. A client-only free game can have no backend; record that honestly rather than inventing score or SDK evidence.
5. With approval, select Publish free practice. The publication receipt identifies the exact artifact and environment. The complete game then appears in the Hub catalog and can be played publicly without a preview token.

Practice needs no paid contest, treasury or payment receipt. A planned IAP catalog may remain on the draft, but checkout must stay disabled in the reviewed practice build. ZIP checks validate structure and a limited credential heuristic; they do not constitute a malware scan or game test. Hosting must be configured on the Hub before publication is available.

Permanent game links and share previews#

The stable game ID is hosted-<draft UUID>. Verify the catalog, /game/<game ID>, /play/<game ID> and /api/games/<game ID>/share.png anonymously. The receipt URL serves the actual reviewed entry and assets on the build’s separate UUID origin. Keep its receipt ID, archive and manifest hashes, environment and URL. A hosted-test receipt proves that environment.

Private preview links expire after ten minutes. Public build links remain available while the build is active; the stable game links follow its replacement. Check the published title, description and contained artwork match the standard preview, including crawler metadata and the 1200 × 630 share image.

Recover an interrupted upload#

Open Publisher → My Games → your game → Upload & test. The panel shows the submitted build and its review status. A received ZIP still needs Playmos build review; only a published active build with a receipt is live.

If the form says Uploads are busy, the recovery controls appear beside your selected ZIP. Wait for active transfers to finish, or choose Cancel interrupted upload on one of your own interrupted transfers, confirm and retry the selected ZIP. A teammate must finish or cancel their own transfer. Completed builds and published games are kept. Unfinished uploads expire after 24 hours.

After a completed ZIP appears in the build list, test it at Phone and Desktop sizes. Open Review & release for feedback. Once the submitted build is approved, an owner or publisher can select Publish free practice and verify the receipt and public link.

Feedback and the next step#

Open your game’s Review & release tab to read feedback and reply to Playmos. The overview and game list show what is blocked, who needs to act and unread updates. Your Notifications inbox collects review updates across your studios. Mark updates read when you have reviewed them.

Shared feedback is visible to your studio and Playmos; team-only notes stay with Playmos staff. Messages do not change the approval status. If saved details change, upload a matching build for review. There is no separate game-details approval for this ZIP flow. Decisions and build updates stay in the conversation history. These are in-app updates; email and push delivery are not available.

ZIP and hash contract#

Hosted services or your own interface#

Playmos Games targets a fully Hub-hosted path: the signed-in account and Mo arrive through the SDK, with managed run validation, saved bests, leaderboard recordings and first-finish achievements in the new service candidate. That candidate is implemented locally and still needs deployment and hosted acceptance. Inspect environment capabilities and your exact build’s supported simulation before enabling server results.

If you choose independent hosting, the SDK transport seam accepts an authenticated HTTPS/JSON interface shim. The Games guide explains its authority boundaries. Existing custom backends remain supported; use the backend-origin rules below. IAP and paid entries retain their registered stablecoin and smart-contract integrations.

Engine-specific resources, license notices and source maps can stay in your browser export. Unknown asset formats are served as binary data. Native executables, server scripts and private keys are rejected.

When you bring a custom backend#

Keep replay validation, scores, database and private SDK/operator credentials on your backend. Declare its exact public HTTPS origin for browser connections and configure CORS for the exact UUID origin of each reviewed build. Hosted builds use separate origins to isolate studio storage and private preview cookies. API sessions must work with browser cross-site restrictions. The Hub does not run your server code. Use SDK/lab hooks at real ready/start/end and server-confirmed score boundaries; browser events do not prove scores or payment.

For Lane Crash, preserve ?host=playmos. Launch and separate-game URLs also include playmosMode=practice. The reviewer must verify that practice actually disables money features.

Compete and contest control#

Studio-owned games and pools are the intended model. This practice flow does not enable Compete; the current paid launch switch remains limited to configured first-party games. A studio release needs SDK game/pool/treasury binding, reviewed terms and complete paid-admission, settlement, fee-routing and withdrawal proof before paid enablement. Integrate the SDK entry popup/forms or your in-game entry with a trusted score backend. Proposed winner shares are not payout proof.

Your studio proposes entry price, duration, board and prize shares. Approval covers recurring rounds under that plan. A new price, duration, split or pool requires a new reviewed plan/series for future entries; existing rounds retain their terms. Contest plan review is separate from build review, so a terms-only change does not require identical client bytes to be uploaded again.

Updates and recovery#

Upload an updated ZIP on the approved draft and obtain a new exact-build review. The previous build stays active until replacement. Restore a previously published approved build whose declaration and runtime still match, or withdraw the listing from the same panel. Reload after a stale active-build conflict. Replacement and withdrawal block future loads of old build assets; already loaded games may keep running. Verify anonymous catalog, launch and asset behavior and retain receipts/history. Changed listing declarations require a matching build submission, not a separate listing approval. Use the existing preview artwork; extra icon/screenshots/tagline are optional presentation work.

Agent and MCP handoff#

Both the repository stdio MCP and the session-scoped Studio MCP expose the read-only playmos_get_publishing_guide tool. Stdio also advertises playmos://guides/game-publication. Read it for the complete workflow and inspect live capabilities before reporting a release.

The stdio playmos_upload_build tool freezes the older 2 MiB/64-file canonical manifest, not this managed ZIP. For compiled games up to 500 MiB ZIP / 1 GiB expanded, use stdio playmos_upload_game_zip with a ZIP path inside the configured project root. Both stdio and HTTP MCP expose playmos_get_hosted_builds, playmos_begin_hosted_upload, playmos_upload_hosted_part, playmos_finish_hosted_upload, playmos_cancel_hosted_upload and playmos_preview_hosted_build. Uploads use 4 MiB parts with durable retry-safe storage and expire after 24 hours if unfinished. Read the publishing guide for arguments and scope requirements. Review uses the authorized backoffice workspace. playmos_publish_hosted_build can activate an exact approved managed ZIP with publishing scope; it cannot approve it. Restore and withdrawal use their authorized workflows. Its legacy release/rollback tools do not substitute for those actions. Studio’s prepare/get/publish tools use a separate self-contained HTML track, origin and approvals; ZIP hosting alone does not enable it. See the MCP guide. Neither MCP can approve its own release.

Connect the game services#

Game hosting serves the reviewed browser build. Game services supply authenticated admission, owned inventory, progression and authoritative results. In Studio, use Play, Competition, Review; your agent reads the same plan through MCP. Saving a draft does not create servers, activate prizes or publish. Check provider readiness and real result persistence before advertising a capability. Managed worker rollout and hosted acceptance remain pending for the new source candidate. See Playmos Games and Live services.

One-hour sessions#

Sessions last one hour without sliding renewal. The draft editor warns five minutes before expiry. Keep your form tab open, sign in in another tab, then retry saving. Failed saves retain the current form in that tab; refreshing or closing it can lose unsaved changes.