Passer au contenu principal
Un alias de build est une couche de gestion située au-dessus des builds, qui permet de répartir de manière contrôlée les appels à RequestMultiplayerServer entre plusieurs builds. Cela peut simplifier et fiabiliser les mises à niveau d’une build à une autre, ainsi que plusieurs autres scénarios décrits ci-dessous. Pour ce faire, les alias spécifient une liste d’ID de build ainsi que le 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 n’a plus de serveurs StandingBy dans une région, ces demandes sont alors dirigées vers la build 2, qui peut ainsi traiter plus de 20 % des demandes dans cette région. Les régions de chaque demande sont toutefois prioritaires, et les poids déterminent uniquement quelle build traite une demande au sein d’une région. Pour plus d’informations, consultez Basculement vers d’autres builds et régions.

​
Déploiement sûr et rétrocompatible

Il s’agit du scénario le plus courant de mise à niveau d’une build à une autre : vous mettez à jour le serveur de jeu, et les clients commerciaux sont compatibles avec les deux serveurs. Les clients référencent l’alias 1, dont la configuration est la suivante :
  • Build 1: Weight = 1
Une fois la build 2 créée, l’alias 1 est modifié comme suit :
  • Build 1: Weight = 8
  • Build 2: Weight = 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’usage typique des alias consiste à les 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 si nécessaire.

​
Déploiement non rétrocompatible

Dans ce cas, vous souhaitez mettre à jour le serveur de jeu en même temps que les clients du jeu, car vos clients 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 référencent l’alias 1, configuré comme suit :
  • Build 1: Weight = 1
Une fois la build 2 créée, les nouveaux clients référencent l’alias 2, configuré comme suit :
  • Build 2: Weight = 1
Dans ce scénario, les alias sont utilisés comme des builds, et leur fonctionnalité de multiplexage n’est pas utilisée.

​
Déploiement immédiat et rétrocompatible

Ce scénario est semblable à celui de la mise à niveau rétrocompatible d’une build à une autre, mais avec un basculement plus brutal de la demande. La transition d’une build à une autre s’effectue comme suit : Les clients référencent l’alias 1, configuré comme suit :
  • Build 1: Weight = 1
Une fois la build 2 créée, l’alias 1 est modifié comme suit :
  • Build 1: Weight = 0
  • Build 2: Weight = 1

​
Test d’un déploiement rétrocompatible

Ce scénario s’applique lorsque vous souhaitez mettre à jour le serveur de jeu, 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 référencent l’alias 1, configuré comme suit :
  • Build 1: Weight = 1
Une fois la build 2 créée, les clients de test référencent l’alias 2, configuré comme suit :
  • Build 2: Weight = 1
Une fois la build 2 vérifiée, l’alias 1 est modifié comme suit :
  • Build 1: Weight = 8
  • Build 2: Weight = 2
Progressivement, le poids de la build 2 augmente jusqu’à ce qu’elle 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 chaque région qui offre une expérience acceptable à vos joueurs, par ordre de préférence. 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 dont le poids est 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 disposant d’un serveur StandingBy. Si aucune build n’en dispose dans la région, MPS passe à la région suivante. Si aucune région n’en dispose, la demande échoue avec l’erreur MultiplayerServerTooManyRequests.
L’ordre des régions prime toujours sur les poids des builds. Les joueurs obtiennent un serveur dans la région préférée disposant 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 performances entre les builds, par exemple entre différentes tailles de machine virtuelle (VM). L’ajout à un alias de builds couvrant davantage de régions ne peut qu’augmenter la capacité. Une build dont le poids est de 0 n’est jamais utilisée pour les allocations, pas même comme solution de repli. Pour conserver une build comme solution de repli, 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 Bonnes pratiques et liste de contrôle de 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 similaires à 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 la n° 1 échoue, une allocation dans East US pour la build 2 est tentée.
  3. Si la n° 2 échoue, une allocation dans WestUS pour la build 1 est tentée.
  4. Si la n° 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 rencontre des problèmes.

​
Gérer un alias de build avec les API REST 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. Répertoriez les alias de build. API:
    Exemple de réponse :

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

Pour allouer à 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

Allouer des serveurs de jeu et connecter le débogueur Visual StudioExemple WrapperIntégration avec PlayFab Multiplayer ServersRésolution des problèmes et commentairesExemples de scénarios et de configurations de matchmaking