Vue approfondie

Découvrez en profondeur les concepts du matchmaker sans code d’Edgegap et personnalisez-les selon vos besoins.

✔️ Introduction

Commencez en moins de 5 minutes et testez toutes les fonctionnalités gratuitement, sans carte de crédit requise.

Passez à une offre supérieure lorsque vous êtes prêt pour un cluster plus puissant et privé (dédié). L’intégration native avec Edgegap Déploiements offre le meilleur ping, peu importe où se trouvent vos joueurs.

Le palier gratuit permet 3 heures d’exécution après chaque redémarrage. Votre matchmaker s’exécutera sur une infrastructure partagée avec des ressources limitées, adaptée aux tests. Après votre mise en ligne publique, le matchmaker doit fonctionner 24 h/24 et 7 j/7.

Il existe trois concepts essentiels pour chaque Matchmaker :

• Vue approfondie - infrastructure serveur sous-jacente, entièrement gérée et opérée par Edgegap.

• ⚙️ Configuration - ensemble de règles et de paramètres qui définissent le fonctionnement du matchmaker.

• 🌐 Instance de service - service de matchmaking en direct fonctionnant 24 h/24 et 7 j/7 sur le cluster, utilisant la configuration pour associer les joueurs et produire les affectations de déploiement (serveur).

Mettez fréquemment à jour la version de votre matchmaker pour profiter des nouvelles fonctionnalités et des corrections de bugs.

▶️ Démarrer le matchmaking

Découvrez le processus de matchmaking pour personnaliser, dépanner et optimiser l’intégration de votre jeu.

Séquence de matchmaking

1. Authentifier le joueur - empêche les copies piratées de jouer en ligne,

2. Créer le salon - rejoignez vos amis et partagez les préférences de joueur/de match,

3. Former un groupe - enregistrez votre salon comme groupe de matchmaking,

4. Trouver une partie - préparez-vous et commencez à chercher une partie (nouvelle ou existante),

   1. Attribuer le serveur et injecter les tickets - le serveur est automatiquement attribué après quelques secondes,

5. Se connecter et s’authentifier - tenter une connexion sécurisée au serveur de jeu,

   1. Confirmer l’identité - le serveur vérifie l’identité du client de jeu à l’aide de jetons tiers,

   2. Accepter le joueur ou l’exclure - le serveur décide si le joueur est autorisé à rejoindre.

Commencez rapidement - ajoutez notre exemple de démarrage de matchmaking à votre jeu:

Authentifier

Ce jeton peut être inclus en toute sécurité dans votre client de jeu, car il ne donne pas accès à l’API Edgegap.

Les joueurs individuels peuvent être identifiés à l’aide de leur ID de ticket, disponible côté client et serveur. En option, ajoutez une authentification ou des limites personnalisées avec un proxy personnalisé en utilisant Serveur à serveur l’API.

Former un groupe

Créer un groupe (party) garantit que les joueurs rejoignent la même équipe et le même serveur que leurs amis.

Créez un groupe marqué comme prêt pour Vue approfondie rapidement comme un joueur solo sans membres de groupe.

Diagramme d’activité du cycle de vie du groupe

Salon et groupe

Utilisez un service de salon si la conception de votre jeu exige de définir des préférences de matchmaking contrôlées par le joueur (par ex. choix du personnage, difficulté, carte, etc.). À mesure que les joueurs rejoignent et quittent le salon, ils mettent également à jour le groupe de matchmaking afin de se préparer à trouver une partie plus tard.

Pas le temps de mettre en place un service de salon ? Invitez les joueurs à partager les IDs de groupe via Discord ou par messages privés.

Conception du jeu - Fonctionnalité / Exigence	Salon pré-match	Groupe du matchmaker
inviter des amis à jouer avec moi	✅	✅
modifier mes préférences de joueur/de match	✅	❌
voir les préférences des autres membres du salon	✅	❌
stocker et gérer des données clé-valeur personnalisées	✅	❌
avertir les membres du groupe que je suis prêt à jouer	❌	✅
afficher la progression du matchmaking et trouver une partie	❌	✅
obtenir l’affectation d’équipe pour un joueur/groupe	❌	✅
récupérer les détails de connexion au serveur de jeu	❌	✅

Notre matchmaker multiplateforme prend en charge tous les services de salon commerciaux et personnalisés :

Service de salon (tiers)	Unreal Engine	Unity	PC	Consoles	VR/XR	Mobile
Salon Epic Online Services (Epic Games)
Salon Steamworks (Valve Corporation)
Groupe Nakama (Heroic Labs)
Salon Playfab (Microsoft)
Salon brainCloud (bitHeads)
Amis Gamekit (Apple)
Salon personnalisé (votre entreprise)

Le propriétaire du salon (le joueur qui envoie les invitations) doit également créer le groupe de matchmaking.

Stockez l’ID de votre groupe dans les données partagées de votre salon, afin que les autres membres du salon puissent facilement trouver et rejoindre un groupe de matchmaking associé au salon tiers. Les joueurs invités au groupe utilisent l’ID du groupe pour créer leurs adhésions (rejoindre), et pour stocker en toute sécurité leurs attributs de matchmaking.

Une fois qu’un groupe commence le matchmaking, il ne peut plus être rejoint. Vue approfondie et en créer un nouveau.

Optimisation du ping

Si ⚙️ Configuration inclut des latences la règle tous les membres du groupe envoient leurs Pings des beacons mesures à empêcher d’associer des joueurs de régions éloignées ou avec un ping (latence) beaucoup plus élevé ou plus faible.

Exemple de mesures de ping du client de jeu en millisecondes

{
  "Chicago": 224.4,
  "Francfort": 23.2,
  "Tokyo": 167.4
}

Abandonner la file d’attente

Le propriétaire du groupe peut supprimer le groupe, supprimant automatiquement toutes les adhésions au groupe. La suppression du groupe après le début du matchmaking annulera toutes les adhésions et les supprimera peu après.

Les membres du groupe (sauf le propriétaire) peuvent supprimer leurs adhésions (quitter le groupe) à tout moment avant Vue approfondie. La suppression d’une adhésion après coup annulera le matchmaking pour tout le groupe.

Une fois le matchmaking annulé, les membres sont retirés automatiquement du matchmaking et notifiés via l’adhésion status:CANCELLED dans leur prochaine réponse de polling de statut.

Une fois annulé, si le groupe souhaite relancer le matchmaking, le propriétaire du groupe doit recréer le groupe, partager le nouvel ID du groupe aux membres et leur faire recréer leurs adhésions.

