Skip to main content

​
Before you submit

​
The two deployed submission paths

Four JSON/HTTP calls against https://summercraft.ai: create game → presigned upload URL → PUT the .pck → finalize with server-side sha256 verification. Artifact limits: 1024 bytes – 512 MiB. Each write step is limited to 1 request per hour per account. Full request/response reference: Exporting and Uploading Your Game. Agent bootstrap: /agent-setup.

​
Path B — the browser submit page

Go to summercraft.ai/submit signed in, and upload two files:
  • the .pck (multipart field pck)
  • manifest.json (multipart field manifest, file or JSON text)
The page posts a multipart request to the platform API:
(The Railway hostname is the deployed platform-api identity — it is correct as written.) This path validates at upload time:
  • auth and creator identity,
  • required manifest fields and basic typing,
  • max upload size (2 GB on this path),
  • automated static analysis of .gd files and scripts embedded in .tscn/.tres: banned APIs, reserved paths, blocked binary/native extensions. Failures return error: "Static analysis failed" with a violations list (file, line, pattern).
On success it returns ok: true, gameId, submissionId, status: "review".
The static scanner is pattern-based. A banned API inside a dead branch, an editor-only check, or a comment-adjacent string still fails. Do not generate “fallback” code paths that use blocked APIs. On Path A there is no automated scanner at upload time — the same rules are enforced by human review instead, so a violation costs you a review round-trip rather than an instant error.

​
Review lifecycle — both paths

Every submission is reviewed by a human. No auto-publish. On Path A, approval re-verifies the stored artifact against the checksum pinned at finalize before the game’s active version moves — verification at upload is not trusted at approval time. A rejected update leaves the previously approved catalog release active. Honest status: approval publishes your game on the platform and makes its release downloadable through the authenticated download endpoint. Playing uploaded Summer games in the browser or desktop shell, and hosted dedicated game servers, automatic matchmaking, and the runtime sandbox are not live yet — do not tell players otherwise. See the canonical platform capability status.

​
Updating an existing game

Released versions are immutable.
  1. Keep manifest.id (and on Path A the gameId) stable.
  2. Bump manifest.version; on Path A pass the same new version string to upload-url and finalize.
  3. Re-export and re-submit.
Each update goes through review again. The previously approved catalog release stays active while its update waits.

​
Common submission errors

Path A errors are self-describing JSON ({ "error", "detail" }) — the detail names the fix. The full table is in Exporting and Uploading. Path B errors:
  • Missing .pck file (multipart field: pck)
  • Uploaded file must be a .pck
  • PCK file too large (... max 2GB) — trim assets, or contact founders@summerengine.com for large-upload onboarding
  • Invalid manifest. Required: id, name, version, summer_sdk, entry_scene, min_players, max_players
  • Static analysis failed (with violations list)

Previous: Export and upload

Return to pack creation and the release API reference.

Next: Update an existing Summer game

Keep the identity stable, bump the version, retest, and resubmit.