The store page

Everything a player sees about your game is edited under your organisation → Games → the game. Nothing here needs approval to write; approval gates what the public sees and whether the game can be bought.

The words and the pictures

Store page: the name (changeable here), a sentence for the shelf (≤ 200 characters), a site, up to five lines of news (≤ 60 each, newest first — the client shows them on the machine), the platforms, up to eight tags, and the long description (Markdown-free plain text, ≤ 6,000). The icon is a square picture — PNG or JPEG under 1.5 MB, 256×256 or bigger, shown small everywhere (an SVG cell grid of ≤ 4 KB does too); the capsule and up to eight screenshots are PNGs of ≤ 1.5 MB each. The emulator's own screenshots are the honest ones.

Builds and channels

Builds takes a version: the machine it is for (one of the fleet, or every machine), a name (V1.2.0, letters, digits, dots and dashes, ≤ 24 — unique to that machine, so the X16's V1.2.0 and the Neo6502's can share it), notes, and one file — the zip a player unpacks onto the card, ≤ 16 MB, kept for ever. Put the PRG and its bank files at the top of the zip, no folder, named as the card holds them (SNAKE.PRG, SNAKE.B01); the client opens the zip on the service and pulls a file at a time onto the card, so what you zip is what lands. Each version gets a SHA-256 and a CRC-32.

Each machine has its own release channel, for the people who own the game, and its own beta, for your testers and admins: point them at that machine's versions, move either to roll back, clear one to point at nothing. A build for every machine has its own pair too, and a machine with no channel of its own takes those — one zip for the fleet, or a zip a machine, or both. The client's Library hands each machine its own (HELLO says which), and the web's DOWNLOAD is direct when there is one build to have, a picker by machine when there are more.

Piracy mitigation: every download stamped, and revocable

Every download of your game — the web's DOWNLOAD, the client's pull — is stamped: a 32-byte tag naming that download is written into the build's marker, a 48-byte block (RPWM, 32 zero bytes, 12 spare) the build reserves in its PRG (R* supplies it as one linker line; your build does nothing else). The tag is invisible in play. It buys two things and is honest about a third:

• Attribution. A copy that turns up where it shouldn't names who downloaded it, when, by which door and from which address — the Piracy mitigation section under your game lists every download, and the service's admins can look a leaked file up.
• Revocation. REVOKE a copy, or ALL OF THEIRS, and once the build says its tag on HELLO that copy cannot connect to the network. Which copies may connect is a policy you set on the Piracy mitigation section: open (any copy — a build without the marker, a dev build; the default), tagged (a copy we issued and have not revoked), bound (the copy was issued to the account logging in — a closed beta's rule). A build made without --live-key says the dev tag, which your admins and testers may connect with whatever the policy. The refusal is at AUTH, with the reason, so a tester with a dead copy hears it rather than hunting a bug. The list shows how many addresses each copy has connected from, and the service's admins can see which. It still plays offline — nothing here is required to play, and that stays true.
• Not copy protection. A determined cracker can find and blank the tag; a tester who forwards a zip to a mate cannot. Every revoke costs a leaker a fresh legitimate download, which is the economics that matter.

Testers, visibility, approval

Testers are gamertags who may see and download a beta game. Visibility is hidden (your admins alone), beta (testers and admins) or public (everyone). A game in beta is invisible to everyone else — SELECT and the pages answer 404, not 403, so its existence is not confirmed.

Approval is the service's: the organisation first (a developer's own waits; chapter 1), then the game. An unapproved game is refused at HELLO. Once approved and public, it is on the shelf and in the client's list.

For sale, or free

On the Store page set the status: in development, beta, free, or for sale with a currency and either one price for every machine or a price a machine — an amount against each machine the game runs on, a machine left empty not for sale there. The shelf then says from the lowest; the buy box offers a machine a line, and what the player buys is that machine's copy. A free game has GET IT, which puts it in the player's library. A game for sale is sold through Retro Play as reseller, and Paddle is the checkout. The service keeps the catalogue — a product a game, a price a machine when priced that way — or you give the price ids yourself; BUY opens Paddle's overlay on the machine's price, the webhook grants the player the game on that machine, a refund takes that copy back. docs/paddle.md.

Ownership is an entitlement, and it is a machine's or every machine's: a purchase is the machine bought; a gift and a free game are every machine's. The player's library on the site says which machines, the buy box says you own this on X16 and offers the others, the download picker lists the machines owned, and LIBRARY on the wire hands a machine its build only when the account owns the game there (or everywhere). A refund takes back the machine bought and no other. Your Payments tab shows each month's sales, the cut, the processing and what is owed; PAID with a date once the transfer has gone.

← Awards and the daily As the players see it →