Regard approfondi

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

✔️ Introduction

Le matchmaking dans les jeux basés sur des matchs vise généralement à :

• trouver d'autres joueurs en fonction de critères tels que la région, la latence, le niveau, ou les paramètres du jeu ;

• rechercher des serveurs pour rejoindre en fonction de la capacité disponible [ou du ping, de la région, du niveau, de la carte, du mode] ;

• démarrer un nouveau serveur si les serveurs existants sont pleins ou ne répondent pas aux critères des joueurs.

L'expérience du joueur passe avant tout, définissant nos objectifs principaux :

• taux de remplissage des matchs élevé et intégration des fonctionnalités sociales (jouer avec des amis en groupe),

• matchs rapides avec qualité de match contrôlée (faible latence, préférences partagées),

• processus de matchmaking fiable et prévisible avec une disponibilité mondiale.

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é). Intégration native avec Edgegap Déploiements offre le meilleur ping de sa catégorie, peu importe où se trouvent vos joueurs.

Trois concepts essentiels composent chaque Matchmaker :

• Regard approfondi - infrastructure serveur sous-jacente, entièrement gérée et exploité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 exécuté 24h/24 et 7j/7 sur le cluster, utilisant la configuration pour mettre les joueurs en relation et produire des affectations de déploiement (serveur).

▶️ Démarrer le matchmaking

Démarrez rapidement - ajoutez l’exemple de démarrage de notre SDK à votre jeu:

• Unreal Engine Outils de développement:

  • lire la documentation par Betide Studios,

  • installer depuis Fab Marketplace (gratuit pour un usage personnel),

  • importer un blueprint d'exemple simple (matchmaking) et personnaliser selon vos besoins.

• Unity Outils de développement:

  • installer le package gratuitement via Unity Package Manager,

  • explorez notre guide de démarrage et des exemples complets.

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

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

2. Créer un lobby - rejoignez vos amis et partagez les préférences joueur/match,

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

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

   1. Attribuer un 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.

Authentifier

Toutes les requêtes doivent envoyer un Authorization en-tête HTTP avec votre secret Jeton d'authentification :

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 personnalisée ou des limites 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.

Lobby et groupe

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

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

Le propriétaire du lobby (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 lobby, afin que les autres membres du lobby puissent facilement trouver et rejoindre un groupe de matchmaking associé au lobby tiers. Les joueurs invités au groupe utilisent l’ID du groupe pour créer leur adhésion (rejoindre), et pour stocker en toute sécurité leurs attributs de matchmaking.

Optimisation du ping

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

Quitter la file

Le propriétaire du groupe peut supprimer le groupe, ce qui supprime automatiquement toutes les adhésions au groupe. Supprimer le groupe après le début du matchmaking annulera toutes les adhésions, puis les supprimera peu de temps après.

Les membres du groupe (à l’exception du propriétaire) peuvent supprimer leurs adhésions (quitter le groupe) à tout moment avant Regard approfondi. Supprimer une adhésion par la suite annulera le matchmaking pour tout le groupe.

Une fois annulé, si le groupe souhaite relancer le matchmaking, le propriétaire du groupe doit recréer le groupe, partager le nouvel ID de groupe avec les 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 Conflit), et sera supprimé automatiquement. Votre serveur doit laisser un certain temps (p. ex. 60 s) aux joueurs pour se connecter avant de considérer qu’un joueur a abandonné.

Si votre serveur signale qu’un joueur a abandonné, vous pouvez :

• remplacer le joueur parti par un personnage IA afin de démarrer immédiatement la partie,

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

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

Trouver une partie

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

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

Les joueurs devraient enregistrer de façon persistante leur adhésion et leurs IDs de groupe, ce qui leur permet de relancer le jeu et de reprendre sans perdre la progression du matchmaking en cas de crash du client de jeu.

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 la réponse de leur 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 toutes les autres affectations de groupe à la même équipe vers status:SEARCHING .

