Comment le SDK est construit

Comment le SDK est écrit, et comment il s’exécute. Pourquoi une même idée prend une forme un peu différente en Python et en Unreal C++, et ce qui se trouve entre votre appel et le réseau.

Écrit du général au particulier

Le SDK est une seule conception, avec deux manières de la préciser, et l’ordre fait loi : rien ne descend d’un niveau tant que le niveau supérieur peut l’exprimer.

Niveau	Ce qui s’y trouve
Les principes communs	Identiques dans chaque binding : un comportement se déclare comme un attribut placé à côté de ce qu’il décrit ; chaque déclaration que vous publiez est une déclaration que le panneau d’administration affiche ; votre code s’adresse aux modules, et à rien d’autre.
La forme du langage	Uniquement ce que le paradigme d’un langage ne peut pas exprimer de la façon commune. C# a des attributs et Python des décorateurs : c’est la même déclaration, écrite comme chaque langage écrit déjà cette idée. Un langage sans construction équivalente porte la même déclaration autrement, et ce support est nommé là où il s’applique au lieu d’être tenu pour acquis.
La forme du moteur	Uniquement ce qu’un moteur de jeu remodèle par-dessus son langage. Unreal C++ n’est pas du C++ ordinaire : il a son propre modèle objet et sa propre réflexion à la compilation, si bien qu’une déclaration y voyage à l’intérieur de la macro de réflexion du moteur, là où cette macro accepte déjà des spécificateurs. Unity C# n’est pas non plus du C# serveur : le runtime est plus ancien, la bibliothèque de base plus réduite.

Lu de haut en bas, ce tableau explique pourquoi les six onglets de chaque exemple ne sont pas six API différentes. C’est une seule API, écrite de six façons, et les différences visibles sont les deux niveaux inférieurs qui transparaissent.

Comment il s’exécute, de votre code vers le bas

Votre code de jeu voit des modules, et son vocabulaire s’arrête là.

Les modules sont ce à quoi vous vous adressez. Ils forment un graphe, pas un arbre, et ce que cela apporte est décrit dans Héritage et composition.
Les quatre primitives sont ce dont les modules sont assemblés — événements, RPC, données et abonnements, groupes. Une salle (room), un chat et un pool de matchmaking sont la même primitive de groupe soumise à des règles différentes.
Le hub se trouve en dessous, et vous ne l’appelez jamais : injection de dépendances, montage des modules, session utilisateur, restauration de l’état et qualité de service des messages. Il est présenté une seule fois, dans Sous le capot.
Les adaptateurs de transport sont tout en bas, un par protocole, et le hub les masque entièrement. Il y en aura plusieurs — WebSocket, notre propre UDP, HTTP — et le choix de celui qui transporte un appel n’est pas une chose que votre code décide ni même remarque.

Ce qu’un module vous dit de la livraison, c’est sa qualité de service — at-least-once ou at-most-once — et rien d’autre. Le transport sous-jacent peut changer sans que votre code change.

Ce que vous y gagnez

Un seul SDK, pas un SDK client et un SDK serveur. Ce qu’un appel peut faire, ce sont les droits accordés à l’acteur, pas une option de build. C’est l’objet de Qui prend les décisions.
Une déclaration alimente tout le reste. Publiez-la : l’API typée apparaît, le panneau d’administration l’affiche, et la génération de code de chaque binding suit. Voir Le schéma dans le code.
Les modules se composent au lieu d’hériter. Comment, et ce que « héritage » veut dire ici : voir Héritage et composition.