The Launcher and the web zip

There are two ways for a tester to get a pushed build. The Launcher is a small app that installs the build, keeps it up to date and hands it its identity. The web zip is a plain download for someone who won't install anything.

1. What a tester does in the Launcher

1. Enter a code. The tester types the invite code, or opens a mulnoplay://redeem?code=… link. The Launcher looks the code up first, without using it. A studio-facing "copy an invite link" button doesn't exist yet, so today the code is what you hand out.
2. Read the privacy notice and accept the NDA, if the studio set them. The studio's own privacy notice for its testers comes first, in its own step: the tester reads it and isn't asked to agree to it. Then the studio's NDA. Both are shown before the code is used and before anything downloads. When the tester goes on, the Launcher redeems the code, adds the game to the tester's list of games, and records which notice they were shown and their acceptance of the NDA. A tester who declines receives nothing, and the code stays unused.
3. Install. The build downloads in chunks, resumes after an interruption, and is checked before it is used: the release is signed, and every file and chunk is verified against its hash before it replaces anything.
4. Play. The Launcher starts the game and hands it its identity (project, branch, build and campaign) in a small mulno-build.json beside it, so every session is stamped with the build it came from. The code the tester already entered goes through a second one-time file, mulno-ticket.json, so the game doesn't ask for it again. The game's own consent screen still asks what may be recorded.
5. Update. When you move the branch to a new build, the same engine compares the new build with what is on disk and fetches only the chunks that changed. A notice that a new build is up isn't built yet.

The Launcher has no tester account. Its list of games is a file on the tester's PC, and Remove can also delete the game's files. Uploads stay the job of MulnoUploader.exe, a separate process that keeps going if the game crashes; the Launcher can resume a leftover session's upload.

2. What you set up

1. Push a build to a branch, and set the branch live.
2. In the web app, make a campaign on that branch (a branch's default campaign is named Share), give it your privacy notice for testers and, if it needs one, an NDA, and mint invite codes. Codes look like MULNO-4K7H-9QWZ-3R2M-84F2 and are shown once.
3. Hand each tester a code and the Launcher's installer from Download. Point them at the page for testers.

The broker checks the campaign every time it signs a download: a stopped campaign (the kill switch), a suspended studio or an expired window gets nothing, and a campaign with an NDA installs nothing without an acceptance. Testers never count as seats.

3. The web zip Soon

A zip is for a friend trying one build, or a teacher opening one student's game. It doesn't update itself, and it carries no Launcher. A push can make it, but no page or button hands it to a tester yet.

• It is made at push time, by mulno build push --branch qa --zip (an admin's push; see the options). The zip is deterministic. On an update push it is assembled inside the bucket from the previous zip, copying the parts that didn't change: when one DLL changed, 15.7 MB was uploaded instead of 128 MB.
• There is one zip per branch, and its hash is signed into the branch's release. Only that zip is ever handed out, never a stale object left at the same key.
• It is kept while the branch is live. By design it counts toward your Mulno Cloud storage while it exists, and in a Private bucket mulno build gc removes the zip of a branch that is no longer live.
• The download link is short-lived. The broker signs it for a tester who redeemed a code. The button that asks for it is what isn't built.