Game Capability Matrix

This page states what Toilet Paper Games supports today. A browser being able to render something does not mean the platform can network, authorize, persist, or scale it. Read every category across all five dimensions before choosing an architecture.

Status meanings:

Supported: covered by the normal release gates within the published budgets in this document.
Experimental: usable for prototypes, but missing at least one production guarantee or full transport/browser acceptance lane.
Planned: tracked work exists; authors should not build against it yet.
Unsupported: outside the current platform contract.

Passive TV rendering

Capability	Status	Current contract
Browser host-display iframe	Supported	Executes a reviewed game surface inside the shell sandbox.
Portable display renderer v1	Experimental	Strict 64 KiB scene documents with text, image, stack, scoreboard, participant-list, timer, basic motion, and audio primitives. Counter is the deterministic validation game.
Chromecast receiver	Experimental	Uses the browser host-display path and shared passive-display admission/reconnect protocol.
Android TV, tvOS, and Roku native renderer clients	Planned	Consume the portable v1 JSON Schema; platform client work is tracked by #660, #662, and #663.
Arbitrary uploaded HTML or JavaScript on native TV clients	Unsupported	Native clients render the portable contract only.

Portable renderer limits, capability identifiers, local commands, and version policy are documented in portable-display-renderer.md. Catalog negotiation and launch rejection remain tracked by #664.

The budgets are ceilings, not targets. Batch drawing points, coalesce noisy controller input, and keep canonical snapshots under 16 KiB when practical. TPG exposes reliable ordered messaging plus an emulated latest-value lane that coalesces queued channel values and drops stale sequence numbers. The deployed WebSocket path remains reliable underneath, so this is not native packet-loss delivery and does not provide competitive real-time netcode. Durable sessions use a separate experimental HTTP authority path; they do not turn live room transports into offline storage.

Real-time delivery contract

Game code can inspect runtime.room().transport without knowing whether the room uses WebSocket, BroadcastChannel, or another backend. The profile reports reliable-ordered support, whether latest-value delivery is native, emulated, or unavailable, the binary payload mode, the payload ceiling, and reconnect support.

Use latest-value delivery only for facts where a newer value makes an older one useless, such as movement, aim, or pointer previews:

await runtime.broadcast(
  "player.movement",
  { x, y },
  { mode: "latest-value", channel: `movement:${playerId}` }
);

Messages on one latest-value channel receive increasing sequence numbers. Queued values on that channel are coalesced and receivers discard duplicates or reordered stale values. Lifecycle, room authority, canonical snapshots, and any message without an explicit delivery option remain reliable ordered.

The WebSocket adapter enforces a 64 KiB transport ceiling, 120 outbound messages per second per connection, a 128-message/512 KiB pre-open queue, and a 4 MiB server buffered-send ceiling. These are hard safety limits, not the supported gameplay budget below. Exceeding a client limit emits a backpressure room event; server abuse closes the connection. ArrayBuffer and standard typed-array values are preserved recursively through a base64 JSON fallback. The negotiated payload profile reports base64 so games do not mistake this for a native binary frame.

@tpg/net-core also provides ReplicationSender and ReplicationReceiver. Frames carry explicit revisions; periodic keyframes recover delta streams, stale frames are ignored, revision gaps request a new keyframe, and reconnect resets receiver state. Public simulation and presentation helpers build on that transport foundation as described below.

Casual real-time simulation envelope

@tpgames/sdk and the normal game-kit entrypoint now export:

FixedStepSimulation with explicit tick/revision identifiers and retained, observable catch-up backlog;
ClockOffsetEstimator for timer and input timestamp alignment;
SequencedInputBuffer for bounded reorder buffering and contiguous acknowledgements;
interpolateSnapshot, lerp, and reconcilePredictedState for remote rendering and optional client-side prediction replay; and
DeterministicFaultLink for seeded latency, jitter, loss, reordering, disconnect, and reconnect tests.

The measured reference is Tank Arena at 20 authoritative ticks/second, at most eight catch-up steps per callback, 64 pending inputs per participant, and a small room within the transport budget. Its deterministic test uses 80 ± 25 ms one-way latency with 25% delayed reordering, while browser coverage applies 80 ms controller latency over the real WebSocket path and requires six sequenced move/fire inputs to be acknowledged and visible within five seconds.

Prediction is a presentation technique, never authority: replace the client base with each authoritative snapshot, discard acknowledged inputs, replay the remainder, smooth small visual corrections, and snap large or safety-critical corrections. Scores, hits, authority, and persistence must use canonical host state. These helpers do not promise rollback fighting games, competitive FPS netcode, packet-loss tolerance, or audio-grade rhythm synchronization.

Experimental asynchronous session envelope

The Async Relay reference is the first server-authoritative flow that does not require a browser host to remain online. It uses participant-specific bearer resume credentials, explicit expected revisions, bounded canonical JSON, scheduled turn deadlines, schema migration, and expiry. Local Bun development keeps the same HTTP contract in memory; deployed signaling uses one AsyncSessionDurableObject per session so canonical state and alarms survive browser disconnects and Worker restarts.

