# Make games on Looop

Looop is a place to play multiplayer games with friends, at
[play.looop.games](https://play.looop.games). Anyone can make one. You don't
need to know how to code: your AI coding agent does the technical work; you
describe the game you want and play-test it.

Looop is **agent-agnostic**: it works with Claude Code, Gemini CLI, Codex,
opencode, or any agent that reads a project's instruction files. There is no
plugin or extension to install. Every game folder carries its own agent
instructions (`AGENTS.md`, with `CLAUDE.md` / `GEMINI.md` pointers, and skills
under `.claude/skills/`), so whatever tool you use picks them up.

**If you are the human:** paste the prompt from
[docs.looop.games](https://docs.looop.games) into your agent and let it work.
The rest of this page is written for the agent.

**If you are the agent:** follow these steps.

**Your whole job here is: create the folder, then hand off.** Two steps, and the
page ends. You are *not* going to build, run, or publish the game from where you
are now — and this page deliberately doesn't tell you how, because that isn't
your task and those instructions are not yours to hold.

**They live in the game folder.** The scaffold you're about to create carries its
own `AGENTS.md`, its own skills (`/build`, `/qa`, `/feedback`, …), its own
handbook, and the engine's craft docs. An agent picks all of that up **only when
its working directory is that folder**. That is the entire reason for the
handoff: not bureaucracy, but the fact that the knowledge for building the game
is *inside* the thing you're creating, and you can't reach it from out here.

## 1. Prerequisites

- Node.js 20.11+ (`node --version`; install from https://nodejs.org if missing).
- A Looop account. You don't need one *before* you start — `create` signs the
  human in as part of making the folder (step 2). It's free, and it takes a
  click.
- Nothing else. The engine, its libraries, and the craft docs download during
  `create`, into the game folder. There is no global install.

## 2. Create the game

Ask the human what to name the game. The name becomes both the folder and the
published URL slug, so it must be **lowercase letters, numbers and dashes**
(e.g. `neon-racer`). Don't invent one silently. It's theirs to choose.

```bash
npx @looop-games/cli create <name>
```

This scaffolds `<name>/` as its own git repo: a working multiplayer game plus
all the agent instructions and the `/build` workflow, inside the folder.

**This command will pause and ask the human to sign in.** That is expected — not
a hang, and nothing has gone wrong. Looop's engine downloads with the game, and
that download is tied to their account. What happens:

1. A browser window opens on the Looop activation page.
2. The command prints a short code (like `WXYZ-1234`) and waits.
3. The human enters that code in the browser and approves.
4. `create` continues on its own.

**Tell them this is coming, before you run it** — a browser opening by itself and
a command that stops mid-way is alarming if nobody warned you. Say something
like: *"This will open your browser to sign you in to Looop — enter the code it
shows and approve, and it'll carry on."* Then read them the code from the output.

If they close the window or it times out, nothing is left behind: `create`
removes the half-made folder so you can simply run it again.

Once signed in, this machine stays signed in — no other command in Looop will
ask again.

## 3. Hand off — and stop

**Say this to the human, and end your turn:**

> "Your game is ready, in the folder `<name>`. Now open your agent again **with
> that folder as its working directory** — a fresh session inside the folder —
> and tell it what you want to build. Everything needed to make the game lives
> in there; I can't reach it from here."

Then stop. **Do not** `cd` in and keep working. **Do not** start the dev server,
install anything, write files into the new repo, take screenshots, or "just check
that it works" — it already works, and the folder ships with its own test that
the next session will run. Anything you do from out here is done *without* the
game's instructions, on a repo that isn't shaped for your current habits. That is
how creators end up with stray files in their first commit and confident, wrong
answers about their own game.

**If the human doesn't know how to do that** — and many won't, this is the one
genuinely technical moment in Looop — walk them through it rather than doing it
for them. Explain it plainly:

> "Whatever you're using me through — a terminal, an editor, a desktop app —
> point it at the `<name>` folder and start a new chat there. It's the same as
> opening a project: the folder *is* the game, and it carries its own
> instructions for me. Once I'm in there I'll know how to run it, build it, test
> it and publish it — none of which I know from here."

If they're in a terminal, that's usually: close this session, `cd <name>`, and
start the agent again. If they're in an editor or a desktop app, it's "open
folder" / "open project" → `<name>` → new chat. Adapt it to their tool; you know
what they're using and this page doesn't.

That's the last step on this page. The next session takes it from there: it will
boot the game and build it with them. They're already signed in, and the engine
is already downloaded — so in there, `looop dev` just runs.

## What Looop provides

- **Multiplayer built in.** Rooms, presence, physics authority, identity.
  Locally `looop dev` runs the full stack; published games use the platform's.
- **The engine.** A versioned library of game components and craft docs,
  downloaded per game and pinned in package.json's `looop.engine`. Upgrade when
  you choose.
- **Services.** LLM-driven NPCs and more, platform-authenticated. No API keys
  to acquire, ever.
- **Hosting.** `play.looop.games/g/<name>`, instantly, from `looop publish`.

Your game's folder is yours: its own git repo, private if you like, hosted
wherever you like (or nowhere). Looop never needs to see your source beyond
what you publish.