Build and publish a browser-native prototype.

01 / Web setup

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

<script src="/prototir.js"></script>
<script type="module" src="./app.js"></script>

Prototir.ready();
Prototir.event('scene_ready');

const canvas = document.querySelector('canvas');

canvas.addEventListener('click', () => canvas.requestPointerLock());

document.addEventListener('pointerlockchange', () => {
  const locked = document.pointerLockElement === canvas;
  game.setPaused(!locked);
});

// Escape releases pointer lock and restores the cursor automatically.

.game-surface,
.game-surface * {
  user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
  -webkit-tap-highlight-color: transparent;
}

.game-surface {
  touch-action: none;
}

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.

my-prototype/
|-- index.html
|-- app.js
|-- styles.css
|-- assets/
|   `-- cover.webp
`-- prototir.json

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": "any",
  "runtime": { "engine": "web", "profile": "standard" },
  "modules": ["three@0.170.0"],
  "permissions": [],
  "ai": { "mode": "disabled" }
}

The curated Web module catalog appears below the SDK section on this page.

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

Prototir.ready();
Prototir.event('level_complete', { level: 2 });
Prototir.score(1200);

const random = Prototir.rng('daily-2026-08-24');

await Prototir.storage.set('difficulty', 'hard');
const difficulty = await Prototir.storage.get('difficulty');
await Prototir.storage.remove('difficulty');

try {
  const answer = await Prototir.ai.generate({
    prompt: 'Give the player a short quest hook.',
    maxTokens: 80
  });
} catch (error) {
  console.warn(error.code, error.message);
}

Add exact name@version specs to prototir.json. Prototir validates them, injects the import map, and serves shared files from its CDN. Unity packages and Godot addons belong in their engine projects instead.

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.

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.

Prototir.review.enable({ project: 'my-prototype' });

Prototir.review.enable({ tools: { console: false, performance: false } });

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