Cette page n’est pas encore traduite : la version anglaise est affichée.
The Operator Plane
Ce qui n’est délibérément pas dans le SDK. Le cycle de vie des projets et des environnements, le déploiement et le rollback, la facturation, l’administration de l’organisation et des utilisateurs et le routage des clusters relèvent du panneau d’administration, de la CLI et de l’interface MCP, pas du code du jeu. Seule exception voulue : Le schéma dans le code. Le schéma est une interface de développeur, il fait donc partie du SDK.
Un modèle, deux plans
| Le plan SDK | Le plan opérateur | |
|---|---|---|
| Accessible depuis | le code du jeu | le panneau de contrôle, la CLI, MCP |
| Contient | salles · entités · joueurs · commerce · classements | projets et environnements · déploiement et rollback · facturation · administration de l’organisation et des utilisateurs · routage des clusters |
| On y travaille avec | déclarations, hooks, événements, opérations | les écrans propres au panneau |
Les deux partagent un même modèle : la déclaration que vous publiez est celle qu’affiche le panneau. Ce qui ne franchit pas la frontière, c’est l’autorité — le code du jeu ne peut ni déployer, ni facturer, ni déplacer un tenant.
Chaque interface du SDK (chaque module, et les presets déclarés sur les entités) a son pendant opérateur dans le panneau de contrôle, où les mêmes déclarations se consultent et se modifient depuis l’autre côté :
| Interface du SDK | Ce que voit l’opérateur |
|---|---|
| Le schéma dans le code / Data & Subscriptions | entités, migrations, l’explorateur d’enregistrements, vues enregistrées, import et export |
| Entity | machines à états, inspection par instance |
| Entity Presets | tables de butin (drop table), définitions de capacités, de statistiques et de projectiles, presets d’objets du monde — le tout réglable en direct |
| Access & Roles | la grille des rôles : rôles × opérations, filtres de lignes, masques de colonnes |
| Extensibility | chaînes de scénarios avec leurs surcharges, ordre résolu, traces d’invocation |
| Rooms | la flotte : salles, santé du tick, placement, état du retrait (drain) |
| Matchmaking | files d’attente, tickets en cours, courbes d’assouplissement des critères |
| Catalog & Commerce | catalogue, programmation de la boutique, reçus, remboursements |
| Leaderboards | cycles, correction des entrées (auditée), fréquence des soumissions |
| Auth & Players | fournisseurs, sessions, bannissements, le scénario d’authentification |
| Files & UGC | assets, files de modération des UGC, quotas |
| Analytics | tableaux de bord, transmetteurs d’événements, retard d’ingestion |
| Map | cartes et jeux d’obstacles, instances en direct |
| Visibility / Collision / Locomotion / Prediction & Lag Comp | réglages par salle : règles, paires de réponse, fenêtres, coût du paquet par acteur |
| Groups / Messaging | explorateur de groupes, modèles, filtres de modération, planifications |
| Bots | profils, quotas de remplissage, endpoints des cerveaux |
| Inventory / Profile | possessions et transferts, vues et ensembles d’entités possédées |
La règle de conception. Chaque fonctionnalité du SDK a son interface dans le panneau, pour que les live-ops puissent la voir, et chaque interface du panneau repose sur une fonctionnalité du SDK. Les modules livrent les deux moitiés ensemble, et une déclaration rédigée à l’un ou l’autre endroit est le même modèle des deux côtés.
Le trajet d’une déclaration : schema-author l’écrit, playserv push la transporte, panel l’affiche pour operator, et le nouveau réglage s’applique à des salles (room) déjà en cours d’exécution.
Accès pour les agents
Tout ce qu’affiche le panneau est aussi accessible aux outils : la plateforme expose une interface MCP (la même API que celle du panneau), si bien que les agents IA et les scripts pilotent les projets (initialisation, schéma, enregistrements, joueurs, déploiements) sous le même modèle d’accès que n’importe quel autre acteur.