Add a game

1 · Open the Studio

Sign in, then go to Studio (under your avatar in the top bar). The first time, you'll see the developer terms. Read them, check the box, and agree. (Or don't. This isn't coercion here. :))

Click New game and give your mighty opus a suitable name. Now you're in the Studio. Open the Files tab to find three starter files already written, with a working createCueClient() call in place.

Every game belongs to a team, and players see the team name on the game's tile. You start with a personal team, which you can rename from the Your teams section on the Make a Game page. You can also invite friends there, two ways:

• Invite gives someone the same run of the place you have: edit your games, submit them, invite other people. Only do this for people you trust that far.
• Invite as tester lets them play your games before anyone else can, and nothing else. No files, no settings, nothing to submit. This is the one you want for the mate who is good at breaking things.

If you're in more than one team, pick which team a new game belongs to when you create it (you can move it later from its Details tab).

2 · Write your game

The Files tab is a full code editor (autocomplete included) over three files to start:

index.html   # entry point, loaded first
main.js      # your game logic
style.css    # linked from index.html

Games are plain JavaScript, not TypeScript, and there is no build step. The file you save is the file that runs. Games with several files (should) work fine as the browser's own module system handles it:

// main.js
import { helper } from './helper.js';  // relative path, .js extension required
import { createCueClient } from '@cue/sdk';  // @cue/sdk is one of three names you can import by itself (so are @cue/2d and @cue/3d); everything else must be a relative path like ./helper.js

CSS is a plain link, not a JS import. Browsers never supported importing CSS from JavaScript, so wire it up directly in index.html:

<link rel="stylesheet" href="style.css" />
<script type="module" src="./main.js"></script>

Your code uses the same SDK as every game. See the API Reference for the full surface:

import { createCueClient, defineCueCard, CueRequestError } from '@cue/sdk';

defineCueCard();
const cue = createCueClient({ gameId: 'your-game-id' });

const { player } = await cue.init();          // connect first
const ids = await cue.player.collection();    // their cards
const cards = await cue.cards.get(ids);       // details + art

// ...render with <cue-card>, run your game...


// save progress (kept per game, per player):
await cue.storage.set('save', JSON.stringify(state));

3 · Add assets

Click Assets in the sidebar to open the asset manager, for uploading images, audio, or anything else your game needs that isn't source code. Each asset's filename is its path: upload coin.png and reference it in your code or CSS as coin.png, the same as any other relative file. Delete an asset from the same panel. Should all be straightforward, but let us know via support if it ain't.

4 · Test it

Click Test on the Details tab to play your game exactly as a player would, without publishing it. Only your team can start a test. An unpublished game is invisible to everyone else.

