Si vous arrivez depuis l'article d'ensemble sur la façon dont le taux de remplissage des sessions affecte les coûts d'hébergement, voici la suite. Vous savez que le taux de remplissage coûte de l'argent. Cet article explique quoi faire à ce sujet.

Les stratégies ci-dessous sont classées approximativement par impact et facilité de mise en œuvre. Toutes ne s'appliquent pas à tous les jeux, mais la plupart des studios disposant d'un matchmaker en service trouveront qu'au moins deux ou trois ne sont pas encore pleinement exploitées.

Commencez par un diagnostic, pas par une solution

Régler la configuration du matchmaking sans base de référence, c'est de l'approximation. Avant de modifier quoi que ce soit, établissez trois éléments :

• Votre taux de remplissage actuel, par région. Une moyenne globale ne suffit pas. La fragmentation régionale est souvent là où réside le vrai problème. Voir « Taux de remplissage régional » ci-dessous.

• Votre variation entre heures de pointe et heures creuses. Un matchmaker réglé pour 10 000 joueurs simultanés aux heures de pointe se comportera très différemment avec 800 joueurs à 3 h du matin. Ces deux situations nécessitent souvent des traitements distincts.

• L'endroit où les sessions perdent du remplissage. Les lobbies n'atteignent-ils jamais le nombre minimum de joueurs et expirent-ils ? Ou démarrent-ils pleins puis se vident-ils en cours de partie ? La réponse détermine quel levier actionner en premier.

Si vous utilisez le matchmaker d'Edgegap, le tableau de bord analytique fournit des métriques de taux de remplissage, le nombre de matchs et les données de phase d'expansion au fil du temps. Pour les studios qui veulent modéliser l'impact sur les coûts d'un objectif précis de taux de remplissage avant d'apporter des modifications, le calculateur de taux de remplissage est le bon point de départ.

Le principal levier : min_team_size et max_team_size

C'est le changement de configuration le plus impactant que la plupart des studios n'ont pas encore effectué. Et c'est aussi l'un des plus simples.

Par défaut, de nombreux matchmakers sont configurés pour exiger un lobby complet avant qu'une session puisse démarrer. Un jeu avec 8 joueurs par match attendra que les 8 soient prêts. Si le pool est trop faible pour les réunir, le matchmaker passe par ses phases d'expansion, en élargissant progressivement les contraintes de compétence et de latence. Si un lobby complet reste impossible à constituer à la fin de la dernière phase d'expansion, ou à l'expiration du ticket, le ticket est annulé et les joueurs retournent en file d'attente.

La séparation de min_team_size et max_team_size modifie le comportement de repli. Le matchmaker continue d'attendre un remplissage maximal aussi longtemps que possible. Mais à la fin d'une phase d'expansion ou à l'expiration du ticket, si suffisamment de joueurs sont disponibles pour un lobby de taille minimale, la session se lance au lieu d'être annulée. Le matchmaker a attendu aussi longtemps qu'il le pouvait raisonnablement, a assemblé autant de joueurs qu'il pouvait, et a livré un match plutôt que de renvoyer tout le monde dans la file.

Le compromis est réel : une session qui démarre en dessous de la capacité maximale offre une expérience joueur légèrement différente d'un lobby complet. La bonne réponse dépend de votre mode de jeu. Pour les formats casual et coopératifs, un démarrage partiel est généralement préférable à une file annulée et à un joueur frustré revenant au lobby. Pour les formats compétitifs où la symétrie des équipes compte, ce n'est peut-être pas le cas. La configuration au niveau du profil vous permet d'appliquer cela de manière sélective, ce que la section « Stratégie de profil » aborde.

Une fois qu'une session partielle démarre, le backfill peut ramener progressivement la capacité à son niveau maximal pendant le match lui-même. Ce mécanisme est abordé dans la section suivante.

Pour la syntaxe de configuration concrète et des exemples détaillés, consultez la documentation de la règle player_count.

Règles d'expansion : échanger du temps contre du remplissage

Les règles d'expansion sont le mécanisme du matchmaker permettant de relâcher les contraintes au fil du temps lorsqu'un lobby complet ne peut pas être constitué rapidement. C'est l'outil principal pour améliorer le taux de remplissage en conditions de faible CCU sans dégrader la qualité des matchs aux heures de pointe.

Ce que font réellement les expansions