Une fois qu’une partie est trouvée, le groupe ne peut plus être supprimé (409 Conflict), et sera retiré automatiquement. Votre serveur doit laisser suffisamment de temps (par ex. 60 s) aux joueurs pour se connecter avant de supposer qu’un joueur a abandonné. Dans ce cas, votre serveur peut :

• remplacer le joueur qui quitte par un personnage IA pour démarrer immédiatement la partie,

• ou créer un backfill pour trouver un nouveau joueur afin de remplacer celui qui a quitté,

• ou continuer sans remplacer le joueur qui a quitté, si la conception de votre jeu permet un nombre variable de joueurs.

Trouver une partie

Pour commencer à chercher une partie, tous les membres et le propriétaire doivent se marquer comme prêts.

Pour permettre au propriétaire du groupe de lancer immédiatement le matchmaking, marquez les adhésions comme prêtes dès leur création. Une fois que le propriétaire se marque comme prêt, le matchmaking démarre, puisque tout le monde est prêt.

Pour une meilleure expérience, fournissez des mises à jour de statut aux joueurs via l’interface en jeu.

Tous les joueurs doivent interroger leur adhésion à intervalles réguliers (3 à 5 s recommandés) pour détecter le démarrage du matchmaking, et pour communiquer la progression du matchmaking via l’interface en jeu.

Les joueurs devraient enregistrer de manière persistante leur adhésion et leurs IDs de groupe, afin qu’en cas de crash du client de jeu, ils puissent redémarrer le jeu et reprendre sans perdre la progression du matchmaking.

Une fois que nous trouvons suffisamment de joueurs pour les mettre dans la même équipe en respectant votre Règles, les joueurs seront notifiés dans leur réponse d’adhésion avec status:TEAM_FOUND.

Supprimer une adhésion à ce stade entraînera l’annulation de toutes les adhésions du groupe et le retour de tous les autres groupes affectés à la même équipe vers status:SEARCHING .

Les équipes poursuivent le matchmaking avec d’autres équipes en utilisant les valeurs communes entre leurs groupes (ou la moyenne dans le cas de number_difference ) jusqu’à ce qu’un nombre suffisant d’équipes soit réuni. Les adhésions l’indiquent avec la réponse status:MATCH_FOUND , ce qui signifie que votre déploiement est en cours de démarrage.

Le matchmaker vise à maximiser le taux de remplissage des parties et ne passera pas à MATCH_FOUND tant que l’une des conditions suivantes n’est pas remplie :

1. un nombre suffisant d’équipes est apparié avec la taille maximale d’équipe configurée,

2. ou si Vue approfondie est défini ET que le temps d’expansion est atteint, ET qu’un nombre suffisant d’équipes est apparié avec la taille minimale d’équipe configurée,

3. ou que le temps d’expiration des tickets configuré s’est écoulé ET qu’un nombre suffisant d’équipes est apparié avec la taille minimale d’équipe configurée.

Si aucun de ces scénarios ne réussit avant l’expiration configurée des tickets, le groupe et les tickets sont annulés.

Vous rencontrez de longs temps d’attente en file pendant les tests, ou avec des joueurs dans des régions moins populaires ? Définissez une période d’expiration des tickets plus courte (par ex. 30 s) et recréez le groupe (ou les tickets) côté client à l’expiration.

L’expiration des tickets se réinitialise automatiquement chaque fois qu’un groupe (ou un joueur) est associé à une équipe.

Stocker team_id et match_id dans le backend de votre jeu pour afficher en jeu les informations des membres de l’équipe.

Chaque joueur reçoit un ID de ticket unique, qui peut être utilisé pour Vue approfondie avec les serveurs de jeu.

Si le joueur a été apparié et affecté à un serveur de jeu, son ticket est supprimé automatiquement. Les joueurs qui abandonnent la file après status:HOST_ASSIGNED peuvent être remplacés par backfill.

Une fois que les joueurs reçoivent status:HOST_ASSIGNED ils passent à Vue approfondie.

Se connecter au serveur

Match de backfill

Une fois l’initialisation du serveur de jeu terminée, votre serveur doit:

• Démarrer un minuteur d’abandon pour chaque nouveau joueur. Nous recommandons d’indiquer la progression du chargement aux joueurs connectés avec une scène/un niveau de chargement - soit une scène 3D complète, une interface sociale de type salon, ou un écran de chargement avec une barre de progression.

• Suivre les nouvelles connexions de joueurs ou les joueurs existants qui quittent au fil du temps:

  1. Les nouveaux joueurs doivent annoncer leur ID de ticket au serveur pour l’authentification et pour faire correspondre leur connexion au matchmaker Vue approfondie ou assigned_ticket (si backfill).

  2. Créez de nouveaux backfills pour la capacité joueur inutilisée (joueurs partis) tout au long de la durée de vie du serveur.

  3. Renouvelez les backfills expirés, qui sont supprimés après ticket_expiration_period.

• Nettoyez (supprimez) tous les backfills restants une fois le Déploiements:

  • Unity - OnApplicationQuit callback ou un callback personnalisé de fin de partie,

  • Unreal Engine - OnWorldDestroyed , PreExit , ou un callback personnalisé de fin de partie.

N’importe quel profil peut être utilisé pour le backfill tant qu’une affectation de serveur valide et au moins un ticket sont fournis. Voir Mise en relation pour un exemple minimal.

⚙️ Configuration

L’API du Matchmaker est générée à partir d’une configuration JSON spécifiée lorsque vous créez un nouveau Matchmaker (ou effectuez un redémarrage rapide). Vous pouvez spécifier n’importe quel nombre de profils avec des règles et des expansions variées :

Voir Mise en relation pour nos SDK et des scénarios d’exemple détaillés.

Modifier un matchmaker en cours d’exécution déclenchera un rechargement rapide, supprimant tous les tickets et entraînant un court temps d’arrêt.

Profils (files d’attente)

Les profils représentent des files de matchmaking entièrement séparées, partageant la même version du matchmaker. Vous pouvez configurer n’importe quel nombre de profils pour chaque matchmaker. Répartir votre base de joueurs sur plusieurs profils peut entraîner des temps d’attente plus longs pour vos joueurs.

Chaque profil de matchmaker utilise une Version de l’application comme modèle pour démarrer de nouveaux déploiements (serveurs).

Certains modes de jeu peuvent nécessiter davantage de vCPU / RAM, surtout s’ils prennent en charge un plus grand nombre de joueurs. Chaque matchmaker peut inclure plusieurs profils, chacun lié à une version d’application avec des ressources ajustées.

