Skip to main content
An AI coding agent can use Summer Engine to build a multiplayer Summer game in GDScript, integrate the Summer SDK, validate it locally, and submit it through the live submission API. A human reviews every submission before its catalog status can become published; published catalog status does not make an uploaded game playable yet.

Point your agent at Summercraft

Paste this into any coding agent:
The prompt at /agent-setup/prompt is the canonical, always-current version — served as plain markdown at https://docs.summerengine.com/agent-setup/prompt.md so agents can fetch it directly. It contains a complete, export-verified multiplayer game template (king-of-the-hill, host-authoritative, 1–8 players), the local validation steps, the exact publish calls with every error explained, and the honest post-submission status.

What the agent will do

  1. Check prerequisites — Summer Engine for local validation/export, curl, a sha256 tool, and (only at publish time) your access token.
  2. Build a multiplayer-native gameextends SummerGame, all gameplay authority on server paths, player state via set_synced, local SDK stubs so everything parses and smoke-runs without the platform runtime.
  3. Validate locally — headless smoke run, banned-API self-check, pack-content check. The upload budget is 1/hour, so the prompt front-loads every check.
  4. Export a game-only .pck — the preset excludes stubs and project config; ships GDScript as readable source.
  5. Publish through the live API — create game → presigned upload → server-verified finalize. See Exporting and Uploading for the full reference.
  6. Report honestly — release pending_review in the manual queue; approval changes its catalog status to published, but does not make it playable yet. Rejection comes with a reason on summercraft.ai/creator.

The one thing the agent cannot do: sign in

Agents must never handle your password. Create your account and session yourself:
  1. Sign up / sign in at summercraft.ai.
  2. In that tab, open dev tools → Application → Cookies → summercraft.ai and find the cookie whose name ends in -auth-token (possibly chunked into .0/.1 — concatenate the values in order).
  3. URL-decode the value; if it starts with base64-, base64-decode the rest. The JSON inside has an access_token field — that string is the Bearer token.
  4. Hand it to your agent as the SUMMERCRAFT_ACCESS_TOKEN environment variable. It expires after about an hour — enough for one publish. Re-extract it when it expires.
There is no dedicated token page yet; this manual step is the current path. The publish API accepts Authorization: Bearer <token> on every endpoint.

Platform status

The release API, browser submission with static scanning, manual review queue, and authenticated release downloads are deployed. That does not make an approved game playable. Use the single canonical Product source & platform status table for every Live / Scaffold / Planned decision. It covers playback, hosted servers, matchmaking, the runtime sandbox, and the transport contract without duplicating a second status table here. If documentation and reality disagree, trust the API’s own error text and mail founders@summerengine.com.

For agents reading this page directly

Fetch https://docs.summerengine.com/agent-setup/prompt.md and follow it. Every page here is markdown-addressable: append .md to any URL. Index: https://docs.summerengine.com/llms.txt (or llms-full.txt for full content).