Export a Unity Web build that fits Prototir.

01 / Unity setup

This section changes with the platform selector. Shared packaging, publishing, page, and community guidance stays below it.

https://github.com/prototir/unity-sdk.git#v0.4.0

using Prototir;
using UnityEngine;

public sealed class PrototypeStart : MonoBehaviour
{
    void Start()
    {
        PrototirSdk.Ready();
        PrototirSdk.Event("scene_ready");
    }
}

Prototir hosts finished client files, not a source repository, editor project, or development server. Browser builds need an HTML entry and their runtime assets in a ZIP. Native builds need the executable and its runtime files, packaged for each supported platform and architecture. You can publish either format or both on one prototype page.

WebBuild/
|-- index.html
|-- prototir.json
|-- Build/
`-- TemplateData/

A root-level prototir.json lets the upload pipeline validate the correct runtime profile, entry, devices, permissions, thumbnail, and platform features. The Unity and Godot SDKs generate it during export; Web creators can write it directly.

{
  "entry": "index.html",
  "thumbnail": "auto",
  "devices": ["desktop", "mobile"],
  "orientation": "landscape",
  "runtime": {
    "engine": "unity",
    "engineVersion": "6000.0",
    "profile": "standard"
  },
  "permissions": [],
  "ai": { "mode": "disabled" }
}

Web, Unity, and Godot use APIs shaped for their runtime. Capabilities differ between browser and native builds. The selector above is currently showing Unity. Call Ready only after the first meaningful interaction is possible. For browser builds, preview generation does not wait for Ready. Native-only publications require a cover image.

using Prototir;
using UnityEngine;

public sealed class SessionStart : MonoBehaviour
{
    void Start()
    {
        PrototirSdk.Ready();
        PrototirSdk.Event("level_complete");
        PrototirSdk.Score(1200);
    }
}

await PrototirSdk.StorageSetAsync("difficulty", "hard");
var difficulty = await PrototirSdk.StorageGetAsync("difficulty");
await PrototirSdk.StorageRemoveAsync("difficulty");

try
{
    var answer = await PrototirSdk.AiGenerateAsync(new PrototirAiOptions
    {
        Prompt = "Give the player a short quest hook.",
        MaxTokens = 80
    });
}
catch (PrototirException error)
{
    Debug.LogWarning($"{error.Code}: {error.Message}");
}

A session is one play. Prototir counts it as real once it lasts at least three seconds and reports at least one event, and almost everything you care about is built on real sessions rather than on opens.

That threshold is also the reason a prototype can look unplayed while people are clearly playing it. A build that never calls Ready and never reports an event has no real sessions, so its analytics stay near zero and it has no real use to rank with. Browser comments require real play; native feedback from an approved device uses its pairing authorization.

Naming events

Names are lowercased and must be 1 to 64 characters of letters, numbers, _, -, . or :. Anything else is dropped rather than corrected, so Level Complete records nothing while level.complete records what you meant.

Pick names once and keep them. A name that changes between builds splits one behaviour across two rows and makes the before and after impossible to compare. Prototir keeps up to 50 distinct names per session; past that the events still count towards the total, but the per-name breakdown stops growing, which is what stops one runaway loop from becoming your entire analytics page.

What you get back

Your prototype's analytics shows each event by name with two numbers: how many sessions reached it, and how many times it fired in total. The two together are the useful part. A step reached by few sessions is a wall; a step fired many times within few sessions is a retry loop. Duration buckets sit beside them as a rough drop-off curve.

A prototype is one page with one set of comments, and it can be reached in more than one way: played in the browser, run as a native build on Windows, macOS or Linux, or both at once. Each of those is a build, they sit side by side, and none of them is the main one.

Exporting one

The Unity package adds Prototir > Export for Prototir (Native). It builds for whichever desktop platform is active, zips the result, and writes the build id beside it. It deliberately does not switch platform for you, because switching reimports the whole project; pick the target in File > Build Profiles first, and run the button once per platform you want to offer.

A zip, not a bare executable: an executable on its own leaves its data folder behind, which is the most common way a download arrives broken.

Pairing a build to a tester

A native build has no browser session, so it cannot know who is playing, and a sign-in inside an embedded browser is both refused by most providers and a bad idea anyway. Instead the build shows a short code and a QR, the tester approves it on prototir.com, and the build receives a token for that one prototype. They approve once per machine, not once per session, and they can revoke any build from their account settings.

Until that happens the build reports nothing and cannot send feedback, which is deliberate: there is nobody to attribute a play to. Draw the code however suits your game. The SDK hands you the code, the link and a ready-made QR and draws none of it, because it cannot know your art direction, your input model, or whether you are in VR.

You do not set the slug. It does not exist until the prototype does, so there was no value you could have put in the first export anyway. Prototir writes it into the .zip while you upload, and the build reads it on the machine it is downloaded to. Export once, upload once, done.

Set it by hand only when you need to override that: with Prototir > Create Settings for a build you ship outside Prototir, or an installer we cannot write into. The injected slug wins wherever both exist, because it travelled with that exact download.

Adding builds also changes how people find you. Discover asks two separate questions: what device someone is holding, and how they want a prototype to reach them. A build for Windows, macOS or Linux puts you in the second one, under How you play › Native, and again under the operating systems you actually ship. Drop a platform in a later release and you leave that filter, because it matches the build on offer now rather than one you used to have.

Managing builds after publishing

Everything lives under Studio › your prototype › Builds: one collapsible panel per platform, the browser build among them rather than above them. Add a platform you did not ship at first, replace one, or remove one, at any time. If a browser build remains, removing the last native build leaves a browser-only prototype. Native builds have independent versions; replacing a browser build does not remove them.

Because feedback knows which build it came from, the comments on a prototype page can be narrowed to one platform, and every comment says whether it came from the browser or from a particular build. A crash report from Windows v1.2 is a different fact from the same words typed in a browser, and the page no longer makes you guess which you are reading.

• Title: identify the idea, not its internal build number.
• Category: choose game, app, art, or showcase as the broad format.
• Prototype tags: add up to five descriptors for mechanics, audience, technology, or subject. Existing normalized tags are reused despite case, spacing, or underscore differences.
• Description: explain what to try, what is unfinished, intended device/input, and the question you need answered. Links open through Prototir's external-site warning.
• Feedback tags: these are separate from prototype tags. They structure what commenters observed, such as confusing, delightful, slow, or would-use.

Only publish files you own or are allowed to distribute. Keep third-party license and attribution files in each build. Browser source download and templates apply to the browser ZIP; compiled native builds do not provide an editable engine project. If you enable browser source download, choose a license that actually grants the permissions you intend.

Anything a browser renders is delivered to that browser. An authorized visitor can inspect network requests and save JavaScript, models, textures, audio, video, WebAssembly, and data. Private visibility prevents anonymous access, but it cannot stop an invited viewer from capturing files they are allowed to run. This is equally true for direct Web code, Unity WebAssembly, and Godot Web exports.

Rule of thumb: if disclosure would cause serious harm, do not include that file in a browser-delivered prototype. Use a reduced derivative, a watermark, or a server-side rendering approach instead.

1. 1. Build locally. Open the production web output through a local static server, not directly from the filesystem.
2. 2. Test the runtime. Check sandbox restrictions, externalize scripts, and remove undeclared network dependencies.
3. 3. Package the build. ZIP the web output with its HTML entry, relative assets, manifest, and license files. Check the size of each file against your plan limit.
4. 4. Complete the public page. Choose the publishing identity, category, tags, description, lineage, and rights confirmation.
5. 5. Set publication behavior. Review visibility, comments, tips, and release details. Browser builds also have source/template, embed, badge, and JavaScript protection settings. Native-only builds require an uploaded cover image.
6. 6. Verify after publishing. Prototir runs the browser candidate in the same opaque-origin sandbox and keeps it unlisted if startup throws an uncaught error. A failed Studio row opens a prefilled repair editor on the same prototype: it identifies the failed check with a stable diagnostic code, explains what to change, and lets you edit metadata, upload a replacement ZIP, or delete the prototype. New manifest values are shown as highlighted changes before the replacement is queued. Runtime-failing builds remain available to their owner and collaborators for testing while forced unlisted. After a build passes, try the player on supported devices and check permissions and analytics events.

Every build that uses the SDK gets a Feedback & tools control, with nothing for you to add: Screenshot, Comment, Console and Performance. Testers point at what they mean and send what they saw with their comment.

A screenshot, a console log or a performance summary is always sent with a message: it is what the comment is about, never a comment on its own. Recording costs almost nothing while the panels are closed.

// Add a PrototirReview component to your scene, then set Project Id.

Turning comments off for a prototype turns feedback off with it.