Lorsqu'un joueur entre dans la file, le matchmaker applique l'ensemble de règles initial : écart de compétence strict, seuils de latence serrés, chevauchement obligatoire du mode de jeu ou de la carte. Si aucun match n'est trouvé dans une fenêtre configurée, les règles d'expansion assouplissent une ou plusieurs de ces contraintes et la recherche s'élargit.

Chaque phase d'expansion est déclenchée par le temps. À 30 secondes, la plage de compétence peut s'élargir. À 60 secondes, la tolérance de latence peut augmenter. À 3 minutes, la taille minimale de l'équipe peut diminuer. Le matchmaker passe par ces phases jusqu'à ce qu'un match soit créé ou que le ticket expire.

Le résultat est un système qui livre des matchs de haute qualité lorsque le pool de joueurs le permet, et des matchs acceptables lorsqu'il ne le permet pas, plutôt que de ne livrer aucun match du tout.

Comment les séquencer

L'ordre dans lequel les contraintes se relâchent compte. Une expansion mal séquencée peut produire des matchs qui semblent pires qu'une attente plus longue.

En règle générale :

• Relâchez les contraintes de compétence avant les contraintes de latence. Un match légèrement déséquilibré est moins pénalisant qu'un match avec du lag. Les joueurs tolèrent mieux la variance de compétence qu'une mauvaise qualité de connexion.

• Relâchez les contraintes de latence avant la taille minimale de l'équipe. Un lobby complet avec une latence modérée est préférable à un lobby partiel avec une bonne latence.

• Faites de la taille minimale de l'équipe la dernière expansion, pas la première. C'est le changement le plus visible pour les joueurs. Utilisez-le en dernier recours avant l'expiration du ticket, pas comme repli précoce.

Les intervalles d'expansion doivent aussi refléter la durée de vos sessions. Un jeu avec des matchs de 5 minutes voit ses joueurs revenir fréquemment dans la file, ce qui augmente naturellement le pool disponible à tout moment. Vous pouvez vous permettre des règles initiales plus strictes et des intervalles d'expansion plus courts. Un jeu avec des matchs de 30 minutes doit réussir le match du premier coup. Des tolérances initiales plus larges et moins de phases d'expansion sont souvent meilleures.

Un autre point à bien calibrer mérite l'attention : les marges d'expansion devraient augmenter à chaque phase, et ne pas rester uniformes. Au fur et à mesure que les premières vagues se déroulent, les joueurs proches des moyennes de paramètres sont appariés en premier. Ce qui reste dans les vagues ultérieures, ce sont les valeurs extrêmes aux bords de la plage autorisée, et ils sont structurellement moins nombreux. Un pas d'expansion uniforme qui fonctionnait bien à la première phase trouvera un pool beaucoup plus réduit à la seconde. Pour tenir compte de cela, chaque expansion devrait relâcher la contrainte d'une marge plus importante que la précédente. Si vous élargissez la latence maximale de 100 ms à 150 ms lors de la première expansion, l'étape suivante devrait aller plus loin, de 150 ms à 250 ms, plutôt qu'un autre incrément uniforme de 50 ms. La même logique s'applique à la plage de compétence. Cela permet de maintenir l'efficacité des phases d'expansion tardives même lorsque le pool de joueurs non appariés se réduit.

Pour le format exact de configuration des expansions et un exemple détaillé avec relâchement par paliers à 30 s, 60 s et 180 s, voir la section Expansion des règles dans la documentation.

Le problème du faible CCU

C'est là que de nombreux studios calibrent mal. Les règles d'expansion sont généralement ajustées pendant les tests ou peu après le lancement, lorsque les populations de joueurs sont concentrées et que les files avancent vite. Ces mêmes règles échouent souvent silencieusement pendant les heures creuses ou dans les régions secondaires où le pool ne représente qu'une fraction du pic.

Le symptôme est un taux d'expiration des tickets plus élevé et un remplissage plus faible pendant les fenêtres à faible trafic, même lorsque le matchmaker semble globalement en bonne santé.

La solution n'est généralement pas de desserrer les valeurs globales par défaut. Cela dégrade la qualité des matchs aux heures de pointe. La solution consiste à créer un profil de matchmaking distinct pour les conditions de faible CCU, avec des intervalles d'expansion plus rapides et des tolérances plus larges dès le départ. La section « Stratégie de profil » explique comment structurer cela.

Backfill : améliorer le remplissage après le lancement du match

Chaque levier abordé jusqu'ici agit au moment de la création du match. Le backfill est différent. Il agit après qu'une session a déjà commencé, en remplissant les places vides laissées par les joueurs partis ou en améliorant l'occupation des sessions qui ont démarré en dessous de la capacité maximale.