Règles

Chaque joueur et groupe rejoint la file de matchmaking et trouve des parties en utilisant d’abord les règles initiales.

Chaque entrée du profil au chemin .rules.initial représente une règle, où :

• key est une valeur de type chaîne pour nommer la règle comme vous le souhaitez ; par ex. match_size , et

• value est un objet définissant le type et les attributs de la règle, conformément à notre ensemble de règles standard.

Toutes les règles doivent être remplies simultanément pour lancer l’affectation d’hôte et démarrer ou trouver un déploiement.

Opérateurs (type de règle)

player_count est une règle spéciale définissant combien de joueurs doivent correspondre pour lancer l’affectation.

La règle player_count est requise et ne peut être définie qu’une seule fois dans vos règles de configuration initiales.

Le matchmaker s’efforce toujours de maximiser le taux de remplissage des parties, jusqu’à la max_team_size :

1. spécifiée ; si la taille maximale de l’équipe est atteinte, la partie est créée immédiatement,

2. sinon, les joueurs attendent dans la file pour remplir la partie jusqu’à ce que l’expansion (ou l’expiration) soit sur le point de se produire,

3. peu avant l’expansion (ou l’expiration), si une partie partielle est possible (≥ min et < taille max de l’équipe), cette partie sera créée avec tous les joueurs au même stade d’expansion (en supposant que les autres règles passent).

Pour les modes de jeu coopératifs, free-for-all ou à taille d’équipe asymétrique, définissez votre "team_count": 1 .

Le nombre d’équipes peut être configuré pour composer plusieurs équipes équilibrées pour les jeux compétitifs :

• les attributs du groupe sont calculés comme moyenne/chevauchement des attributs du joueur du groupe,

• les attributs de l’équipe sont calculés comme moyenne/chevauchement des attributs du groupe de l’équipe.

En supposant une taille d’équipe fixe de 4 joueurs :

Exemples de scénarios de match

Les groupes sont appariés en équipes sans surcharger, uniquement si une équipe dispose d’une capacité suffisante pour accueillir tout le groupe.

string_equality associe les joueurs ayant exactement la même valeur de chaîne.

Exemple de règle : selected_game_mode

selected_game_mode la règle associera les joueurs en respectant la casse :

✅ Alice + Bob + Dave peuvent correspondre,

❌ Alice + Erin, ou Charlie + Frank ne correspondront jamais.

"Free For All"	"Capture The Flag"	"capture the flag"
Alice	Erin	Frank
Bob	Charlie
Dave

number_difference associe les joueurs dont la différence numérique absolue entre eux est respectée.

Exemple de règle : elo_rating

elo_rating la règle ci-dessus avec "max_difference": 50 initialement :

✅ Alice + Bob peuvent correspondre, ou Bob + Charlie peuvent correspondre,

❌ Alice + Bob + Charlie ne correspondront jamais.

intersection associe les joueurs ayant une ou plusieurs valeurs de chaîne qui se chevauchent, en respectant la casse.

Exemple de règle : selected_map

selected_map la règle ci-dessus avec "overlap": 1 associera :

✅ Alice + Bob + Charlie peuvent correspondre, ou Alice + Bob + Dave peuvent correspondre,

❌ Alice + Bob + Charlie + Dave ne correspondront jamais.

Expansion des règles

En option, les expansions modifient les attributs d’une règle après une période passée dans la file afin d’assouplir les limitations et d’élargir le pool de joueurs pouvant être appariés, ce qui conduit à des parties plus rapides.

Exemple de scénario : expansions

Au départ, nous avons besoin d’une équipe composée exactement de 4 joueurs (éventuellement répartis en groupes) avec :

• une latence maximale de 125 ms contre le même beacon (n’importe lequel),

• une différence de latence de 125 ms ou moins entre la valeur la plus basse et la plus haute pour le même beacon,

• une différence de score de compétence de 50 points ou moins entre le joueur le mieux et le moins bien classé,

• le même mode de jeu sélectionné exact (respect de la casse),

• au moins une sélection de carte correspondante (respect de la casse) parmi les joueurs,

• au moins une taille de groupe de backfill correspondant à une valeur parmi les joueurs.

Dans l’exemple ci-dessus, nous élargissons la recherche en modifiant les attributs après :

30 secondes :

• 4 joueurs

• plage de score de compétence de 150

• latence max. 250 ms

60 secondes :

• 4 joueurs

• plage de score de compétence de 200

• latence max. 250 ms

3 minutes (180 s) :

• 1 à 4 joueurs

• plage de score de compétence de 200

• n’importe quelle latence

Ajustement fin des expansions

Prédire les préférences des joueurs est similaire à tirer sur une cible en mouvement. Commencez avec un ensemble de règles moins restrictif au lancement, puis optimisez ensuite par itérations avec Vue approfondie.

Ces questions peuvent aider à structurer votre réflexion :

• Quelle est la durée de ma session de jeu ?

  • Une session de 5 min signifie que chaque joueur revient dans la file toutes les 5 min, ce qui réduira indirectement le temps d’attente grâce à un plus grand nombre de joueurs en file à un instant donné.

• Quel est mon pic de CCU et mon CCU à marée basse?

  • S’il existe une forte variance (plus de 60 %) entre le bas et le haut, vous pourriez avoir besoin d’un profil distinct pour la marée basse afin d’attendre plus longtemps dans chaque expansion et accumuler davantage de joueurs.

• Quelle est la répartition géographique de mes joueurs ?

  • Une répartition uniforme sur plusieurs fuseaux horaires signifie que le pic et la marée basse ont une variance plus faible, mais n’améliore pas la vitesse de matchmaking, car les joueurs de régions différentes ne devraient pas être appariés si votre Vue approfondie est correctement configuré (ce qui entraînerait un ping élevé).

• Quelle est la répartition de mon score de compétence (par région) ?

  • La distribution des compétences suit généralement une courbe en cloche (distribution naturelle), donc à chaque écart-type par rapport à la moyenne, on trouve moins de joueurs plus éloignés de la moyenne. Les joueurs aux valeurs moyennes seront appariés rapidement, dès la première expansion, mais les extrêmes posent problème.

  • Nous recommandons d’augmenter le montant de la différence élargie à chaque expansion, par exemple 25 -> 50 -> 100, afin de tenir compte du fait qu’il y a moins de joueurs aux extrémités de la courbe.

  • Si vous avez un palier challenger quelconque (joueurs pro), nous recommandons un profil séparé avec une configuration de compétence personnalisée, car l’échantillon est plus petit et ne suit souvent pas la tendance globale de l’ensemble de la base de joueurs. (penchant vers les extrêmes, courbe en cloche inversée)

