Passer au contenu principal
Un alias de build est une couche de gestion superposée aux builds, qui permet de répartir de façon contrôlée les appels à RequestMultiplayerServer entre plusieurs builds. Cela peut améliorer la simplicité et la fiabilité des mises à niveau d’une build à une autre ainsi que de plusieurs autres scénarios décrits ci-dessous. Pour ce faire, les alias spécifient une liste d’ID de builds accompagnée du poids de chacune. Le poids d’une build détermine la probabilité que cette build soit essayée en premier pour chaque demande d’allocation. Par exemple, si la build 1 a un poids de 8 et la build 2 un poids de 2, la build 1 est essayée en premier pour environ 80 % des demandes; elle en traite donc environ 80 % tant qu’elle dispose de serveurs StandingBy. Si la build 1 manque de serveurs StandingBy dans une région, ces demandes sont plutôt dirigées vers la build 2, qui peut alors traiter plus de 20 % des demandes dans cette région. Toutefois, les régions de chaque demande ont priorité, et les poids déterminent uniquement quelle build traite une demande au sein d’une région. Pour plus de détails, consultez Basculement vers d’autres builds et régions.

​
Déploiement sécuritaire rétrocompatible

Il s’agit du scénario le plus courant de mise à niveau d’une build à une autre, dans lequel vous mettez à jour le serveur de jeu et où les clients commerciaux sont compatibles avec les deux serveurs. Les clients font référence à l’alias 1, dont la configuration est la suivante :
  • Build 1 : poids = 1
Une fois la build 2 créée, l’alias 1 est modifié comme suit :
  • Build 1 : poids = 8
  • Build 2 : poids = 2
Vous pouvez modifier progressivement les poids jusqu’à ce que toutes les nouvelles demandes de serveur soient traitées par la build 2. À ce stade, le poids de la build 1 est de 0 et celle-ci peut être retirée de l’alias. Un cas d’utilisation typique d’un alias consiste à l’associer à une version de compatibilité client et à un mode de jeu. Par exemple, « DeathMatch client 2.2 RETAIL ». Les alias vous permettent de gérer cette abstraction de plus haut niveau tout en mettant continuellement à jour les builds qui alimentent cette expérience. Les alias facilitent également la restauration des builds au besoin.

​
Déploiement non rétrocompatible

Dans ce cas, vous souhaitez mettre à jour le serveur de jeu en même temps que les clients de jeu, car vos clients de jeu actuels ne sont pas compatibles avec l’ancienne build de serveur. La transition d’une build à une autre s’effectue comme suit : Les anciens clients font référence à l’alias 1, dont la configuration est la suivante :
  • Build 1 : poids = 1
Une fois la build 2 créée, les nouveaux clients font référence à l’alias 2, dont la configuration est la suivante :
  • Build 2 : poids = 1
Dans ce scénario, les alias sont utilisés de la même manière que les builds, et leur fonctionnalité de multiplexage n’est pas utilisée.

​
Déploiement massif rétrocompatible

Ce scénario est semblable à celui de la mise à niveau rétrocompatible d’une build à une autre, mais avec un changement plus soudain du comportement de la demande. La transition d’une build à une autre s’effectue comme suit : Les clients font référence à l’alias 1, dont la configuration est la suivante :
  • Build 1 : poids = 1
Une fois la build 2 créée, l’alias 1 est modifié comme suit :
  • Build 1 : poids = 0
  • Build 2 : poids = 1

​
Test d’un déploiement rétrocompatible

Lorsque vous souhaitez mettre à jour le serveur de jeu et que la version du client est compatible avec les deux serveurs, mais que vous voulez tester la deuxième version avant de la déployer à grande échelle pour tous les joueurs. Le test et la transition d’une build à une autre peuvent s’effectuer comme suit : Les clients font référence à l’alias 1, dont la configuration est la suivante :
  • Build 1 : poids = 1
Une fois la build 2 créée, les clients de test font référence à l’alias 2, dont la configuration est la suivante :
  • Build 2 : poids = 1
Une fois la build 2 vérifiée, l’alias 1 est modifié comme suit :
  • Build 1 : poids = 8
  • Build 2 : poids = 2
