> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Pratiques exemplaires et liste de vérification du lancement

> Pratiques exemplaires et liste de vérification du lancement pour PlayFab Multiplayer Servers, couvrant le développement, les tests avec LocalMultiplayerAgent, la mise à l'échelle et les opérations en direct.

* Faites en sorte que le processus de votre serveur de jeu se termine lorsque sa session de jeu est terminée, par exemple à la fin du match ou lorsque le dernier joueur connecté quitte. Si votre jeu permet aux joueurs de se reconnecter, attendez d'abord une courte période de grâce. MPS ne met pas fin à une session de jeu à votre place. Un serveur reste Active jusqu'à ce que son processus se termine. MPS ne supprime pas les serveurs Active lorsque votre build est réduite; un serveur qui ne se termine jamais continue donc d'utiliser une capacité que vous payez. Lorsque le processus se termine, MPS le remplace par un nouveau serveur. Pour plus d'informations, consultez [Cycle de vie d'un serveur multijoueur](/fr-CA/services/playfab/multiplayer/servers/multiplayer-game-server-lifecycle).

* Démarrez une minuterie lorsque votre serveur devient Active, par exemple lorsque la méthode `ReadyForPlayers` du SDK de serveur de jeu (GSDK) retourne `true`. Si aucun joueur ne se connecte en quelques minutes, terminez le processus. Ainsi, un serveur que personne ne rejoint, pour quelque raison que ce soit, ne reste pas Active indéfiniment. Basez le délai d'expiration sur le temps que vos joueurs mettent habituellement à se connecter.

* Inscrivez un rappel d'arrêt du GSDK qui effectue le nettoyage nécessaire à votre serveur, puis termine le processus. Le GSDK ne termine pas le processus à votre place. MPS appelle votre rappel lorsque vous appelez l'API [ShutdownMultiplayerServer](xref:titleid.playfabapi.com.multiplayer.multiplayerserver.shutdownmultiplayerserver). N'appelez cette API qu'en cas d'urgence, par exemple pour arrêter des serveurs de jeu bloqués. Ne l'utilisez pas pour mettre fin à des sessions de jeu dans des circonstances normales. Vos serveurs de jeu devraient se terminer d'eux-mêmes, comme décrit plus tôt dans cette section. Si le processus est toujours en cours d'exécution 15 minutes après une demande d'arrêt, MPS y met fin de force. Pour plus d'informations, consultez [Arrêt approprié de votre serveur de jeu](/fr-CA/services/playfab/multiplayer/servers/integrating-game-servers-with-gsdk#gracefully-shutting-down-your-game-server).

Voici quelques pratiques exemplaires pour les différentes étapes du cycle de vie du jeu, afin de tirer le meilleur parti de PlayFab Multiplayer Servers (MPS) :

## Développement

* Utilisez [LocalMultiplayerAgent (LMA)](https://github.com/PlayFab/MpsAgent) pour effectuer des tests itératifs sur votre poste de travail local. Cela permet d'économiser temps et argent tout en simplifiant le débogage, puisque tous les artefacts s'exécutent localement. L'outil est en code source libre, et les contributions et améliorations sont toujours les bienvenues. Pour plus de détails sur son utilisation, cliquez [ici](/fr-CA/services/playfab/multiplayer/servers/locally-debugging-game-servers-and-integration-with-playfab)

* Utilisez les [planifications](/fr-CA/services/playfab/multiplayer/servers/scheduled-standby) pour configurer des horaires précis afin de réduire les coûts des serveurs StandingBy. Par exemple, si tous les tests et toutes les validations sont effectués pendant les heures ouvrables, la planification peut être configurée pour n'avoir des serveurs en attente que pendant les heures ouvrables. La configuration des planifications n'entraîne aucuns frais supplémentaires.

* Utilisez les [métriques de machine virtuelle](/fr-CA/services/playfab/multiplayer/servers/vm-metrics) ou vos propres [profileurs](/fr-CA/services/playfab/multiplayer/servers/attaching-a-profiler) pour déterminer le nombre de serveurs de jeu à exécuter sur une machine virtuelle de la taille choisie. Effectuez des tests de charge avec tous les serveurs de la machine virtuelle à l'état Active et remplis de joueurs. Les serveurs d'une même machine virtuelle peuvent être alloués et démarrer leurs sessions de jeu presque en même temps; incluez donc ce cas dans vos tests. Conservez une marge de processeur : sur une machine virtuelle dont le processeur est saturé, les allocations peuvent être lentes ou échouer.

* Utilisez les [journaux de serveur](/fr-CA/services/playfab/multiplayer/servers/archiving-and-retrieving-multiplayer-server-logs) et les [vidages sur incident](/fr-CA/services/playfab/multiplayer/servers/crash-dump-collection) pour une analyse plus approfondie.

## Préparation au lancement

* Orientez vos demandes d'allocation vers des [alias de build](/fr-CA/services/playfab/multiplayer/servers/allocating-with-build-alias). Ils facilitent la migration harmonieuse des clients de jeu vers de nouveaux serveurs de jeu lors des mises à jour de serveur et peuvent également aider à gérer les problèmes de quota (abordés plus loin).

* Utilisez les [balises QoS](/fr-CA/services/playfab/multiplayer/servers/using-qos-beacons-to-measure-player-latency-to-azure) pour déterminer la région la plus proche d'un client de jeu et l'utiliser pour les allocations. Elles peuvent également être combinées avec [PlayFab Matchmaking](/fr-CA/services/playfab/multiplayer/matchmaking) pour regrouper les clients ayant des latences semblables et allouer un serveur le plus proche possible d'eux.

* Tirez pleinement parti de la couverture géographique de PlayFab MPS pour vous assurer que les serveurs de jeu sont toujours situés près de vos joueurs. Envisagez d'utiliser plusieurs régions dans une zone géographique pour offrir une plus grande disponibilité en cas de défaillance régionale. Par exemple, avoir des serveurs dans NorthEurope et WestEurope et spécifier les deux régions dans la demande d'allocation (par ordre de priorité) permet à une allocation qui échoue dans une région de réussir dans la région suivante de la liste.

* Lorsque vous effectuez une allocation à partir d'un [alias de build](/fr-CA/services/playfab/multiplayer/servers/allocating-with-build-alias), indiquez dans `PreferredRegions`, par ordre de préférence, chaque région qui offre une expérience acceptable à vos joueurs. MPS essaie vos régions dans cet ordre, et les poids des builds déterminent uniquement quelle build traite une demande au sein d'une région. Une build ayant un poids de 0 n'est jamais utilisée, pas même comme solution de basculement. Pour plus de détails, consultez [Basculement vers d'autres builds et régions](/fr-CA/services/playfab/multiplayer/servers/allocating-with-build-alias#fallback-to-other-builds-and-regions).

* Si [RequestMultiplayerServer](xref:titleid.playfabapi.com.multiplayer.multiplayerserver.requestmultiplayerserver) échoue avec l'erreur `MultiplayerServerTooManyRequests`, aucune des builds ne disposait d'un serveur StandingBy dans l'une des régions demandées. Malgré son nom, cette erreur ne signifie pas que vos demandes font l'objet d'une limitation. Pour l'éviter :

  * Indiquez plusieurs régions voisines dans `PreferredRegions`.
  * Configurez vos serveurs en attente en fonction de votre pic prévu.
  * Définissez le nombre maximal de serveurs pour chaque région de build avec une marge supérieure à votre pic prévu. MPS ne crée pas de serveurs au-delà de ce maximum, même lorsque les serveurs en attente sont épuisés.

* Demandez un [quota](/fr-CA/services/playfab/multiplayer/servers/quota-changes) bien avant le lancement, pour chaque famille de machines virtuelles et chaque région utilisées par vos builds. Lorsque vous déployez une nouvelle build, l'ancienne et la nouvelle build utilisent des cœurs en même temps jusqu'à ce que les serveurs de l'ancienne build se vident; demandez donc un quota suffisant pour les deux. Pour répartir votre capacité, envisagez de placer des builds utilisant différentes familles de machines virtuelles derrière le même alias, afin que les allocations puissent basculer vers une autre famille de machines virtuelles dans la même région.

* Il peut arriver que la référence SKU de machine virtuelle de votre serveur de jeu ne soit pas disponible dans toutes les régions où le lancement du jeu est prévu. Dans ce cas, utilisez des alias pour répartir les builds par référence SKU et par région, ou utilisez des remplacements de région au sein d'une même build pour choisir une autre référence SKU de machine virtuelle uniquement pour ces régions.

* Utilisez [Dynamic StandingBy](/fr-CA/services/playfab/multiplayer/servers/dynamic-standby) pour augmenter le nombre de serveurs de jeu en fonction de la demande. Combiné à la configuration StandingBy statique par défaut, cela peut constituer un moyen économique de gérer une forte demande lors du lancement.

* Configurez la surveillance de vos serveurs de jeu avant le lancement. Activez les [métriques de machine virtuelle](/fr-CA/services/playfab/multiplayer/servers/vm-metrics) pour afficher les métriques de processeur, de mémoire, de disque et de réseau de vos machines virtuelles dans Game Manager. Pour une surveillance plus avancée, utilisez [VmStartupScript](/fr-CA/services/playfab/multiplayer/servers/vmstartupscript) pour installer vos propres outils de surveillance sur vos machines virtuelles. Le référentiel [VmStartupScriptGallery](https://github.com/PlayFab/VmStartupScriptGallery) contient des exemples qui envoient les métriques de machine virtuelle et les journaux de serveur de jeu à des services tels qu'Azure Monitor, Application Insights et Azure Data Explorer.

## Jour du lancement

* Suivez le succès du lancement de votre jeu à l'aide des tableaux de bord et des flux d'événements de [PlayFab Game Manager](https://developer.playfab.com/). Prenez le temps de célébrer, vous l'avez bien mérité!

## Après le lancement

* Les jeux ont tendance à suivre un rythme de demande qui peut lui aussi être traduit en [planifications](/fr-CA/services/playfab/multiplayer/servers/scheduled-standby). Utilisez les planifications avec [Dynamic StandingBy](/fr-CA/services/playfab/multiplayer/servers/dynamic-standby) pour une mise à l'échelle économique du jeu après le lancement.

* Utilisez les [alias de build](/fr-CA/services/playfab/multiplayer/servers/allocating-with-build-alias) pour les mises à jour des serveurs de jeu et pour réorienter progressivement le trafic vers la nouvelle expérience de jeu.

* Lorsque vous faites passer un alias à de nouvelles builds, définissez à 0 les serveurs en attente des anciennes builds afin que MPS puisse libérer leurs machines virtuelles inactives. Ne supprimez les anciennes builds qu'une fois leurs serveurs Active vidés. Veillez également à ce que les régions demandées par vos clients restent synchronisées avec les régions où les builds de l'alias sont déployées. Si aucune des builds de l'alias n'est déployée dans l'une des régions demandées, la demande échoue avec `MultiplayerServerNotFound`.


## Related topics

- [Pratiques exemplaires](/fr-CA/services/xbox-services/develop/best-practices/index.md)
- [XAG 123 : Pratiques exemplaires en matière de santé mentale](/fr-CA/build/game-principles/accessibility/xag-deep-dives/xag-123-mental-health-best-practices.md)
- [Pratiques exemplaires et recommandations pour les expériences](/fr-CA/services/playfab/live-service-management/game-configuration/experiments/experimentation-keys.md)
- [Notions de base et pratiques exemplaires de connexion](/fr-CA/services/playfab/identity/player-identity/login/login-basics-best-practices.md)
- [Pratiques exemplaires pour appeler les services XBOX](/fr-CA/services/xbox-services/develop/best-practices/live-best-practices-calling-xbl.md)