Not translated yet — showing English.

PlayServ SDK

The game backend that ships with the gameplay. PlayServ is a backend-as-a-service for live games: a studio runs its game's backend — data, players, rooms, matchmaking, commerce — without hosting one. The SDK is how your code, on the server and in the engine, works with that platform.

The simulation is not your code

Rooms, collision, locomotion, prediction and sync all run inside the platform. Your game is declarations (entities, maps, abilities, drop tables, sync policy), hooks (your rules, called at named steps), events (subscribe, don't poll) and operations (what you ask for or command). Every module page is organised around exactly those four.

What you skip is concrete: a game loop, snapshot assembly, a delta encoder, collision resolution, movement integration, reconnect handling, hit validation with lag compensation. A game like Tanks fits in ~300 lines. Getting Started builds it.

Mutating declared state is the network call

There is no send. You declare how a field synchronises with one attribute beside it, and changing the field is the network operation. Deltas against the last acknowledged state, per-aspect policy, priority and send rate, the retained window and change hooks all follow from that declaration; you write none of it.

The same applies to everything else that is declared: an event, an RPC, a group, a leaderboard axis. One declaration becomes the typed API in every binding, a screen in the admin panel, named steps your hooks can replace, access rules per actor and generated code per binding. That is why you version the declaration, not the generated code. See Data & Subscriptions and Schema as Code.

Interfaces follow the actor, not the side

There is no client SDK and no server SDK. One SDK ships, and what a call may do is decided by the actor behind it — a player, a service, a bot brain, an operator.

The case it is built for is a player's machine that creates a room and then runs it: a master-client, holding the room-owner interfaces and nothing more. A room-visitor build has no kick and no close: those interfaces are absent, not disabled.

Rights are composed from atomic permissions, so there are no built-in role tiers, and a role gates data down to the row and the column. See Authority, and Access & Roles for how a grant is spelled.

One design, one stack

How it is written

The SDK is one design with two ways to narrow it, and nothing moves down a level until the level above can't express it. Common principles are identical in every binding. A language's shape takes only what its paradigm cannot express the common way. An engine's shape takes only what an engine reshapes on top of its language — in Unreal a declaration rides inside the engine's own reflection macro.

How it runs

Your game code addresses modules and nothing else. Modules are assembled from four primitives — events, RPC, data and subscriptions, groups. Under them sits the hub you never call: dependency injection, module mounting, the session, state recovery, message quality of service. Under that, transport adapters, one per protocol, and which one carries a call is not something your code decides or notices.

Both halves in full: How the SDK Is Built, ending at Under the Hood.

Modules compose; nothing subclasses

There is no base module to derive from and no hierarchy to extend — modules form a graph, because real features cross branches: matchmaking reserves seats in rooms, drops place items through the map, a chat lives inside a room.

"Inheritance" covers four different mechanisms here, and they are worth telling apart: an entity's RPCs are part of the entity; a preset is a named bundle of aspects, not a base class; overriding a platform step is an attribute on your replacement; a module borrows another through a decorator that narrows the borrowed interface. See Inheritance & Composition.

Who sees what is declared, not filtered on the client

At forty players a whole-room snapshot is fine; at two hundred it isn't. Interest rules decide who receives which slice, and per-actor packets and broadcast are two delivery modes of one declared model — moving between them is configuration, not a rewrite. Distant things degrade through declared detail tiers before they disappear.

This is also a security property: state that must not leak is never sent. Fog of war and owner-only fields are absent from the packet, not hidden on the client. Spectators, admins and replays get their wider view by holding a wider grant. See Visibility.

What survives losing a host

A host dying does not end the match. Room state is not copied between hosts while play runs: a single owner keeps ordering free of consensus. The match survives because its state is declared, and declared state is held outside the host, snapshotted on a declared interval. A replacement host resumes from the last snapshot.

The replacement has the whole state as of that snapshot, so the play since then is lost. A deploy uses the same mechanism without the loss: draining a host is the failover path run deliberately.