> ## 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. # Configuration du matchmaking dans Partner Center > Configurez le matchmaking SmartMatch dans Partner Center pour les titres XBOX, notamment les modèles de session, les règles de hopper et les règles d'équipe pour la mise en relation de joueurs compatibles. Cette rubrique explique comment configurer Partner Center pour sélectionner des joueurs compatibles. [Configuration des opérations d'exécution du matchmaking SmartMatch](#SmartMatch-config) [Définition des règles d'équipe lors de la configuration de SmartMatch](#SmartMatch-defining) ## Configuration des opérations d'exécution du matchmaking SmartMatch Toute la configuration du matchmaking SmartMatch s'effectue dans [Partner Center](https://partner.microsoft.com/dashboard). ### Configuration des modèles de session de matchmaking Le matchmaking comporte deux types de sessions associées. * La *session de ticket de match*, qui constitue l'entrée du service de matchmaking * La *session cible de match*, qui constitue la sortie Lors de la configuration des modèles de session, vous devez créer un modèle pour chaque type de session. Pour une session de ticket, vous pouvez utiliser un modèle dédié. Vous pouvez également réutiliser un modèle prévu pour une session de salon ou une autre session qui n'est pas destinée au jeu proprement dit. Les vérifications de qualité de service (QoS) ne doivent pas être activées pour la session de ticket, et celle-ci ne doit pas être marquée avec la fonctionnalité « gameplay ». Pour une session cible, vous devez utiliser un modèle destiné aux parties issues du matchmaking. Ce modèle doit comporter des paramètres qui activent les vérifications QoS entre pairs avant le début de la partie, et doit être marqué avec la fonctionnalité « gameplay ». Grâce à l'interface de configuration de Partner Center, vous pouvez associer chaque session à un ou plusieurs hoppers, chacun contenant des règles qui déterminent la façon dont les sessions sont mises en relation dans ce hopper. Pour plus d'informations, consultez la section Configuration de base des hoppers pour le matchmaking ci-dessous. ### Configuration de base des hoppers pour le matchmaking Cette section définit les champs utilisés pour configurer les champs de base d'un hopper. Après cette configuration, vous devez configurer les règles de hopper, comme décrit dans la section Configuration des règles de hopper plus loin dans cette rubrique. La capture d'écran suivante montre l'éditeur de hopper. Celui-ci est décrit dans les sections suivantes. Capture d'écran de l'éditeur de hopper #### Name Nom du hopper utilisé lors de la soumission d'une session au matchmaking. Ce nom doit correspondre à la valeur transmise en paramètre à la méthode [XblMatchmakingCreateMatchTicketAsync](/fr/reference/live/xsapi-c/matchmaking_c/functions/xblmatchmakingcreatematchticketasync) lors de la création du ticket de match. #### Min/Max Group Size Tailles minimale et maximale du groupe de joueurs à créer à partir des sessions du hopper. Le service de matchmaking tente de créer un groupe mis en relation aussi grand que possible, dans la limite de la taille maximale du groupe. Il crée toutefois un groupe mis en relation s'il parvient à réunir suffisamment de joueurs pour atteindre la taille minimale du groupe. #### Should Rule Expansion Cycles Pour une règle SHOULD, si aucune mise en relation n'aboutit, le service de matchmaking tente d'élargir l'espace de recherche et d'assouplir progressivement les règles de matchmaking fournies. Ce processus s'effectue sur plusieurs cycles, comme spécifié dans le champ Should Rule Expansion Cycles. Lors du dernier cycle d'expansion, les règles SHOULD sont abandonnées afin qu'elles n'empêchent plus la mise en relation des tickets. Elles restent toutefois utilisées pour déterminer la meilleure correspondance si plusieurs tickets sont disponibles. Seuls les types numérique et QoS sont élargis avant d'être abandonnés. Pour plus d'informations, consultez la section Configuration des règles de hopper plus loin dans cette rubrique. L'augmentation de la valeur du paramètre Should Rule Expansion Cycles offre davantage de cycles pour l'expansion des règles SHOULD. Elle augmente toutefois aussi la durée du matchmaking. La valeur par défaut est 3, ce qui suffit généralement pour la plupart des configurations. Les cycles d'expansion se produisent à intervalles fixes de cinq secondes. Après le dernier cycle d'expansion, aucune règle SHOULD n'est plus prise en compte pour le reste de la tentative de matchmaking. #### Ranked hopper En règle générale, SmartMatch empêche la mise en relation de joueurs qui se sont bloqués. Si l'option Ranked Hopper est sélectionnée, cette logique est contournée afin d'empêcher les joueurs d'utiliser ce système pour éviter des joueurs plus compétents. ### Configuration des règles de hopper Cette section définit les champs utilisés pour configurer les règles d'un hopper. #### Champs communs des règles Les champs définis dans cette section sont communs à toutes les règles de hopper. * **Rule Name :** nom convivial affiché pour la règle à des fins de configuration. * **Rule Type :** type de la règle. Les options sont MUST et SHOULD. * Les règles MUST doivent être satisfaites pour que le matchmaking aboutisse. * Les règles SHOULD peuvent être assouplies ou supprimées pour trouver une correspondance. Pour plus de détails sur ce processus, consultez la section Should Rule Expansion Cycles plus haut dans cette rubrique. * **Data Type :** type de données de l'attribut de la règle de matchmaking. Les valeurs possibles sont les suivantes. * **Number :** spécifiez une simple valeur numérique 32 bits. * **String :** spécifiez une chaîne Unicode de 128 caractères au maximum. * **Collection :** spécifiez un tableau de chaînes. Utilisez cette valeur pour identifier le contenu téléchargeable (DLC), l'appartenance à une escouade ou la préférence de rôle des joueurs. * **Quality of Service :** spécifiez un type de données personnalisé permettant d'inclure les données QoS de latence dans le matchmaking. Une seule règle de ce type doit être utilisée par hopper de matchmaking. > \[!NOTE] > Si cette limite pose problème pour votre titre, contactez votre gestionnaire de compte développeur (DAM). * **Total Value :** spécifiez un type de données personnalisé qui additionne les valeurs de matchmaking soumises. Vous pouvez utiliser cette valeur pour vous assurer que la somme obtenue se situe dans une plage spécifique ou correspond à une valeur exacte. * **Team :** spécifiez un type de données personnalisé pour les équipes de joueurs incluses dans les demandes de matchmaking. Vous pouvez utiliser cette valeur pour éviter de répartir les joueurs d'un même ticket de match entre plusieurs équipes. #### Champs de règle propres à certains types de données Cette section définit les champs utilisés pour définir des règles qui s'appliquent à certains types de données mais pas à d'autres. L'interface utilisateur doit permettre de déterminer clairement quels types de données s'appliquent à quelles règles. * **Allow Wildcards :** valeur qui indique si l'attribut peut être omis dans le ticket de match. S'il est omis, le ticket devient compatible avec tout autre ticket, quelle que soit la valeur de cet attribut. * **Attribute Source :** source de la valeur du type de données. Les sources possibles sont les suivantes. * **Title provided :** la valeur des données est soumise dans le ticket de match. * **User stat instance :** la valeur des données est automatiquement récupérée auprès du service `UserStatistics`. * **Attribute Name :** nom de la source de la valeur de l'attribut. Il s'agit soit du nom de la propriété dans le ticket de match, soit du nom d'une statistique utilisateur. * **Default Value :** valeur par défaut du type de données, si aucune valeur n'est spécifiée ou disponible pour la demande de matchmaking. La valeur par défaut n'est pas appliquée lorsque le champ Allow Wildcards est sélectionné et qu'aucune valeur n'est spécifiée. * **Weight :** importance de la règle. Le poids permet d'indiquer les règles prioritaires lors du matchmaking et de l'expansion des règles. La valeur du poids doit être un nombre positif ; sa valeur par défaut est 1. * **Flatten Method :** types de données numériques uniquement. Valeur qui indique comment plusieurs valeurs sont combinées pour satisfaire une correspondance. Elle s'applique aux valeurs multiples de différents joueurs d'un même ticket de match et entre plusieurs tickets. Les valeurs possibles sont les suivantes. * **Min/Max :** utilise la valeur minimale ou maximale parmi plusieurs valeurs provenant de différents tickets de match. * **Average :** utilise la moyenne de plusieurs valeurs provenant de différents tickets de match. * **Max Diff :** types de données numériques uniquement. Différence numérique maximale acceptable entre deux valeurs comparées pour satisfaire une règle. Pour une règle SHOULD, cette valeur constitue le point de départ de l'expansion de la règle. * **Set Operation :** types de données collection uniquement. Opération à effectuer lors de la mise en correspondance du groupe de valeurs de l'ensemble. Les options possibles sont les suivantes. * **Intersection :** met en correspondance deux collections en fonction de leur degré d'intersection. Ce paramètre produit des valeurs de collection similaires ou identiques. * **Difference :** met en correspondance deux collections en fonction de leur degré de différence. * **Role Preference :** met en correspondance des collections en fonction des préférences de rôle d'un joueur dans les modes de jeu basés sur des rôles. * **Target Intersection :** fait partie de la configuration de Set Operation. Intersection minimale ou différence maximale entre deux collections avant leur mise en correspondance. * **Network Topology :** type de données Quality of Service uniquement. Topologie réseau utilisée pour la QoS. Les valeurs possibles sont Peer to Peer, Peer to Host et Client/Server. * **Maximum Latency/Scaling Maximum :** type de données Quality of Service uniquement. Latence maximale permettant un matchmaking réussi dans la topologie réseau spécifiée. Cette valeur est traitée comme une valeur d'échelle (et non comme une latence requise) lors de l'utilisation d'une règle SHOULD Quality of Service Client/Server. > \[!NOTE] > En outre, des règles de réputation par défaut sont également appliquées à un hopper. Ces règles ne peuvent pas être supprimées et servent à garantir une gestion correcte de la réputation pendant le matchmaking. * **Allow Waiting for Roles :** type de données Collection Role Preferences uniquement. Indique si le service de mise en relation conserve le ticket de matchmaking jusqu'à ce que tous les rôles disponibles soient pourvus. #### Delta d'expansion Valeur qui indique dans quelle mesure assouplir la règle soumise à chaque génération d'expansion. Le delta d'expansion s'applique en plus de la valeur Max Diff. Pour plus de détails, consultez l'Exemple 1 (expansion de règle) plus loin dans cette rubrique. Vous pouvez également utiliser le delta d'expansion pour élargir plusieurs valeurs numériques à des vitesses différentes. Cela n'est pas possible au moyen du paramètre de configuration des cycles d'expansion, car celui-ci s'applique à toutes les règles. L'approche consiste plutôt à utiliser des valeurs d'expansion décimales ; par exemple, 0,4. Une expansion ne se produit que lorsqu'un nouvel entier est atteint, ce qui permet des vitesses d'expansion différentes, même pour un même nombre de cycles d'expansion. #### Expansion QoS (pair à pair, pair à hôte) Pour l'expansion de type QoS des jeux entre pairs, le delta d'expansion ne peut pas être configuré. Vous devez plutôt utiliser l'une des stratégies d'expansion suivantes. 1. MaxLatency inférieure à 256 L'expansion s'effectue selon MaxLatency × cycle d'expansion. Par exemple, si la valeur initiale est 200, la valeur 200 est utilisée au premier cycle et 400 au deuxième cycle. 2. MaxLatency supérieure ou égale à 256 L'expansion évolue linéairement de 50 à MaxLatency - 256. Par exemple, si la valeur initiale est 556, la valeur évolue linéairement de 50 à 300 sur le nombre de cycles. Autrement dit, si six cycles ont été choisis, les valeurs sont 50, 100, 150, 200, 250 et 300. Si cinq cycles ont été choisis, les valeurs sont 50, 112,5, 175, 237,5 et 300. #### Expansion QoS (client/serveur) Lors de l'utilisation de serveurs dédiés, l'expansion repose sur la préférence relative. Seuls les serveurs les plus préférés sont pris en compte lors des premiers cycles d'expansion. Au fil du temps, d'autres serveurs moins préférés sont utilisés. Pour garantir une expansion appropriée, nous exigeons une valeur semblable à MaxLatency, appelée *Scaling Maximum*. Elle doit toujours être définie sur le temps de ping le plus élevé acceptable. Toutefois, cette valeur fournit une échelle relative pour les différents temps de ping des serveurs fournis par un joueur, plutôt qu'une exigence absolue en matière de temps de ping. Vous pouvez exclure les serveurs dont les temps de ping sont inacceptables en les supprimant de la liste de la demande. [Revenir au début de cette rubrique.](#top) #### Exemple 1 (expansion de règle) Le niveau du joueur est utilisé pour le matchmaking, et les joueurs sont mis en relation de façon souple, en fonction de la proximité de leurs niveaux. Les joueurs dont les niveaux présentent le moins d'écart sont privilégiés. * Règle de niveau du joueur * Rule Type : SHOULD * Data Type : Number * Max Diff : 1 * Expansion Delta : 2 * Flatten Method : Average Par défaut, l'écart requis entre les niveaux des joueurs est inférieur ou égal à 1. * Si une correspondance est trouvée dans cet écart, les joueurs sont mis en relation. * Si aucune correspondance initiale n'est trouvée, la valeur du niveau du joueur est élargie de 2 à chaque itération (par défaut, il y a trois itérations). Ce scénario donne lieu, pour un joueur de niveau 20, au comportement de matchmaking indiqué dans le tableau suivant. \| Étape | Valeur de niveau des candidats potentiels | Écart de niveau effectif pour une mise en relation réussie | \|-----| \| Valeur soumise initiale | 19-21 | 1 | \| Cycle d'expansion 1 | 17-23 | 3 | \| Cycle d'expansion 2 | 15-25 | 5 | \| Cycle d'expansion 3 | 13-27 | 7 | Au fil des cycles d'expansion, l'écart de niveau effectif pour une mise en relation réussie augmente sans que la valeur Max Diff soit modifiée. Seule la valeur du niveau du joueur est assouplie. #### Exemple 2 (règle de collection) Le jeu publie trois types de DLC disponibles pour les joueurs. Cette règle de matchmaking s'applique au matchmaking des parties « DLC uniquement », et un joueur doit posséder au moins un DLC pour être mis en relation avec d'autres joueurs. * Règle de DLC du joueur * Rule Type : MUST * Data Type : Collection * Set Operation : Intersection * Target Intersection : 1 Les joueurs évaluent leurs DLC et soumettent dans leurs tickets de match les valeurs indiquées dans le tableau suivant. Dans le tableau suivant, la valeur de collection indique la possession du DLC. Si le DLC est disponible pour le joueur, la valeur est définie sur 1. Sinon, elle est définie sur 0. | | Joueur | Valeur de collection | Mis en relation avec les joueurs | Remarques | | - | - | - | - | | Joueur 1 | { "1", "1", "1"} | 3 | Possède tous les DLC | | Joueur 2 | { "0", "0", "0"} | Aucun | Ne possède aucun DLC | | Joueur 3 | { "1", "0", "0"} | 1 | Possède le premier DLC | Si l'intersection cible de cet exemple est définie sur 2, les joueurs 1 et 3 ne sont pas mis en relation, car leur intersection n'est que de 1. #### Exemple 3 (éviter les joueurs précédents) Le titre préfère éviter une partie avec le joueur affronté le plus récemment. * Rule Type : MUST * Data Type : Collection * Set Operation : Difference * Target Intersection : 0 [Revenir au début de cette rubrique.](#top) ## Définition des règles d'équipe lors de la configuration de SmartMatch ### Configuration des règles d'équipe Pour configurer la règle d'équipe (Team Rule), commencez par en créer une dans Partner Center. Renseignez les tailles d'équipe que votre jeu prévoit de créer à partir des tickets mis en relation dans ce hopper. Par exemple, si votre jeu prévoit du quatre contre quatre, vous devez créer deux entrées, chacune avec une taille maximale de quatre et un nom différent. Il existe également une taille d'équipe minimale. Utilisez-la si une partie peut se jouer avec moins de joueurs dans une équipe. Sinon, le minimum et le maximum doivent avoir la même valeur. ### Utilisation des règles d'équipe Une fois la règle d'équipe configurée, les tickets du hopper ne peuvent pas être mis en relation s'il est impossible de répartir leurs groupes en équipes sans les scinder. La règle écrit la répartition des équipes obtenue dans la session cible, sous *members/constants/custom/matchmakingresult/initialTeam*. Il ne s'agit que d'une répartition suggérée. Le titre peut constater qu'en réorganisant les joueurs, il peut créer une meilleure partie tout en évitant que des tickets soient répartis dans des équipes différentes. Si un ticket est créé pour une partie en cours, la règle d'équipe nécessite des informations supplémentaires. Supposons, par exemple, que huit joueurs disputent une partie en quatre contre quatre lorsque deux joueurs abandonnent ou sont déconnectés. Le titre souhaite pourvoir ces places vacantes, mais il ne peut pas remanier les équipes pendant la partie. Les tentatives de compléter des parties en cours sont représentées par des tickets dont le champ `PreserveSession` est défini sur `always`. Dans ce cas, comme les équipes ont déjà été attribuées aux joueurs, le titre doit spécifier la répartition actuelle des équipes, afin que le service de mise en relation sache combien de places sont disponibles dans chaque équipe. Pour fournir le nom de l'équipe de chaque joueur, chaque joueur écrit le nom de son équipe dans la session de jeu, sous *members/me/properties/system/groups*. Ce champ est un `JArray`. Une fois les propriétés mentionnées précédemment écrites dans la session de jeu, un joueur crée un ticket pour la session afin de trouver d'autres joueurs. Lorsque le ticket est satisfait, le service de mise en relation écrit de nouveau l'équipe suggérée de tous les joueurs qui rejoignent la partie dans *members/constants/custom/matchmakingresult/initialTeam*. #### Préférence pour des équipes équilibrées En outre, les mises en relation commencent par les équipes les plus grandes. Cela signifie que, dans un hypothétique hopper en quatre contre quatre, les tickets de quatre joueurs sont d'abord mis en relation entre eux, jusqu'à ce qu'il ne reste plus de tickets de quatre. Les tickets de trois sont ensuite traités, en intégrant des joueurs seuls si nécessaire, et ainsi de suite. De cette manière, les tickets de taille similaire s'affrontent généralement, s'ils sont présents et que d'autres règles ne l'empêchent pas. Cela confère à la règle d'équipe une priorité assez forte sur les autres règles. Par exemple, supposons que vous disposiez d'une population limitée, composée d'un ticket de taille 4 de haut niveau (A), d'un ticket de taille 4 de faible niveau (B) et de quatre tickets de taille 1 de haut niveau (C-F). La règle d'équipe amène le service de mise en relation à privilégier la mise en relation de A et B, plutôt que celle de A, C, D, E et F. #### Variante SHOULD La règle MUST empêche la scission des tickets à toutes les générations et fournit le tri privilégiant des équipes équilibrées. La règle SHOULD est identique jusqu'à la dernière génération : à ce stade, les tickets peuvent être scindés, bien que le tri privilégiant des équipes équilibrées reste actif. [Revenir au début de cette rubrique.](#top) ## Voir aussi [Modèles de session multijoueur](/fr/services/xbox-services/multiplayer/mpsd/concepts/live-session-templates) [Vue d'ensemble du Multiplayer Session Directory](/fr/services/xbox-services/multiplayer/mpsd/live-mpsd-overview) ## Related topics - [Configuration](/fr/services/xbox-services/multiplayer/matchmaking/config/index.md) - [Configuration du matchmaking dans le portail](/fr/services/xbox-services/multiplayer/matchmaking/config/live-matchmaking-config-nav.md) - [Vue d'ensemble du matchmaking](/fr/services/xbox-services/multiplayer/matchmaking/live-matchmaking-overview.md) - [Vue d'ensemble de la configuration du portail](/fr/services/xbox-services/fundamentals/portal-config/live-portal-config-overview.md) - [Configuration initiale dans Partner Center](/fr/publishing/xstore-commerce/xstore-initial-configuration.md)