Passer au contenu principal
Steamworks et le XBOX Game Development Kit (GDK) présentent un certain nombre de différences sur le plan de la structure, des modèles de leurs API et de leur objectif. Elles sont décrites dans cette rubrique.

Aucun singleton d’API dans le XBOX Game Development Kit (GDK)

Steamworks suit un modèle dans lequel chaque ensemble de fonctionnalités de l’API est défini comme une interface (par exemple, toutes les fonctions de statistiques utilisateur se trouvent dans l’interface ISteamUserStats et le stockage à distance se trouve dans ISteamRemoteStorage), dont les instances sont rendues disponibles dès que l’API est initialisée par le jeu dans le code. Le singleton de l’API Steamworks, initialisé au démarrage du jeu, fournit ces fonctions et assure le suivi de l’état pendant toute la durée de vie de l’application. Ce n’est pas le cas avec les API du XBOX Game Development Kit (GDK), qui privilégient une API C dans laquelle une grande partie du contexte et de l’état actuel des données de l’API doit être conservée par le jeu lui-même et passée aux différentes fonctions de l’API. Par exemple, après avoir authentifié un utilisateur auprès des XBOX services, le jeu doit conserver le handle de contexte des XBOX services et un handle d’utilisateur. Les API utilisées pour obtenir ces informations ne les « mémorisent » pas pendant toute la durée de vie de vos jeux comme le fait Steamworks. Par conséquent, vous devez ajouter des variables membres à la classe de votre jeu ou assurer autrement le suivi de ces handles dans votre jeu.

Fonctions asynchrones et rappels

Les fonctions asynchrones de Steamworks déclenchent des événements auxquels vous pouvez vous abonner à l’aide de la macro STEAM_CALLBACK ou d’une variable CCallResult. Lorsqu’un événement correspondant au type de struct d’événement spécifié est déclenché, la méthode spécifiée est appelée et reçoit une struct d’événement comme seul argument. Cette struct contient le résultat retourné par l’API ainsi que les informations contextuelles disponibles auparavant qui pourraient être nécessaires pour traiter les résultats de l’appel. Par exemple, lors de l’appel de ISteamUserStats::DownloadLeaderboardEntries, vous avez besoin d’un handle SteamLeaderboard_t dans la fonction de rappel pour le passer à ISteamUserStats::DownloadLeaderboardEntries, que vous pouvez obtenir en tant que membre de la struct LeaderboardScoresDownloaded_t passée comme paramètre à la méthode de rappel que vous avez définie. Dans le XBOX Game Development Kit (GDK), toutes les actions asynchrones suivent un modèle différent : vous créez une struct XAsyncBlock, vous l’affectez éventuellement à une file d’attente de tâches, puis vous appelez la méthode d’API asynchrone. Une fois cet appel d’API terminé, il déclenche la fonction de rappel définie comme membre du XAsyncBlock et fournit un pointeur vers le bloc asynchrone comme seul argument. Si vous devez accéder à des informations à l’intérieur de la fonction de rappel, vous pouvez utiliser le membre pointeur de contexte du bloc asynchrone pour le faire. Contrairement à Steam, les informations de cette struct de contexte ne sont pas fournies automatiquement; vous devez la construire vous-même. En reprenant notre exemple précédent, si vous aviez besoin d’accéder à un ensemble de données dans votre fonction de rappel, vous pourriez procéder comme illustré dans cet exemple de code.
L’exemple précédent inclut également un pointeur vers this au moyen de shared_from_this() afin que la fonction de rappel puisse appeler des méthodes d’instance ou accéder à des variables membres au besoin. Soyez très prudent lorsque vous passez des pointeurs bruts en raison des problèmes de durée de vie. Notez également que si vous n’avez besoin d’accéder qu’à une seule variable dans votre rappel, vous pouvez simplement définir la valeur du pointeur context de votre bloc asynchrone comme un pointeur vers cette valeur, puis effectuer un cast vers le type de cette valeur dans votre rappel, au lieu de devoir définir une struct.
Steamworks exige également que le code du jeu déclenche les rappels à un certain intervalle à l’aide de la fonction SteamAPI_RunCallbacks. Cela n’est pas nécessaire dans le XBOX Game Development Kit (GDK). Les rappels sont déclenchés une fois terminée la tâche asynchrone répartie par sa file d’attente de tâches, si vous utilisez une file d’attente de tâches de pool de threads, ce qui est le comportement par défaut. Pour un meilleur contrôle, vous pouvez répartir manuellement la tâche asynchrone vers un thread spécifique en appelant XTaskQueueDispatch lorsque vous utilisez une file d’attente de tâches manuelle. Cette méthode est plus complexe, et les détails de sa mise en œuvre dépassent la portée de ce guide. Pour plus d’informations sur la façon dont le XBOX Game Development Kit (GDK) gère les opérations d’API asynchrones, y compris un exemple de code, consultez Modèle de programmation asynchrone.

Source de vérité pour les API gérées par le titre

