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="https://cdn.prototir.com/sdk/v0.2.0/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;
}

02 / Start

Export first, then package the browser-ready result

Prototir hosts finished client files, not a source repository, editor project, or development server. Every build path ends with a ZIP whose root contains an HTML entry and all files required at runtime.

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

03 / Build

Describe the export and its device needs

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.

04 / Build

Tell the shell what happened

Web, Unity, and Godot expose the same platform capabilities through APIs shaped for their runtime. The selector above is currently showing Web. Call Ready only after the first meaningful interaction is possible. Preview generation does not wait for this signal, so a cutscene should report readiness only when control reaches the visitor.

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);
}

Web only / Curated modules

Reuse browser dependencies without rebundling them

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.

05 / Build

Sessions, events, and scores

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, visitors cannot leave feedback on it, and it has nothing to rank with.

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.

06 / Build

Ship a build people run

Not everything belongs in a browser. A prototype can offer downloadable builds for Windows, macOS, and Linux, either on its own or beside a playable web version.

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 › Download, 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.

Already published? Adding a build later keeps what you have: the page shows the player with your downloads beside it, and removing the last build turns it back into a web prototype. Nothing here is a one-way door.

07 / Publish

Design for an unfamiliar visitor

08 / Publish

Help the right people understand it

• 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.

09 / Publish

Make reuse traceable

Only publish files you own or are allowed to distribute. Keep third-party license and attribution files in the bundle. If you enable source download, choose a license that actually grants the permissions you intend.

10 / Publish

Protect the master, publish the runtime copy

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.

11 / Publish

Run the release checklist

1. 1. Build locally. Open the production output through a local static server, not directly from the filesystem.
2. 2. Test the sandbox assumptions. Remove arbitrary network dependencies, externalize scripts, and test without hidden environment variables.
3. 3. ZIP the output contents. Check the archive root, compressed size, entry file, relative assets, manifest, and license files.
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, source downloads/templates, embed access and domains, badge visibility, build protection, and optional release details before submitting.
6. 6. Verify after processing. Prototir runs the 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 desktop and mobile and check permissions and analytics events.

12 / Grow

Let testers point at what they mean

Turn on screenshot feedback and a tester can capture the moment, drop a pin on it and write a comment without leaving your prototype. It works the same whether they are playing here, on your own site, or in a downloaded build.

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

Turning comments off for a prototype turns feedback off with it. In embeds the Prototir badge stays visible while feedback is on, because testers use it to reach the menu.

13 / Grow

Show work together

A collection is a curated page that gathers prototypes under your own identity: a course showcase, a studio portfolio, a festival selection. It has no deadline and no winner, unlike a jam. You choose what belongs, in what order, with a note on each.

Create one from Dashboard › Collections. It lives at /c/your-collection.

14 / Grow

Use a jam or challenge for a focused question