Not translated yet — showing English.
The Operator Plane
What is deliberately not in the SDK. Project and environment lifecycle, deploy and rollback, billing, org and user administration and cluster routing belong to the admin panel, the CLI and the MCP surface, not to game code. The one deliberate exception is Schema as Code: schema is a developer surface, so it is in the SDK.
One model, two planes
| The SDK plane | The operator plane | |
|---|---|---|
| Reached from | game code | the Control Panel, the CLI, MCP |
| Holds | rooms · entities · players · commerce · leaderboards | projects & environments · deploy and rollback · billing · org and user administration · cluster routing |
| Works in | declarations, hooks, events, operations | the panel's own screens |
They share one model: the declaration you push is the one the panel renders. What does not cross the line is authority — game code cannot deploy, bill, or move a tenant.
Every SDK surface (each module, and the presets declared on entities) has an operator counterpart in the Control Panel, where the same declarations are viewed and edited from the other side:
| SDK surface | The operator sees |
|---|---|
| Schema / Data | entities, migrations, the record browser, saved views, import/export |
| Entity | state machines, per-instance inspection |
| Entity Presets | drop tables, ability, stat and projectile definitions, world-object presets — live-tunable |
| Access | the role grid: roles × operations, row filters, column masks |
| Extensibility | scenario chains with overrides, resolved order, invocation traces |
| Rooms | the fleet: rooms, tick health, placement, drain status |
| Matchmaking | queues, tickets in flight, relaxation curves |
| Commerce | catalog, storefront scheduling, receipts, refunds |
| Leaderboards | cycles, record correction (audited), submission rates |
| Auth | providers, sessions, bans, the auth scenario |
| Files | assets, UGC review queues, quotas |
| Analytics | dashboards, forwarders, ingestion lag |
| Map | maps and obstacle sets, live instances |
| Visibility / Collision / Locomotion / Prediction | per-room tuning: rules, response pairs, windows, per-actor packet cost |
| Groups / Messaging | group browser, templates, moderation filters, schedules |
| Bots | profiles, fill quotas, brain endpoints |
| Inventory / Profile | holdings and transfers, views and owned-entity sets |
The design rule. Every SDK capability has a panel surface, so live ops can see it, and every panel surface is backed by an SDK capability. Modules ship both halves together, and a declaration authored in either place is the same model in both.
One declaration's trip: the schema-author writes it, playserv push carries it, the panel renders it for the operator, and the retune lands in rooms that are already running.
Agent access
Everything the panel shows is also reachable by tooling: the platform exposes an MCP surface (the same API the panel uses), so AI agents and scripts operate projects (bootstrap, schema, records, players, deploys) under the same access model as any other actor.