The current measured policy is 2–8 participants, 64 KiB canonical state, 2 KiB turn commands, 128 retained relay entries, 24-hour turn deadlines, 30-day absolute retention, and 7-day idle expiry. See durable-asynchronous-sessions.md for the record model, API, ownership rules, and non-goals. This is an experimental platform reference, not yet a public arbitrary creator-defined persistence API, notification service, blob store, persistent-world contract, or large-session backend.

Reviewed browser-frame policy

Game-frame capability policy starts with sandbox="allow-scripts". The shell then applies a source-aware origin policy: inline built-in documents keep an opaque origin and receive bridge messages through the required wildcard target, while their inbound messages must report origin null. Inline frames expose at most the shell origin as their referrer so the runtime can authenticate parent bridge messages without exposing the room URL. Browsers that omit referrers for opaque documents authenticate the exact parent window instead. Hosted published, private, and development documents receive allow-same-origin only after an absolute secure URL is proven to use a different origin from the shell. Hosted bridge traffic is pinned to that exact origin in both directions. No optional browser feature is granted by default. The shell expands capability grants only for a manifest returned by the registry's published-game endpoint, which means the version has passed submission, review, approval, and publication.

The Workbench uses this same hosted baseline: sandbox="allow-scripts allow-same-origin" with an empty Permissions Policy grant. In particular, it does not grant allow-forms; authored controls must handle activation through script events just as they do after publication. Manifest-granted capabilities still require a reviewed published build for a production check.

Non-browser game capabilities do not alter the iframe. Capabilities are validated against the public manifest enum; unknown values, duplicates, and contradictory declarations are rejected.

Manifest declaration	Status	Effective iframe policy	Author action
`tpg:pointer-lock`	Supported	Adds `allow-pointer-lock` to `sandbox`	Request pointer lock from a player gesture.
`tpg:fullscreen`	Supported	Adds `fullscreen` to `allow` and enables the iframe fullscreen attribute	Request fullscreen from a player gesture.
`tpg:gamepad`	Supported	Adds `gamepad` to `allow`	Keep keyboard, pointer, or touch fallback controls.
`tpg:camera` plus permission `camera`	Supported after review	Adds `camera` to `allow`	Declare both values. The browser still asks the player for permission.
`tpg:microphone` plus permission `microphone`	Supported after review	Adds `microphone` to `allow`	Declare both values. The browser still asks the player for permission.
`tpg:webxr`	Future	No `xr-spatial-tracking` grant	Provide a non-XR path.
`tpg:downloads`	Denied	No `allow-downloads` sandbox token	Send bounded data through the runtime bridge or render copyable output.
`clipboard-read` or `clipboard-write` permission	Denied	No clipboard Permissions Policy grant	Use shell-owned paste/copy affordances.
Any other sensitive browser feature	Denied unless listed here	No sandbox or Permissions Policy grant	Open a platform issue before depending on it.

permissions: ["none"] is valid only by itself. Camera and microphone must each be declared in both capabilities and permissions; declaring only one side is rejected. Known unavailable requests fail preflight with actionable JSON paths before upload. The defensive frame policy also returns an actionable diagnostic instead of silently granting access if legacy or otherwise unvalidated data reaches it.

Example:

{
  "capabilities": [
    "tpg:pointer-lock",
    "tpg:fullscreen",
    "tpg:camera"
  ],
  "permissions": ["camera"]
}

Published budgets

Budget	Supported envelope
Interactive participants	2–8 supported; 9–16 experimental; 17+ unsupported
Reliable message budgets	10 messages/second per participant and 60 messages/second room aggregate
Maximum transient payload	16 KiB per runtime/room message
Maximum canonical snapshot	64 KiB serialized JSON
Reconnect expectation	Seat may be recovered during the 30-second room reconnect grace; active gameplay still requires a live authority
Supported network profile	Up to 250 ms round-trip latency and 50 ms jitter on the reliable lane; packet-loss simulation is not a supported guarantee

Supported transport profiles

Transport	Product use	Reliable ordered	Unreliable/latest-value	Reconnect	Regression probe
Local BroadcastChannel	Same-browser development and deterministic room acceptance.	Yes	Emulated latest-value (no native packet loss)	Yes	120 × 16 KiB messages; ≥60/second; p95 ≤250 ms
WebSocket signaling	Supported deployed room transport and browser release-gate matrix.	Yes	Emulated latest-value (no native packet loss)	Yes	120 × 16 KiB messages; ≥60/second; p95 ≤250 ms

Game category matrix