Un comportement important à comprendre : lorsque le backfill est configuré et que les règles du profil l'autorisent, le matchmaker donne la priorité au remplissage d'une session en cours plutôt qu'au lancement d'une nouvelle. Un joueur entrant dans la file peut être redirigé vers une place libre dans une session active plutôt que d'attendre la constitution d'un nouveau lobby. Cela améliore directement le taux de remplissage sur l'ensemble de votre parc de serveurs actifs, et pas seulement au moment de la création du match.

Remplacer les joueurs partis

Lorsqu'un joueur se déconnecte ou abandonne en cours de session, le serveur crée un ticket de backfill représentant la place vide. Ce ticket réintègre la file de matchmaking et peut être apparié avec un joueur en recherche d'une partie. Du point de vue du joueur entrant, il rejoint une session en cours. Du point de vue du serveur, la place est comblée et la session continue avec une occupation plus élevée.

Pour les modes de jeu où un départ provoquerait autrement un redémarrage ou une expérience dégradée, le backfill prolonge de manière significative à la fois la durée de vie des sessions et le remplissage moyen.

Remplir les lobbies partiels

Le backfill s'applique également lorsqu'une session a démarré en dessous de la capacité maximale via un appariement en remplissage partiel. Si une session démarre avec moins que le nombre maximal de joueurs sous la stratégie min_team_size / max_team_size décrite ci-dessus, le serveur peut immédiatement émettre un ticket de backfill pour les places restantes. Ces places peuvent être remplies alors que la session est déjà en cours, en revenant vers la pleine capacité sans obliger le match à attendre avant de démarrer.

Les deux cas d'usage suivent le même chemin d'implémentation. Le serveur crée et gère les tickets de backfill, traite les temporisations d'abandon pour les joueurs entrants et nettoie tous les tickets de backfill ouverts lorsque la session se termine. La documentation sur le backfill couvre l'ensemble du cycle de vie, y compris la création des tickets, la gestion des affectations et le nettoyage côté serveur.

Le backfill n'est pas approprié pour tous les modes de jeu. Les formats compétitifs où la composition des équipes est fixe, ou les modes où rejoindre en cours de match crée un désavantage injuste, ne devraient pas utiliser le backfill. Pour les formats casual, coopératifs, sociaux et open world, c'est l'un des outils de taux de remplissage les plus efficaces disponibles.

Stratégie de profil : adapter votre matchmaker aux conditions réelles

La plupart des studios lancent avec un seul profil de matchmaking et l'ajustent globalement. Cela fonctionne à grande échelle avec un pool de joueurs sain et concentré. Cela se complique à mesure que le jeu mûrit, que la base de joueurs se diversifie selon les régions et les fuseaux horaires, et que différents modes de jeu attirent des audiences de tailles différentes.

La réponse est une segmentation volontaire des profils. Trois scénarios couvrent la plupart des titres live :

Modes de jeu compétitifs vs casual. Les modes compétitifs doivent appliquer des contraintes serrées : appariement de compétence strict, limites de latence sévères, aucun remplissage partiel, aucun backfill. Les modes casual doivent être plus souples : expansion plus rapide, backfill activé, remplissage partiel accepté. Faire fonctionner les deux sur le même profil impose un compromis qui ne sert bien aucun des deux. Des profils séparés permettent à chaque mode de se comporter de manière appropriée pour son public.

Heures de pointe vs heures creuses. Si l'écart de CCU entre le pic et le creux dépasse 60 %, un seul profil sera soit trop restrictif pendant les fenêtres de faible CCU (provoquant des expirations de tickets et un mauvais remplissage), soit trop permissif aux heures de pointe (provoquant une dégradation de la qualité). Un profil dédié au faible CCU, avec des intervalles d'expansion plus rapides et des tolérances initiales plus larges, gère les conditions hors pointe sans toucher à la configuration de pointe.

Niveaux pro ou challenger. Les joueurs de haut niveau représentent une petite fraction de la population et ne suivent pas la distribution en cloche de compétence pour laquelle la plupart des réglages d'expansion sont conçus. Un profil dédié aux joueurs les mieux classés, avec ses propres seuils de compétence et une patience d'expansion plus longue, produit de meilleurs matchs pour ce segment sans déformer l'expérience de la majorité.

Pour des exemples de configuration couvrant côte à côte les modes de jeu compétitifs, coopératifs et sociaux, consultez la section de configuration des profils dans la documentation.

Taux de remplissage régional : corriger le problème caché

