Publishing games

Ways to publish

Whichever way you use, a new game gets a game ID and release 1; every later update is a new release.

Upload requirements

• A static web build, zipped, with index.html at its root. If the ZIP holds a single top-level folder containing index.html, the platform lifts it to the root. HTML, Three.js, Godot and Unity web exports all work.
• The running game must not make cross-origin requests to other sites; ship every resource in the package.
• A new game needs a title and a cover. The cover is a 16:9 PNG or JPEG, at least 640×360 and at most 5 MB.
• Optional: a 3:4 portrait poster (PNG or JPEG, at least 600×800, at most 5 MB); up to 6 screenshots of at most 2 MB each.
• A ZIP uploaded in the file field of POST /api/deploy may be up to 200 MB (the platform can set this limit lower; larger uploads answer 413).

Unity WebGL

Build for WebGL (Unity: File → Build Settings → WebGL) and publish the build folder, the one with index.html, Build/ and TemplateData/.

• Any compression works: Brotli, Gzip or Disabled. "Decompression Fallback" is not required. The platform recognizes a Unity build compressed with Brotli or Gzip (a *.loader.js that defines createUnityInstance, with .br or .gz files beside it) and serves those files with their Content-Encoding and the type of the file inside (game.wasm.br as application/wasm).
• Each file may be up to 512 MiB, and the whole build up to 1 GiB (20,000 files).
• A multithreaded build needs cross-origin isolation: put origingame.runtime.json with {"version":1,"crossOriginIsolated":true} at the root of the build.
• Windows, Mac, Linux and Android builds cannot be published: export WebGL.
• npx origingame detects a Unity project and builds it for you when the Unity Editor with WebGL Build Support is installed.

Runtime declaration

origingame.runtime.json at the root of a build describes how the platform runs it. Every field except version is optional:

The value in effect is reported as runtime in the publication answer and in each entry of the release list.

Publish from Origin

Choose "Publish…" in Origin's "Publish" view, or ask Origin in the conversation to publish. Origin packages the game first (an immutable build archive of a checkpoint), publishes with deploy_create or deploy_update, and records the source checkpoint on the publication. Before committing, the platform checks in the Player that the game loads and reports ready; if the check fails, nothing is published. After publishing, switch the live release in the "Publish" view. Details: Origin.

Publish through Origin MCP

With Origin MCP connected (https://mcp.origingame.ai/mcp, see Origin MCP), tell your agent "publish this game to Origin". The agent uses these tools:

Origin MCP's publishing guide requires the agent to get your permission before publishing publicly, updating a named game or deleting; to reuse the same operation_id and identical input on a retry; and, when the outcome is uncertain, to check deploy_status instead of publishing again. After a successful publication the agent should report the returned gameId, playUrl and portalUrl.

Publish with the script

The deploy script deploy.sh is in the origingame-skill repository. It needs bash, curl and Bun, and reads OG_API_KEY and OG_HOST from the environment:

git clone https://github.com/fran0220/origingame-skill
export OG_HOST=https://origingame.ai
export OG_API_KEY=og-...
origingame-skill/scripts/deploy.sh ./dist --title "Neon Dodge" --cover cover.png

• After the first publication the script writes .origingame-deploy.json in the game directory, remembering the publisher and the game ID, so later runs update the same game instead of creating another. The file is left out of the uploaded package.
• Updates must pass --expected-revision, taken from the release list:

origingame-skill/scripts/deploy.sh releases list GAME_ID
origingame-skill/scripts/deploy.sh ./dist --update GAME_ID --expected-revision 3

• Run deploy.sh --help for every option (description, genre, orientation, tags, languages, screenshots, poster, unlisted and more).

Publish with the HTTP API

Every request uses Authorization: Bearer og-... against https://origingame.ai.

Create a game

curl https://origingame.ai/api/deploy \
  -H "Authorization: Bearer $OG_API_KEY" \
  -F "title=Neon Dodge" \
  -F "cover=@cover.png" \
  -F "file=@dist.zip" \
  -F "description=Dodge the neon walls." \
  -F "genre=arcade" \
  -F "orientation=portrait"

On success the answer is 201:

{
  "gameId": "...",
  "slug": "neon-dodge",
  "version": 1,
  "releaseId": "...",
  "traceId": "...",
  "runtime": { "crossOriginIsolated": false, "precompressed": false },
  "warnings": [],
  "playUrl": "...",
  "portalUrl": "https://origingame.ai/g/neon-dodge"
}

Update a game

Read the release list first to get the current revision, then update with it. Without expected_revision the answer is 428; if the revision has changed it is 409: review the release history again before deciding, and never retry automatically with the new value.

curl https://origingame.ai/api/deploy/games/GAME_ID/releases \
  -H "Authorization: Bearer $OG_API_KEY"

curl -X PUT https://origingame.ai/api/deploy/GAME_ID \
  -H "Authorization: Bearer $OG_API_KEY" \
  -F "expected_revision=3" \
  -F "file=@dist.zip" \
  -F "changelog=Faster walls after level 5"

GET /api/deploy/mine lists the games your account owns.

Form fields

Releases, going live and rollback

• Every publication or update creates a new release. Successful releases do not expire automatically; their files are kept until you discard the release or delete the game.
• Making a retained release live needs no new upload or build. Four ways: "Make live" in Origin's "Publish" view; the release history at /me/games; MCP deploy_activate; or the HTTP API:

curl https://origingame.ai/api/deploy/games/GAME_ID/releases/activate \
  -H "Authorization: Bearer $OG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"releaseId": "previous", "expectedRevision": 3, "operationId": "rollback-neon-dodge-0001"}'

• releaseId is a releaseId from the release list, or previous for the previous live release. operationId is 16 to 128 characters; reuse it on retries.
• Switching releases does not roll back players' cloud saves, and old multiplayer rooms disconnect. Runtime settings follow the release; storefront text, cover and screenshots stay as they are.
• The script equivalent is deploy.sh releases activate GAME_ID previous REVISION OPERATION_ID.
• Discarding a release (deploy_discard_release, or discard in /me/games) permanently deletes its files; you can no longer switch back to it.

What a published game gets

• A share link https://origingame.ai/g/<slug>, the play page /g/<slug>/play, and the standalone play address given as playUrl in the answer.
• A game page /games/<slug> with the leaderboard, comments and the creator's other games. The game appears in "Games" and on your creator page and can be shared, liked and commented on; an unlisted game is reachable only by its link.
• Platform features: through the Player protocol (Player protocol 2) the game uses player identity, leaderboards, cloud saves and multiplayer rooms; see Game protocol.
• Management: at /me/games edit the title, description and genre, switch public listing, view release history and delete the game. Through Origin MCP you can also inspect and reset leaderboards, inspect cloud saves, moderate comments and read reports.
• Checks and review: after publication the platform checks in the Player that the game loads, and records the result in the release list; when a new game is published, the operations team is notified to review its content.