Avec Steamworks, l’API est l’unique source de vérité pour pratiquement toutes les valeurs qui y transitent. Par exemple, les statistiques utilisateur sont récupérées à partir de l’API et calculées en fonction des valeurs de ISteamUserStats::GetStat/ISteamUserStats::SetStat, et vous n’êtes pas tenu de stocker ces valeurs ailleurs vous-même. Les API de succès et de statistiques/classements du XBOX Game Development Kit (GDK) offrent toutes deux une option de gestion par le titre pour les développeurs qui souhaitent plus de souplesse et de simplicité dans les appels qu’ils doivent effectuer. Les valeurs des API gérées par le titre sont, comme leur nom l’indique, gérées par votre titre. L’unique source de vérité pour ces valeurs est votre jeu, qui peut stocker les valeurs n’importe où, par exemple dans un fichier de sauvegarde, dans un stockage infonuagique ou sur un serveur dorsal tiers. La valeur stockée sur les serveurs du réseau XBOX (également appelé XBOX Live) peut servir d’instantané que vous mettez à jour occasionnellement, mais elle ne devrait pas être votre unique source de vérité au moment de l’exécution. Une autre option aux statistiques et succès gérés par le titre est celle des statistiques et succès basés sur les événements. Ceux-ci utilisent des événements de télémétrie pour mettre à jour la progression d’un utilisateur vers un succès ou recalculer ses statistiques, et ils considèrent les XBOX services comme leur source de vérité. Vous pouvez choisir l’API que vous souhaitez utiliser pour les statistiques et les succès dans la page Gameplay Setting de votre jeu dans Partner Center. Pour plus d’informations à ce sujet, consultez les descriptions dans les rubriques qui comparent les statistiques basées sur les événements et gérées par le titre et les succès basés sur les événements et gérés par le titre. Il arrive que ces API soient désignées par leurs anciens noms, soit Stats/Achievements 2013 (basés sur les événements) et Stats/Achievements 2017 (gérés par le titre).

Le XBOX Game Development Kit (GDK) est multiplateforme

Les jeux qui utilisent les API Steamworks peuvent supposer qu’ils sont toujours lancés au moyen de Steam, et l’API peut donc injecter, lors de l’initialisation, un certain contexte sur la personne qui joue au jeu. Le XBOX Game Development Kit (GDK) peut être utilisé par des jeux qui s’exécutent sur une console XBOX, sur un PC au moyen de l’application XBOX Gaming, ou sur un grand nombre d’appareils et de lanceurs. Par conséquent, certains éléments de contexte disponibles automatiquement avec Steam pourraient devoir être initialisés manuellement avec le XBOX Game Development Kit (GDK), comme l’identité de l’utilisateur. Pour accéder à ces informations, vous pouvez suivre les étapes de la rubrique Initialisation du GDK de ce guide, qui fournit des instructions pour authentifier un utilisateur avec son compte Microsoft/gamertag. Cela signifie également que certains paradigmes des fonctions du XBOX Game Development Kit (GDK) sont adaptés aux scénarios sur console, comme la prise en charge de la connexion de plusieurs utilisateurs pour les API XUser, qui n’ont pas d’équivalent sur PC.

Création de packages

La plupart des jeux sur Steam peuvent utiliser les fonctions de l’API Steamworks en configurant simplement les informations du jeu dans le portail d’administration de Steamworks, en téléchargeant le SDK, en important les fichiers requis et en initialisant l’API dans le code. Une fois ces étapes effectuées, votre jeu s’intègre à l’API Steamworks peu importe d’où il est lancé, par exemple dans l’éditeur d’un moteur de jeu. Pour que les API du XBOX Game Development Kit (GDK) fonctionnent, votre jeu doit d’abord être empaqueté. Pour empaqueter correctement votre jeu, vous devez modifier le fichier MicrosoftGame.config de votre jeu et utiliser l’outil MakePkg du XBOX Game Development Kit (GDK) pour créer le package MSIXVC de votre jeu, que vous pouvez ensuite charger de manière indépendante en tant qu’application du Microsoft Store sur un PC où le Mode développeur est activé. Cela signifie également que, contrairement aux jeux Steamworks, certaines fonctionnalités du XBOX Game Development Kit (GDK) ne fonctionnent pas dans l’éditeur d’un moteur de jeu ou dans d’autres environnements de développement sans que le jeu ait d’abord été empaqueté. Pour plus d’informations sur la création de packages, consultez les ressources suivantes.

Développer et tester des jeux Unity

Les jeux créés avec le moteur de jeu Unity peuvent utiliser le plug-in GDK Unity pour développer leurs titres. Ce plug-in est inclus dans l’offre du XBOX Game Development Kit (GDK) et en tant que complément autonome sur le portail XBOX Developer Downloads. Ce plug-in comprend des wrappers d’API qui vous permettent d’appeler les fonctions du XBOX Game Development Kit (GDK) dans le code C# de votre jeu. Pour plus d’informations sur le plug-in GDK Unity, consultez Prise en main d’Unity pour le développement sur PC.
Dernière modification le 6 octobre 2026