Comme l'explique l'article compagnon, le taux de remplissage agrégé masque les valeurs aberrantes régionales. Une bonne moyenne globale peut masquer une région unique fonctionnant à une fraction du remplissage attendu, payant ainsi deux ou trois fois le coût par joueur.

Une fois qu'une région sous-performante a été identifiée via le tableau de bord analytique ou le suivi du taux de remplissage par région, les options sont les suivantes :

Appliquer un profil d'expansion spécifique à la région. Les régions secondaires avec des pools de joueurs plus petits ont besoin d'expansions plus rapides et plus larges que les marchés principaux. Plutôt que de desserrer les valeurs globales par défaut, créez une variante de profil avec des déclencheurs d'expansion plus précoces et une taille minimale d'équipe plus faible pour cette région précise.

Consolider les serveurs actifs pendant les heures creuses. Dans les régions où la population de joueurs chute fortement en dehors des heures de pointe, conserver le même nombre de serveurs actifs qu'aux heures de pointe revient à payer pour une capacité qui ne se remplira jamais. Réduire le nombre minimal de serveurs actifs pendant les fenêtres à faible trafic, tout en s'appuyant sur le dimensionnement dynamique pour réaugmenter la capacité aux heures de pointe, réduit les coûts d'inactivité sans affecter l'expérience joueur.

Utiliser les règles de latence pour faire matcher des régions proches sans fragmenter les pools. La règle latencies permet à des joueurs de régions géographiques différentes d'être appariés sur un serveur partagé, tant qu'ils restent tous deux dans les seuils de latence configurés. Pour les régions à faible population, cela consolide effectivement les pools de matchmaking au lieu de forcer chaque région à remplir ses sessions indépendamment. Les joueurs obtiennent un match. Les serveurs tournent plus pleins.

Accepter une latence légèrement plus élevée dans les régions peu denses. Si le pool de joueurs d'une région est trop faible pour remplir les sessions dans des contraintes de latence conçues pour un marché dense, il peut être nécessaire d'assouplir les règles de latence pour cette région. Un match avec 80 ms de ping vaut mieux qu'aucun match. Les profils spécifiques à la région rendent cette approche ciblée plutôt que globale.

La discipline clé consiste à traiter chaque région comme son propre problème de taux de remplissage plutôt que comme une simple ligne d'un agrégat. Ce qui fonctionne pour l'Amérique du Nord aux heures de pointe ne fonctionnera pas pour les régions secondaires ni pour les audiences à n'importe quelle heure.

Mesurer l'impact des changements

L'optimisation du taux de remplissage est itérative. Les changements de configuration doivent être évalués par rapport à la base de référence établie lors de l'étape de diagnostic, et non par intuition.

Les principaux signaux à surveiller après chaque changement sont le taux de remplissage par région, le taux d'expiration des tickets et la distribution des phases d'expansion. Si le taux de remplissage s'améliore mais que l'expiration des tickets augmente également, les changements peuvent produire davantage de matchs tout en faisant perdre davantage de joueurs à cause des délais avant d'y parvenir. Si la distribution des phases d'expansion se déplace fortement vers les phases tardives, vos règles initiales sont peut-être encore trop strictes pour votre pool réel de joueurs.

Le tableau de bord analytique d'Edgegap (disponible dans l'offre Enterprise) fournit ces métriques prêtes à l'emploi, y compris des taux par minute sur des périodes personnalisées et des vues de séries temporelles du taux de remplissage et du comportement d'expansion. Pour les studios qui veulent modéliser l'impact sur les coûts d'un taux de remplissage cible avant de le tester en conditions réelles, le calculateur de taux de remplissage reste le moyen le plus rapide de traduire une amélioration du taux de remplissage en montant en dollars.

Les changements apportés aux règles d'expansion et à la configuration des profils sont peu risqués à tester de manière incrémentale. Commencez par le changement le plus impactant (généralement la séparation min_team_size / max_team_size), mesurez pendant une à deux semaines sur les fenêtres de pointe et de creux, puis passez au levier suivant. Empiler plusieurs changements à la fois rend difficile l'attribution des améliorations à des décisions spécifiques.

Pour la syntaxe de configuration la plus récente, les notes de version et des exemples JSON détaillés pour chaque scénario abordé dans cet article, reportez-vous à la documentation du matchmaker Edgegap. La documentation est mise à jour à chaque version du matchmaker.

Pour l'explication des coûts derrière ces optimisations, voir l'article compagnon : Comment le taux de remplissage des sessions affecte vos coûts d'hébergement multijoueur.