• Comment puis-je améliorer la vitesse de matchmaking et le taux de remplissage des parties avec une petite base de joueurs ?

  • Apprenez-en autant que possible sur vos joueurs et leurs préférences !

  • Envisagez de supprimer certaines règles ou d’assouplir les restrictions au départ.

  • Assouplissez la taille de l’équipe ou le nombre d’équipes au fil du temps - une partie partielle vaut mieux qu’aucune partie.

  • Augmentez la durée entre les expansions pour accumuler davantage de joueurs.

  • Contactez-nous pour plus d’astuces et de conseils, spécifiquement pour la conception de votre jeu.

Les expansions de n’importe quel attribut d’une règle écraseront les valeurs précédentes de cet attribut.

📌 Variables injectées

Votre serveur peut avoir besoin de connaître des détails sur ses joueurs. Les attributs des joueurs, les valeurs de match résolues et d’autres valeurs sont injectés dans votre déploiement en plus des variables habituelles Applications et versions.

Aperçu non formaté 🏁 Variables d’exemple avancées :

MM_MATCH_PROFILE=advanced-example
MM_EXPANSION=initial
MM_TICKET_IDS=["cusfn10msflc73beiik0","cusfn18msflc73beiil0"]
MM_TICKET_cusfn10msflc73beiik0={"id":"cusfn10msflc73beiik0","created_at":"2025-02-21T22:17:42.3886970Z","player_ip":"174.93.233.25","group_id":"b2080c27-19c9-4fb0-8fe7-4bf1e5d285d1","team_id":"cusfn1gmsflc73beiim0","attributes":{"beacons":{"Chicago":12.3,"LosAngeles":145.6,"Tokyo":233.2},"elo_rating":1337,"selected_game_mode":"quickplay","selected_map":["DustII","Airport","BankVault"],"backfill_group_size":["new","1"]}}
MM_TICKET_cusfn18msflc73beiil0={"id":"cusfn18msflc73beiil0","created_at":"2025-02-21T22:17:42.2548390Z","player_ip":"174.93.233.23","group_id":"015d4dc8-6c79-4b5c-bbc6-f309b9787c8f","team_id":"cusfn1gmsflc73beiim0","attributes":{"beacons":{"Chicago":87.3,"LosAngeles":32.4,"Tokyo":253.2},"elo_rating":1339,"selected_game_mode":"quickplay","selected_map":["Island","Airport"],"backfill_group_size":["new","1"]}}
MM_GROUPS={"b2080c27-19c9-4fb0-8fe7-4bf1e5d285d1":["cusfn10msflc73beiik0"],"015d4dc8-6c79-4b5c-bbc6-f309b9787c8f":["cusfn18msflc73beiil0"]}
MM_TEAMS={"cusfn1gmsflc73beiim0":["b2080c27-19c9-4fb0-8fe7-4bf1e5d285d1","015d4dc8-6c79-4b5c-bbc6-f309b9787c8f"]}
MM_MATCH_ID=advanced-example_initial-2025-02-21T22:17:43.3886970Z
MM_INTERSECTION={"selected_map":["Airport"],"backfill_group_size":["new","1"]}
MM_EQUALITY={"selected_game_mode":"quickplay"}

Les variables d’environnement sont stockées sous forme de JSON sérialisé en chaîne, analysez-les à l’aide de notre SDK ou d’une méthode personnalisée.

Les serveurs peuvent associer les connexions des joueurs aux groupes et aux attributs après que le joueur a envoyé son ID de ticket au serveur.

🧵 Suivi des joueurs

Si vos joueurs rencontrent des problèmes, retracer leur parcours jusqu’aux journaux du serveur peut être utile. Chaque déploiement de Matchmaker sera balisé avec les IDs de ticket des joueurs affectés afin que vous puissiez facilement et trouver Déploiements pour vous aider à dépanner. Déploiements Affichez les IDs de ticket et les IDs de déploiement dans l’interface d’historique des parties du client

pour suivre les joueurs lors du dépannage. pour en savoir plus sur le dépannage des déploiements.

Voir Déploiements pour en savoir plus sur le dépannage des déploiements.

👀 Analytique

Obtenez des informations sur la charge et les performances de votre matchmaker, sans code ni configuration requis.

🌟 Passez le Matchmaker au niveau Entreprise pour débloquer les métriques et les analyses de matchmaking :

☁️ Cluster d’hébergement

Le Matchmaker est hébergé et géré 24 h/24 et 7 j/7 de manière pratique par Edgegap.

Choisissez l’option d’hébergement la mieux adaptée à votre objectif :

Niveaux de cluster privé

Passez à un cluster privé en un clic. Il est également possible de changer de niveaux de cluster privé après le lancement, sans aucun temps d’arrêt pour les joueurs, avec ⏩ Mises à jour progressives. Les clusters gérés fournissent un hébergement de service haute disponibilité maintenu par Edgegap avec une assistance en direct 24 h/24 et 7 j/7 pour les jeux publiés publiquement.

Les besoins en ressources de votre instance dépendront de plusieurs facteurs :

• nombre de joueurs - plus il y a de joueurs, plus il y a de tickets et de requêtes API,

• nombre de requêtes par joueur - des nouvelles tentatives plus rapides augmentent la charge du service et consomment des ressources,

• complexité de la configuration - les règles d’intersection et les expansions sont particulièrement exigeantes,

• durée moyenne d’un match - des sessions plus courtes font que les joueurs rejoignent plus souvent le matchmaking,

• périodes d’expiration et de suppression - les tickets obsolètes s’accumulent au fil du temps et consomment des ressources,

• logique de repli des nouvelles tentatives du client - réessayer avec un backoff à jitter aide à répartir les pics de trafic.

Préparez-vous au succès et optimisez après le lancement, afin de ne pas bloquer vos joueurs le jour de la sortie. Utilisez Outils pour développeurs ou implémentez un backoff exponentiel avec jitter pour vous remettre d’une forte charge.

Limites de débit

Pour protéger votre cluster contre le dépassement de sa capacité de pic et les crashs, nous limitons le nombre de requêtes par seconde en nous basant sur nos tests de charge internes utilisant Mise en relation la configuration.

