Concepts clés

Les termes que les autres pages emploient sans les expliquer. Chacun reçoit une définition courte et un lien vers la page qui décrit le mécanisme derrière lui.

Trois sujets sont trop vastes pour une simple entrée et ont chacun leur page : Qui prend les décisions — qui appelle, et ce que cela seul détermine ; Comment le SDK est construit — de quoi le SDK est fait ; Héritage et composition — comment les modules s’appuient les uns sur les autres.

Les quatre façons de travailler avec un module

Chaque module expose exactement quatre choses, et chaque page de module s’organise autour d’elles. C’est le modèle de programmation :

Façon de travailler	Ce que c’est
Déclarations	ce qui existe et comment cela se comporte, écrit dans le code ou dans le panneau d’administration ; le modèle est le même dans les deux cas
Hooks	vos règles, que la plateforme appelle à des étapes nommées ; déployés comme fonctions cloud
Événements	ce que la plateforme vous signale comme arrivé — abonnez-vous au lieu d’interroger en boucle
Opérations	ce que vous demandez ou ordonnez, depuis une fonction ou un client

Acteur

Celui qui effectue un appel. Ce qu’un appel a le droit de faire dépend de l’acteur qui l’émet, jamais du build dans lequel le code a été compilé. L’argument est développé dans Qui prend les décisions, le mécanisme (permissions atomiques, rôles composés, InterfaceGrant) dans Access & Roles.

Les noms d’acteurs de ces pages viennent des presets fournis par la plateforme. Un projet peut nommer ses propres acteurs ; les presets sont :

player · backend-service · operator · host · moderator · schema-author · architect · bot-brain · room-owner · room-visitor · entry-validator · spectator · match-organizer · warehouse-keeper · seller — et any quand une page parle de tous à la fois.

Lieu d’exécution

L’endroit où le code s’exécute. Chaque tableau d’opérations utilise ces quatre étiquettes :

Étiquette	Lieu d’exécution
`fn`	Fonction cloud (C# · TypeScript · Python · Go). Le serveur fait autorité ; c’est là que vivent d’abord vos règles
`cl`	Client de jeu (Unreal C++ / Unity C#). API symétrique ; les rôles y débloquent moins de choses
`mc`	L’hôte de la salle (room) : un client maître (un client propriétaire d’une salle) ou un serveur dédié Unreal muni de sa clé hôte
`adm`	Panneau d’administration / CLI / MCP — là où le SDK et le plan opérateur partagent un même modèle

L’endroit où le code s’exécute ne dit pas au nom de qui il agit

L’endroit où le code s’exécute et l’interface d’acteur qu’il détient sont deux questions distinctes. Le même code a les mêmes droits où qu’on le place ; seuls les droits accordés (grant) changent.

Projet et environnement

Un projet est le backend d’un jeu, avec un schéma et ses données répartis dans des environnements isolés (dev, prod). Chaque appel s’exécute dans un couple projet + environnement.

Entité

Le nom central. Une entité est une déclaration de schéma plus ses aspects vivants : données 0..*, états 0..*, RPC 0..*, événements 0..*, hooks et historique des modifications. Un tank, une porte, une barre de statistique et une quête sont tous des entités ; seuls les aspects qu’ils portent les distinguent. Les combinaisons courantes sont livrées sous forme de presets (GameObject, Stat, Character, Interactable, Projectile). Voir Entity.

État attendu

Une demande de transition peut nommer l’état qu’elle attend : soit la machine est dans cet état, soit la demande est refusée. Une demande qui n’en nomme aucun est évaluée par rapport à l’état de la machine au moment où la plateforme la traite — jamais par rapport à l’état au moment de l’envoi.

La réponse décrit ce moment-là et ne promet rien pour la suite : si la transition de quelqu’un d’autre aboutit pendant que la réponse est en route, la réponse reste vraie et n’est pas annulée.

Nommez l’état attendu quand il compte

Quand le résultat dépend de ce qui était là avant, nommez l’état attendu. Sinon, ne lisez pas la réponse comme un snapshot qui survivrait à l’appel.

Salle

Une salle est une session de jeu, pas un endroit où votre code s’exécute. Peu importe à la plateforme ce qui l’héberge : un serveur dédié, un client maître ou le backend lui-même. Le fonctionnement interne des salles nous appartient ; vous pilotez une salle de l’extérieur, depuis les fonctions cloud et les clients, au moyen des déclarations, des hooks, des événements et des opérations. Voir Rooms.

Canal et flux

Les primitives asynchrones sous-jacentes à tout le reste. Un canal (channel) est un sujet pub/sub adressable : une salle, un groupe, une entité ou un canal à vous. Un flux (stream) circule par morceaux dans un sens comme dans l’autre : les fichiers se consomment au fil des morceaux reçus, les requêtes peuvent être diffusées en flux, et un RPC peut se déployer vers un groupe et collecter les réponses. Voir Core.

Primitive

L’une des quatre briques dont chaque module est assemblé : les événements (déclarer, émettre, s’abonner), les RPC (appeler de l’autre côté du réseau), les données et abonnements (mécanique de synchronisation) et les groupes (une liste, de nombreux auditeurs). Une salle, un chat et un pool de matchmaking sont la même primitive de groupe soumise à des règles différentes.

Contrat des hooks

Un seul contrat partout. Un hook before s’exécute avant la validation, reçoit la charge utile typée et peut la modifier ou la rejeter. Un hook after s’exécute une fois l’opération validée, reçoit la requête et le résultat, et ne peut qu’ajouter des effets de bord — il ne peut jamais faire échouer l’opération. Les hooks sont ordonnés ; chaque étape enregistrée de la plateforme peut en porter. Voir Extensibility.

Delta et révision

Les clients reçoivent l’état sous forme de deltas : uniquement les champs modifiés, encodés par rapport au dernier état dont le destinataire a accusé réception. Chaque enregistrement porte une révision ; une écriture conditionnelle est rejetée si elle ne correspond pas. Une seule notion de versionnement sert à la fois la synchronisation, la concurrence et l’historique. Voir Data & Subscriptions. (Ce qu’Unreal appelle replication — quel client voit quel état, et à quelle fréquence — relève de cette page ainsi que de Visibility et Prediction & Lag Comp. La page Ce qui survit à la perte d’un hôte traite de l’autre question : quelle machine possède une entité, et laquelle la possédera ensuite.)

Tick

Les salles simulent à pas fixe. Chaque changement d’état est horodaté avec son tick ; synchronisation, prédiction, compensation de latence et historique se comptent tous en ticks plutôt qu’en temps réel. Les données portent l’instant réel de l’événement, ce qui rend le retour en arrière et la réconciliation exacts. Voir Prediction & Lag Comp.