Listing guidelines: what gets a game on FanZero

FanZero lists very early browser games: napkin ideas, prototypes, vertical slices, alphas. To get listed, a game needs one build that runs in the browser with no network, a pitch, and at least one pact for streamers. Automated checks and an AI critic review every build, and a human curator plays it and gives the final yes.

At a glance

Your agent can run the automated checks as often as it likes with check_build: no key needed, nothing is saved. Publish from Claude Code walks through the whole flow.

The full guidelines follow, exactly as the MCP tool read_listing_guidelines returns them to agents.

FanZero lists very early games: napkin ideas, prototypes, vertical slices. Rough is fine. Boring is not.

The build

• Must run in a browser from an index.html at the root. Single-file builds are ideal.
• Max 8 MB total. Assets inline (data URIs) or as extra files you send with the build.
• No network calls at runtime: no fetch/XHR/WebSocket, no CDNs, no analytics, no ads, no links out. Games run in a sandboxed iframe that blocks network calls and outside assets.
• One page: the game never loads another page in its frame (no location changes, location.assign/replace, meta refresh or links to other pages). The checks refuse a build that does, and the player closes a game that does it anyway.
• Games run on an opaque origin: localStorage, sessionStorage, IndexedDB and cookies throw. Keep state in memory or wrap storage in try/catch.
• No eval tricks, no cookie/storage snooping of the parent page, no popups.
• It has to be playable in under 10 seconds: a title screen, then fun. Keyboard + mouse/touch where possible.
• Tip: call parent.postMessage({ type: 'fanzero:score', score }, '*') on game over and FanZero will show the score to the player.
• The automated checks read the code; they don't play it. Play your build in a sandboxed iframe (sandbox="allow-scripts") before you send it, above all as an update to a game that is already listed.

The pitch

• title (max 60 chars), tagline (8-120 chars, make it bite), description (60-4000 chars: what it is, what makes it weird, where it's going).
• genre: arcade, action, puzzle, roguelike, platformer, cozy, strategy, rhythm, horror, weird.
• stage: napkin, prototype, vertical-slice, alpha.
• controls: one line.
• store_url: optional https link to where it already sells (Steam, itch.io, your site). Already on sale is fine.

Pacts (the whole point)

At least one pact. A pact = what % of net revenue the streamer who takes it gets, and for doing what (YouTubers and TikTokers count as streamers).

• action: livestream | video | short | post | playtest
• share_pct: 0 < x <= 50 (percent of the game's net revenue, so 10 means 10%)
• requirement: be concrete, e.g. "Min 60 min live, link in chat", "Video >= 8 min, game in title".
• min_audience: optional follower floor.

How every pact runs (same rules for all, nothing to configure):

• One streamer at a time per game. Other streamers can still pitch while it's held; you accept the next one when the game is free again. No overlap, no attribution fights.
• Accepting a pitch gives the streamer 30 days to go live and send proof. Miss it and the claim expires; the game is free again. Deadlines are exact times, shown in UTC.
• The window is 4 weeks (28 days), counted from when the stream, video or post went live (the streamer reports it with the proof link), not from when you confirm. A window never starts before the previous one on the same game ends.
• The share is share_pct% of the game's net revenue earned during those 4 weeks, from every store it sells on (Steam, itch.io, your site). Already on sale before the pact? Those stores count too.
• Proof doesn't check out? Send it back (send_back): no window starts, and the first time they get at least 3 more days to fix it. A later send-back adds no time, and one after their deadline ends the claim. Or turn it down (decline): no window, and the game is free for the next pitch.
• Proof waiting for your check holds the game only until its 4 weeks would have ended. After that the game is free; you can still confirm (the window is recorded as completed) or turn it down.
• You can only accept a pitch on an open pact of a live game. Closing a pact (or replacing it with update_game) passes the pitches still waiting on it.
• When a window ends, the same pact can go to the next streamer.

Pacts are tracked on FanZero; money moves outside the platform for now. Be honest: under-promise.

Review

1. The Bouncer: automated checks above (it reads the source and the pitch; it doesn't run the game). Blocking issues bounce the build back with notes.
2. The Critic: an AI reviewer scores fun potential, clarity and pitch (0-100) and leaves notes.
3. The Curator: a human plays it and gives the final yes. No game is listed without a person. Status: checking -> changes_requested | awaiting_curator -> listed | rejected. Fix notes with update_game (send a new build) and it goes through review again. Agents can dry-run the automated checks with check_build first; it saves nothing. A new build for a game that is already listed goes through the automated checks (the Bouncer and the critic) before it replaces anything: if it fails you get build_rejected, and the live version, pitch and pacts stay as they were. If it passes, the new version goes live right away, with no human playing it first (the game was already approved; curators see it in the log). So play it yourself before you send it.

More

• Publish from Claude Code: connect your agent and publish, step by step
• Pact rules: every rule of a pact
• MCP tools: what your agent can do, and what waits for your OK
• The agent guide: the page your agent reads