Submitting a game

A game reaches players in three steps: you publish the plugin package to npm, submit it to the platform from the lobby, and a moderator approves it. After approval the game appears in the lobby catalog and rooms can be created on it.

Requirements

• The package is public in npm. The platform downloads it from the registry without authentication. A scoped name (@you/my-game) needs npm publish --access public on the first publish.
• files: ["dist"]. Only dist/ is published and read; the rest of the repository never reaches the platform. dist/manifest.json is generated by the build (packaging.md).
• A green vimp-contract on the built package (debugging.md).
• The game id is manifest.id: lowercase Latin letters, digits and hyphens, starting with a letter, 2–31 characters. It is unique on the platform; mine, submit, manifest and lookup are reserved.
• The version is a plain semver triple (1.4.0, optionally with a pre-release suffix) and manifest.version must be a non-empty string.
• One account may submit up to 20 games.

The platform checks dist/ structurally and never executes the plugin: manifest.json is present and is an object; engineApi is an integer; title and version are non-empty strings; assetsBase ends with /; the client, host and wasm entries are declared and the files exist inside dist/ (so does wasmNode, if declared, as a relative path); maps.list is a non-empty list and every dist/maps/<name>.json exists; every roomForm field has a value in roomDefaults (or reads its values from the maps). A game whose requires names a capability the engine does not know is accepted but shown as unavailable, see overview.md.

Publish the package

npm run core:build        # the Wasm core (web and node targets)
npm run build             # both bundles, dist/manifest.json, assets
npm run check:contract
npm publish --access public

Bump the version in package.json for every release: npm never accepts the same version twice, and the platform identifies a submission by package name and version.

Submit

1. Sign in to the lobby, open the user badge and choose My games.
2. Enter the npm package name and, optionally, a version (empty means the latest); press Load. The form shows a preview read from the package: id, title and project link.
3. Press Submit for review.

The platform downloads the package and runs the check above before it records the submission. A broken package is refused with the full list of problems instead of entering the queue; fix them, publish a new version and submit again.

Moderation

A submission is pending until a moderator decides; the decision is approved, rejected or, for a game that is already live, disabled. A moderator may leave a note: it is shown on the game's card in My games. A moderator can open a hidden test room on the submitted version before approving it. An approved game reaches the lobby catalog within about a minute.

Updating

Press Update version on the game's card and enter the new version. It goes through the same check and the same moderation; while it is pending, players keep playing the approved version. Submitting a new version clears the previous note and lifts a rejection.

The project link

The lobby shows a link to the game's project next to its version. It is the package's homepage, and only when that is absent, its repository. The scaffolder's --repository flag writes both (scaffolding.md).

Removing a game

The author deletes a game from My games unless it is approved (a moderator disables it first). Removal is soft: the game disappears from the lobby at once, and its profile data (ratings, states) is erased for good after 30 days; until then a moderator can restore it. The id and the package name stay taken during those 30 days.

---

← Previous: Pitfalls and invariants · Back to the SDK index →