Playmos Live
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.
Connect your player#
After publication, install @playmos/[email protected]. 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#
Playmos Live is premium and operated by Playmos. There is no self-hosted Live product. The public package contains clients only; @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.