Point de terminaison de l’API	Niveau gratuit	Niveau amateur	Niveau studio	Niveau entreprise
Limite globale	100	200	750	2,000
Créer un déploiement	5	10	30	30
Lister les balises	10	20	75	200
Créer un groupe + Créer un ticket + Créer un ticket de groupe	10	20	75	200
Lire l’adhésion + Lire le groupe + Lire le ticket	10	120	450	1,300
Créer un backfill	5	10	37	100

Les limites de débit sont exprimées en requêtes combinées par seconde vers l’ensemble spécifié de points de terminaison API.

Si vos clients de jeu ne réessaient pas les requêtes lorsqu’ils reçoivent la réponse 429 Trop de requêtes vos déploiements peuvent manquer de joueurs qui arrêtent de lire leurs affectations en raison d’une charge élevée.

Tests de charge

Le matchmaking et les affectations nécessitent une utilisation du CPU et de la mémoire, ce qui entraîne un coût d’hébergement pour chaque matchmaker privé. Consultez les ressources et les prix associés à chaque niveau sur notre page de tarification.

Utilisez toujours des clusters privés pour les tests de charge. Les matchmakers gratuits sont strictement limités aux tests de développement uniquement.

Lors de la conception de votre test de charge, veuillez prendre en compte des comportements de joueurs réalistes:

Scénario réaliste	Schéma de trafic irréaliste
✅ Les joueurs rejoignent progressivement le matchmaking, augmentant les req/s sur plusieurs heures.	❌ Tous les joueurs se coordonnent et créent leurs tickets exactement à la même seconde.
✅ Les joueurs attendent de plus en plus longtemps entre leurs tentatives (par ex. 1 s-5 s-10 s-10 s).	❌ Tous les joueurs réessaient immédiatement après avoir reçu 429 Trop de requêtes la réponse.
✅ La plupart des joueurs recevront leur affectation en peu de temps (10 à 60 s) et cesseront d’interroger.	❌ Tous les joueurs continuent d’interroger pendant une durée déterminée même après avoir reçu l’affectation.
✅ La plupart des joueurs terminent leur partie (ce qui prend du temps) avant de relancer le matchmaking.	❌ Tous les joueurs relancent immédiatement le matchmaking après avoir reçu leur affectation.
✅ Le trafic de pointe est soutenu pendant 6 à 8 heures par jour, après quoi certains fuseaux horaires décroissent.	❌ Le trafic de pointe est soutenu 24 heures sur 24, tous les joueurs jouant jour et nuit.

Si un matchmaker subit une forte charge :

• si le CPU est bridé, le matchmaking peut être ralenti,

• si le matchmaker manque de mémoire, il redémarrera sans perdre les informations du ticket, en espérant que les clients implémenteront un backoff exponentiel et que la rafale sera étalée sur une période plus longue.

⏩ Mises à jour progressives

Garder une trace de la compatibilité entre les versions serveur et client peut devenir compliqué. Suivez nos conseils pour des versions fiables, des mises à jour et la prévention des temps d’arrêt ou des problèmes de compatibilité.

L’URL de votre matchmaker et votre jeton d’authentification resteront toujours identiques après un redémarrage.

Créez des matchmakers distincts pour les environnements de développement et de production afin d’expérimenter en toute sécurité.

⚠️ Avant la mise en ligne

Nous recommandons de créer à l’avance plusieurs copies de votre matchmaker : vert, bleu et orange. Vous pouvez faire tourner le matchmaker utilisé au fur et à mesure du déploiement des mises à jour (stratégie bleu/vert).

Choisissez différentes régions pour chaque instance afin d’éviter les interruptions lors de pannes localisées.

Exemple d’environnement DevOps bleu/vert

🔃 Mise à jour client + serveur

Prérequis : Cette section suppose que vous avez terminé Vue approfondie.

Afin de publier des mises à jour du client et du serveur de jeu, vous pouvez :

1. Préparer une nouvelle version de l’application serveur v1.2.0-rc sur Edgegap :

   1. publier une nouvelle balise d’image dans votre registre de conteneurs t1.2.0,

   2. créer une nouvelle version d’application v1.2.0-rc,

2. Effectuer tous les tests de développement en déployant votre nouvelle version d’application v1.2.0-rc:

   1. connecter l’éditeur de votre moteur de jeu à l’URL fournie + au port externe,

3. Mettre à jour le matchmaker inutilisé bleu pour le lier à votre nouvelle balise d’image t1.2.0,

   1. activer la mise en cache pour la nouvelle version d’application v1.2.0-rc , activer le cache pour cette version garantira que l’image est également mise en cache pour la version v-blue puisqu’elles font référence à la même balise,

   2. attendre que l’indicateur de mise en cache dans la version v1.2.0-rc atteigne 🟢 vert,

4. Mettre à jour votre nouveau client de jeu c2 pour utiliser la nouvelle version v-blue lors de la création des tickets :

   1. mettez à jour votre URL de base et votre jeton d’autorisation dans le client de jeu,

5. Effectuer les tests QA et les vérifications finales de votre nouveau client de jeu c2:

   1. si vous trouvez et résolvez des problèmes, recommencez le processus depuis le début,

   2. attendre 3 à 7 jours pour propager les changements DNS du matchmaker aux FAI dans le monde entier, après l’arrêt du matchmaker (un redémarrage rapide ne nécessite ni mise à jour DNS ni délai d’attente),

6. Publier la mise à jour de votre nouveau client de jeu c2 sur les plateformes de distribution de jeux,

7. Accorder du temps au nouveau client de jeu c2 pour se distribuer sur les appareils des joueurs (généralement jusqu’à 3 à 7 jours) :

   1. surveiller les clients de jeu obsolètes c1 en utilisant le déploiement Déploiements,

8. Nettoyez les ressources inutilisées dans votre compte Edgegap :

   1. supprimer la balise d’image t1.0.0 pour libérer de la capacité du registre de conteneurs,

   2. supprimer la balise d’image t1.1.0 pour libérer de la capacité du registre de conteneurs,

   3. désactivez votre vert matchmaker pour suspendre la facturation jusqu’à votre prochaine mise à jour.

Pour votre prochaine mise à jour, augmentez les numéros de version et remplacez vert et bleu les mots-clés dans le guide.

⚡ Correctif serveur

Prérequis : Cette section suppose que vous avez terminé Vue approfondie.

Pour publier un correctif serveur sans nécessiter de mise à jour du client de jeu, vous pouvez :

1. Préparer une nouvelle version de l’application serveur v1.2.0-rc sur Edgegap :

   1. publier une nouvelle balise d’image dans votre registre de conteneurs t1.2.0,

   2. créer une nouvelle version d’application v1.2.0-rc,

