Question 1

What kinds of games can I build?

Accepted Answer

Anything where every player can see the shared game state. Strong fits:

Turn-based: chess, checkers, card and word games, tic-tac-toe, board games.
Casual & co-op: party games, trivia, drawing/guessing, puzzle co-op, clickers.
.io-style arena: top-down shooters, agar/snake-likes, battle royales, with the client-side prediction and interpolation patterns from the docs.

Hidden information is fine too, as long as the secret lives in server logic rather than in room state. The two to design around are frame-perfect competitive netcode and very large single rooms: see “What does this backend ask you to design around?” below.

Question 2

How do I actually build one with my AI agent?

Accepted Answer

Point your AI agent (Claude Code, or any MCP client) at your MCP URL with your secret key, grab both from Studio key & MCP , then describe the game you want. The agent calls the platform’s build tools to create the game, define its rooms, and write the client HTML already wired to your key. You don’t write backend code. Prefer no MCP at all? Drop the SDK <script> tag, your publishable key, and a room name into a single HTML file and you have a working multiplayer page, the docs have the exact snippet.

Question 3

What is the Game Builder, and how is it different from connecting my own agent?

Accepted Answer

The Game Builder is the same agent, hosted for you in the browser. Open it from the dashboard, describe the game, and it appears beside the chat with a play link. Invite teammates into the session and one build takes in what everyone asked for. There is nothing to install and no key to paste. Connecting your own agent over MCP suits people who already work in Claude Code or Cursor and want the game in their own repository from the first line. Both make the same kind of game under the same studio, and a game made either way shows up in your dashboard. The builder spends credits per build; the MCP path costs whatever your agent already costs you.

Question 4

How do two people end up in the same game?

Accepted Answer

A live game is identified by your publishable key + a room name . Same key + same room name = the same running instance, so everyone who joins that room is in the same game. Share a link that opens your page on that room and a friend drops straight in. A different room name is a different game, created automatically on first join. Use a fixed name for a shared public game, or a random one for private matches and invite links.

Question 5

Do players have to sign up to play?

Accepted Answer

No; players are anonymous-first . The SDK mints a durable player id on first load, so someone can play instantly with no account and still keep saved progress on that device. They can optionally claim that identity later with a username + password to carry it across devices. By default players are shared across all of your games (one identity per studio, so saves and leaderboards follow them between your titles). You can opt a game into per-game players instead: set it once, before the game has players.

Question 6

How do I add levels or game modes?

Accepted Answer

The room name is your unit of separation. Treat each level, mode, or match as its own room name under the same key: level-1 , ranked , lobby , a match id, whatever fits. Rooms share nothing by default (each has its own live state), auto-create on first join, and cost nothing to add. One deployment hosts all of them: you don’t provision anything per mode.

Question 7

How do leaderboards work?

Accepted Answer

Named boards scoped to your players. Submit a score with one of three modes: max (keep the best), inc (running total), or set (overwrite). Read the top-N, or a single player’s rank. Every read also returns the total number of players on the board, so you can render “rank 7 of 412” from a single call. Scores are client-submitted by default; for a competitive board, submit them from authoritative server logic so they can’t be faked (next question).

Question 8

Can players share levels they've made?

Accepted Answer

Yes. A player’s saved data is private to them, so on its own it can hold “my levels” but never “everyone’s levels.” Player content is the shared half: a player publishes an item, a level, a track, a ship, a deck, and every other player of that game can browse it, load it, and vote on it. It’s one call to publish and one to list; a collection like levels is created the first time something is published to it. Each item gets a short share code, so “play my level” is just a link. Libraries are per game: one game never sees another’s, even under the same account. Publishing requires a claimed player (an anonymous identity disappears with its browser storage, and with it any way to edit or answer for what it posted); reading and voting stay open to everyone. Moderation comes with it: players can report an item, enough distinct reports hide it automatically, and your game’s Content tab here is the review queue where you restore or delete.

Question 9

How do I stop players from cheating?

Accepted Answer

By default each client writes its own state, so anything client-written can be forged, fine for cosmetics, preferences, and casual play, not for competitive integrity. For trustworthy games, deploy authoritative server logic (your AI agent can do this for you): the server runs the room on a tick, clients send inputs , and the server computes the real state. With that in place a player can’t set their own score, currency, or unlocks; the server does, writing them into server-managed ( @ ) documents the client can only read. That’s the line between “a cheater can edit this” and “this is trustworthy.”

Question 10

Can players see stats I don't want them to edit?

Accepted Answer

Yes: that’s what the @ prefix on a namespace means. A document whose name starts with @ is server-managed : your deployed server logic writes it, and clients can read it but never write it. That makes the values in it trustworthy; a player can’t fabricate them before submitting. Anything a client can write (the plain namespaces) is fine for preferences, cosmetics, and local settings, but treat it as player-supplied input. Currency, unlocks, ranked stats, and anything you’d be upset to see forged belong in a server-managed document.