Category	Overall	Renderer / browser	Transport	Authority	Persistence	Scale	Tracking
Turn-based	Supported	Supported. DOM, Canvas, WebGL, and engine Web exports.	Supported. Reliable ordered intents and snapshots.	Supported. Live host-authoritative logic.	Experimental. A bounded asynchronous relay reference persists turns and resume credentials; normal game-kit sessions remain live-only.	Supported. 2–8 players; 9–16 is experimental.	—
Prompt / voting	Supported	Supported. DOM, Canvas, and WebGL surfaces.	Supported. Reliable prompt, answer, vote, and result events.	Supported. Live host-authoritative rounds.	Unsupported. Sessions require a live authority.	Supported. 2–8 players; 9–16 is experimental.	—
Drawing	Supported	Supported. Canvas/pointer drawing and image assets.	Supported. Bounded reliable stroke batches or completed images.	Supported. Host-authoritative rounds and submissions.	Unsupported. No durable gallery/session storage guarantee.	Supported. 2–8 players within payload and snapshot budgets.	—
Casual real-time	Experimental	Supported. Browser animation and WebGL rendering.	Experimental. Latest-value channels coalesce queued input and drop stale sequence numbers over the reliable transport.	Experimental. Public fixed-step, clock-offset, input acknowledgement, interpolation, and prediction-replay helpers support casual host-authoritative simulation.	Unsupported. Live sessions only.	Experimental. Small rooms within reliable-message budgets.	#414, #415
Rhythm	Planned	Supported. Web Audio and browser rendering are available.	Experimental. Clock-offset and timestamp helpers support ordinary timers, not audio-grade synchronization.	Planned. No shared timing/scoring helper.	Unsupported. Live sessions only.	Planned. Not budgeted for synchronized scoring.	#414, #415
RTS	Planned	Supported. Canvas/WebGL rendering is available.	Experimental. Bounded queues and generic revisioned delta/keyframe primitives exist.	Experimental. Fixed-step and deterministic fault helpers exist; entity-scale simulation remains unbudgeted.	Unsupported. No durable world state.	Planned. Entity-heavy snapshots exceed the supported envelope.	#414, #415
3D / voxel	Experimental	Supported. WebGL, Three.js, Godot Web, and Unity WebGL paths exist.	Experimental. Only party-game-rate reliable messages are supported.	Experimental. Host authority and generic simulation helpers work; renderer-specific physics integration remains game-owned.	Unsupported. No persistent worlds.	Experimental. Renderer complexity is separate from room-state budgets.	#414, #416
Racing / fighting	Planned	Supported. Canvas/WebGL rendering is available.	Experimental. Emulated latest-value delivery and basic prediction replay exist; rollback and competitive reconciliation do not.	Planned. No competitive simulation contract.	Unsupported. Live sessions only.	Planned. No supported latency envelope for competitive play.	#414, #415, #416
FPS	Unsupported	Experimental. WebGL rendering is possible; pointer lock is not policy-backed.	Unsupported. No native unreliable lane, prediction, reconciliation, or competitive latency envelope.	Unsupported. No prediction, reconciliation, or lag compensation.	Unsupported. No persistent worlds.	Unsupported. Competitive FPS latency/replication is outside the beta target.	#414, #415, #416
Asynchronous	Experimental	Supported. Browser surfaces can render resumed state.	Experimental. A bearer-authenticated HTTP turn path works independently of connected room transports.	Experimental. The server-side durable authority adapter enforces revisions and scheduled turns for the Async Relay reference.	Experimental. Cloudflare Durable Objects persist bounded canonical JSON with schema migration and expiry.	Experimental. 2–8 participants, 64 KiB state, 2 KiB commands, 30-day retention, and 7-day idle expiry.	#417
Media	Experimental	Experimental. Playback works; camera/microphone grants are not manifest-driven.	Unsupported. No media streaming transport.	Supported. Metadata and bounded control events can stay host-authoritative.	Unsupported. No media storage guarantee.	Experimental. Playback-only rooms must stay within normal room budgets.	#416
Large-session	Planned	Supported. Browser rendering is application-specific.	Planned. No high-fanout replication or backpressure contract.	Planned. Single live authority is not budgeted beyond 16 participants.	Unsupported. The bounded durable reference is not a large-session service.	Planned. 17 or more participants is unsupported.	#414, #417

How the budgets are verified

Run:

bun run benchmark:game-capabilities

The probe starts the real local and WebSocket transport adapters, sends the published maximum payload through each, records throughput and p95 delivery latency, and fails when either supported transport does not meet its published regression threshold. The normal unit suite runs the same probe. This is an adapter-overhead regression gate, not a claim that the public internet always meets the published network profile.

The 2026-07-27 local baseline (Bun, loopback signaling) delivered the 120 × 16 KiB probe at 69,372 messages/second with 0.8 ms p95 for BroadcastChannel and 10,829 messages/second with 7.2 ms p95 for WebSocket. The published guarantee remains the much lower 60 messages/second and 250 ms p95 ceiling above.

Manifest validation also compares declared participant counts and reserved platform capability requests with this matrix. Experimental requests produce status-specific warnings, including the tracking issue when one exists.