Open Play overview
This page summarizes which ready-made building blocks Open Play offers your game and which channel you use to talk to each of them. Read it before you start integrating; follow the links at the end of each section for details.
What is Open Play?
Open Play covers a game’s backend needs as a single server: player identity and sessions, characters, inventory, economy, store, rewards, social features, leaderboards, notifications, webhooks, and realtime connections. You connect your game to this server over HTTP (REST) and WebSocket; the team that runs the game configures the same server from the admin panel.
Note
Today Open Play is a Docker Compose stack and runs on your or your team’s infrastructure. For installation and deployment, see the production deployment guide (
docs/production-and-adapters.tr.md); this document describes the game developer’s point of view.
What does it offer? The module map
Most features are turned on and off as modules. The endpoints of a disabled module do not work and return 404 with the code module_disabled (see Concepts). Modules are managed in the panel under Game settings › Modules.
| Module | What it gives your game | Guide |
|---|---|---|
characters | Character definitions, characters, commands, rules, traits, level curves | Characters |
economy | Currencies, wallets, transfers, ledger | Economy |
items | Item definitions, item instances, inventory | Inventory and items |
trading | Merchants and player-to-player trading | Raw REST: endpoints |
store | Store catalog, purchasing, in-app purchase (IAP) verification | Store and IAP |
rewards | Reward tables, quests, NPC rewards, VIP, daily login reward | Rewards |
social | Clans and parties | Social |
chat | Chat | Chat |
competition | Leaderboards and tournaments | Competition |
notifications | Notification channels, templates, player inbox, web push | Notifications |
webhooks | Delivering game events to your own server, signed | Webhooks |
scenes | Scenes and visual assets | Scenes, assets, models |
plugins | The plugin platform and the realtime surface | Plugins, Realtime |
Core surfaces that have no module switch are always on:
- Player identity and sessions: guest, email/password, Google. See Authentication.
- Content groups and catalog: data managed from the panel and read by the game. See Content groups.
- Game rules and automations. See Game rules.
- API keys, environments, and domains. See Concepts.
Which channel do you talk through?
| Channel | Who uses it? | Credential | What for? |
|---|---|---|---|
REST (/v1/...) + server key | Your game server (trusted backend) | Authorization: Bearer crx_live_<prefix>_<secret> | Administration and operations that change money or items |
| REST + client key | Your game client | a client key in the same format | Limited, non-sensitive operations |
| REST + player session | The player’s own client (browser, Unity) | cookie or session token + x-crx-env | The player’s own data: sign-in, catalog, store, rankings, plugin commands |
WebSocket (/v1/realtime/ws etc.) | The player’s client | single-use ticket | Plugin state, live input, uninterrupted streaming |
| Webhook (Open Play → your server) | Your server | X-Crx-Signature signature | Event notification |
| SDK | TypeScript and Unity | a wrapper over the channels above | Typed use of REST and WebSocket |
Warning
A server key is a secret. Do not put it in the browser, in a mobile app, or in the game bundle. On the client side, use only the player session and (if needed) a client key.
A gRPC interface exists on the server side, but it is not a public channel for game developers; by default it listens on loopback only and the SDKs do not use it. This document does not cover it.
Where to start
- Concepts: studio, game, environment, module, key types, player session.
- Quickstart: your first server call and your first player sign-in.
- Architecture and hosting: direct CORS or reverse proxy, domains, what runs where.
- Authentication and the SDKs.
Current limits
The following are written honestly on purpose; plan your roadmap accordingly.
- CORS is open only to origins in the environment’s domain list, and the cookie needs the same site. A browser game can call Open Play directly if its domain is bound to an environment; if the game is on a different registrable domain than Open Play, the
SameSite=Laxsession cookie is not sent (use a reverse proxy). See Architecture and hosting. - Loading third-party plugins is not supported. Plugins ship compiled into the server; you cannot upload a plugin from the panel. See Plugins.
- SDK coverage is partial. Modules that have no typed client in the TypeScript SDK are used through raw REST. See TypeScript SDK.
- On Unity, only Unity 6000.6.7f1 is verified. See Unity SDK.
- Error bodies are mostly plain text. Only a few places have a JSON error envelope. See Errors.