Progressivement, la build 2 reçoit un poids plus élevé et absorbe tout le trafic.

​
Basculement vers d’autres builds et régions

Les alias peuvent rendre vos déploiements de serveurs multijoueurs plus résilients en permettant le basculement entre plusieurs builds. Lorsque vous demandez un serveur à partir d’un alias, indiquez dans PreferredRegions, par ordre de préférence, chaque région qui offre une expérience acceptable à vos joueurs. PlayFab Multiplayer Servers (MPS) traite chaque demande comme suit :
  1. MPS utilise les poids des builds pour ordonner les builds de l’alias pour la demande. Une build ayant un poids plus élevé a plus de chances d’arriver en premier.
  2. MPS parcourt vos régions dans l’ordre où vous les avez indiquées. Dans chaque région, il essaie chaque build dans cet ordre. Il ignore les builds qui ne sont pas déployées dans la région.
  3. MPS alloue un serveur à partir de la première build qui dispose d’un serveur StandingBy. Si aucune build n’en a dans la région, MPS passe à la région suivante. Si aucune région n’en a, la demande échoue avec l’erreur MultiplayerServerTooManyRequests.
L’ordre des régions a toujours priorité sur les poids des builds. Les joueurs obtiennent un serveur dans la région préférée la mieux classée qui dispose de capacité, et les poids déterminent uniquement quelle build les sert dans cette région. Utilisez les poids pour exprimer vos préférences en matière de coût et de performance entre les builds, par exemple entre des tailles de machines virtuelles (VM). Ajouter à un alias des builds couvrant davantage de régions ne peut qu’augmenter la capacité. Une build ayant un poids de 0 n’est jamais utilisée pour les allocations, pas même comme solution de basculement. Pour conserver une build comme solution de basculement, attribuez-lui plutôt un petit poids non nul, par exemple 1 contre 999 pour votre build principale. Si aucune des builds de l’alias n’est déployée dans l’une des régions demandées, la demande échoue avec l’erreur MultiplayerServerNotFound. Pour savoir comment éviter ces deux erreurs, consultez Pratiques exemplaires et liste de vérification du lancement. Par exemple, supposons qu’une demande d’allocation ciblant un alias de build classe EastUS comme région n° 1 et West US comme région n° 2. Cet alias de build attribue des poids semblables à deux builds, la build 1 et la build 2. Supposons que la build 1 arrive en premier dans l’ordre pour une allocation donnée.
  1. Une allocation dans East US pour la build 1 est tentée.
  2. Si l’étape 1 échoue, une allocation dans East US pour la build 2 est tentée.
  3. Si l’étape 2 échoue, une allocation dans WestUS pour la build 1 est tentée.
  4. Si l’étape 3 échoue, une allocation dans WestUs pour la build 2 est tentée.
En particulier lorsque vous effectuez une mise à niveau progressive d’une build à une autre, ce comportement de basculement est optimisé pour que les joueurs obtiennent le serveur offrant la latence la plus faible, même si l’une des builds éprouve des difficultés.

​
Gérer un alias de build avec les API REST de PlayFab

Vous pouvez désormais gérer les alias de build dans Game Manager. Pour commencer, consultez la page de vue d’ensemble des builds
  1. Créez un alias de build à l’aide de l’API. API :
    Exemple de corps :
    Exemple de réponse :
    L’ID de l’alias de build est fourni dans la réponse.
  2. Mettez à jour n’importe quel paramètre de l’alias de build. API :
    Exemple de corps :
    Exemple de réponse :
  3. Supprimez un alias de build. API :
    Exemple de corps :
  4. Listez les alias de build. API :
    Exemple de réponse :

​
Allouer à l’aide d’un alias de build

Pour effectuer une allocation à l’aide d’un alias de build, spécifiez l’ID de l’alias de build dans l’appel RequestMultiplayerServer. API :
Exemple de corps :
Dernière modification le 12 octobre 2026

Sujets connexes

Authentification des services XBOX pour les services de titreChangement d'éditeur parent d'un jeuVue d'ensemble des privilèges utilisateur des services XBOXProcédures pas à pas et exemples de Game SavesGestion des sessions multijoueur de service à service