2. Effectuez les tests et vérifications en déployant votre nouvelle version d’application v1.2.0-rc:

   1. connecter l’éditeur de votre moteur de jeu à l’URL fournie + au port externe,

   2. si vous trouvez et résolvez des problèmes, recommencez le processus depuis le début,

   3. activer la mise en cache pour la nouvelle version d’application v1.2.0-rc , activer le cache pour cette version garantira que l’image est également mise en cache pour la version v-green plus tard puisqu’ils feront référence à la même balise,

   4. attendre que l’indicateur de mise en cache dans la version v1.2.0-rc atteigne 🟢 vert,

3. Mettre à jour la version v-green pour le lier à votre nouvelle balise d’image t1.2.0,

   1. les nouvelles parties lanceront automatiquement l’affectation avec la balise mise à jour t1.2.0,

   2. surveiller les clients de jeu obsolètes c1 en utilisant le déploiement Déploiements,

4. Nettoyage des ressources inutilisées dans votre compte Edgegap :

   1. supprimer la balise d’image t1.1.0 pour libérer de la capacité du registre de conteneurs.

📗 API

Les clients et les serveurs peuvent appeler l’API directement ou avec les SDK du moteur de jeu, voir aussi Mise en relation.

Serveur à serveur

Ajoutez des contrôles améliorés ou personnalisés sur le flux de matchmaking - implémentez un proxy personnalisé à l’aide de notre Clusters gérés ou de toute plateforme cloud FaaS plateforme de calcul, pour atteindre l’un des objectifs suivants :

• associer des attributs sensibles du joueur - tels que des indicateurs de triche, des classements de compétence ou similaires,

• fournir le contexte de l’équipe et du match en jeu - lister mes coéquipiers et mes adversaires pendant le chargement,

• restreindre des cas particuliers spécifiques - par ex. autoriser seulement 1 groupe par joueur à tout moment,

• ajouter de la mise en cache ou une limitation du débit de l’API - réduire le nombre de requêtes et la charge sur le matchmaker,

• personnaliser l’intégration lobby-groupe - créer des lobbies asymétriques/basés sur des rôles avant le matchmaking.

Inclure le paramètre player_ip avec l’adresse IP publique du membre pour garantir la latence la plus faible possible pour le joueur et tirer parti de Déploiements.

Les clients de jeu peuvent utiliser le service gratuit ipify.org pour trouver leur IP publique. Les VPN peuvent masquer l’adresse IP publique.

Diagramme d’activité de matchmaking serveur à serveur

Partage de ressources entre origines (CORS)

Pour les jeux WebGL hébergés sur des plateformes de distribution tierces (par ex. itch.io), l’envoi de requêtes au matchmaker depuis le client de jeu peut entraîner des violations de la politique de partage de ressources entre origines . La plupart des navigateurs web modernes envoient une requête de pré-vérification pour vérifier qu’un service backend (le matchmaker) comprend et accepte la communication de votre client de jeu.

L’échec de la vérification préalable (par défaut pour des raisons de sécurité) peut entraîner l’une de plusieurs erreurs possibles liées au CORS, le plus souvent en-tête CORS 'Access-Control-Allow-Origin' manquant .

Pour résoudre cette erreur, ajoutez le paramètre allowed_cors_origin à votre configuration afin de :

• mettre sur liste blanche vos domaines exacts d’hébergement client :

🍀 Exemple simple (exemple de domaines spécifiques)

{
  "version": "3.2.0",
  "allowed_cors_origins": [
    "https://dev.my-game-server.com",
    "https://prod.my-game-server.com"
  ],
  "profiles": {
      ...
  }
}

• ou mettre sur liste blanche un domaine générique (y compris tous les sous-domaines) :

🍀 Exemple simple (exemple de domaine générique)

{
  "version": "3.2.0",
  "allowed_cors_origins": ["https://*.my-game-server.com"],
  "profiles": {
      ...
  }
}

Aucun identifiant n’est requis pour les requêtes de pré-vérification du matchmaker, si les domaines sont correctement configurés.

🚨 Dépannage

Votre réussite est notre priorité. Si vous souhaitez envoyer des requêtes personnalisées, demander des fonctionnalités critiques manquantes ou partager vos impressions, veuillez nous contacter sur notre Discord communautaire.

Pourquoi est-ce que j’obtiens des erreurs lorsque j’essaie de créer un nouveau matchmaker ?

• Veuillez lire l’erreur, il est possible que vous ayez mal orthographié un identifiant, une règle ou un opérateur. - Utilisez JSONLint pour valider le format JSON, vous avez peut-être oublié une virgule ou une accolade. - Contactez-nous sur notre Discord communautaire pour obtenir de l’aide, nous serons heureux de vous assister. 🙏

Pourquoi mon matchmaker s’est-il éteint automatiquement après 3 heures ?

• Les matchmakers du niveau gratuit sont destinés aux tests initiaux et s’éteignent automatiquement après 3 heures. Pour continuer les tests, vous pouvez redémarrer votre matchmaker.

• Envisagez de passer à un niveau payant pour une durée d’exécution illimitée.

Pourquoi ne puis-je pas lancer un deuxième déploiement sur mon compte ?

• Vous ne pouvez exécuter qu’un seul déploiement simultané au niveau gratuit.

• Veuillez envisager de passer à un niveau payant pour des déploiements illimités.

Pourquoi est-ce que je reçois des affectations/déploiements à des moments aléatoires, en ignorant player_count?

• Vous ou un autre membre de l’équipe avez peut-être créé des tickets lors d’une session de test précédente qui n’ont pas été attribués. Veuillez redémarrer votre matchmaker.

Mon ticket est bloqué en RECHERCHE .

• Veuillez vérifier que vous avez créé suffisamment de tickets correspondants en respectant votre configuration.

Mon ticket reste bloqué en alternance entre MATCH_FOUND et ÉQUIPE_TROUVÉE à répétition.

• Les comptes du niveau gratuit sont limités à 1 déploiement à la fois.

• Veuillez envisager une mise à niveau ou arrêter votre déploiement actuel pour en lancer un nouveau.

Mon ticket passe directement à ANNULÉ.

• Votre ticket a atteint sa date d’expiration. Créez un nouveau ticket ou augmentez la période d’expiration dans votre configuration à des fins de test.

Je reçois HTTP 404 Introuvable lors de la vérification de mon ticket.

• Votre ticket a été supprimé soit par une requête DELETE, soit en atteignant sa période de suppression (qui commence après l’expiration du ticket, définie dans votre configuration). Recréez un nouveau ticket ou augmentez les périodes d’expiration/suppression dans votre configuration à des fins de test.