If you want someone else to test it before you submit (which we'd recommend, obvs), you have two options.

Share test link, next to Test, copies a link that's valid for 7 days, no team invite needed. Handy for a one-off.

Invite as tester, back on the Make a Game page, is the standing version: your games turn up under Games to test whenever they sign in, with no link to expire and nothing they can change. Better for someone you'll be asking more than once.

Either way the test runs your latest saves, so a tester who reloads after your fix sees the fix. (...and likewise if you decide to break it.)

There is no local preview: @cue/sdk needs the portal on the other side, so a game opened any other way waits forever on cue.init() - so plan on Test being your feedback loop.

While a test runs, the game's console messages and errors are recorded. If you build with an AI assistant through the MCP, it can read that log after you play and fix what went wrong without you describing the screen.

5 · Submit it

When it's ready, click Submit for review on the Details tab. The CUE Portal team plays your game and either approves it, which puts it straight in the public Games list, or sends it back with a short note on your Details tab explaining what to fix.

Honestly, we are making zero promises around this moderation/review bit at the moment as we have no idea how complex it will be or how many games or tools will be submitted. All we can say is that we will do our best.

The team may also send you a message about your game, such as a question or a suggestion. You'll get a notification, and the message appears at the top of your Details tab with a box to reply. Every owner on your team can see it and answer. A message never changes your game or its place in review.

While it's being reviewed your files are locked; click Withdraw if you want to keep editing, then submit again.

Once your game is live, you can keep working on it. Your edits show in Test, but players keep the published version until you ship them. Click Submit update on the Details tab and the update goes through the same review while your game stays up on its current version. When it's approved, players get the new version on their next load. If it's rejected, the note appears on your Details tab and the game stays live on the old version. Withdraw update pulls it back out of review if you want to keep editing first.

Changed your mind about what you were working on? Discard changes puts your files back to the version players have right now. It only shows up while you have unsubmitted changes, and it is final: anything you saved since your last update is gone and we cannot get it back for you. Your game's details and images are not files, so they are not touched.

Unpublish takes a live game down instantly. Your files aren't deleted, they are just no longer served, and any update still in review is dropped with it. To put the game back up, submit it for review again.

Set a thumbnail before you submit; it's what shows on your game's tile. Use a 3:4 portrait image, for example 600 x 800. Put your game's name in the artwork if you want it on the tile: until you add a thumbnail, the tile shows the name you typed, and once artwork is there it's yours alone. Oh and obviously don't violate copyright. If you've made something cool but artwork isn't your thing our in-house designers might give you a hand. No promises though.

There's a second image slot on the Details tab: the feature graphic. When your game is picked as the featured game, this is the big banner across the top of the home page. Aim for a wide 18:5 image, for example 1440 x 400, and keep the action toward the right, because your game's name sits over the left side. Other shapes work but get cropped to fill. If you skip it, the banner uses your thumbnail instead. Both images need to be under 2 MB.

A few more settings live on the Details tab and change how your game actually behaves:

• Screen: the shape of the area your game gets when it opens. Desktop (wide) keeps it at least as wide as 16:10; on a wider screen it grows to fill, and on anything squarer the portal blanks off the top and bottom so your game never gets squashed. Mobile (upright) is the same idea turned on its side: never wider than a phone held upright. Free (any shape) fills whatever the player's window is, so your layout has to cope with any shape. Whichever you pick, your game should fills its area exactly and the area should never scroll. If you want scrolling, build it inside your own layout. A player holding their phone the wrong way round is asked to turn it.
• Max players: how many seats a match really has. See the API reference's Multiplayer section.
• Min players: the fewest players a match can start with. Leave it the same as Max to always wait for a full room. Set it lower and a match can start early once that many people have joined, which is handy for a big room that would take a while to fill. See the API reference's Multiplayer section.
• Beta: shows BETA on your game's tile instead of New or Recommended, for a game players can try before it is finished. Turn it off when you are happy with it.

6 · Renaming and deleting

Picked a name you've gone off? You can change it, but not while the game is up. Click Unpublish, type the new name on the Details tab, then submit it for review again. (NB Everything else on that tab you can still change any time - it's only the name that waits, because players chose your game by it and it shouldn't turn into something else overnight. :))

Renaming changes your game's web address too, so the old link stops working. Nobody else can ever grab that old address, so it won't quietly start opening somebody else's game.

One thing does not change when you rename: your game's id, the short code you pass to createCueClient() in main.js. That stays the same for the whole life of the game. So after a rename, leave your code alone. If an AI assistant offers to "fix" the id for you, it's wrong.

Delete is for the game you had a go at, didn't enjoy, and would rather not see on your list any more. You'll find it on the Details tab once the game is off the portal. It asks you to type the game's name first, because it really does mean it.

There is one type of game you can't delete. A game that's live or waiting for review has to come off the portal first. Unpublish takes it off the portal, which is all anyone will notice.

7 · After it's live

Players can report a game they think is broken or out of line, using the flag button next to the close button while they play. Reports go to the CUE Portal team, not to you, and no number of them takes a game down by itself. A person always looks first. Granted, that person may be more easily swayed by half a million flags. What can I say - we're a fickle bunch.

If something needs fixing, you'll get a notification and a note on your Details tab, usually with a date. Update the game and submit it for review before then, or it comes off the portal. Submitting the update should 'stop the clock', so you won't be penalised for time we spend reviewing it, beyond the agony of waiting. If it's approved, the deadline goes away. If the game does come down, your files are all still there, and submitting it again puts it back through review.

The best way to avoid all of this is the boring one: play your own game in Test before every submit, and follow the rules.

What's different from a normal web app

There are two main constraints compared to 'normal' web apps:

• No npm packages. Ever. The import allowlist (@cue/sdk, @cue/2d, @cue/3d, and your own files by relative path) isn't about bundle size. It means nobody's game can pull in arbitrary third-party code, which is what makes it safe for your game to run at all.
• No build step. Plain JavaScript, checked and saved as-is. If you have used TypeScript or a bundler before, the only adjustments are: explicit .js extensions on your own imports, and a real <link> tag instead of importing CSS. If you haven't, there's nothing to unlearn.

The rest works the way you'd hope: your game runs in its own protected box, asks the portal for anything real through the SDK, and can never hand out currency or cards on its own.

Checklist

• Developer terms accepted (once, in the Studio)
• index.html links style.css and loads main.js as a module
• Only @cue/sdk, @cue/2d, @cue/3d, and relative imports in your JS files
• Tested via the Test button before submitting
• Thumbnail set, then Submitted for review