Playground: disposable chain, test WCHI, wiped without warning
Builder docs

Quickstart

The shortest honest path from nothing to a game on the Arcade: starting with whether your idea fits at all.

The shortest honest path from nothing to a game running on the Arcade.

This page is the path itself: follow it top to bottom and you will have a game running. Everything here is a command you run and a file you edit; nothing assumes an AI agent, and nothing is hidden behind one.

If you are driving an agent, the opening prompts are the literal text to paste first, and the agent skills are the same knowledge in a form it can load. Both point back here. The agent path is a convenience, not a different platform: the constraints, the commands and the submission are identical either way.

Part 0: Will your idea fit?

Read this before anything else. It is the cheapest possible moment to find out that the Arcade is the wrong home for what you have in mind.

An Arcade game is 2 to 4 seats, React/Next only (the SDK has no supported non-React path today), and ships as a static export with no server of any kind: no API routes, no server actions, no database, no asset backend, no leaderboard service, and no accounts beyond your Xaya p/ name. All shared state is produced by a deterministic wasm judge with no floats, no clock, no network and no file access, whose state output is bounded and whose execution is fuel-capped, which caps how big a world and how long a history you can have. Input is keyboard- or tap-shaped, and every game must be playable by touch: it declares on-screen touch controls (a d-pad and/or action buttons) that the SDK mounts on touch devices, or it declares that it draws its own touch surface and takes the whole frame to draw it in: a game that declares neither is labelled desktop-only on the shelf and a player on a phone cannot start or join a match in it. There is no gamepad support and no key remapping. And a match needs two to four named, funded humans online at the same moment; there is no solo mode, no bot and no matchmaking.

Authority: arcade-xayaman/next.config.ts: "A static export has NO SERVER".

If your idea does not fit, say so in Discord before you build. A persistent world, an economy or an async every-move-on-chain game is not a worse idea; it is the other architecture.

What it costs. Building and testing is free: every check in Part 2 runs offline with no chain and no funds, and the playground in Part 3 runs on a disposable fork whose wallets are pre-funded with fake money. The only real money in the whole path is the WCHI to register your own p/ name on Polygon, and you do not need one until you want to play on the real arcade.

Part 1: What you need

  • Node 22 (20.9 is the floor, but 22 is what every gate is proven on: see What you need), Docker, git.
  • A clone of the template: git clone https://github.com/xaya/arcade-xayaman.git. /repos says what each repository is and whether you can clone it today.
  • Roughly an hour to get the template running and a match playing before you change anything. Do that first. A game you have not seen work is a game you cannot debug.

Part 2: The offline ladder

All of this runs with no chain, no relay, no funds and no network. Get every rung green before you go near the playground.

npm ci
npm test                     # unit tests
bash blob/tests/run-tests.sh # the wasm rules, in isolation
npm run e2e                  # 12 scripted channel scenarios, no chain
npm run e2e:determinism      # the same moves must produce the same bytes
npm run selfplay             # a full match driven by script
bash blob/check-blob.sh      # the blob matches its committed sha256
npm run dev                  # single-client UI work: no chain, no wallet

npm run dev is for looking at your board and iterating on the UI. It cannot open a channel: there is no local chain, and anything involving a second player needs Part 3.

Part 3: Optional playground testing

Channel tests need a registered rules blob and a running referee, relay and chain. The public playground at test-arcade.xaya.io has all of them: Testing says how to attach your build there.

Then point the dev server at the playground:

PLAYGROUND_ORIGIN=https://test-arcade.xaya.io npm run dev:playground

Getting started lists the five values that script sets, the recognition test that tells you they reached the browser (a dev-wallet picker, not a wallet-connect prompt), and why they must never move into .env.local.

Then play it for real on the playground's own /play/<slug>, whose test wallets are the funded, named ones (the dev server's four are the SDK's fixed addresses, which a playground does not fund): open it in two browser profiles, pick a different test-wallet slot in each, and play a full match at every seat count you mean to declare. Two tabs of one profile are the same player.

Part 4: Submit your game

Open the Game submission form. Provide the repository, full tested commit containing frontend and rules, WASM path and SHA-256, game details and test results. Click Submit new issue and follow that issue for the review. You do not need a hosted playground run or a production frontend bundle hash.

We rebuild from your commit and test privately before listing. For an update, use the same form with a new commit and a link to the earlier issue. Submission requirements describe each field.

Where to go next

  • The opening prompts: the literal text to give an AI agent.
  • Agent skills: the full corpus, browsable, or a zip to unzip into .claude/skills/. Fetch it with curl, as the opening prompts do: the edge answers some non-browser HTTP clients with 403.
  • Submitting: everything a submission carries, and what rejects a bundle.
  • /repos: every repository this site points you at, and what your relationship to it is.