Question 11

Is analytics the right way to show a player their own history?

Accepted Answer

No. Analytics is anonymous and device-scoped by design: events aren’t linked to a player identity, so they can’t be queried back for one person. It answers your questions about the game as a whole (how many players, how long they play, what they do), not a player’s question about themselves. Anything a player should see about their own history belongs in the datastore, written per player. Use both: analytics for your dashboards, the datastore for their stats screen.

Question 12

What does this backend ask you to design around?

Accepted Answer

Worth knowing before you design around it: Where a secret lives. Room state replicates to everyone in the room, so a hidden hand kept in room state is not hidden. Keep it in server logic instead and send each player only their own view: poker hands and fog of war work, they just do not work by accident. Competitive twitch action. The realtime connection is reliable and ordered rather than lowest-possible-latency, so precision shooters and racing want client-side prediction and interpolation rather than rollback. That is a pattern, not a wall, and the docs have it. Very large rooms. State broadcasts to everyone in the room, so player counts per room are best kept modest: many rooms scale better than one huge one.

Question 13

Can I charge money or sell items?

Accepted Answer

Yes: one-time purchases via Stripe Checkout. A successful purchase grants a server-verified entitlement the client can read but cannot fake, so you can safely gate paid content, unlocks, or currency on it. There is nothing for you to set up: no Stripe account, no keys and no dashboard. Checkout runs on ours, so your game calls player.checkout("premium") and reads player.entitlements() on load. For now the catalog is five fixed price points, from $0.99 to $4.99. Your own products and prices, and payouts to your own account through Stripe Connect, are on the roadmap.

Question 14

Can I run ads in my game?

Accepted Answer

Yes: bring your own Google H5 Games Ads. Set your ad publisher id per game (on the game’s settings) and the platform hands it to your client so your agent can embed the ad code. You keep 100% of the ad revenue . If no publisher id is set, render no ad code; the game runs fine without it.

Question 15

How much can I store per player?

Accepted Answer

There is no per-player storage quota, not on bytes, documents, or namespaces. The limits that do exist are shape limits, not size limits: 256KB per write. One save request must fit in that, so keep any single document under ~200KB. Unlimited namespaces per player. Each namespace is its own document, so you can spread data across as many as you like. Documents are read and written whole. There are no partial field updates, saving one number re-sends the entire document. That last point is the one that matters in practice. The cost of a document isn’t its size, it’s size × how often you write it . Keep the things you save every match small, and let the big history-style documents be ones you write rarely and load only when a player opens a stats screen.

Question 16

What does storage actually cost me?

Accepted Answer

Storage at rest is not the thing to optimize: it’s the cheapest part of the system, and totals in the megabytes-per-player range are unremarkable. Two things actually cost: Write frequency. Every save rewrites the whole document, so a large document saved every few seconds is expensive every single time, no matter how little changed. Save per match, not per tick. Server-managed documents load on join. When a player joins a room running your authoritative server logic, all of their @ -prefixed documents are loaded at once so your code can read them. Keep that set deliberate; a handful is fine, hundreds per player would add real join latency for that player. A sizing that needs no thought: on the order of a megabyte per player, tens of namespaces, one save per match. Prefer one document holding an array of 500 matches over 500 separate documents, same bytes, far fewer round trips. Heading well past that? Ask us and we’ll look at it with you rather than have you guess.

Question 17

How many players and games can I have?

Accepted Answer

On the free plan: 3 games per studio (each game is one publishable key). 30 concurrent players per game , counted across all of that game’s rooms. Joins past the cap are rejected with a clear “concurrent-player limit” error rather than degrading the game for everyone. That’s plenty for launching a game and validating it. Reuse an existing game rather than minting throwaway keys for tests. Higher limits come with paid plans; the pricing page always has the current numbers for every plan.

Question 18

Why won't my game run in the Claude or ChatGPT preview?

Accepted Answer

The in-chat artifact preview runs in a sandboxed iframe that blocks WebSocket connections, so the live game can’t connect there . It’s a limitation of the preview, not your game. The chat still produces the correct HTML: save it and open it as a real page (or host it) and it works. Claude Code writes the file to disk and opens a real browser for you, so it just works end-to-end; that’s the smoothest path.

Question 19

Is it safe to put my key in client HTML?

Accepted Answer

Your publishable key ( pk_… ) is designed to ship in client code, it’s in every game page you publish, and pasting it into a chat or a doc is fine. It identifies your game; it doesn’t grant control of your studio. Your secret key ( sk_… ) is the opposite: it’s your studio admin credential, it belongs only in your MCP client’s config, and it must never appear in game code or anywhere public. If it leaks, rotate it from Studio key & MCP , that permanently invalidates the old one.

FAQ