Regard approfondi
En savoir plus sur les concepts de matchmaker sans code d’Edgegap en profondeur et personnalisez-les selon vos besoins.
✔️ Introduction
Commencez en 5 minutes et testez toutes les fonctionnalités gratuitement, sans carte de crédit requise.
Passez à la version 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 un ping de premier ordre où que soient vos joueurs.
Le niveau gratuit permet 3 heures d’exécution après chaque redémarrage. Votre matchmaker fonctionnera sur une infrastructure partagée avec des ressources limitées, adaptée aux tests. Après votre sortie publique, le matchmaker doit fonctionner 24/7.
Il y a trois concepts essentiels pour 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 fonctionnant 24/7 sur le Cluster, utilisant la Configuration pour mettre les joueurs en relation et produire des affectations de déploiement (serveur).
Mettez fréquemment à jour votre version de matchmaker pour profiter des nouvelles fonctionnalités et 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.
Authentifier le joueur - empêche les copies piratées de jouer en ligne,
Créer une lobby - rejoignez vos amis et partagez les préférences joueur/match,
Se regrouper - enregistrez votre Lobby en tant que groupe de matchmaking,
Trouver un match - préparez-vous et commencez à chercher un match (nouveau ou existant),
Affecter le serveur et injecter les tickets - le serveur est automatiquement affecté après quelques secondes,
Se connecter et authentifier - tenter une connexion sécurisée au serveur de jeu,
Confirmer l’identité - le serveur vérifie l’identité du client de jeu en utilisant des jetons tiers,
Accepter ou expulser un joueur - 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 n’accorde pas d’accès à l’API Edgegap.
Les joueurs individuels peuvent être identifiés à l’aide de leur ID de ticket, disponible sur les clients et le serveur. Optionnellement, ajoutez une authentification personnalisée ou des limites avec un proxy personnalisé en utilisant Serveur à Serveur l’API.
Se regrouper
Créer un groupe (party) garantit que les joueurs rejoignent la même équipe et le même serveur avec leurs amis.
Créez un groupe marqué prêt à Regard approfondi aussi rapidement qu’un joueur solo sans membres de groupe.
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 (par ex. choix de personnage, difficulté, carte, etc.). Lorsque les joueurs rejoignent et quittent le Lobby, ils mettent également à jour le groupe de matchmaking pour se préparer à trouver un match plus tard.
Pas le temps pour un service de Lobby ? Invitez les joueurs à partager les IDs de groupe via Discord ou messages privés.
inviter des amis à jouer avec moi
✅
✅
modifier mes préférences joueur/match
✅
❌
voir les préférences des autres membres du lobby
✅
❌
stocker et gérer des données personnalisées clé-valeur
✅
❌
notifier les membres du groupe que je suis prêt à jouer
❌
✅
afficher la progression du matchmaking et trouver un match
❌
✅
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 Lobby commerciaux et personnalisés :
Epic Online Services Lobby (Epic Games)
Steamworks Lobby (Valve Corporation)
Nakama Group (Heroic Labs)
Playfab Lobby (Microsoft)
brainCloud Lobby (bitHeads)
Gamekit Friends (Apple)
Lobby personnalisé (votre entreprise)
Le propriétaire du Lobby (le joueur envoyant des invitations) doit également créer le groupe de matchmaking.
Stockez l’ID de votre groupe dans vos données de lobby partagées, afin que les autres membres du lobby puissent facilement trouver et rejoindre un groupe de matchmaking associé au lobby tiers. Les joueurs invités dans le 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. Regard approfondi et en créer un nouveau.
Optimisation du ping
Si ⚙️ Configuration comprend latences règle tous les membres du groupe envoient leurs Balises de ping mesures à empêcher de mettre en relation des joueurs dans des régions éloignées ou avec un ping (latence) beaucoup plus élevé/plus faible.
Abandonner la file d’attente
Le propriétaire du groupe peut supprimer le groupe, supprimant automatiquement toutes les adhésions du groupe. Supprimer le groupe après le démarrage du matchmaking annulera toutes les adhésions, et 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 le matchmaking annulé, les membres sont retirés du matchmaking automatiquement et notifiés via l’adhésion statut:CANCELLED dans leur prochaine réponse de sondage 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 de groupe avec les membres et leur faire recréer leurs adhésions.
Une fois qu’un match est trouvé, le groupe ne peut pas être supprimé (409 Conflit), et sera supprimé automatiquement. Votre serveur devrait laisser un certain 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 partant par un personnage IA pour démarrer immédiatement le match,
ou créer un backfill pour trouver un nouveau joueur pour remplacer le partant,
ou poursuivre sans remplacer le partant, si la conception de votre jeu permet un nombre variable de joueurs.
Trouver un match
Pour commencer à chercher un match, tous les membres et le propriétaire doivent se marquer comme prêts.
Pour permettre au propriétaire du groupe de démarrer le matchmaking immédiatement, marquez les adhésions comme prêtes lors de la création. Une fois que le propriétaire se marque prêt, le matchmaking commencera, puisque tout le monde est prêt.
Pour une meilleure expérience, fournissez des mises à jour de statut aux joueurs via l’interface utilisateur en jeu.
Tous les joueurs doivent sonder leur adhésion à intervalles réguliers (recommandé 3-5 s) pour détecter le démarrage du matchmaking, et pour communiquer la progression du matchmaking via l’interface utilisateur en jeu.
Les joueurs devraient enregistrer de manière persistante leur ID d’adhésion et de groupe, afin qu’en cas de plantage du client de jeu ils puissent relancer le jeu et reprendre sans perdre la progression du matchmaking.
Une fois que nous trouvons suffisamment de joueurs à placer dans la même équipe en respectant votre Règles, les joueurs seront notifiés dans leur réponse d’adhésion avec statut:TEAM_FOUND.
Supprimer une adhésion à ce stade entraînera l’annulation de toutes les adhésions de groupe et le retour de toutes les autres équipes affectées au même équipage à statut:SEARCHING .
Les équipes continuent 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 que suffisamment d’équipes soient constituées. Les adhésions l’indiquent avec la réponse statut:MATCH_FOUND , ce qui signifie que votre déploiement est en cours de démarrage.
Le matchmaker vise à maximiser le taux de remplissage des matchs, et ne passera pas à MATCH_FOUND jusqu’à ce que l’un des cas suivants :
suffisamment d’équipes sont appariées avec la taille d’équipe maximale configurée,
ou si Regard approfondi est défini ET le temps d’expansion est atteint, ET suffisamment d’équipes sont appariées avec la taille d’équipe minimale configurée,
ou que le temps d’expiration du ticket configuré soit écoulé ET suffisamment d’équipes sont appariées avec la taille d’équipe minimale configurée.
Si aucun des scénarios ne réussit avant l’expiration du ticket configuré, le groupe et les tickets sont annulés.
Vous constatez de longs temps d’attente pendant les tests, ou avec des joueurs dans des régions moins populaires ? Réglez une période d’expiration de ticket plus courte (par ex. 30 s) et recréez le groupe (ou les tickets) côté client à l’expiration.
L’expiration du ticket se réinitialise automatiquement chaque fois qu’un groupe (ou un joueur) est apparié à une équipe.
Stocker team_id et match_id dans le backend de votre jeu pour afficher les informations des membres de l’équipe en jeu.
Chaque joueur reçoit un ID de ticket unique, qui peut être utilisé pour Regard approfondi 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 d’attente après statut:HOST_ASSIGNED peuvent être remplacés par backfill.
Une fois que les joueurs reçoivent statut:HOST_ASSIGNED ils passent à Regard approfondi.
Se connecter au serveur
Backfill du match
Une fois l’initialisation du serveur de jeu terminée, votre serveur doit:
Démarrer le minuteur d’abandon pour chaque nouveau joueur. Nous recommandons d’indiquer la progression du chargement aux joueurs connectés avec une scène/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.
Suivez les nouvelles connexions de joueurs ou les départs de joueurs existants au fil du temps:
Les nouveaux joueurs doivent annoncer l’ID de ticket au serveur pour authentification et pour mapper leur connexion au matchmaker Regard approfondi ou
assigned_ticket(si backfilled).Créez de nouveaux backfills pour la capacité de joueur inutilisée (départs) tout au long de la durée de vie du serveur.
Renouvelez les backfills expirés, qui sont supprimés après
ticket_expiration_period.
Nettoyez (supprimez) tout backfill restant une fois le Déploiements:
Unity -
OnApplicationQuitcallback ou callback de fin de jeu personnalisé,Unreal Engine -
OnWorldDestroyed,PreExit, ou un callback de fin de jeu personnalisé.
Tout profil peut être utilisé pour le Backfill tant qu’une affectation de serveur valide et au moins un ticket sont fournis. Voir Matchmaking 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émarrage rapide). Vous pouvez spécifier n’importe quel nombre de profils avec des règles et expansions variées :
Voir Matchmaking pour nos SDKs 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 provoquant une brève période d’indisponibilité.
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. Diviser votre base de joueurs en 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).
Certaines modes de jeu peuvent nécessiter plus 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 matchs en utilisant initiales règles au départ.
Chaque entrée dans le profil au chemin .rules.initial représente une règle, où :
clé est une valeur chaîne pour nommer la règle comme vous le souhaitez ; par ex.
match_size, etvaleur est un objet définissant le type et les attributs de la règle, conformément à notre jeu de règles standard.
Toutes les règles doivent être satisfaites simultanément pour initier 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 initier l’affectation.
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 matchs, jusqu’à la max_team_size :
spécifiée ; si la taille d’équipe maximale est atteinte, le match est constitué immédiatement,
sinon, les joueurs restent en file d’attente pour remplir le match jusqu’à ce que l’expansion (ou l’expiration) soit sur le point d’être écoulée,
peu avant l’expansion (ou l’expiration), si un match partiel est possible (≥ min et < max team size), ce match sera constitué avec tous les joueurs au même stade d’expansion (en supposant que les autres règles passent).
Pour les modes 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 la moyenne/chevauchement des attributs des joueurs du groupe,
les attributs de l’équipe sont calculés comme la moyenne/chevauchement des attributs de groupe de l’équipe.
En supposant une taille d’équipe fixe de 4 joueurs :
Les groupes s’apparentent en équipes sans sur-remplir, uniquement si une équipe a une capacité suffisante pour accueillir tout le groupe.
string_equality apparie les joueurs ayant exactement la même valeur chaîne.
Exemple de règle : selected_game_mode
selected_game_mode la règle fera correspondre les joueurs en respectant la casse :
✅ Alice + Bob + Dave peuvent être appariés,
❌ Alice + Erin, ou Charlie + Frank ne seront jamais appariés.
Alice
Erin
Frank
Bob
Charlie
Dave
number_difference apparie les joueurs selon la différence numérique absolue entre eux.
Exemple de règle : elo_rating
elo_rating règle ci-dessus avec "max_difference" : 50 initialement :
✅ Alice + Bob peuvent être appariés, ou Bob + Charlie peuvent être appariés,
❌ Alice + Bob + Charlie ne seront jamais appariés.
intersection apparie les joueurs avec une ou plusieurs valeurs chaîne qui se chevauchent, en respectant la casse.
Exemple de règle : selected_map
selected_map 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 de règle
Optionnellement, les expansions modifient les attributs d’une règle après une période passée en file d’attente pour assouplir les limitations et élargir le pool de joueurs pouvant être appariés, ce qui entraîne des matchs plus rapides.
Scénario d’exemple : Expansions
un maximum de 125 ms de latence contre le même (n’importe quel) beacon,
une différence de latence de 125 ms ou moins entre la valeur la plus basse/la plus haute pour le même beacon,
une différence de classement de compétence de 50 points ou moins entre le joueur le moins bien classé et le mieux classé,
le même mode de jeu sélectionné (respect de la casse),
au moins une sélection de carte correspondante (respect de la casse) parmi les joueurs,
au moins une valeur correspondante de taille de groupe de backfill parmi les joueurs.
Dans l’exemple ci-dessus, nous élargissons la recherche en modifiant les attributs après :
30 secondes :
4 joueurs
plage d’elo de 150
latence max 250 ms
60 secondes :
4 joueurs
plage d’elo de 200
latence max 250 ms
3 minutes (180 s) :
1-4 joueurs
plage d’elo de 200
toute latence
Affinement des expansions
Prédire les préférences des joueurs est similaire à viser une cible en mouvement. Commencez avec un ensemble de règles moins restrictif au lancement et optimisez ensuite par itérations avec Regard approfondi.
Ces questions peuvent aider à cadrer votre réflexion :
Quelle est la durée de ma session de jeu ?
Une session de 5 min signifie que chaque joueur rejoint la file toutes les 5 min, ce qui réduira indirectement le temps d’attente grâce à davantage de joueurs en file à un moment donné.
Quel est mon pic CCU et mon CCU de basse période?
S’il y a une forte variance (plus de 60 %) entre bas/haut, vous pourriez avoir besoin d’un profil séparé pour la basse période afin d’attendre plus longtemps à chaque expansion, pour accumuler plus de joueurs.
Quelle est la distribution géographique de mes joueurs ?
Une répartition homogène sur plusieurs fuseaux horaires signifie que le pic et la basse période ont une variance plus faible, mais n’améliore pas la vitesse de match puisque les joueurs de différentes régions ne devraient pas s’apparier si votre Regard approfondi est correctement configuré (cela entraînerait un ping élevé).
Quelle est la distribution des notes de compétence de mes joueurs (par région) ?
La distribution des compétences suit typiquement une courbe en cloche (distribution naturelle), donc à chaque écart-type par rapport à la moyenne, vous trouvez moins de joueurs plus éloignés de la moyenne. Les joueurs avec des valeurs moyennes seront appariés rapidement, lors de la première expansion, mais les extrêmes posent problème.
Nous recommandons d’augmenter la valeur de différence élargie à chaque expansion, par ex. 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 une catégorie challenger (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 macro sur l’ensemble de la base de joueurs. (tendance vers les extrêmes, courbe en cloche inversée)
Comment puis-je améliorer la vitesse de matchmaking et le taux de remplissage des matchs avec une petite base de joueurs ?
Apprenez autant que possible sur vos joueurs et leurs préférences !
Envisagez de supprimer certaines règles ou d’assouplir les restrictions initialement.
Assouplissez la taille d’équipe ou le nombre d’équipes au fil du temps - un match partiel vaut mieux que pas de match.
Augmentez la durée entre les expansions pour accumuler plus de joueurs.
Contactez-nous pour plus d’astuces et conseils, spécifiquement pour la conception de votre jeu.
Les expansions de n’importe quel attribut de règle écraseront les valeurs précédentes de cet attribut.
📌 Variables injectées
Votre serveur pourrait 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 parallèlement aux habituels Applications et versions.
Aperçu non formaté 🏁 Variables d’exemple avancées :
Les variables d’environnement sont stockées sous forme de JSONs sous forme de chaîne, analysez-les en utilisant notre SDK ou une méthode personnalisée.
Les serveurs peuvent mapper les connexions des joueurs aux groupes et aux attributs après que le joueur envoie son ID de ticket au serveur.
🧵 Traçage des joueurs
Si vos joueurs rencontrent des problèmes, tracer leur chemin jusqu’aux logs du serveur peut être utile. Chaque déploiement de Matchmaker sera étiqueté avec les IDs de tickets des joueurs affectés afin que vous puissiez facilement Déploiements et trouver Déploiements pour vous aider à dépanner.
Affichez les IDs de ticket et les IDs de déploiement dans l’UI d’historique des matchs du client pour tracer les joueurs lors du dépannage.
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 requise.
🌟 Passez le Matchmaker au niveau Enterprise pour débloquer les métriques et insights du matchmaking :
☁️ Cluster d’hébergement
Le matchmaker est hébergé et géré 24/7 par Edgegap.
Choisissez une option d’hébergement la mieux adaptée à votre objectif :
Niveaux de cluster privé
Passez à un cluster privé en un clic. Changer de niveau de cluster privé après le lancement, sans aucune indisponibilité pour les joueurs, est aussi possible avec ⏩ Mises à jour progressives. Les clusters gérés fournissent un hébergement de service à haute disponibilité maintenu par Edgegap avec support en direct 24/7 pour les jeux publiés.
Les besoins en ressources pour votre instance dépendront des facteurs suivants :
nombre de joueurs - plus de joueurs entraînent plus de tickets et de requêtes API,
nombre de requêtes par joueur - des tentatives de nouvelle requête 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 du match - des sessions plus courtes font que les joueurs rejoignent 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 de nouvelle tentative côté client - réessayer avec un backoff jitter aide à étaler 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 récupérer d’une forte charge.
Limites de débit
Pour protéger votre cluster contre le dépassement de sa capacité de rafale et un crash, nous limitons le nombre de requêtes par seconde en nous basant sur nos tests de charge internes en utilisant Matchmaking la configuration.
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'appartenance + 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 après avoir reçu une réponse 429 Trop de requêtes vos déploiements peuvent manquer des joueurs qui arrêtent de lire leurs affectations en raison d'une forte charge.
Test de charge
Le matchmaking et les affectations nécessitent l'utilisation du CPU et de la mémoire, entraînant 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 clusters privés pour les tests de stress. 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 schémas de joueurs réalistes:
✅ Les joueurs rejoignent le matchmaking progressivement, augmentant les req/s sur plusieurs heures.
❌ Tous les joueurs se coordonnent et créent leurs tickets à la même seconde exacte.
✅ Les joueurs attendent un temps croissant entre leurs nouvelles tentatives (par ex. 1s-5s-10s-10s).
❌ 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 leurs affectations en peu de temps (10-60s) et arrêteront le polling.
❌ Tous les joueurs continuent à interroger pendant une durée définie même après avoir reçu une 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 chutent.
❌ Le trafic de pointe est soutenu 24 heures sur 24, avec tous les joueurs jouant nuit et jour.
Si un matchmaker subit une forte charge :
si le CPU est limité, le matchmaking peut être ralenti,
si le matchmaker manque de mémoire, il redémarrera sans perdre les informations des tickets, en espérant que les clients implémentent un backoff exponentiel et que le pic soit étalé sur une période plus longue.
⏩ Mises à jour progressives
Suivre la compatibilité entre les versions serveur et client peut devenir compliqué. Suivez nos conseils pour des releases et mises à jour fiables et pour éviter les temps d'arrêt ou les problèmes de compatibilité.
Votre URL de Matchmaker et le jeton d'authentification resteront toujours les mêmes après un redémarrage.
Créez des matchmakers séparés pour dev & production environnements pour expérimenter en toute sécurité.
⚠️ Avant la mise en ligne
Nous recommandons de créer plusieurs copies de votre matchmaker à l'avance : vert, bleu et orange. Vous pouvez faire pivoter le matchmaker en service lorsque vous publiez des mises à jour (stratégie blue/green).
Choisissez des régions différentes pour chaque instance afin de prévenir les temps d'arrêt lors d'incidents localisés.
🔃 Mise à jour Client + Serveur
Pré-requis : Cette section suppose que vous avez complété Regard approfondi.
Afin de publier des mises à jour client + serveur du jeu, vous pouvez :
Préparer une nouvelle version de l'application serveur
v1.2.0-rcsur Edgegap :pousser une nouvelle étiquette d'image vers votre registre de conteneurs
t1.2.0,créer une nouvelle version d'application
v1.2.0-rc,
Effectuer des tests dev en déployant votre nouvelle version d'application
v1.2.0-rc:connecter l'éditeur de votre moteur de jeu à l'URL fournie + port externe,
Mettre à jour le matchmaker inutilisé
bleupour le lier à votre nouvelle étiquette d'imaget1.2.0,activer la mise en 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 versionv-bluepuisqu'elles référencent la même étiquette,attendre que l'indicateur de mise en cache dans la version
v1.2.0-rcatteigne 🟢 vert,
Mettez à jour votre nouveau client de jeu
c2pour utiliser la nouvelle versionv-bluelors de la création des tickets :mettez à jour votre URL de base et le jeton d'autorisation dans le client de jeu,
Effectuez des tests QA et des vérifications finales de votre nouveau client de jeu
c2:si vous trouvez et résolvez des problèmes, répétez le processus depuis le début,
attendre 3-7 jours pour propager les changements DNS du matchmaker auprès des FAI globalement, après l'arrêt du matchmaker (un redémarrage rapide n'exige pas de mises à jour DNS ni de période d'attente),
Publiez la mise à jour de votre nouveau client de jeu
c2sur les plateformes de distribution de jeux,Laissez le temps au nouveau client de jeu
c2de se distribuer aux appareils des joueurs (généralement jusqu'à 3-7 jours) :surveillez les clients de jeu obsolètes
c1en utilisant le déploiement Déploiements,
Nettoyez les ressources inutilisées dans votre compte Edgegap :
supprimer l'étiquette d'image
t1.0.0pour libérer de la capacité dans le registre de conteneurs,supprimer l'étiquette d'image
t1.1.0pour libérer de la capacité dans le registre de conteneurs,éteignez votre
vertmatchmaker pour suspendre la facturation jusqu'à votre prochaine mise à jour.
Pour votre prochaine mise à jour, augmentez les numéros de version et échangez vert et bleu mots-clés dans le guide.
⚡ Correctif serveur
Pré-requis : Cette section suppose que vous avez complété Regard approfondi.
Pour publier un patch serveur sans nécessiter de mise à jour du client de jeu, vous pouvez :
Préparer une nouvelle version de l'application serveur
v1.2.0-rcsur Edgegap :pousser une nouvelle étiquette d'image vers votre registre de conteneurs
t1.2.0,créer une nouvelle version d'application
v1.2.0-rc,
Effectuez des tests et des vérifications en déployant votre nouvelle version d'application
v1.2.0-rc:connecter l'éditeur de votre moteur de jeu à l'URL fournie + port externe,
si vous trouvez et résolvez des problèmes, répétez le processus depuis le début,
activer la mise en 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 versionv-greenplus tard puisqu'ils référenceront la même étiquette,attendre que l'indicateur de mise en cache dans la version
v1.2.0-rcatteigne 🟢 vert,
Mettre à jour la version
v-greenpour le lier à votre nouvelle étiquette d'imaget1.2.0,les nouveaux matchs initieront automatiquement l'affectation avec l'étiquette mise à jour
t1.2.0,surveillez les clients de jeu obsolètes
c1en utilisant le déploiement Déploiements,
Nettoyage des ressources inutilisées dans votre compte Edgegap :
supprimer l'étiquette d'image
t1.1.0pour libérer de la capacité dans le registre de conteneurs.
📗 API
Les clients et serveurs peuvent appeler l'API directement ou via les SDK des moteurs de jeu, voir aussi Matchmaking.
Serveur à Serveur
Ajoutez des contrôles améliorés ou personnalisés sur le flux de matchmaking - implémentez un proxy personnalisé en utilisant notre Clusters gérés ou n'importe quel cloud FaaS plateforme de calcul, pour obtenir l'un des éléments suivants :
attacher des attributs sensibles du joueur - tels que des drapeaux de tricheur, des classements de compétence, ou similaires,
fournir le contexte d'équipe et de match en jeu - lister mes coéquipiers et adversaires pendant le chargement,
restreindre des cas limites spécifiques - par ex. autoriser seulement 1 groupe par joueur à tout moment,
ajouter de la mise en cache ou des limites de débit 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 profiter de Déploiements.
Les clients de jeu peuvent utiliser ipify.org service gratuit pour trouver leurs IP publiques. Les VPN peuvent masquer l'adresse IP publique.
Partage de ressources cross-origin (CORS)
Pour les jeux WebGL hébergés sur des plateformes de distribution tierces (par ex. itch.io), l'envoi de requêtes vers le Matchmaker depuis le client de jeu peut entraîner des violations de la politique de partage de ressources cross-origin . La plupart des navigateurs web modernes envoient une requête préliminaire pour vérifier qu'un service backend (le Matchmaker) comprend et accepte la communication depuis votre client de jeu.
L'échec de la vérification préliminaire (par défaut pour des raisons de sécurité) peut entraîner l'une des 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 pour soit :
mettre en liste blanche vos domaines d'hébergement client exacts :
ou mettre en liste blanche un domaine générique (incluant tous les sous-domaines) :
Aucune authentification n'est requise pour les requêtes préliminaires du Matchmaker, si les domaines sont configurés correctement.
🚨 Dépannage
Votre succès est notre priorité. Si vous souhaitez envoyer des requêtes personnalisées, demander des fonctionnalités critiques manquantes, ou partager des remarques, veuillez nous contacter sur notre Discord communautaire.
Pourquoi est-ce que j'obtiens des erreurs en essayant 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 formatage de votre JSON, il se peut que vous ayez oublié une virgule ou une parenthèse. - Contactez-nous via notre Discord communautaire pour obtenir de l'aide, nous serons heureux d'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 sont automatiquement éteints après 3 heures. Pour continuer les tests, vous pouvez redémarrer votre matchmaker.
Envisagez de passer à un niveau payant pour un temps d'exécution illimité.
Pourquoi ne puis-je pas démarrer un deuxième déploiement sur mon compte ?
Vous ne pouvez exécuter qu'un seul déploiement simultané dans le 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, sans tenir compte de 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é affectés. Veuillez redémarrer votre matchmaker.
Mon ticket est bloqué dans RECHERCHE .
Veuillez vérifier que vous avez créé suffisamment de tickets correspondants respectant votre configuration.
Mon ticket est bloqué en changeant entre MATCH_FOUND et ÉQUIPE_TROUVÉE à plusieurs reprises.
Les comptes du niveau Gratuit sont limités à 1 déploiement à la fois.
Veuillez envisager de passer à un niveau supérieur ou d'arrêter votre déploiement actuel pour en démarrer un nouveau.
Mon ticket passe directement à ANNULÉ.
Votre ticket a atteint son 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 lorsque je vérifie mon ticket.
Votre ticket a été supprimé soit par une requête DELETE, soit en atteignant sa période de suppression (commence après que le ticket a expiré, 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 de redémarrer d'abord votre matchmaker. - Veuillez signaler tout problème via notre Discord communautaire.
Dans le cas où ce problème impacte un jeu en direct, 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.1. Tous les exemples sur cette page sont à jour. Surveillez les avis de fin de support pour la version de votre matchmaker. Voir aussi ⏩ Mises à jour progressives.
3.2.1 (24 nov. 2025)
Ceci est la dernière version du service matchmaker, recommandée pour une utilisation en production.
Pour mettre à niveau la version de votre matchmaker - Arrêtez, Éditez, Redémarrez. Le redémarrage rapide n'appliquera pas les changements de version.
🩹 Corrections de bugs :
Corrections de bugs mineurs de déploiement, résolution de plusieurs erreurs lors du démarrage de votre matchmaker.
3.2.0 (31 oct. 2025)
🩹 Corrections de bugs :
Diverses petites corrections de spécification et mises à jour de cohérence de la documentation.
Divers correctifs de stabilité et d'auto-réparation dans l'infrastructure du matchmaker.
✨ Améliorations et nouvelles fonctionnalités :
Introduction de Regard approfondi fonctionnalité - la gestion des groupes est désormais facile et ne nécessite pas de tiers !
Fini le partage d'attributs complexes de ticket entre les membres du groupe, vous n'avez besoin que de l'ID de groupe.
Commencez à faire correspondre 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 leader du groupe lors de la jonction, empêchant les groupes non appariables (les attributs des joueurs du groupe ne correspondraient pas aux règles du profil).
Validez la taille du groupe et refusez les nouvelles adhésions une fois la taille d'équipe maximale atteinte.
Lisez notre documentation mise à jour avec le nouveau flux utilisateur, mises à jour SDK bientôt disponibles !
Les tickets (appartenances) incluent désormais votre ID de match - suivez les joueurs et ajoutez des éléments UI pour partager les surnoms de votre équipe ou des équipes adverses, le classement de compétence, ou d'autres propriétés stockées chez des tiers.
Refonte Regard approfondi majeure basée sur des tests de stress internes, meilleure gestion des courtes rafales.
Taux de remplissage des matchs amélioré en retardant la taille des matchs partiels jusqu'à la fin de l'expansion.
Si la taille maximale de l'équipe est atteinte, match immédiat.
Sinon, faire le match à la fin de l'expansion en cours, si la taille minimale de l'équipe est atteinte.
Définissez les 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 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 taille d'équipe).
Les matches complets (taille d'équipe maximale atteinte) sont effectués immédiatement (aucun changement).
Passez à Enterprise Regard approfondi pour débloquer le matchmaking Regard approfondi! Obtenez des informations sur la charge et la performance du matchmaker, sans code ni configuration requis. Les métriques au lancement incluent :
tickets totaux, backfills, affectations et déploiements effectués sur une période personnalisée,
taux par minute pour les métriques ci-dessus sur une période personnalisée,
totaux et séries temporelles des tickets expirés, matchs étendus, taux de remplissage des matchs,
métriques d'utilisation de l'API, et plus encore.
Documentation Règles améliorée avec de meilleurs exemples et visuels.
3.0.0 (20 mai 2025)
⚠️ Changements incompatibles :
Utilisez taille min/max d'équipe pour remplir les équipes efficacement (remplace les expansions basées sur le nombre de joueurs) :
dans votre configuration
player_countrègle, remplacezteam_sizeparmin_team_sizeetmax_team_sizepour atteindre le matching en "meilleur effort" visant à maximiser le taux de remplissage des matchs,pour exiger un nombre spécifique de joueurs par équipe, définissez min et max à la même valeur,
les backfills contournent la
player_countrègle et correspondent toujours avec 1 ticket (inchangé).
Les tickets, tickets de groupe et backfills avec toutes les latences supérieures à la plus élevée
max_latencydans un profil donné seront immédiatement rejetés avec400 Requête incorrecteen réponse à la requête de création de ticket, au lieu d'expirer :s'applique uniquement si règle de latence est configurée,
pour contourner ce comportement, créez une expansion avec
max_latency: 99999(toute valeur supérieure à votre délai d'attente de mesure de latence client).
Les variables d'environnement injectées contenant les données du ticket incluent désormais le champ
id(ID du ticket) afin qu'elles puissent être réutilisées plus facilement lors de la création Regard approfondi.
🩹 Corrections de bugs :
Regard approfondi utilise désormais la période de suppression et d'expiration configurée (comme les tickets et tickets de groupe).
Regard approfondi correspond désormais correctement en utilisant les
intersectionrègles.Corrigé spécification openAPI pour la requête POST Regard approfondi (requiert
public_ip) et la réponse GET /tickets (team_idest optionnel), incluant des exemples.
✨ Améliorations et nouvelles fonctionnalités :
Jusqu'à 3x plus de matchs potentiels sont désormais considérés, produisant des groupes plus optimaux et maximisant le taux de remplissage des matchs.
Jusqu'à 200% plus rapide pour le matching grâce aux optimisations de concurrence.
Jusqu'à 40% d'augmentation du taux de remplissage des matchs 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 configuration d'exemple avancée.
2.1.0 (24 févr. 2025)
⚠️ Changements incompatibles :
Séparation des informations de profil de jeu et d'étape d'expansion dans la Regard approfondi:
MM_MATCH_PROFILEinclura désormais uniquement le nom du profil tel qu'il apparaît dans la configuration.Introduction de
MM_EXPANSION_STAGEqui contiendra l'étape d'expansion sous forme de chaîne (par ex. "initial", "15", "30").
Les affectations de tickets incluent désormais l'ID de groupe lorsque Regard approfondi. L'ID de groupe est également inclus en tant que Regard approfondi, comme un mappage de l'ID de groupe vers une liste des IDs des joueurs du groupe.
Les affectations de tickets incluent désormais l'ID d'équipe lorsque Regard approfondi. L'ID d'équipe est également inclus dans chaque donnée de ticket Regard approfondi.
Regard approfondi renvoie désormais
409 Conflitcode HTTP au lieu de204 Pas de contenupour indiquer que le ticket ne peut pas être supprimé car le déploiement démarre. Pour remplacer les partants, utilisez un Regard approfondi émis par le serveur après une période d'attente pré-spécifiée.Regard approfondi paramètre du corps de la requête
attributes.deployment_request_ida été déplacé versattributes.assignment.request_id.Regard approfondi le corps de la requête exige désormais les détails complets de l'affectation dans le cadre de
attributesparamètre en plus durequest_id.
🩹 Corrections de bugs :
Les valeurs résolues de la règle d'intersection sont désormais Regard approfondi 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 API et la spécification openAPI lorsque la configuration est modifiée.
Correction de plusieurs bugs lors du (re)démarrage du matchmaker provoquant un temps de démarrage prolongé ou bloquant le matchmaker.
✨ Améliorations et nouvelles fonctionnalités :
Augmentation des limites de débit et de la scalabilité de tous les points de terminaison API, pour tous les niveaux de matchmaker.
Lors de l'affectation d'un joueur à un Regard approfondi, l'ID du ticket du nouveau joueur sera ajouté en tant que tag au Déploiements.
Backfill.
Ajout de la fonctionnalité d'authentification 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. Regard approfondi Ajout de nouveau
destiné au développement et aux fins de débogage.
Permet de lister tous les tickets joueurs actuels dans une liste paginée.
Permet de lister tous les matchs actuels dans une liste paginée.
Regard approfondi1.0.0 (9 déc. 2024)
: À la demande (populaire), nous réintroduisons le backfill avec affectation automatisée des tickets, ce qui vous permet de réutiliser les sièges serveur lorsque des joueurs quittent la session.
Regard approfondiIdéal pour remplir les sièges de joueurs vides après le début d'un match, ou pour remplacer des joueurs partis pendant un match.
: Nous ajoutons la possibilité de rejoindre en groupe à la capacité déjà disponible de remplir plusieurs équipes avec des joueurs.
Outils pour développeurs et Outils pour développeurs Idéal pour rejoindre une file de matchmaking avec un groupe d'amis ou venant d'un lobby commun.
SDKs 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. Regard approfondi Correction d'un bug où le
n'était pas appliqué correctement. Regard approfondi Les tickets seront désormais automatiquement annulés après un
s'ils n'ont pas été affectés à un déploiement. Regard approfondi Vous pouvez désormais
pour améliorer le flux de votre processus de matchmaking.
Les déploiements effectués par le matchmaker sont désormais étiquetés avec les IDs de tickets.
Corrigé Regard approfondi Vous pouvez désormais modifier votre configuration pendant que le matchmaker fonctionne. Cela déclenche un rechargement rapide de votre configuration sans nécessiter un cycle complet d'arrêt/démarrage du matchmaker. Note : 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é Regard approfondi pour utiliser les bons types primitifs au lieu de tableaux.
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 des requêtes étaient effectuées depuis une application WebGL (politiques CORS).
0.2.2 (3 oct. 2024)
Correction d'un problème de validation de certificat TLS/SSL empêchant le lancement du matchmaker.
0.2.1 (30 sept. 2024)
Correction d'un bug provoquant une erreur 500 sur le point de terminaison des balises.
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 tentatives en cas d'échec d'affectation sur le serveur.
Le matchmaking basé sur les équipes est désormais la valeur par défaut pour toutes les configurations de matchmaking.
L'application et la version sont désormais des champs obligatoires dans tous les profils.
Ajout 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 pour permettre 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 refonte).
La clégame_profiledans la réponse GET ticket a été remplacée par la clé suivante :.
Mis à jour
Ce contenu vous a-t-il été utile ?