Update the game live in the Playgama catalog
send_playgama_catalog_updateSend this archive and the saved form to the Playgama catalog as an update of the game live there, without moderation: once it is published, every catalog player gets it and no moderator checks it first. Write updateNote — what players will notice in this update — every time; a refused note writes nothing: fix it and call again. Call it only on the developer’s explicit yes in this conversation: first tell them the game, the archive and that the game live in the Playgama catalog will be updated for all its players with no moderation; a yes to an earlier update or to a sandbox publish does not count. Before asking, read get_submission_state with this archiveId and reviewType AUTO: it says whether this call would be refused, in the same words. Only a game live in the catalog takes it (autoReviewPlatforms holds PLAYGAMA); a first publication and every other platform go to moderation, which a human submits in the console. Answers outcome PENDING and releaseId: the archive is built, then published. Follow the PLAYGAMA publication of get_publications with that releaseId, waiting its retryAfterSeconds between reads: PUBLISHED — the update is live; FAILED — it never went live, players keep the previous build and no reason is given: tell the developer; the same form may go again, after a new yes. Until it ends, another publication of the game, to the catalog or the sandbox, is refused with 409 PUBLICATION_IN_PROGRESS. Read get_publications before the call. A call with no answer may still go in after any read, so never tell the developer it did not: read get_publications again — a PLAYGAMA publication with a new releaseId naming this archive is an update of this archive, this call’s or another submit’s: follow it. Otherwise the outcome is unknown: say so, and never call again on the old yes — a call sends the form as it is when it goes in, which may have changed since: another call is a new update, after get_submission_state and a new yes. Refusals (reason; relay message word for word): AUTO_REVIEW_UNAVAILABLE — not live in the catalog; NO_CHANGES — the archive and the form are those of the last submit; PUBLICATION_IN_PROGRESS; and every reason get_submission_state names.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| archiveId | Yes | The archive to send: one of this game whose build check PASSED (get_archive_status `state`), the one get_submission_state judged with `reviewType` AUTO. Its form goes with it, as saved | |
| updateNote | Yes | What a returning player will notice in this build, 80 to 500 characters, 1 to 4 sentences. Not a changelog: pick the one or two changes a player would actually feel (a new level, controls that work differently, a boss that got easier) and say them the way you’d tell a friend who played last week. Skip refactors, build settings and fixes nobody could see. If it fixes something players complained about, say so. Required: this update replaces the build every catalog player has now. It is kept with this release. Always write it in English, even when you talk to the developer in another language: translate, don’t switch. Write as the developer posting in the game’s chat, not as an announcement: first person, short sentences, contractions, plain words, one or two short paragraphs. Plain text only: no headings, lists, markdown, links, e-mail addresses or hashtags, and one emoji at most. Avoid ad words and AI tells: immersive, dive into, embark, journey, unleash, elevate, seamless, thrilling, "whether you’re…", "not just X but Y", lists of three, em dashes. Don’t open with the game’s title, "Welcome to" or "Hey everyone". Use only what you know from the game and from building it; never invent a backstory, feelings or numbers. Non-Latin letters and links are refused: fix the text or leave it out, and never let it block the rest of the call. Here the note cannot be left out: fix a refused one and send it again. | |
| applicationId | Yes | Application (game) id, as returned by list_applications |