Testing Your Game on Arcadible

Test in two places: locally while you build, with arc serve, and on Arcadible's staging channel before you release, the only way to run it on Arcadible before players get it.

Locally

arc serve runs your game on your machine the way Arcadible runs it. It builds, then serves deploy_dir framed in a local play page, with the sandbox and the Arcadible SDK, and reloads the game when the build changes. For the starters:

Starter	While you edit	To check the build players get
Blank	arc serve	The same: there's no build
Three.js, Phaser, PixiJS, Babylon.js	npm run dev, with arc serve --url http://localhost:5173 beside it	arc serve

Run npm install first in the engine starters. npm run dev is Vite's dev server, which reloads as you edit, and arc serve --url frames it in the local play page, with the sandbox and the SDK's host (Framing a dev server). arc serve on its own builds once, and serves what arc deploy would publish.

Any other local server, such as a dev server opened on its own, isn't the Arcadible sandbox:

• Paths aren't case-sensitive on most machines: your machine may find Ship.png when the game asks for ship.png. Arcadible won't.
• Cross-origin isolation is off, unless the server sends Arcadible's headers, as the engine starters' vite.config.js does: assets from other servers can load, and be blocked on Arcadible.
• The sandbox's limits are off: dialogs, popups, and form submission work, and are blocked on Arcadible.

What no local server reproduces is a fresh origin per version: browser storage persists locally across builds, but each version on Arcadible starts with it empty. Saves carry over on Arcadible and under arc serve; see Locally.

On staging

Deploy a prerelease to try a build on Arcadible itself, without changing what players get:

arc deploy             # with a version such as 1.2.0-beta.1
arc play -r staging    # the latest prerelease

A prerelease goes to the staging channel. It's playable at its link, isn't shown in the store, and doesn't change the store page. To see the store page it would publish, open the game's Store tab in Arcadible Studio and choose Staging. Its play page shows that version's own title, icon, and orientation, as the installed game does. Share the staging link with testers:

https://play.arcadible.com/star-drift:staging/

Deploy to staging as you develop, not only before a release, so each problem shows up soon after the change that caused it. See Channels.

A specific version

Every build stays playable at its version link, in either channel. Use it to compare two versions, or to find the release that broke something:

arc play -r 1.1.0

https://play.arcadible.com/star-drift:1.1.0/

On devices

• Phones and tablets: open the staging link on the device. Test touch, rotation, and the safe area on real hardware; see Best Practices.
• The desktop app: arc play opens the game in the Arcadible desktop app when it's installed. Games there run in their own window, with a few differences from a browser.
• Browsers: arc play --browser opens the play page in your default browser. Test the browsers your players use, including Safari.

In CI

arc validate exits with 1 when the project has issues, so it works as a check on every pull request:

.github/workflows/validate.yml

on: pull_request

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm install -g arcadible
      - run: arc validate

arc validate needs no login. To release from CI, see Deploying from GitHub.

Checklist

• The game runs under arc serve, not only under a dev server
• A prerelease plays on staging in a browser and in the desktop app
• Tested on a phone, with touch and both orientations your game supports
• No errors in the browser's console on the play page
• Saves carry over from one prerelease to the next, if the game uses them