Les équipes continuent le matchmaking avec d’autres équipes en utilisant les valeurs qui se chevauchent entre leurs groupes (ou la moyenne dans le cas de number_difference ) jusqu’à ce que suffisamment d’équipes soient assemblées. 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. suffisamment d’équipes sont appariées avec la taille d’équipe maximale configurée,

2. ou si Regard approfondi est défini ET que le temps d’expansion est atteint, ET que suffisamment d’équipes sont appariées avec la taille d’équipe minimale configurée,

3. ou que le temps d’expiration du ticket configuré s’est écoulé ET que suffisamment d’équipes sont appariées avec la taille d’équipe minimale configurée.

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

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

Si le joueur a été apparié et affecté à un serveur de jeu, son ticket est supprimé automatiquement. Les joueurs qui quittent 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 à Regard approfondi.

Se connecter au serveur

Quelques secondes après avoir trouvé une correspondance, les adhésions passent à status:HOST_ASSIGNED indiquant que votre le déploiement est maintenant prêt et votre serveur de jeu est en cours d'initialisation.

Chaque joueur lit son ticket_id et attribution et tente une connexion en utilisant le FQDN (URL du déploiement) et le port externe. Votre serveur de jeu est peut-être encore en cours d'initialisation à ce moment-là, donc les joueurs doivent réessayer la connexion plusieurs fois, jusqu’à dépasser votre temps d'initialisation habituel du serveur :

Les clients de jeu doivent enregistrer de façon persistante leur identifiant d’attribution entre les redémarrages du jeu, afin qu’en cas de plantage du client de jeu, ils puissent récupérer les détails de connexion et tenter de se reconnecter.

Match de backfill

Optionnellement, certains jeux peuvent avoir des besoins particuliers en matière de matchmaking, tels que :

• permettre à de nouveaux joueurs de rejoindre des parties en cours (amis ou « aléatoires »),

• remplacer les joueurs qui quittent (abandonneurs) après le démarrage du serveur afin d’éviter de relancer la partie,

• permettre aux spectateurs de rejoindre et d’observer les matchs de tournoi ou d’amis (e-sport),

• centraliser les joueurs sur des serveurs plus grands afin d’offrir davantage d’interactions sociales (MMO).

Le backfill est un ticket détenu par le serveur représentant les joueurs actuellement connectés au serveur. Cela garantit que les joueurs ajoutés ultérieurement respecteront vos règles de matchmaking lorsqu’ils seront mis en correspondance avec les joueurs actuels.

Les étapes pour réaliser un backfill réussi sont :

1. Le serveur crée un Backfill pour chaque équipe à laquelle il manque des joueurs, en utilisant les valeurs provenant de :

   • Réel affectation données récupérées depuis Variables injectées (déploiement).

   • des joueurs actuellement connectés tickets:

     • depuis Regard approfondi (matchmaker), des backfills précédents assigned_ticket réponse, ou des données fictives manipulées pour correspondre à des joueurs spécifiques,

     • remplacer backfill_group_size les valeurs par les tailles de groupe possibles jusqu’à la capacité disponible,

2. Les clients de jeu créent de nouveaux tickets (adhésions) et incluent backfill_group_size valeurs :

   • "1" si le joueur effectue le matchmaking seul.

   • "2" si le joueur fait partie d’un groupe de matchmaking de 2x membres au total.

   • "nouveau" si les joueurs ont activé le lancement de nouvelles parties en plus de la possibilité de rejoindre des parties en cours.

3. Les clients de jeu passent ensuite à Regard approfondi et associent les joueurs au backfill correspondant.

4. Si le groupe complété par backfill n’a pas entièrement rempli l’équipe, le serveur peut répéter ce processus avec les tickets des joueurs nouvellement ajoutés via backfill, afin d’ajouter davantage de joueurs et d’atteindre les tailles d’équipe souhaitées.

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

• Lancer le 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 lobby, ou un écran de chargement avec une barre de progression.

