Skip to main content
Most exports need nothing on this page. Read it when you meet opengame dev --contract, when your export selects a platform runtime such as js-dos, Ruffle or Pyodide, or when you vendor a runtime.

​
Try a runtime contract

Every release is served under a runtime contract, and you don’t choose it. A new release starts on 2027-03. It lets the game call any https: or wss: host, load scripts, stylesheets, fonts and media from any https: host, and use eval, and it adds no SDK. When OpenGame’s scan sees threads in the build, it moves the release onto 2027-04 before anybody previews it. 2027-04 is 2027-03 plus cross-origin isolation, and it adds the SDK at /_og/sdk.js to every HTML document. Threads and WebGPU covers isolation, and what a running game may reach covers the network rules. A release keeps the contract it was frozen with. Releases made before 26 October 2026 stay on 2026-11, or 2027-02 if they use threads. Those two let a game reach only OpenGame’s own hosts and don’t allow eval. To give an older game the open network, deploy a new release. 2027-01 adds isolation, eval and the SDK. It is deprecated, and no new release is served under it. opengame dev uses 2027-03 unless you name another contract. The CLI includes 2026-10, 2026-11, 2027-01, 2027-02, 2027-03 and 2027-04. To try isolation, run:
This sends the isolation headers and adds the SDK, as the live site does for a threaded build. --contract 2027-01 adds the host runtime and the packaged global SDK locally too, unless you turn SDK injection off. A game that works under either locally shows that the game and the SDK agree. It does not show that the hosted game will get the SDK, because only a build that uses threads gets it.

​
Platform runtimes

When the export selects a platform runtime, opengame dev and opengame vendor read the CLI’s packaged catalog and shell templates, then download the pinned runtime archive and verify its hashes, so they can need network access even for a local preview. When the manifest declares runtimes, opengame check and opengame deploy only confirm that the selection matches the catalog, and print a runtime_acquisition_deferred notice; add --vendor to have them download and verify it too. A raw payload with no runtimes field gets no such notice. Under the current contract OpenGame adds no runtime on its side, so deploy with --vendor and the upload carries the runtime it needs. If the catalog is incomplete, source-distribution evidence is missing or the archive check fails, fix that before you preview. A game may load a runtime from a CDN, but a CDN copy can change under you, so it is not a substitute for the pinned one. The optional runtimes manifest field is an array of objects with id, version and, for shells that take them, options. Each runtime can appear once. Use the exact version pinned in your CLI’s runtime catalog. Any other version, or an alias such as latest, fails validation. The catalog ships inside the CLI package. With the CLI installed globally, as the Quickstart does, this prints each runtime ID and the version pinned for it:
Put the version it prints for your runtime in the manifest:
opengame.json
These are the options each runtime accepts, all optional.
  • jsdos
    • autoStart: true or false
    • renderBackend: webgl or canvas
    • renderAspect: AsIs, 1/1, 5/4, 4/3, 16/10, 16/9 or Fit
    • imageRendering: pixelated or smooth
  • ruffle
    • letterbox: off, fullscreen or on
    • autoplay: off or on
  • pyodide, wasmoon and flutter-canvaskit take no options. You choose the version only.
For a raw SWF or .jsdos upload, the CLI picks the matching pinned runtime from what its parser finds, even when this field is absent. Manifest options configure the shell the CLI derives. They cannot turn on network access, Ruffle script access or a cloud service. Selecting a runtime explicitly also stores its files on the game origin for a complete HTML export. When the CLI stages them, it rewrites only the references it recognises, so read its packaging receipt and play through anything that loads late.

​
Payload-only exports

SWF and .jsdos packages that the parser validates are the only exports accepted without an index.html. The folder must contain a single such file and no index.html at any depth, with complete raw-runtime evidence and approved runtime artifacts. A renamed file or an arbitrary ZIP does not qualify. When it does qualify, the check prints a raw-runtime-shell note in place of the missing-entry failure. Deploy it with opengame deploy . --vendor, which writes the pinned runtime and a page into the upload; without --vendor the upload has no page and the server refuses it. Read the Ruffle or js-dos guide first. Each explains how a raw payload differs from a custom integration.

​
Redistribution and notices

Runtime versions, companion files, notices and required source-distribution receipts come from the approved catalog. Vendoring records which bytes were packaged, with their hashes and licence notices. A hash records bytes. It does not grant a licence to redistribute them, so keep any separate permission your game needs. Vendoring also cannot tell whether an engine downloaded every optional decoder, which is why the export workflow asks you to play through every feature that loads one.