Playmos Live
Try it first
Check whether your hosted multiplayer path is ready#
You need A supported game build and the current environment’s capability report.
- Inspect provider, simulation and exact-build readiness.
- Where active, join two authenticated clients and complete a server-admitted run.
- Reconnect or restart and read the saved authoritative result.
Check your result The server receipt and restored state agree; local predictions remain presentation only.
Add live players to a competitive leaderboard game. Share the course, chase a verified ghost and keep each player’s result independent.
Compete together. Keep your own time.#
A shared room brings players together without turning the game into a head-to-head contest. In Tabletop Rivals, everyone starts from the same conditions, cars pass through one another and fixed hazards affect each run equally. Live drivers, recorded ghosts and NPCs are labeled separately.
Each player earns an independently verified time. A provisional finish becomes final after the rollback window closes. Other drivers can continue; the finished player can find another chase. Room placement does not authorize a prize or payout.
One integration, different games#
| Piece | Your integration |
|---|---|
| Game rules | Deterministic initial state, sanitized input, fixed-step simulation and an integer score reader. Seed randomness and pin the exact game/build/rules/seed/tick rate. |
| Player UI | Read controls, predict the local entity, render snapshots and show searching/reconnecting/pending/confirmed states. |
| Managed worker | Playmos operates rollback, matchmaking, replay capture, confirmed results and usage metering around the approved simulation. |
The same player API supports a time trial, runner or other scored game. Other players’ actions must not alter the eligible score. Ghosts must match the exact competition context and carry a private service signature binding their replay. A client-generated hash is not verified evidence.
Configure services in Studio#
Use Game services: Play, Competition, Review. Managed hosting is the default; choose a registered self-hosted worker when needed. Room limits and region stay under Advanced. Your agent can read and save the same revision-checked draft through MCP. Missing worker, verification, pool and recovery capabilities block activation. Setup, worker deployment and hosted acceptance remain distinct; the new service modules are source candidates.
Connect your player#
After publication, install @playmos/live@0.1.0. Before publication, use Playmos’s exact tested archive. Obtain a short-lived player session from your authenticated backend. Keep studio secret keys on that backend.
import { connectPlayer } from '@playmos/live';const player = connectPlayer({sessionToken: playerSessionToken,readInput: readControls,simulate: stepLocalPlayer,selectState: (snapshot, assignment) => snapshot.cars.find(car => car.id === assignment.playerId),onSnapshot: renderWorld,onSearch: showSearch,onStatus: showConnectionStatus,onError: showError,});await player.findRace({ name: 'Racer' });
Your connection supplies readInput, simulate, selectState and onSnapshot. The helper exposes player.state for prediction and manages the connection lifecycle across searches. Close it with player.leave() when the game exits. The lower-level PlaymosLive client is available for custom flows.
Phone and physical controllers#
Use the standalone @playmos/controller SDK package for in-game QR pairing, the full-screen phone gamepad, physical Gamepad API input and Hub iframe passthrough. It works on your own game site and requires no Live multiplayer or game-server allocation. Physical input is local; phone pairing uses the managed controller relay. Follow the complete controller integration guide.
Bounded rollback and confirmation#
The default authority runs at 60 Hz with a twelve-frame (200 ms) rollback window. Late inputs within the window can be replayed; confirmed results cannot change. The browser batches and retransmits inputs, caps prediction at six frames and reconciles snapshots. Those bounds describe input age, not a supported-ping guarantee. Same-runtime deterministic replay is tested; cross-engine bitwise determinism is not claimed.
Simple matchmaking#
Compatible game/build/mode pools group up to four players. Full groups start immediately; two or more start after two seconds. After eight seconds the racer can start a solo chase with compatible recordings and NPCs. Cancellation and heartbeat expiry prevent abandoned searches from reserving players. Your game selects compatible competition contexts for each matchmaking pool.
Hosted game servers and spending caps#
Managed Playmos Live is operated by Playmos. Studios can also run their own engine behind the source-candidate Node worker shim and register its HTTPS endpoint. The premium Playmos rollback authority remains private; the public worker shim does not include it. The public browser entry contains client code; @playmos/live/server gives studio backends allocation, status, stop and usage controls.
Hosting uses server runtime with a monthly spending cap. The service reserves the bounded lease cost before provisioning and meters confirmed start/stop time. Reuse a saved allocation key on retries. Unknown provider operations retain their reservation until reconciled. Your studio’s approved rate and spending cap apply to every allocation. These charges are separate from contest commerce fees.
Free browser-game ZIP hosting is a different service: see Host and publish your game. Paid contest admission and settlement still use the commerce SDK.
If it did not work#
If the managed provider or pinned runtime is unavailable, stay in practice. Source implementation is not hosted acceptance.
Try one variation Disconnect and reconnect a test client. Its local prediction must not overwrite the authoritative saved result.
Continue with the next guide →