Mon matchmaker affiche une erreur, que dois-je faire ?

• S’il s’agit d’une instance de développement ou de test, essayez d’abord de redémarrer votre matchmaker. - Veuillez signaler tout problème via notre Discord communautaire.

• Si ce problème affecte un jeu en ligne, créez une demande de support urgente.

🔖 Journal des modifications

Votre fichier de configuration sera validé en fonction de la version du matchmaker utilisée, assurez-vous que vos règles correspondent aux capacités de la version du matchmaker.

La dernière version du matchmaker est 3.2.2. Tous les exemples sur cette page sont à jour. Surveillez les avis de fin de support pour votre version du matchmaker. Voir aussi ⏩ Mises à jour progressives.

3.2.2 (18 mars 2025)

🩹 Corrections de bugs :

• Correction mineure pour dissoudre les équipes si un joueur apparié supprime son ticket avant qu’un match ne soit trouvé.

Il s’agit de la dernière version du service de matchmaker, recommandée pour une utilisation en production.

Pour mettre à niveau la version de votre matchmaker - Arrêter, Modifier, Redémarrer. Le redémarrage rapide n’appliquera pas les changements de version.

3.2.1 (24 nov. 2025)

🩹 Corrections de bugs :

• Corrections mineures de déploiement, plusieurs erreurs résolues lors du démarrage de votre matchmaker.

3.2.0 (31 oct. 2025)

🩹 Corrections de bugs :

• Divers correctifs mineurs de spécification et mises à jour de cohérence de la documentation.

• Divers correctifs de stabilité et d’auto-réparation sur l’infrastructure du matchmaker.

✨ Améliorations et nouvelles fonctionnalités :

• Présentation de la fonctionnalité Vue approfondie fonction - la gestion des groupes est désormais facile et ne nécessite pas de tiers !

  • Plus besoin de partager des attributs de ticket complexes entre les membres du groupe, vous n’avez besoin que de l’ID du groupe.

  • Commencez le matchmaking en tant que groupe une fois que tous vos joueurs se sont déclarés prêts.

  • Validez les attributs des membres du groupe par rapport au chef du groupe lors de l’adhésion, empêchant les groupes impossibles à apparier (les attributs des joueurs du groupe ne correspondraient pas selon les règles du profil).

  • Validez la taille du groupe et refusez les nouvelles adhésions une fois la taille maximale de l’équipe atteinte.

  • Lisez notre documentation mise à jour avec le nouveau flux utilisateur, les mises à jour du SDK arrivent bientôt !

• Les tickets (adhésions) incluent désormais votre ID de match - suivez les joueurs et ajoutez des éléments d’interface pour partager les pseudonymes de votre équipe ou des équipes adverses, leur classement de compétence ou d’autres propriétés stockées chez des tiers.

• Majeure Vue approfondie remaniement basé sur des tests de charge internes, meilleure gestion des courtes rafales.

• Taux de remplissage des matchs amélioré grâce au report de la taille des matchs partiels jusqu’à la fin de l’expansion.

  • Si la taille maximale de l’équipe est atteinte, le match est apparié immédiatement.

  • Sinon, le match est apparié à la fin de l’expansion en cours, si la taille minimale de l’équipe est atteinte.

• Définissez des périodes d’expiration et de suppression par profil et optimisez pour la meilleure expérience joueur.

Pour mettre à jour votre configuration, augmentez la version et copiez les champs d’expiration et de suppression dans chaque profil.

3.1.0 (10 juin 2025)

🩹 Corrections de bugs :

• Les matchmakers valident désormais correctement les tickets avec plusieurs profils incluant des règles différentes.

✨ Améliorations et nouvelles fonctionnalités :

• Plus d’optimisations pour maximiser le taux de remplissage des matchs avec la règle player_count. Les tickets attendront désormais la fin de l’expansion (ou l’expiration) si seul un match partiel est possible (>min et <max team size).

  • Les matchs complets (taille maximale de l’équipe atteinte) sont créés immédiatement (aucun changement).

• Passez à Enterprise Vue approfondie pour débloquer le matchmaking Vue approfondie! Obtenez des informations sur la charge et les performances du matchmaker, sans code ni configuration requis. Les métriques au lancement incluent :

  • le total des tickets, backfills, affectations et déploiements effectués sur une période personnalisée,

  • les taux par minute pour les métriques ci-dessus sur une période personnalisée,

  • les totaux et des informations de séries temporelles sur les tickets expirés, les matchs étendus, le taux de remplissage des matchs,

  • les métriques d’utilisation de l’API, et plus encore.

• Amélioration de la Règles documentation avec de meilleurs exemples et visuels.

3.0.0 (20 mai 2025)

⚠️ Changements incompatibles :

• Utilisez taille minimale/maximale de l’équipe pour remplir les équipes efficacement (remplace les expansions par nombre de joueurs) :

  • dans votre configuration player_count règle, remplacez team_size par min_team_size et max_team_size pour obtenir un appariement au "meilleur effort" visant à maximiser le taux de remplissage des matchs,

  • pour exiger un nombre spécifique de joueurs par équipe, définissez la valeur minimale et la valeur maximale à la même valeur,

  • les backfills contournent la player_count règle et s’apparentent toujours avec 1 ticket (inchangé).

• Les tickets, tickets de groupe et backfills dont toutes les latences dépassent le plus élevé max_latency dans un profil donné seront immédiatement rejetés avec une réponse 400 Bad Request à la requête de création de ticket, au lieu d’expirer :

  • s’applique uniquement si la règle de latence est configurée,

  • pour contourner ce comportement, créez une expansion avec max_latency: 99999 (toute valeur supérieure au délai d’attente de mesure de latence de votre client).

• Les variables d’environnement injectées contenant les données du ticket incluent désormais le champ id (ID du ticket) afin de pouvoir être réutilisées plus facilement lors de la création de Vue approfondie.

🩹 Corrections de bugs :

• Vue approfondie utilise désormais les périodes de suppression et d’expiration configurées (comme les tickets et les tickets de groupe).

• Vue approfondie correspond désormais correctement en utilisant les intersection règles.

• Corrigé la spécification openAPI pour la requête POST Vue approfondie (nécessite public_ip) et la réponse GET /tickets (team_id est facultatif), y compris des exemples.

✨ Améliorations et nouvelles fonctionnalités :

• Jusqu’à 3 fois plus de correspondances potentielles sont désormais prises en compte, produisant des groupes plus optimaux et maximisant le taux de remplissage des matchs.

