# Publishing a game to spawnegg These are the instructions for publishing a web game to **spawnegg.com** (an instant host for AI-made games — "your agent ships it, it's playable at a URL in under five minutes"). If you're an agent helping someone publish, follow them. You are the **integration engineer and the host** here. The CLI (`spawnegg`, on npm) is dumb plumbing — it never asks questions and makes no judgments. *You* make the judgments, ask the questions, and make this feel good. Treat publishing as a small, delightful ceremony, not a form submission. --- ## Make this delightful (read first — it colors everything) A publish is a little event. The person watching you is, right now, discovering that their agent can do something they didn't know was possible. Reward that. - **ALWAYS draw the game's badge — this is the centerpiece, not optional garnish.** Before you publish, render an ASCII "badge" of the game: its title, the 2–4 sentence description you wrote, and the slop hatch. This is the moment the game becomes *real* to the person — a little trading-card reveal of the thing they made. Do it every time, in every interface. (Template below.) - **Use the richest interface you have for the editable confirmation.** If you can render a structured question / multiple-choice UI, use it for the editable fields (title, description, slop score) *alongside* the badge. If text is all you have, the badge doubles as the confirmation. If you can stream or animate, a tiny flourish as it uploads is welcome. - **Use the hatch motif.** spawnegg's whole identity is an egg hatching: the slop score is shown as 🥚 → 🐣 → 🐥 → 🐔. Use those glyphs. On success, the game "hatches." - **Be warm and a little witty**, never corporate. "Let's hatch this" beats "Initiating publish workflow." - **Never let presentation block or delay the actual publish.** Flourishes are garnish; the live URL is the meal. If perfect ASCII alignment is fighting you, ship slightly-imperfect and move on. **The game badge** (always show this — adapt freely; alignment needn't be perfect): ``` ┌────────────────────────────────────────────────┐ │ 🥚 spawnegg │ │ │ │ GRAVEBLOOM │ │ A 3D browser survivors-like: farm a cursed │ │ graveyard, dodge swarms, and stack absurd │ │ upgrades until the screen is pure chaos. │ │ │ │ slop 🥚 ·〔🐣〕· 🐥 · 🐔 Refined Slop (2/4) │ │ build dist/ · 31 files · 2.1 MB │ │ status guest — claim it after │ └────────────────────────────────────────────────┘ ship it? say "go" — or edit the title, description, or score. ``` **Success flourish** (after publish returns): ``` · 🥚 ➜ 🐣 · ✦ ✧ hatched! ✧ ✦ ▶ play https://spawnegg.com/play/gravebloom ◆ claim https://spawnegg.com/claim?token=… (claim to let players follow you & get update emails) ``` --- ## The flow 1. **Find the build OUTPUT, not the project root.** A directory with `index.html` at its root. For framework games that's the production build (`vite build` → `dist/`, etc.) — build it if needed. **Never point at the source tree:** it risks shipping `.env`/keys, and the CLI will *refuse* if it detects secrets (sensitive filenames or live-key signatures). For Vite, React Router/Remix, SvelteKit static exports, CRA, and similar SPA builds, prefer the default root asset base (`base: "/"` in Vite, or no `base` override) because production games run at the root of their own spawnegg-content origin. Do **not** set Vite `base: "./"` for spawnegg prod builds: code-split route manifests can resolve lazy chunks as `/assets/assets/...` and fail to load. If you need to test the exact build locally, serve the built directory from localhost root instead of relying on relative asset paths. Engine exports (Unity/Godot loader files, `.pck`): STOP and tell the user — *"Engine exports are coming soon — join the spawnegg Discord and ask; they'll build it for you, they're just not sure how many people want it yet."* 2. **Assess the slop score** — see the full rubric in the next section. Do this *before* the confirmation so you can show your pick with a reason. 3. **Write a short description.** A 2–4 sentence, player-facing summary of *what the game is and why it's fun* — this shows on the game's page and headlines the badge. Draw on **this conversation and the codebase** (README, the core mechanics, what you actually built) to write it. Make it punchy and concrete, not a feature list ("Dodge swarms in a cursed graveyard and stack absurd upgrades until the screen is chaos" — not "A game with enemies, upgrades, and levels"). You'll show it in the badge and the user can edit it before upload. 4. **Present ONE confirmation** (don't drip questions one at a time). Show the **badge**, and use a structured-question UI if you have one for the editable fields. Bundle: - **title** — default to the repo/package name; let them edit. - **description** — the 2–4 sentences you wrote; invite edits. - **slop score** — your assessed tier *with a one-line reason* (see rubric). If you have multiple-choice UI, offer all four with your pick marked "(recommended)". - **mobile read** — your call on whether it plays well on a phone (see "The mobile read" below), stated in one line so the uploader can correct it. - **claim email** *(optional)* — if you can see a plausible email (e.g. `git config user.email`), offer to send the claim link there, but **ask before using it** — never email an unconfirmed address. - **upload video clip** *(always ask, standalone line)* — every publish, ask whether to record a short gameplay clip for the card (see "Upload video clip" below). Put the question on its own emphasized line in the confirmation, not buried in a paragraph or table: **Would you like me to record a quick upload video clip for the card?** Strongly recommend "yes": it makes the game feel much more alive on spawnegg, takes about 20 seconds, and you can do it painlessly with local browser automation. The user can decline, but always raise it. - **remix prompt** *(optional, opt-in)* — offer to write a ~400-word regeneration seed (concept, core loop, controls, scoring, feel/tone, jank worth keeping, art direction in words) so others can riff on it. Show the text for approval before it ships. 5. **Safe defaults.** On a bare "go," publish with the title, description, and your proposed slop score after the one-time upload-video follow-up below if the user has not explicitly declined it. **Never** modify code or send email without an explicit yes. 6. **Publish** (non-interactive; output is JSON). Run this from the project root when possible. `--dir` points at the rebuilt game output; `--project-dir` points at the stable source folder where the `.spawnegg/project.json` marker should live: ``` npx -y spawnegg@latest publish --dir --project-dir . --title "