• Suivre les nouvelles connexions de joueurs ou les départs des joueurs existants au fil du temps:

  1. Les nouveaux joueurs doivent annoncer l’ID de ticket au serveur pour l’authentification et pour associer leur connexion au matchmaker Regard approfondi ou assigned_ticket (si complété par backfill).

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

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

• Nettoyer (supprimer) tout backfill restant une fois que le Déploiements:

  • Unity - OnApplicationQuit callback ou 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 valide du serveur et au moins un ticket sont fournis. Voir Appariement 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 redémarré rapidement). Vous pouvez spécifier n’importe quel nombre de profils avec des règles et des expansions variées :

Profils (files d’attente)

Les profils représentent des files de matchmaking entièrement séparées, partageant la même version de 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).

Règles

Chaque joueur et groupe rejoint la file de matchmaking et trouve des matchs en utilisant les règles initiales

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

• key est une valeur de chaîne servant à 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.

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.

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 d’arriver,

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

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

• les attributs du groupe sont calculés comme la moyenne/le chevauchement des attributs joueurs du groupe,

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

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

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

number_difference associe les joueurs selon la différence numérique absolue entre eux.

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.

latences est une règle spéciale optimisant le ping des matchs de joueurs :

• réduire la latence client-serveur en supprimant les régions à forte latence (au-dessus du seuil),

• améliorer l’équité des matchs en regroupant les joueurs ayant une latence similaire (en dessous de la différence).

Certains joueurs ayant un ping élevé vers tous les balises en raison de Fournisseur d'accès des problèmes ou d'une connexion lente (par ex. sans fil/mobile) peuvent provoquer des lags et dégrader l'expérience de jeu des autres. Pour atténuer ce problème :

• Élargir progressivement la latence maximale et l'écart autorisés (voir Exemple de configuration avancée),

  • les joueurs avec un ping élevé peuvent devoir attendre plus longtemps que d'habitude pour trouver une partie.

• Alternativement, permettre aux joueurs de remplacer la mesure par une sélection manuelle de région, n'envoyant des valeurs de ping factices que pour les régions sélectionnées par le joueur uniquement (par ex. 25 ms pour une correspondance rapide),

  • cela peut avoir un impact négatif sur l'expérience des coéquipiers et des adversaires du joueur.

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 correspondra :

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

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

Expansion des règles

Optionnellement, 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 permet d’obtenir des parties plus rapides.

📌 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 éléments habituels Applications et versions.

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

🧵 Traçage des joueurs

Si vos joueurs rencontrent des problèmes, tracer leur parcours jusqu’aux journaux du serveur peut être utile. Chaque Matchmaker déploiement sera étiqueté avec les IDs de ticket des joueurs attribués afin que vous puissiez facilement Déploiements et trouver Déploiements pour vous aider à résoudre les problèmes.

👀 Analytique

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

🌟 Passez Matchmaker au niveau Entreprise pour débloquer les métriques et les informations du matchmaking :

☁️ Cluster d’hébergement

Matchmaker est hébergé et géré 24 h/24, 7 j/7 par Edgegap.

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

• Cluster gratuit (partagé) pour tester toutes les fonctionnalités et explorer les synergies avec votre conception,

  • s'éteint automatiquement après 3 heures, nécessitant un redémarrage pour continuer les tests.

• Cluster privé (dé dédié) pour garantir un environnement stable pour vos besoins de production,

  • choisissez votre région et obtenez un support 24/7 pour les jeux en direct afin de publier en toute confiance.

Niveaux de cluster privé

Nous proposons actuellement 3 niveaux de cluster privé pour répondre aux besoins de chacun :

Passez à un cluster privé en un clic. Il est également possible de modifier les niveaux de cluster privé après le lancement, sans interruption 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, 7 j/7 pour les jeux publiés au public.

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

• 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 tentatives plus rapides augmentent la charge du service et consomment des ressources,

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

• durée moyenne d’un match - des sessions plus courtes poussent les joueurs à rejoindre le matchmaking plus souvent,

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

• logique de repli des tentatives côté client - réessayer avec un backoff à temporisation aléatoire aide à répartir les pics de trafic.

