Ship a native Unreal build people download and run.

01 / Unreal Engine setup

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

1. Download Prototir-0.1.0.zip from the v0.1.0 release.
2. Unzip it into the project's Plugins folder (Plugins/Prototir).
3. Enable Prototir in Edit > Plugins and restart the editor.

// The same from C++: add "Prototir" to your module's dependencies.
#include "PrototirSubsystem.h"

if (UPrototirSubsystem* Prototir = UPrototirSubsystem::Get(this))
{
    Prototir->Ready();
    Prototir->Event(TEXT("first_action"));
    if (!Prototir->IsPaired()) Prototir->ShowPairingScreen();
}

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.

MyGame-windows/
|-- MyGame.exe
|-- prototir-build.json
|-- Engine/
`-- MyGame/
    |-- Binaries/Win64/MyGame.exe
    `-- Content/Paks/

Native builds do not use an HTML entry, browser permissions, or a web manifest. In Builds, choose the platform, architecture, version, minimum OS, and installation notes. The SDK export command writes a build identifier; Prototir adds the prototype slug to uploaded ZIPs. Set the slug in the SDK yourself for an installer or disk image.

// Native builds do not need an HTML entry or a web prototir.json.
// Publish to Prototir writes prototir-build.json with the build ID.
// Prototir adds prototir-prototype.json with the slug to uploaded ZIPs.
// Choose platform, architecture, version and requirements in Builds.
// Packaged by hand? ZIP the whole Windows folder, not just the .exe.

Native builds report Ready, events, scores, sessions, and feedback after device pairing, and show Feedback & tools to testers by themselves. SDK storage stays in memory and managed AI is not connected.

Web, Unity, and Godot use APIs shaped for their runtime. Capabilities differ between browser and native builds. The selector above is currently showing Unreal Engine. 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.

// Blueprint nodes: Prototir Ready, Prototir Event, Prototir Score.
// After the tester approves the pairing code:
Prototir->Ready();
Prototir->Event(TEXT("first_action"));
Prototir->Score(1200);
Prototir->FlushSession();
Prototir->SendFeedback(TEXT("The first interaction was clear."));

// The Unreal plugin has no Prototir storage.
// Use your game's own SaveGame objects.

// Managed AI is not available in the Unreal plugin.

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 Unreal plugin adds Tools > Prototir > Publish to Prototir. It packages the project for the machine you are on with Unreal's own packaging, writes the build id into it, zips it, uploads it and opens the website with the build waiting. Development packaging is the default because Shipping removes the log the Console tool shows; choose in Project Settings > Plugins > Prototir.

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: in Project Settings > Plugins > Prototir 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. Export a release for each supported platform and architecture. Run it on a clean machine without the editor installed.
2. 2. Test the runtime. Verify installation, OS requirements, pairing approval, Ready, events, session reporting, and Feedback & tools.
3. 3. Package the build. Keep the executable and its runtime data together in a native ZIP or supported installer, with license notices and the correct SDK settings. 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. Download the uploaded file from the prototype page and run it on each advertised platform. Confirm the pairing points to the right prototype and build, then check that real use reaches analytics. Prototir hosts native files; it does not execute or scan them.

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.

// Or untick Feedback Tools in Project Settings > Plugins > Prototir.
Prototir->SetFeedbackToolsVisible(false);
Prototir->ShowFeedbackScreen();           // the same comment screen, from your own button
FString Log = Prototir->GetConsoleText(); // what the Console tool records

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