Passer au contenu principal
Par défaut, la plupart des SDK PlayFab mettent en cache les résultats de connexion des joueurs. Cette mise en cache peut être pratique dans le scénario le plus courant, lorsque vous attendez la connexion d’un seul joueur. Dans les jeux qui prennent en charge plusieurs joueurs simultanés, ou sur les serveurs où vous gérez à la fois les éléments d’authentification des joueurs et les informations d’identification du serveur, cette mise en cache peut devenir gênante. Pour faciliter ces scénarios, les SDK PlayFab contiennent à la fois des classes d’API statiques et des classes d’API instanciées.

Classes d’API statiques et classes d’API instanciées

La plupart des exemples et des exemples de code pour PlayFab sont créés à l’aide de classes d’API statiques. Dans Unity, par exemple, vous pouvez voir une référence à PlayFabClientAPI. Ces classes statiques lisent et écrivent dans un état statique au sein du SDK. Leur dépendance à l’état statique rend leur utilisation difficile lorsque vous travaillez avec plusieurs joueurs au sein du même client de jeu. Les classes d’API instanciées évitent ces problèmes, en contrepartie d’exigences accrues de gestion et de suivi de votre part. Si vous devez prendre en charge plusieurs connexions PlayFab simultanées, nous vous recommandons d’utiliser des classes d’API instanciées. Dans le SDK Unity, PlayFabClientInstanceAPI est la version instanciée de PlayFabClientAPI. Toutes les autres classes d’API suivent un modèle de nommage similaire. Lorsque vous utilisez la version instanciée d’une classe d’API, vous devez créer une instance de la classe avant de pouvoir appeler des méthodes. Pour créer une instance, vous devez spécifier un contexte supplémentaire. Pour la plupart des classes, le contexte supplémentaire requis est simplement le contexte d’authentification du joueur. Dans Unity, ce contexte est PlayFabAuthenticationContext. Certaines classes contiennent des appels de connexion. Pour ces appels, vous ne disposez peut-être pas encore du contexte d’authentification d’un joueur. Dans ce cas, il vous suffit de fournir des paramètres de base, comme un ID de titre. Ces paramètres sont transmis via un objet PlayFabApiSettings.

Utilisation des classes d’API instanciées

Une fois que vous avez créé une classe d’API instanciée avec un contexte d’authentification ou un objet de paramètres d’API appropriés, elle peut être utilisée de la même manière qu’une classe statique. Tous les objets de requête et de réponse sont identiques. La seule différence est que vous êtes responsable du suivi de la durée de vie de l’instance et que vous devez vous assurer que tous les appelants potentiels de PlayFab reçoivent une instance appropriée. Lorsque vous gérez plusieurs joueurs, vous avez besoin de plusieurs instances de chaque classe d’API, une par joueur. Il est souvent plus simple de gérer ces instances en les encapsulant derrière un objet joueur qui en est le propriétaire, mais ce choix vous appartient. Les classes instanciées qui connectent un joueur (comme PlayFabClientInstanceAPI) créent et mettent également en cache le contexte d’authentification de ce joueur au sein de l’instance de la classe d’API. Cette fonctionnalité vous permet de référencer facilement le contexte d’authentification lors de la création des autres classes dont vous avez besoin.

Exemple Unity

Cet exemple de code montre comment plusieurs joueurs peuvent se connecter à un jeu et disposer d’un état indépendant suivi dans des instances de classe distinctes. Dans cet exemple, les classes d’API et les fonctionnalités de base sont encapsulées derrière un objet PlayFabPlayer simplifié. Au démarrage du jeu, nous connectons deux joueurs, puis nous récupérons les données stockées dans PlayFab pour chacun d’eux.

Exemple Unreal

Cet exemple de code présente un acteur dans Unreal qui contient son propre contexte de connexion PlayFab. Il montre comment encapsuler des classes d’instance d’API PlayFab au sein d’une classe ALoginActor. Plusieurs instances d’ALoginActor peuvent être ajoutées à une carte, recevoir leurs propres CustomIds et effectuer des opérations PlayFab de manière indépendante. LoginActor.h:
LoginActor.cpp:

Authentification serveur

De la même manière que les classes d’API instanciées permettent à un client de jeu de gérer plusieurs joueurs, elles permettent aux serveurs de gérer une combinaison d’authentification de titre et de joueur, voire plusieurs titres simultanément. Le modèle de base est presque identique. Instanciez une classe d’API pour gérer la connexion du serveur, fournissez à cette instance l’objet PlayFabApiSettings approprié, puis appelez une API d’authentification. Sur un serveur, cette API est généralement PlayFabAuthenticationInstanceAPI.GetEntityToken. Comme pour la connexion d’un joueur, le résultat d’un appel à GetEntityToken est mis en cache dans l’instance de la classe d’API et peut être référencé pour créer d’autres instances de classes d’API via la propriété d’instance authenticationContext.
Dernière modification le 6 octobre 2026