Skip to main content
OpenGame accepts static browser exports that pass its upload and runtime checks. Choose an engine with a web target, then follow its export guide. Three.js, Phaser, React and JavaScript have runnable starters with the SDK included. The table below records past uploads. Bevy’s starter contains export notes and an opengame.json; bring your own Bevy project. PixiJS has a separate rendering result from a corrected starter.

​
Engine status

A small test game for each of these engines was uploaded with the CLI on 22 Oct 2026. Each upload reached Ready after the server checks. That status makes a release available for private preview; it does not record whether the game rendered or its services worked. Detected as is the server’s engine result for that upload; where that differs from the engine, the engine’s guide explains why. Versions are the ones the server read, and it read none for React, JavaScript and Bevy. Each starter is a folder under templates/ in the OpenGame repository to begin your own game from. PixiJS’s first test build did not play. PixiJS 8 needed import "pixi.js/unsafe-eval" before the app started, because OpenGame did not allow eval then, and that build lacked it, so it showed a blank frame. New releases run on contract 2027-03, which allows eval. templates/pixijs now has the import, and a build of it drew in a private preview on 23 Oct 2026 with no CSP violations. These are upload results. Rendering, review, Firefox and Safari, the public page and platform services need separate evidence under what tested means; no engine has a complete acceptance result yet.
Each engine links to its guide. Recognised says whether opengame check names the engine from the export’s files. “From source” means the signature was taken from the engine’s runtime source and has not yet been matched on a real export. “As Rust” means the export is identified by the runtime it ships, so a Bevy game reads as a Rust one. Emscripten is recognised only from a threaded build’s runtime, so a single-threaded C, C++ or raylib export reads as custom. The ID is what opengame init . --engine <id> takes.
KAPLAY also reached Ready on 22 Oct 2026, with the server identifying that sample as Custom. The preview process for that day’s uploads lacked its session configuration, so those uploads have no rendering result. On 23 Oct, a separate PixiJS starter build drew in a private preview with no page errors or CSP violations. That confirms rendering for that build; its SDK services still need testing.

​
Upload eligibility

An engine name is not required for hosting. An unrecognised export is checked as Custom. Package a browser build with index.html and its companion files, or use the raw SWF and js-dos workflow. Desktop executables and editor projects need a web build first. New releases use contract 2027-03, which permits HTTPS resources, HTTPS and WSS connections, and eval. A scan that detects threads selects 2027-04, adding cross-origin isolation and the page SDK. Threads and WebGPU covers the browser requirements. Each game still runs on its own origin inside the sandbox. Unencrypted engine containers that the scanner cannot fully decode can proceed to manual review. The reviewer must acknowledge the files listed as not inspected before approving the release. Encrypted containers, invalid archives, credentials and other failed checks can stop the upload. Read the export workflow for the result codes. Upload eligibility does not establish SDK, multiplayer or browser compatibility. A jam can also accept fewer engines than the platform hosts.

​
What tested means

A tested integration needs evidence for a named engine version and export variant through the creator’s full workflow:
  1. opengame check reports the expected engine or runtime and finds no unexpected failures.
  2. The game renders and takes input in Chrome, Firefox and Safari under the game page’s security policy, with required assets loading and no unexplained console errors.
  3. The upload passes the server’s scan and the automated play test.
  4. The private preview, the review copy and the public page serve the same files.
  5. With the SDK, sign-in, a score, an event, a link, fullscreen and, where the engine supports them, two-player rooms work on the live site. Test sign-in on a published game; private previews return unavailable for it.
  6. Somebody uploads it through the website and plays it on the public page.
  7. OpenGame’s own code for that engine gets an independent review.
Record detection, export build, hosting, services and native multiplayer separately. A pass applies to the tested variant. Threaded builds, WebGPU and native multiplayer adapters each need their own test. Published games keep their pinned runtime contract.

​
Choose an engine

A language guide covers a game written straight against the browser in that language. It cannot add a browser target or an interop path to an engine that has neither. Unreal is not part of this release: there is no guide for it, and OpenGame does not recognise its exports.

​
Build your game

Licensed editors need a valid licence and their web export module installed. OpenGame does not supply editors, licences or compiled games. Runtime-based targets such as js-dos, Ruffle and Pyodide need the real runtime and your game’s files. Each engine guide with a web export ends with the same steps: opengame init . --engine <id>, then opengame dev, opengame check, opengame deploy and opengame submit. Stride and MonoGame have no web export, so their guides cover porting the game to an engine that has one, such as KNI. These pages cover what the guides share:

Export, check and preview

Choose an export, read failures and vendor runtime files.

Services from any engine

Sign-in, scores, events and rooms, and how to turn the SDK off.

SDK packages

Install the package for your engine and keep its files together.

Threads and WebGPU

What a threaded or WebGPU export needs from the page.

Memory and runtime diagnostics

Tell download size, wasm memory, browser heap and renderer failures apart.

Runtimes and contracts

Runtime contracts and platform runtimes.