⏩ Mises à jour progressives

Suivre la compatibilité entre les versions du serveur et du client peut devenir complexe. Suivez nos conseils pour des mises en production fiables, des mises à jour fiables et pour éviter les interruptions ou les problèmes de compatibilité.

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

⚠️ Avant la mise en ligne

Nous recommandons de créer plusieurs copies de votre matchmaker à l’avance : vert, bleu et orange. Vous pouvez faire tourner le matchmaker utilisé au fur et à mesure que vous publiez 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.

🔃 Mise à jour du client + serveur

Prérequis : Cette section suppose que vous avez terminé Regard approfondi.

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

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

   1. publier un nouveau tag d’image dans votre registre de conteneurs t1.2.0,

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

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

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

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

   1. activer le cache pour la nouvelle version de l’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’ils font référence au même tag,

   2. attendez 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 de tickets :

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

5. Effectuez des 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. attendez 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 période d’attente),

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

7. Laissez 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 le tag d’image t1.0.0 pour libérer de la capacité dans le registre de conteneurs,

   2. supprimer le tag d’image t1.1.0 pour libérer de la capacité dans le registre de conteneurs,

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

⚡ Correctif serveur

Prérequis : Cette section suppose que vous avez terminé Regard approfondi.

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 un nouveau tag d’image dans votre registre de conteneurs t1.2.0,

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

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

   1. connectant 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 le cache pour la nouvelle version de l’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 au même tag,

   4. attendez 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 nouveau tag d’image t1.2.0,

   1. les nouveaux matchs lanceront automatiquement l’attribution avec le tag mis à 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 le tag d’image t1.1.0 pour libérer de la capacité dans le registre de conteneurs.

📗 API

Les clients et les serveurs peuvent appeler l’API directement ou via les SDK des moteurs de jeu, voir aussi Appariement.

Importer la spécification de l'API vers Client Web de l'API Scalar ou Éditeur Swagger pour inspecter les détails.

Limites de débit

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

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

Tests de charge

Les tests de charge dans un environnement similaire à la production entraînent un coût d’hébergement du déploiement. Consultez les ressources et les prix associés à chaque niveau sur notre page de tarification.

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

Comportement sous charge

Si un matchmaker subit une forte charge :

• si le CPU est bridé, le matchmaking peut ralentir,

• si le matchmaker manque de mémoire, il redémarrera sans perdre les informations des tickets, en espérant que les clients mettront en œuvre un backoff exponentiel et que la rafale sera répartie sur une période plus longue.

Partage des ressources entre origines croisées (CORS)

Pour les jeux WebGL hébergés sur des plateformes de distribution tierces (p. ex. itch.io), l’envoi de requêtes au Matchmaker depuis le client de jeu peut entraîner le partage des ressources entre origines croisées des violations de politique. La plupart des navigateurs Web modernes envoient une requête de prévol 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 de prévol (par défaut pour des raisons de sécurité) peut entraîner l’une de plusieurs erreurs possibles liées à CORS, le plus souvent en-tête CORS 'Access-Control-Allow-Origin' manquant .

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

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

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

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 n’importe quel cloud FaaS plateforme de calcul, pour obtenir l’un des résultats suivants :

• associer des attributs sensibles des joueurs - comme des indicateurs de triche, des notes de compétence ou similaires,

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

• restreindre certains cas particuliers - par ex. n’autoriser qu’un seul groupe par joueur à tout moment,

• ajouter du 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 salon-groupe - créer des salons asymétriques ou basés sur les rôles avant le matchmaking.

🚨 Dépannage

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

🔖 Journal des modifications

Versionnage sémantique

Nos outils de développement et nos services managés utilisent les officielles Versionnage sémantique, indiquant quelles mises à jour sont ✅ sûres (mineures, correctifs) et lesquelles peuvent contenir des ⚠️ changements incompatibles (majeurs).

Une fois qu'une version est publiée, elle ne sera jamais modifiée/changée.

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