> ## 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.

# Bonnes pratiques et liste de contrôle de lancement

> Bonnes pratiques et liste de contrôle de lancement pour PlayFab Multiplayer Servers, couvrant le développement, les tests avec LocalMultiplayerAgent, la mise à l'échelle et les opérations en production.

* Faites en sorte que le processus de votre serveur de jeu se termine à la fin de sa session de jeu, par exemple à la fin du match ou lorsque le dernier joueur connecté quitte la partie. Si votre jeu permet aux joueurs de se reconnecter, attendez d'abord un court délai 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 réduit sa capacité : 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/services/playfab/multiplayer/servers/multiplayer-game-server-lifecycle).

* Démarrez un minuteur lorsque votre serveur passe à l'état Active, par exemple lorsque la méthode `ReadyForPlayers` du Game Server SDK (GSDK) renvoie `true`. Si aucun joueur ne se connecte en quelques minutes, terminez le processus. Ainsi, un serveur que personne ne rejoint, quelle qu'en soit la raison, ne reste pas Active indéfiniment. Basez le délai d'expiration sur le temps que mettent habituellement vos joueurs à se connecter.

* Inscrivez un rappel d'arrêt 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 aux sessions de jeu dans des circonstances normales. Vos serveurs de jeu doivent se terminer d'eux-mêmes, comme décrit plus haut dans cette section. Si le processus est toujours en cours d'exécution 15 minutes après une demande d'arrêt, MPS l'arrête de force. Pour plus d'informations, consultez [Arrêt approprié de votre serveur de jeu](/fr/services/playfab/multiplayer/servers/integrating-game-servers-with-gsdk#gracefully-shutting-down-your-game-server).

Voici quelques bonnes pratiques 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 station de travail locale. Cela permet de gagner du temps et de l'argent tout en simplifiant le débogage, puisque tous les artefacts s'exécutent localement. L'outil est open source, et les contributions et améliorations sont toujours les bienvenues. Plus d'informations sur son utilisation sont disponibles [ici](/fr/services/playfab/multiplayer/servers/locally-debugging-game-servers-and-integration-with-playfab)

* Utilisez les [planifications](/fr/services/playfab/multiplayer/servers/scheduled-standby) pour définir des plannings concrets afin de réduire les coûts des serveurs standingBy. Par exemple, si tous les tests et validations sont effectués pendant les heures de bureau, la planification peut être définie pour n'avoir des serveurs standingBy que pendant ces heures. La configuration de planifications n'entraîne aucun coût supplémentaire.

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

* Utilisez les [journaux du serveur](/fr/services/playfab/multiplayer/servers/archiving-and-retrieving-multiplayer-server-logs) et les [vidages sur incident](/fr/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/services/playfab/multiplayer/servers/allocating-with-build-alias). Ils facilitent la migration transparente des clients de jeu vers de nouveaux serveurs de jeu lors des mises à jour de serveurs et peuvent également aider à gérer les problèmes de quota (abordés plus loin).

* Utilisez les [balises QoS](/fr/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/services/playfab/multiplayer/matchmaking) pour regrouper les clients ayant des latences similaires et leur allouer le serveur le plus proche.

* Exploitez toute l'étendue de la couverture géographique de PlayFab MPS pour vous assurer que les serveurs de jeu sont toujours situés à proximité de vos joueurs. Envisagez d'utiliser plusieurs régions dans une même zone géographique pour bénéficier d'une plus grande disponibilité en cas de défaillance régionale. Par exemple, disposer de 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/services/playfab/multiplayer/servers/allocating-with-build-alias), indiquez dans `PreferredRegions` chaque région qui offre une expérience acceptable à vos joueurs, par ordre de préférence. 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 dont le poids est de 0 n'est jamais utilisée, pas même comme solution de repli. Pour plus d'informations, consultez [Basculement vers d'autres builds et régions](/fr/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 requêtes sont limitées. Pour l'éviter :

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

* Demandez un [quota](/fr/services/playfab/multiplayer/servers/quota-changes) bien avant le lancement, pour chaque famille de VM et chaque région utilisées par vos builds. Lorsque vous déployez une nouvelle build, l'ancienne et la nouvelle utilisent des cœurs simultanément 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 VM derrière le même alias, afin que les allocations puissent basculer vers une autre famille de VM 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 jeu doit être lancé. Dans ce cas, utilisez des alias pour répartir les builds par 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/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 VM](/fr/services/playfab/multiplayer/servers/vm-metrics) pour afficher les métriques de CPU, de mémoire, de disque et de réseau de vos VM dans Game Manager. Pour une surveillance plus avancée, utilisez [VmStartupScript](/fr/services/playfab/multiplayer/servers/vmstartupscript) afin d'installer vos propres outils de surveillance sur vos VM. Le référentiel [VmStartupScriptGallery](https://github.com/PlayFab/VmStartupScriptGallery) contient des exemples qui envoient les métriques de VM et les journaux des serveurs de jeu vers des services tels qu'Azure Monitor, Application Insights et Azure Data Explorer.

## Jour du lancement

* Suivez la réussite du lancement de votre jeu grâce aux tableaux de bord et aux 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 suivent généralement un rythme de demande qui peut à nouveau être traduit en [planifications](/fr/services/playfab/multiplayer/servers/scheduled-standby). Utilisez les planifications avec [Dynamic StandingBy](/fr/services/playfab/multiplayer/servers/dynamic-standby) pour une mise à l'échelle économique du jeu après le lancement.

* Utilisez les [alias de build](/fr/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 pointer un alias vers de nouvelles builds, définissez à 0 les serveurs de secours des anciennes builds afin que MPS puisse libérer leurs VM 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 celles 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

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