Builds and Versions

What a build is#

A build is a snapshot of your game that the editor packages and uploads to the platform. It is the unit everything else in publishing works with: you push builds from the editor, test them, and then promote one to become the version players download.

Every build is made of three artifacts, plus a small manifest:

Each build also records a build number (auto-incremented per game, shown as #7), the build name you typed in the editor, the upload timestamp and the download size. The SHA-256 of every artifact is computed in the editor before upload and verified by the platform before the build is accepted, so a corrupted transfer can never become a playable build.

Where builds show up#

• Editor — the Publish / Update popup (top-right button) lists Build History with number, name, version label, date and status.
• Dashboard, game page — the Update tab lists every build for that game and is where you deploy them. The History tab shows only builds that have been live.
• Dashboard, Builds page — /dashboard/builds merges builds across all your games with game and status filters.

Build statuses#

The platform tracks each build with one of these statuses. The dashboard shows them as badges; the editor shows them in upper case in Build History.

Only ready and archived builds can be deleted. A build that is live, on beta, or still uploading refuses deletion.

Game states#

A game has its own lifecycle, separate from its builds:

The first promotion moves a game from development to live. That first promotion happens through the Launch wizard, which also picks hosting; see Launch and Hosting.

Versions and patches#

A version is what a build becomes when it is promoted. The platform numbers versions for you; you only choose how a build is released:

Numbering rules, as the platform applies them:

• The very first promotion of any kind is v1.
• An update always increments the major version and clears the patch number (v2.3 → v3).
• A patch increments the patch number of the current major (v3 → v3.1). If the game is somehow at major 0, a patch also produces v1.
• A rollback re-deploys an earlier build's content but does not create a new version label. The history shows the old label as live again.

The dashboard previews the next label before you push (for example Push hotfix · v3.1 or Push update · v4), but the platform is the source of truth and assigns the label when the deploy runs.

Update posts#

When you promote a build as an update you can attach an update post — a title (up to 120 characters) and Markdown release notes. Posts are listed newest-first on the game's public page under the game description, and on the dashboard's Update tab under Update posts, where each can be edited later.

You can also write a post ahead of time and Save as draft (don't push yet). Drafts stay unlisted until you attach one to a push, at which point it is stamped with that build and version and becomes public. Drafts can be deleted from the same list.

Patches do not create update posts. Their optional note is stored on the build.

Incremental bundles (opt-in)#

By default every push produces one monolithic game.pck and uploads all of it. For a large project that means re-uploading hundreds of megabytes to change one map.

The Incremental (bundles) checkbox in the editor's New Build card switches the push to content-addressed bundles:

• The export is split into a small core bundle (data, interfaces, game config, asset library) plus one bundle per map, per model folder, per animation base folder, per terrain texture set, and per remaining asset folder.
• Each bundle is cached under <project>/.packcache/ and keyed by a hash of its source files. Unchanged bundles are not repacked.
• Before uploading, the editor asks the platform which bundle hashes it already has and uploads only the missing ones, four at a time. Identical content is stored once per game and shared across builds.
• Retrying a failed first upload resumes where it left off, because bundles that already landed are skipped.

The dashboard shows a bundle build's total download size (core plus all bundles), not just the core file. On the player side, a bundle-capable client downloads only bundles whose hash changed since the last version and can stream maps, animations and textures on demand instead of downloading everything up front.

The .packcache/ folder lives at the project root, is excluded from project zips and exports, and is safe to delete — the next incremental push simply repacks everything.

With AI (MCP)#

An assistant can run the same pipeline without the editor open: export_pck produces the client PCK (through a live editor or headless), build_server_package produces server_data.zip, create_build reserves a build and returns upload URLs, upload_build_artifacts or upload_pck_multipart transfer the files, and finalize_build submits sizes and hashes for verification. list_builds returns a game's builds newest-first (with include_deleted for restorable ones), and get_live_status reports what is currently deployed.