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?path=/

using Prototir;
using UnityEngine;

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

02 / Shared contract

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.

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

03 / Manifest

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": "landscape",
  "runtime": {
    "engine": "unity",
    "engineVersion": "6000.0",
    "profile": "standard"
  },
  "permissions": [],
  "ai": { "mode": "disabled" }
}

04 / SDK

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

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

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 / Protection

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.

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

10 / Events

Use a jam or challenge for a focused question