Skip to main content
You deploy a Three.js build to a private OpenGame preview, play it, and send that same release for review once it plays well.

​
Before you start

  • The CLI, installed and signed in. The quickstart sets it up with the team’s package and internal origin.
  • A static browser build with index.html at the root of its output folder.
  • Every Three.js module, texture, sound and decoder file inside that output folder. A script from a CDN is allowed, but the game breaks whenever the CDN is slow or down.

​
Deploy and play your game

1

Use relative asset paths

If you build with Vite, set base to "./" so asset URLs are relative to the page. The build then loads its files on any host, including a private preview. The templates/three-vite starter in the OpenGame repository ships with this setting; it is not in the CLI or SDK package, so ask the team for the folder if you have no repository.
vite.config.js
2

Describe the game

From the game folder, create opengame.json if it is missing:
Check the build fields. build.command runs your build and build.output names the folder it writes:
opengame.json
Set the description, genre and controls in the same file. Packaging lists every field and the runtime requirements.
3

Check and deploy

check --build runs your build and checks the output before anything uploads. deploy runs the build again, uploads the output folder and waits for the server checks. It returns a previewUrl when the preview is ready.
4

Play the preview

Open previewUrl while signed in to the account that deployed it. Play a full round from start to finish, then:
  • Resize the window and check the canvas follows.
  • Pause the game and toggle sound.
  • Open the network panel and confirm that textures, audio and any Draco or KTX2 decoder files load.
A build that works on your machine can still ask for a file that never reached the upload. The hosted preview is where that shows.
5

Send it for review

From the linked game folder:
This sends the release to review. It goes live when a reviewer approves and publishes it. Confirm the release, answer the jam’s fields if submissions are going to a jam, then complete certification in your browser. An agent passes --release <releaseId> and submits only when you ask it to. Enter a jam lists what a jam entry needs.

​
Fix a problem

Each finding lists its evidence and a correction. Read both before you change the game, fix the cause, then run opengame check . --build again. The repair loop explains findings and retry advice.
The file was not in the output folder when it uploaded. Put it somewhere your build copies into the output, such as Vite’s public/ folder, and load it with a relative path. Check the letter case as well: macOS and Windows ignore case, and our servers do not. Optimise your assets shows how to ship the KTX2 transcoder.
Run opengame status --watch from the game folder. It follows the server checks until the deploy is ready, failed or expired.

​
Where next

Optimise your assets

Compress models, textures and audio before the first frame.

Connect the SDK

Identify players and follow pause, mute and sign-in.

Add multiplayer

Host rooms and let players join by code.

Update a live game

Ship a new release while the published one keeps serving.