• Vitesse de matchmaking jusqu’à 200 % plus rapide grâce aux optimisations de concurrence.

• Taux de remplissage des matchs jusqu’à 40 % plus élevé grâce à l’optimisation de l’algorithme d’expansions.

• Stabilité du service améliorée et vitesse accrue des redémarrages rapides.

Les benchmarks ont été produits avec des données générées par chaos en utilisant la configuration de l’exemple avancé.

Archives du journal des modifications (v2.1.0 et antérieures)

2.1.0 (24 fév. 2025)

⚠️ Changements incompatibles :

• Séparation des informations de profil de jeu et d’étape d’expansion dans le Vue approfondie:

  • MM_MATCH_PROFILE n’inclura désormais que le nom du profil tel qu’il apparaît dans la configuration.

  • Introduction de MM_EXPANSION_STAGE qui contiendra l’étape d’expansion sous forme de chaîne (par ex. "initial", "15", "30").

• Les affectations de tickets incluent désormais l’ID du groupe lorsque Vue approfondie. L’ID du groupe est également inclus comme Vue approfondie, sous forme de mappage de l’ID du groupe vers une liste des IDs des joueurs du groupe.

• Les affectations de tickets incluent désormais l’ID de l’équipe lorsque Vue approfondie. L’ID de l’équipe est également inclus dans chaque donnée de ticket Vue approfondie.

• Vue approfondie retourne désormais le code 409 Conflict HTTP au lieu de 204 No Content pour indiquer que le ticket ne peut pas être supprimé puisque le déploiement est en cours de démarrage. Pour remplacer les départs, utilisez un Vue approfondie émis par le serveur après un délai d’attente prédéfini.

• Vue approfondie paramètre du corps de la requête attributes.deployment_request_id a été déplacé vers attributes.assignment.request_id.

• Vue approfondie le corps de la requête nécessite désormais les détails complets de l’affectation dans attributes paramètre en plus de request_id.

🩹 Corrections de bugs :

• Les valeurs de règle d’intersection résolues sont désormais Vue approfondie dans la variable d’environnement MM_INTERSECTION .

• La fonctionnalité de redémarrage rapide régénère désormais de manière fiable les points de terminaison de l’API et la spécification openAPI lorsque la configuration est modifiée.

• Correction de plusieurs bogues lors du démarrage (ou redémarrage) du matchmaker, provoquant un temps de démarrage prolongé ou le blocage du matchmaker.

✨ Améliorations et nouvelles fonctionnalités :

• Augmentation des limites de débit et de la scalabilité de tous les points de terminaison de l’API, sur tous les niveaux de matchmaker.

• Lors de l’affectation d’un joueur à un Vue approfondie, le ticket du nouveau joueur sera ajouté comme balise au Déploiements.

• Ajout de la fonctionnalité d’authentification de l’interface Swagger UI pour tester l’API directement dans l’interface web sans avoir besoin de Postman.

• Amélioration des exemples openAPI pour refléter plus fidèlement des requêtes et réponses réalistes.

• Ajout d’un nouveau Vue approfondie destiné à des fins de développement et de débogage.

  • Permet de lister tous les tickets de joueurs actuels dans une liste paginée.

  • Permet de lister tous les matchs actuels dans une liste paginée.

1.0.0 (9 déc. 2024)

• Vue approfondie: À la demande (populaire), nous ajoutons le backfill avec affectation automatique des tickets, ce qui vous permet de réutiliser les sièges serveur lorsque des joueurs quittent la session.

  • Idéal pour remplir les sièges joueurs vides après qu’un match a commencé, ou pour remplacer les joueurs qui ont quitté pendant un match.

• Vue approfondie: Nous ajoutons la possibilité de rejoindre en groupe à la fonctionnalité déjà disponible de remplir plusieurs équipes avec des joueurs.

  • Idéal pour rejoindre une file de matchmaking avec un groupe d’amis ou à partir d’un lobby commun.

• Outils pour développeurs et Outils pour développeurs SDK de matchmaking :

  • Pour faciliter l’intégration, nous proposons désormais des kits de développement logiciel pour les moteurs de jeu les plus populaires.

• Correction d’un bug où le Vue approfondie n’était pas appliqué correctement.

• Les tickets seront désormais automatiquement annulés après un Vue approfondie s’ils n’ont pas été affectés à un déploiement.

• Vous pouvez désormais Vue approfondie pour améliorer le déroulement de votre processus de matchmaking.

• Les déploiements effectués par le matchmaker sont désormais étiquetés avec des IDs de ticket.

• Vous pouvez désormais modifier votre configuration pendant que le matchmaker est en cours d’exécution. Cela déclenche un rechargement rapide de votre configuration sans nécessiter un cycle complet d’arrêt/démarrage de votre matchmaker. Remarque : Cette fonctionnalité n’est pas recommandée pour les environnements de production, car elle supprime tous les tickets en cours et rend temporairement l’API non réactive.

• Corrigé Vue approfondie pour utiliser les types primitifs corrects au lieu de tableaux.

• Corrigé Vue approfondie Valeurs JSON, qui contenaient auparavant des caractères échappés.

0.2.3 (8 oct. 2024)

• Correction d’un bug où certains en-têtes n’étaient pas acceptés par le matchmaker lorsque les requêtes provenaient d’une application WebGL (politiques CORS).

0.2.2 (3 oct. 2024)

• Correction d’un problème de validation du certificat TLS/SSL empêchant le lancement du matchmaker.

0.2.1 (30 sept. 2024)

• Correction d’un bug provoquant le retour d’une erreur 500 par le point de terminaison beacons.

0.2.0 (25 sept. 2024)

• L’authentification de base est désormais obligatoire pour tous les points de terminaison.

• Ajout de la possibilité de configurer le nombre de nouvelles tentatives en cas d’échec de l’affectation au serveur.

• Le matchmaking basé sur les équipes est désormais le mode par défaut pour toutes les configurations de matchmaking.

• L’application et la version sont désormais toutes deux des champs obligatoires dans tous les profils.

• Introduction d’un nouveau point de terminaison pour surveiller l’état du matchmaker.

• Mise à jour du format de la variable d’environnement des tickets dans le déploiement.

• Ajout d’une option de configuration permettant aux hôtes de communiquer avec le matchmaker.

• L’API de débogage n’est désormais disponible que lorsqu’elle est explicitement activée dans la configuration (elle est actuellement désactivée pour remaniement).

• Le game_profile clé dans la réponse GET du ticket a été remplacée par profil.