Build something people can actually try.

01 / Prototype

What Prototir runs

A prototype is a client-side web experience that opens inside a contained player. It can be a game, tool, app concept, interactive artwork, product flow, simulation, or any other idea that benefits from being used instead of merely described.

02 / Bundle

Package a browser-ready ZIP

Upload the built files a browser needs, not your source repository or development server. Put index.html at the ZIP root, or declare another HTML entry in a root-level prototir.json. Use relative paths so every asset stays inside the bundle.

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

03 / Manifest

Describe runtime needs explicitly

The optional root-level manifest lets the upload pipeline validate and prepare the prototype. Form values remain authoritative; a manifest description and tags are used as fallbacks when the form leaves them empty.

{
  "description": "A short explanation for people trying the prototype.",
  "tags": ["Physics", "Co-op"],
  "entry": "index.html",
  "thumbnail": "auto",
  "modules": ["three@0.170.0", "prefab-input@0.2.0"],
  "permissions": [],
  "devices": "both",
  "orientation": "landscape",
  "ai": { "mode": "disabled" }
}

Browse exact versions, requirements, sizes, and availability in the module catalog.

04 / SDK

Tell the shell what happened

Load the SDK before your external application file. Call ready() only after the first meaningful interaction is possible. That signal begins measurement of a real session. Preview generation does not wait for ready(), so a cutscene should call it only when control reaches the visitor; choose a bundled thumbnail when the public image should show a later scene.

<script src="https://cdn.prototir.com/sdk/v0.0.1/prototir.js"></script>
<script type="module" src="./app.js"></script>

// Call this when the prototype is visible and interactive.
Prototir.ready();

// Record meaningful milestones for creator analytics.
Prototir.event('onboarding_complete', { route: 'guided' });

// Optional: update a challenge-compatible score.
Prototir.score(1200);

// Storage is scoped to this prototype in this browser.
await Prototir.storage.set('difficulty', 'hard');

// Reproducible randomness for fair runs and daily variations.
const random = Prototir.rng('daily-2026-07-23');

// Enable with: "ai": { "mode": "managed" } in prototir.json.
// Calls are stateless, so include any conversation history you need.
const answer = await Prototir.ai.generate({
  prompt: 'Reply as a concise museum guide: What is chiaroscuro?',
  maxTokens: 160
});

05 / Quality

Design for an unfamiliar visitor

06 / Page setup

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.

07 / Source

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.

08 / 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.

09 / Events

Use a jam or challenge for a focused question