Découvrez comment fonctionne Edgegap

Découvrez comment fonctionne Edgegap

Comment ajouter un matchmaking à un jeu de combat multijoueur

Publié

Publié

Publié

Points Clés

Points Clés

Points Clés

Le matchmaker d'Edgegap est un système de matchmaking entièrement géré et infiniment personnalisable qui regroupe de manière optimale les joueurs du monde entier – et son utilisation est gratuite pendant le développement de votre jeu multijoueur de combat.

C'est également le seul système de matchmaking (à notre connaissance) avec des règles de matchmaking basées sur la latence pour fournir l'expérience multijoueur en ligne idéale pour votre jeu, quel que soit le moteur (Unity, Unreal, etc.) ou les services de jeu (EOS, UGS, PlayFab, Heroic Labs, Braincloud, etc.).

Comme notre matchmaker est basé sur des paramètres, il n'est pas nécessaire d'écrire du code. L'intégration est donc très facile et, si nécessaire, nos guides d'intégration vous accompagnent à chaque étape.

Lorsque votre jeu est en ligne, comme notre système de matchmaking est entièrement géré, vous n'avez pas besoin de gérer l'infrastructure, les bugs, les pannes, la scalabilité ou la gestion de la base de données. Nous nous occupons de tout pour vous, réduisant ainsi votre charge de travail DevOps à presque zéro.

Comment intégrer le matchmaking dans votre jeu de combat multijoueur

-> Cet article est basé sur la documentation de Matchmaking. Si vous rencontrez des problèmes ou des divergences, veuillez vous référer au guide original, car il est mis à jour plus fréquemment.

L'exemple suivant vous aidera à tester le flux de joueurs principal du matchmaking, à savoir :

  • Créer l'instance du matchmaker sur le Hosting Cluster partagé,

  • Définir les règles et les paramètres dans la Configuration de votre matchmaker,

  • Et enfin, tester le flux de joueurs et gérer les Player Tickets avec notre API.

Il y a cinq étapes pour implémenter notre matchmaker dans votre jeu :

  1. La première étape consiste à créer un compte et à utiliser notre exemple de jeu de combat. Voilà, vous avez fait (techniquement) la moitié du chemin ! Il ne vous restera plus qu'à intégrer le matchmaker dans votre jeu (voir étape 5).

  2. Maintenant, vous ne devriez jamais suivre aveuglément un exemple JSON trouvé sur Internet, et il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu. L'étape 2 (« Explore Configuration ») est notre guide de lecture qui détaille la fonction de chaque règle de matchmaking (« Explore Configuration »).

  3. L'étape 3 (« Review Instance Details ») couvre les détails de votre matchmaker personnel et spécifique afin de s'assurer qu'il est déployé et qu'il fonctionne avec la conception de votre jeu.

  4. L'étape 4, comme son nom l'indique (« 4. Test Ticket API »), consiste à tester si les demandes de matchmaking de vos joueurs, appelées tickets, sont bien reçues par le matchmaker.

  5. L'étape 5 (« Integrate Matchmaking in your Game ») explique comment intégrer le matchmaker dans le projet de votre moteur de jeu.

Si vous rencontrez des difficultés de dépannage, notre Learning Center détaillé propose des conseils de dépannage supplémentaires.

1. Configuration du niveau gratuit (Free Tier)

Inscrivez-vous pour obtenir votre compte Edgegap gratuit, puis accédez à la page du tableau de bord du Matchmaker.

De là, cliquez d'abord sur Create Matchmaker, puis saisissez :

  • Un nom pour votre matchmaker – uniquement pour votre propre référence, par exemple quickstart-dev,

  • Ensuite, téléchargez l'exemple simple suivant sous forme de configuration JSON ci-dessous pour votre jeu de combat :

{
  "version": "1.0.0",
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "casual-example": {
      "application": {
        "name": "my-game-server=>CHANGE-THIS-NAME-HERE",
        "version": "2024.01.30-16.23.00-UTC=>CHANGE-THIS-HERE "
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 1
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "10": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "30": {
            "beacons": {
              "difference": 50
            }
          },
          "60": {
            "league_rank": {
              "max_difference": 2
            }
          },
          "180": {
            "beacons": {
              "difference": 100,
              "max_latency": 500
            }
          }
        }
      }
    },
    "competitive-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "60": {
            "beacons": {
              "difference": 50
            }
          },
          "180": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    },
    "challenger-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "180": {
            "beacons": {
              "difference": 50
            }
          },
          "240": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    }
  }
}

(rappel amical pour vous assurer de modifier le name et la version de l'application afin qu'ils correspondent à vos Applications et Versions !)

Si aucune erreur de validation n'apparaît, cliquez sur Create and Start et attendez que le processus se termine. Cela lancera un nouveau cluster gratuit avec votre matchmaker Simple Exemple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la Configuration​

Règles uniques pour les jeux de combat

Spécifiquement pour les jeux de combat, vous pouvez définir plusieurs Profils de Matchmaking pour des règles et paramètres spécifiques aux modes de jeu :

  • restreindre le rang dans une certaine limite de différence entre deux joueurs pour des parties plus occasionnelles,

  • restreindre la différence de rang pour n'autoriser que des adversaires de même rang pour les parties classées,

  • permettre aux joueurs d'indiquer leurs préférences de cartes et de choisir une carte qui convient à tout le monde,

  • ajouter une UI de sélection de Hub pour restreindre les adversaires à des Balises de Ping spécifiques,

  • restreindre la latence de matchmaking à un seuil maximal pour éviter de faire correspondre des joueurs trop éloignés,

  • restreindre la latence de matchmaking à une différence maximale afin d'optimiser l'équité du ping,

  • allouer plus de CPU ou de mémoire en utilisant différentes Versions d'application lorsque plus de joueurs sont autorisés,

  • Rejoindre en groupe pour des salons pré-créés ou pour remplir des équipes sans dépasser la taille limite des équipes.

Commencez avec les conditions idéales, puis élargissez les restrictions pour garantir des parties rapides :

  • assouplissez lentement les restrictions de latence au fil du temps pour trouver plus de joueurs,

  • augmentez lentement la différence de rang autorisée pour trouver plus de joueurs,

  • augmentez le temps entre les expansions pour les rangs les plus élevés (les challengers), car il y a moins de joueurs disponibles.

Créez des tickets avec un rang plus élevé pour les matchs de promotion, afin de vous mesurer à des adversaires plus coriaces.

Définissez des profils de tricheurs distincts pour vous assurer que les tricheurs signalés ou les joueurs ayant un grand nombre de rapports de modération n'impactent pas négativement l'expérience des joueurs légitimes dans les matchs classés.

Gestion sémantique des versions

Chaque nouvelle version utilise la Gestion sémantique des versions pour communiquer clairement l'impact des changements en interprétant le format majeur.mineur.correctif :

  • les versions majeures incluent des changements majeurs et nécessitent une révision de l'intégration,

  • les versions mineures incluent des améliorations substantielles rétrocompatibles,

  • les versions de correctif incluent des corrections de bugs et des améliorations mineures.

Certains déploiements peuvent générer des erreurs. Nous tentons de résoudre ce problème en réessayant automatiquement le déploiement jusqu'à max_deployment_retry_count fois (sans confirmation du client).

Pour s'assurer que les plantages inattendus du client ou les tickets abandonnés ne s'éternisent pas et ne consomment pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, faisant passer leur statut à CANCELLED, puis définitivement supprimés après ticket_removal_period.

Le cœur de notre logique de matchmaking est configuré dans les Profils de Matchmaking. Chaque profil est une file d'attente de matchmaking complètement isolée, pointant vers des Versions d'application avec une quantité prédéfinie de ressources CPU et de mémoire (RAM) requises.

Les Règles de Matchmaking du jeu de règles initial doivent être respectées pour que les joueurs soient regroupés, chacune étant définie par trois propriétés :

  • le nom de votre choix, par exemple - match size,

  • le type de règle, également appelé opérateur, par exemple - player_count,

  • et enfin les attributs de l'opérateur, par exemple team_count ou team_size.

Règle de nombre de joueurs (Player Count)

Il s'agit d'une règle spéciale définissant le nombre de joueurs requis pour lancer une attribution :

  • team_count fait référence au nombre d'équipes, 1 équipe pouvant être utilisée pour les modes coopératifs ou chacun pour soi,

  • team_size fait référence au nombre de joueurs par équipe.

Notre exemple simple illustre un jeu coopératif à 2 joueurs.

Veuillez noter que la règle « Player Count » est requise et ne peut être définie qu'une seule fois dans vos règles de configuration initiales.

Règle de latences (Latencies)

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de trajet aller-retour (ping) par rapport à toutes les balises disponibles, Gen2 ne prendra en compte que les matchs situés dans une difference spécifique de valeurs de ping, mesurée par rapport aux Balises de Ping. Cela représente une solution « douce » pour diviser votre base de joueurs, permettant de jouer avec des régions voisines, ce qui améliore particulièrement la vitesse de matchmaking pour les régions moins peuplées. Utilisez max_latency pour éviter de jouer contre des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle beacons ci-dessus avec "difference": 50, "max_latency": 200 au départ :

  • Alice et Bob correspondront, puisque Pékin est écarté (>200) et le reste est dans les limites | A-B | < 50 :

    • Alice {Montréal : 12.3, Newark : 45.6, Dallas : 59.9, Pékin : 264.4} ; et

    • Bob {Montréal : 27.3, Newark : 32.4, Dallas : 23.1, Pékin : 252.2}.

  • Charlie et Dave ne correspondront pas, puisque | C-D | > 50 pour la balise Dallas :

    • Alice {Montréal : 5.7, Newark : 44.2, Dallas : 59.5, Pékin : 263.2} ; et

    • Bob {Montréal : 57.8, Newark : 32.0, Dallas : 24.2, Pékin : 272.3}.

Veuillez noter que les « Règles de Latences » ne peuvent être définies qu'une seule fois dans vos règles de configuration initiales.

3. Examiner les détails de l'instance​

Examinez les détails de votre nouveau matchmaker dans notre tableau de bord une fois qu'il est initialisé :

L'état (Status) indique la santé du service, il peut être ONLINE, OFFLINE ou ERROR.

  • L'identifiant (Identifier) aide l'équipe d'Edgegap à trouver rapidement votre matchmaker si vous avez besoin d'aide pour le dépannage.

  • Démarré à (Started at) peut être utile pour suivre l'heure de la dernière mise à jour.

  • La taille (Size) correspond à l'un de nos Niveaux de tarification.

  • L'URL de l'API (API URL) sera utilisée par les clients de jeu et les serveurs de jeu pour communiquer avec Gen2.

  • L'URL Swagger (Swagger URL) est une interface graphique openAPI pratique que nous fournissons pour explorer le schéma de l'API.

  • Le jeton d'authentification (Auth Token) est un jeton secret unique utilisé par les clients de jeu et le serveur de jeu pour l'authentification.

Pour tester votre nouveau matchmaker à l'aide de l'API, vous aurez besoin de l'URL Swagger, de l'URL de l'API et du jeton d'authentification.

Vous pouvez maintenant passer à l'étape suivante.

4. Tester l'API des tickets

Tout d'abord, ouvrez votre URL Swagger pour inspecter votre schéma openAPI dans l'interface utilisateur de Swagger.

Cliquez sur l'URL /...swagger.json sous le titre « Matchmaker » pour ouvrir le schéma JSON brut :

Enregistrez cette page sous forme de fichier sur votre disque (CTRL/CMD+S).

Ouvrez votre application Postman et connectez-vous à votre compte gratuit.

Importez votre fichier swagger.json de l'étape précédente :

  • gardez Postman Collection sélectionné,

  • sélectionnez View Import Settings et remplacez le paramètre Parameter generation par Example.

Confirmez l'importation. Une nouvelle collection intitulée Matchmaker apparaîtra dans la liste des collections à gauche.

Affichez plus d'actions, ouvrez l'onglet Authorization et choisissez :

  • Auth Type - API Key,

  • Key - « Authorization »

  • Value - insérez votre valeur AuthToken ici,

  • Add to - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône d'enregistrement pour enregistrer les modifications. Le point orange dans votre onglet Postman devrait disparaître.

Dans votre collection Matchmaker, sélectionnez tickets et Create a matchmaking ticket, ce qui ouvrira un nouvel onglet.

Sélectionnez l'onglet Body pour prévisualiser votre demande de ticket de joueur :

notez que player_ip est défini sur null. Cela permettra d'utiliser l'adresse IP automatiquement ajoutée à votre demande (voir Intégration de Serveur à Serveur pour des alternatives),

  • profile fait référence à vos Profils de Matchmaking,

  • les attributes comprennent les valeurs pour les règles de votre matchmaker, dans ce cas pour la règle latencies,

    • la règle player_count est la seule règle qui ne nécessite aucun attribut dans les tickets des joueurs.

REMARQUE : Assurez-vous de vous référer à la configuration d'importation de Swagger de l'échantillon. 

Cliquez sur Send et examinez la réponse à votre demande de ticket de joueur :

  • id est l'ID unique de votre ticket de matchmaking, conservez-le pour vérifier votre ticket plus tard,

  • profile confirme le choix des Profils de Matchmaking,

  • group_id est un ID de groupe unique émis pour chaque ticket, un joueur solo étant représenté comme un groupe de 1,

  • player_ip est l'adresse IP publique résolue du joueur, quelle que soit la méthode d'identification utilisée,

  • assignment est défini sur null pour indiquer que le ticket n'a pas encore été mis en correspondance ou attribué à un serveur,

  • created_at fournit des informations sur le moment où le ticket du joueur a été créé pour l'interface utilisateur du jeu,

  • status indique le statut actuel du ticket, tous les tickets commençant par SEARCHING (voir Processus de Matchmaking pour plus de détails).

Créez un deuxième ticket en cliquant à nouveau sur Send, afin que nos deux joueurs correspondent et qu'un serveur soit démarré.

Dans votre collection Matchmaker, sélectionnez {ticketId} et Read a matchmaking ticket.

Saisissez l'ID du ticket de la réponse à l'étape précédente et cliquez sur Send.

Examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est d'abord passé à MATCH_FOUND, tout en maintenant assignment défini sur null pour indiquer que les joueurs ont trouvé une correspondance et qu'un serveur est en cours d'attribution,

Cliquez à nouveau sur Send pour vérifier votre ticket, et examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est passé à HOST_ASSIGNED avec assignment contenant les détails du serveur attribué.

 Inspectez votre nouveau déploiement dans notre tableau de bord :

  • notez que chaque déploiement est étiqueté avec tous les ID de ticket et le profil pour une meilleure traçabilité.

Essayez de vous connecter depuis votre client de jeu au serveur attribué.

Une fois que vous avez vérifié que vous êtes en mesure de vous connecter à votre déploiement sans problème et que vous avez terminé les tests, arrêtez votre déploiement pour libérer de la capacité dans votre compte pour la prochaine version.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrer le Matchmaker dans votre jeu​

Le matchmaking d'Edgegap s'intègre :

  • avec le client de jeu (Game Client), pour gérer les Player Tickets,

  • avec le serveur de jeu (Game Server), pour :

    • traiter les préférences des joueurs transmises par leurs tickets,

    • éventuellement pour prendre en charge le Backfill afin d'ajouter ou de remplacer des joueurs après le démarrage.

Pour le client de jeu, nous recommandons de fournir des mises à jour du statut des tickets tout au long du Processus de Matchmaking aux joueurs via l'interface utilisateur du jeu pour une meilleure expérience joueur. Voir :

Dans le client de jeu, assurez-vous de gérer les erreurs non réessayables :

  • HTTP 404 Not Found - le ticket a été supprimé,

  • HTTP 500 Internal Server Error - interruption temporaire du service.

Dans le serveur de jeu, traitez les préférences des joueurs et le contexte initial du serveur. Aucune intégration d'API n'est requise :

  1. Lisez les variables d'environnement injectées (Gen2) pour récupérer les données de matchmaking initiales des joueurs.

  2. Lisez les variables d'environnement injectées (Versions d'application) pour obtenir les paramètres spécifiques à la version, les réglages (capacité de joueurs) et les secrets.

  3. Lisez les variables d'environnement injectées (Déploiement) pour obtenir des informations sur le déploiement, telles que l'adresse IP, l'emplacement ou autre.

Une fois que les joueurs se connectent, le serveur de jeu et les clients de jeu lancent une scène de chargement pour effectuer les étapes de synchronisation (par exemple, sélectionner et charger une carte/scène/niveau). Nous recommandons une scène 3D complète, une interface sociale de type salon ou un écran de chargement avec une barre de progression pour indiquer que l'initialisation progresse.

Une fois les clients de jeu complètement chargés, les joueurs chargent/se déplacent vers la scène de jeu principale.

En option, le serveur de jeu peut créer et gérer le Backfill et la capacité des joueurs (ajouter ou remplacer les joueurs qui partent).

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l' DELETE_URL injectée, si :

  • aucun joueur ne rejoint la partie,

  • tous les joueurs ont quitté la partie,

  • la partie se termine correctement.

Félicitations, vous avez terminé l'intégration d'Edgegap Matchmaker ! Si vous souhaitez en savoir plus, lisez tout à ce sujet dans notre Learning Center.

Comment intégrer le matchmaking dans votre jeu de combat multijoueur

-> Cet article est basé sur la documentation de Matchmaking. Si vous rencontrez des problèmes ou des divergences, veuillez vous référer au guide original, car il est mis à jour plus fréquemment.

L'exemple suivant vous aidera à tester le flux de joueurs principal du matchmaking, à savoir :

  • Créer l'instance du matchmaker sur le Hosting Cluster partagé,

  • Définir les règles et les paramètres dans la Configuration de votre matchmaker,

  • Et enfin, tester le flux de joueurs et gérer les Player Tickets avec notre API.

Il y a cinq étapes pour implémenter notre matchmaker dans votre jeu :

  1. La première étape consiste à créer un compte et à utiliser notre exemple de jeu de combat. Voilà, vous avez fait (techniquement) la moitié du chemin ! Il ne vous restera plus qu'à intégrer le matchmaker dans votre jeu (voir étape 5).

  2. Maintenant, vous ne devriez jamais suivre aveuglément un exemple JSON trouvé sur Internet, et il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu. L'étape 2 (« Explore Configuration ») est notre guide de lecture qui détaille la fonction de chaque règle de matchmaking (« Explore Configuration »).

  3. L'étape 3 (« Review Instance Details ») couvre les détails de votre matchmaker personnel et spécifique afin de s'assurer qu'il est déployé et qu'il fonctionne avec la conception de votre jeu.

  4. L'étape 4, comme son nom l'indique (« 4. Test Ticket API »), consiste à tester si les demandes de matchmaking de vos joueurs, appelées tickets, sont bien reçues par le matchmaker.

  5. L'étape 5 (« Integrate Matchmaking in your Game ») explique comment intégrer le matchmaker dans le projet de votre moteur de jeu.

Si vous rencontrez des difficultés de dépannage, notre Learning Center détaillé propose des conseils de dépannage supplémentaires.

1. Configuration du niveau gratuit (Free Tier)

Inscrivez-vous pour obtenir votre compte Edgegap gratuit, puis accédez à la page du tableau de bord du Matchmaker.

De là, cliquez d'abord sur Create Matchmaker, puis saisissez :

  • Un nom pour votre matchmaker – uniquement pour votre propre référence, par exemple quickstart-dev,

  • Ensuite, téléchargez l'exemple simple suivant sous forme de configuration JSON ci-dessous pour votre jeu de combat :

{
  "version": "1.0.0",
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "casual-example": {
      "application": {
        "name": "my-game-server=>CHANGE-THIS-NAME-HERE",
        "version": "2024.01.30-16.23.00-UTC=>CHANGE-THIS-HERE "
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 1
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "10": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "30": {
            "beacons": {
              "difference": 50
            }
          },
          "60": {
            "league_rank": {
              "max_difference": 2
            }
          },
          "180": {
            "beacons": {
              "difference": 100,
              "max_latency": 500
            }
          }
        }
      }
    },
    "competitive-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "60": {
            "beacons": {
              "difference": 50
            }
          },
          "180": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    },
    "challenger-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "180": {
            "beacons": {
              "difference": 50
            }
          },
          "240": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    }
  }
}

(rappel amical pour vous assurer de modifier le name et la version de l'application afin qu'ils correspondent à vos Applications et Versions !)

Si aucune erreur de validation n'apparaît, cliquez sur Create and Start et attendez que le processus se termine. Cela lancera un nouveau cluster gratuit avec votre matchmaker Simple Exemple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la Configuration​

Règles uniques pour les jeux de combat

Spécifiquement pour les jeux de combat, vous pouvez définir plusieurs Profils de Matchmaking pour des règles et paramètres spécifiques aux modes de jeu :

  • restreindre le rang dans une certaine limite de différence entre deux joueurs pour des parties plus occasionnelles,

  • restreindre la différence de rang pour n'autoriser que des adversaires de même rang pour les parties classées,

  • permettre aux joueurs d'indiquer leurs préférences de cartes et de choisir une carte qui convient à tout le monde,

  • ajouter une UI de sélection de Hub pour restreindre les adversaires à des Balises de Ping spécifiques,

  • restreindre la latence de matchmaking à un seuil maximal pour éviter de faire correspondre des joueurs trop éloignés,

  • restreindre la latence de matchmaking à une différence maximale afin d'optimiser l'équité du ping,

  • allouer plus de CPU ou de mémoire en utilisant différentes Versions d'application lorsque plus de joueurs sont autorisés,

  • Rejoindre en groupe pour des salons pré-créés ou pour remplir des équipes sans dépasser la taille limite des équipes.

Commencez avec les conditions idéales, puis élargissez les restrictions pour garantir des parties rapides :

  • assouplissez lentement les restrictions de latence au fil du temps pour trouver plus de joueurs,

  • augmentez lentement la différence de rang autorisée pour trouver plus de joueurs,

  • augmentez le temps entre les expansions pour les rangs les plus élevés (les challengers), car il y a moins de joueurs disponibles.

Créez des tickets avec un rang plus élevé pour les matchs de promotion, afin de vous mesurer à des adversaires plus coriaces.

Définissez des profils de tricheurs distincts pour vous assurer que les tricheurs signalés ou les joueurs ayant un grand nombre de rapports de modération n'impactent pas négativement l'expérience des joueurs légitimes dans les matchs classés.

Gestion sémantique des versions

Chaque nouvelle version utilise la Gestion sémantique des versions pour communiquer clairement l'impact des changements en interprétant le format majeur.mineur.correctif :

  • les versions majeures incluent des changements majeurs et nécessitent une révision de l'intégration,

  • les versions mineures incluent des améliorations substantielles rétrocompatibles,

  • les versions de correctif incluent des corrections de bugs et des améliorations mineures.

Certains déploiements peuvent générer des erreurs. Nous tentons de résoudre ce problème en réessayant automatiquement le déploiement jusqu'à max_deployment_retry_count fois (sans confirmation du client).

Pour s'assurer que les plantages inattendus du client ou les tickets abandonnés ne s'éternisent pas et ne consomment pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, faisant passer leur statut à CANCELLED, puis définitivement supprimés après ticket_removal_period.

Le cœur de notre logique de matchmaking est configuré dans les Profils de Matchmaking. Chaque profil est une file d'attente de matchmaking complètement isolée, pointant vers des Versions d'application avec une quantité prédéfinie de ressources CPU et de mémoire (RAM) requises.

Les Règles de Matchmaking du jeu de règles initial doivent être respectées pour que les joueurs soient regroupés, chacune étant définie par trois propriétés :

  • le nom de votre choix, par exemple - match size,

  • le type de règle, également appelé opérateur, par exemple - player_count,

  • et enfin les attributs de l'opérateur, par exemple team_count ou team_size.

Règle de nombre de joueurs (Player Count)

Il s'agit d'une règle spéciale définissant le nombre de joueurs requis pour lancer une attribution :

  • team_count fait référence au nombre d'équipes, 1 équipe pouvant être utilisée pour les modes coopératifs ou chacun pour soi,

  • team_size fait référence au nombre de joueurs par équipe.

Notre exemple simple illustre un jeu coopératif à 2 joueurs.

Veuillez noter que la règle « Player Count » est requise et ne peut être définie qu'une seule fois dans vos règles de configuration initiales.

Règle de latences (Latencies)

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de trajet aller-retour (ping) par rapport à toutes les balises disponibles, Gen2 ne prendra en compte que les matchs situés dans une difference spécifique de valeurs de ping, mesurée par rapport aux Balises de Ping. Cela représente une solution « douce » pour diviser votre base de joueurs, permettant de jouer avec des régions voisines, ce qui améliore particulièrement la vitesse de matchmaking pour les régions moins peuplées. Utilisez max_latency pour éviter de jouer contre des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle beacons ci-dessus avec "difference": 50, "max_latency": 200 au départ :

  • Alice et Bob correspondront, puisque Pékin est écarté (>200) et le reste est dans les limites | A-B | < 50 :

    • Alice {Montréal : 12.3, Newark : 45.6, Dallas : 59.9, Pékin : 264.4} ; et

    • Bob {Montréal : 27.3, Newark : 32.4, Dallas : 23.1, Pékin : 252.2}.

  • Charlie et Dave ne correspondront pas, puisque | C-D | > 50 pour la balise Dallas :

    • Alice {Montréal : 5.7, Newark : 44.2, Dallas : 59.5, Pékin : 263.2} ; et

    • Bob {Montréal : 57.8, Newark : 32.0, Dallas : 24.2, Pékin : 272.3}.

Veuillez noter que les « Règles de Latences » ne peuvent être définies qu'une seule fois dans vos règles de configuration initiales.

3. Examiner les détails de l'instance​

Examinez les détails de votre nouveau matchmaker dans notre tableau de bord une fois qu'il est initialisé :

L'état (Status) indique la santé du service, il peut être ONLINE, OFFLINE ou ERROR.

  • L'identifiant (Identifier) aide l'équipe d'Edgegap à trouver rapidement votre matchmaker si vous avez besoin d'aide pour le dépannage.

  • Démarré à (Started at) peut être utile pour suivre l'heure de la dernière mise à jour.

  • La taille (Size) correspond à l'un de nos Niveaux de tarification.

  • L'URL de l'API (API URL) sera utilisée par les clients de jeu et les serveurs de jeu pour communiquer avec Gen2.

  • L'URL Swagger (Swagger URL) est une interface graphique openAPI pratique que nous fournissons pour explorer le schéma de l'API.

  • Le jeton d'authentification (Auth Token) est un jeton secret unique utilisé par les clients de jeu et le serveur de jeu pour l'authentification.

Pour tester votre nouveau matchmaker à l'aide de l'API, vous aurez besoin de l'URL Swagger, de l'URL de l'API et du jeton d'authentification.

Vous pouvez maintenant passer à l'étape suivante.

4. Tester l'API des tickets

Tout d'abord, ouvrez votre URL Swagger pour inspecter votre schéma openAPI dans l'interface utilisateur de Swagger.

Cliquez sur l'URL /...swagger.json sous le titre « Matchmaker » pour ouvrir le schéma JSON brut :

Enregistrez cette page sous forme de fichier sur votre disque (CTRL/CMD+S).

Ouvrez votre application Postman et connectez-vous à votre compte gratuit.

Importez votre fichier swagger.json de l'étape précédente :

  • gardez Postman Collection sélectionné,

  • sélectionnez View Import Settings et remplacez le paramètre Parameter generation par Example.

Confirmez l'importation. Une nouvelle collection intitulée Matchmaker apparaîtra dans la liste des collections à gauche.

Affichez plus d'actions, ouvrez l'onglet Authorization et choisissez :

  • Auth Type - API Key,

  • Key - « Authorization »

  • Value - insérez votre valeur AuthToken ici,

  • Add to - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône d'enregistrement pour enregistrer les modifications. Le point orange dans votre onglet Postman devrait disparaître.

Dans votre collection Matchmaker, sélectionnez tickets et Create a matchmaking ticket, ce qui ouvrira un nouvel onglet.

Sélectionnez l'onglet Body pour prévisualiser votre demande de ticket de joueur :

notez que player_ip est défini sur null. Cela permettra d'utiliser l'adresse IP automatiquement ajoutée à votre demande (voir Intégration de Serveur à Serveur pour des alternatives),

  • profile fait référence à vos Profils de Matchmaking,

  • les attributes comprennent les valeurs pour les règles de votre matchmaker, dans ce cas pour la règle latencies,

    • la règle player_count est la seule règle qui ne nécessite aucun attribut dans les tickets des joueurs.

REMARQUE : Assurez-vous de vous référer à la configuration d'importation de Swagger de l'échantillon. 

Cliquez sur Send et examinez la réponse à votre demande de ticket de joueur :

  • id est l'ID unique de votre ticket de matchmaking, conservez-le pour vérifier votre ticket plus tard,

  • profile confirme le choix des Profils de Matchmaking,

  • group_id est un ID de groupe unique émis pour chaque ticket, un joueur solo étant représenté comme un groupe de 1,

  • player_ip est l'adresse IP publique résolue du joueur, quelle que soit la méthode d'identification utilisée,

  • assignment est défini sur null pour indiquer que le ticket n'a pas encore été mis en correspondance ou attribué à un serveur,

  • created_at fournit des informations sur le moment où le ticket du joueur a été créé pour l'interface utilisateur du jeu,

  • status indique le statut actuel du ticket, tous les tickets commençant par SEARCHING (voir Processus de Matchmaking pour plus de détails).

Créez un deuxième ticket en cliquant à nouveau sur Send, afin que nos deux joueurs correspondent et qu'un serveur soit démarré.

Dans votre collection Matchmaker, sélectionnez {ticketId} et Read a matchmaking ticket.

Saisissez l'ID du ticket de la réponse à l'étape précédente et cliquez sur Send.

Examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est d'abord passé à MATCH_FOUND, tout en maintenant assignment défini sur null pour indiquer que les joueurs ont trouvé une correspondance et qu'un serveur est en cours d'attribution,

Cliquez à nouveau sur Send pour vérifier votre ticket, et examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est passé à HOST_ASSIGNED avec assignment contenant les détails du serveur attribué.

 Inspectez votre nouveau déploiement dans notre tableau de bord :

  • notez que chaque déploiement est étiqueté avec tous les ID de ticket et le profil pour une meilleure traçabilité.

Essayez de vous connecter depuis votre client de jeu au serveur attribué.

Une fois que vous avez vérifié que vous êtes en mesure de vous connecter à votre déploiement sans problème et que vous avez terminé les tests, arrêtez votre déploiement pour libérer de la capacité dans votre compte pour la prochaine version.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrer le Matchmaker dans votre jeu​

Le matchmaking d'Edgegap s'intègre :

  • avec le client de jeu (Game Client), pour gérer les Player Tickets,

  • avec le serveur de jeu (Game Server), pour :

    • traiter les préférences des joueurs transmises par leurs tickets,

    • éventuellement pour prendre en charge le Backfill afin d'ajouter ou de remplacer des joueurs après le démarrage.

Pour le client de jeu, nous recommandons de fournir des mises à jour du statut des tickets tout au long du Processus de Matchmaking aux joueurs via l'interface utilisateur du jeu pour une meilleure expérience joueur. Voir :

Dans le client de jeu, assurez-vous de gérer les erreurs non réessayables :

  • HTTP 404 Not Found - le ticket a été supprimé,

  • HTTP 500 Internal Server Error - interruption temporaire du service.

Dans le serveur de jeu, traitez les préférences des joueurs et le contexte initial du serveur. Aucune intégration d'API n'est requise :

  1. Lisez les variables d'environnement injectées (Gen2) pour récupérer les données de matchmaking initiales des joueurs.

  2. Lisez les variables d'environnement injectées (Versions d'application) pour obtenir les paramètres spécifiques à la version, les réglages (capacité de joueurs) et les secrets.

  3. Lisez les variables d'environnement injectées (Déploiement) pour obtenir des informations sur le déploiement, telles que l'adresse IP, l'emplacement ou autre.

Une fois que les joueurs se connectent, le serveur de jeu et les clients de jeu lancent une scène de chargement pour effectuer les étapes de synchronisation (par exemple, sélectionner et charger une carte/scène/niveau). Nous recommandons une scène 3D complète, une interface sociale de type salon ou un écran de chargement avec une barre de progression pour indiquer que l'initialisation progresse.

Une fois les clients de jeu complètement chargés, les joueurs chargent/se déplacent vers la scène de jeu principale.

En option, le serveur de jeu peut créer et gérer le Backfill et la capacité des joueurs (ajouter ou remplacer les joueurs qui partent).

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l' DELETE_URL injectée, si :

  • aucun joueur ne rejoint la partie,

  • tous les joueurs ont quitté la partie,

  • la partie se termine correctement.

Félicitations, vous avez terminé l'intégration d'Edgegap Matchmaker ! Si vous souhaitez en savoir plus, lisez tout à ce sujet dans notre Learning Center.

Comment intégrer le matchmaking dans votre jeu de combat multijoueur

-> Cet article est basé sur la documentation de Matchmaking. Si vous rencontrez des problèmes ou des divergences, veuillez vous référer au guide original, car il est mis à jour plus fréquemment.

L'exemple suivant vous aidera à tester le flux de joueurs principal du matchmaking, à savoir :

  • Créer l'instance du matchmaker sur le Hosting Cluster partagé,

  • Définir les règles et les paramètres dans la Configuration de votre matchmaker,

  • Et enfin, tester le flux de joueurs et gérer les Player Tickets avec notre API.

Il y a cinq étapes pour implémenter notre matchmaker dans votre jeu :

  1. La première étape consiste à créer un compte et à utiliser notre exemple de jeu de combat. Voilà, vous avez fait (techniquement) la moitié du chemin ! Il ne vous restera plus qu'à intégrer le matchmaker dans votre jeu (voir étape 5).

  2. Maintenant, vous ne devriez jamais suivre aveuglément un exemple JSON trouvé sur Internet, et il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu. L'étape 2 (« Explore Configuration ») est notre guide de lecture qui détaille la fonction de chaque règle de matchmaking (« Explore Configuration »).

  3. L'étape 3 (« Review Instance Details ») couvre les détails de votre matchmaker personnel et spécifique afin de s'assurer qu'il est déployé et qu'il fonctionne avec la conception de votre jeu.

  4. L'étape 4, comme son nom l'indique (« 4. Test Ticket API »), consiste à tester si les demandes de matchmaking de vos joueurs, appelées tickets, sont bien reçues par le matchmaker.

  5. L'étape 5 (« Integrate Matchmaking in your Game ») explique comment intégrer le matchmaker dans le projet de votre moteur de jeu.

Si vous rencontrez des difficultés de dépannage, notre Learning Center détaillé propose des conseils de dépannage supplémentaires.

1. Configuration du niveau gratuit (Free Tier)

Inscrivez-vous pour obtenir votre compte Edgegap gratuit, puis accédez à la page du tableau de bord du Matchmaker.

De là, cliquez d'abord sur Create Matchmaker, puis saisissez :

  • Un nom pour votre matchmaker – uniquement pour votre propre référence, par exemple quickstart-dev,

  • Ensuite, téléchargez l'exemple simple suivant sous forme de configuration JSON ci-dessous pour votre jeu de combat :

{
  "version": "1.0.0",
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "casual-example": {
      "application": {
        "name": "my-game-server=>CHANGE-THIS-NAME-HERE",
        "version": "2024.01.30-16.23.00-UTC=>CHANGE-THIS-HERE "
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 1
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "10": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "30": {
            "beacons": {
              "difference": 50
            }
          },
          "60": {
            "league_rank": {
              "max_difference": 2
            }
          },
          "180": {
            "beacons": {
              "difference": 100,
              "max_latency": 500
            }
          }
        }
      }
    },
    "competitive-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "60": {
            "beacons": {
              "difference": 50
            }
          },
          "180": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    },
    "challenger-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "180": {
            "beacons": {
              "difference": 50
            }
          },
          "240": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    }
  }
}

(rappel amical pour vous assurer de modifier le name et la version de l'application afin qu'ils correspondent à vos Applications et Versions !)

Si aucune erreur de validation n'apparaît, cliquez sur Create and Start et attendez que le processus se termine. Cela lancera un nouveau cluster gratuit avec votre matchmaker Simple Exemple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la Configuration​

Règles uniques pour les jeux de combat

Spécifiquement pour les jeux de combat, vous pouvez définir plusieurs Profils de Matchmaking pour des règles et paramètres spécifiques aux modes de jeu :

  • restreindre le rang dans une certaine limite de différence entre deux joueurs pour des parties plus occasionnelles,

  • restreindre la différence de rang pour n'autoriser que des adversaires de même rang pour les parties classées,

  • permettre aux joueurs d'indiquer leurs préférences de cartes et de choisir une carte qui convient à tout le monde,

  • ajouter une UI de sélection de Hub pour restreindre les adversaires à des Balises de Ping spécifiques,

  • restreindre la latence de matchmaking à un seuil maximal pour éviter de faire correspondre des joueurs trop éloignés,

  • restreindre la latence de matchmaking à une différence maximale afin d'optimiser l'équité du ping,

  • allouer plus de CPU ou de mémoire en utilisant différentes Versions d'application lorsque plus de joueurs sont autorisés,

  • Rejoindre en groupe pour des salons pré-créés ou pour remplir des équipes sans dépasser la taille limite des équipes.

Commencez avec les conditions idéales, puis élargissez les restrictions pour garantir des parties rapides :

  • assouplissez lentement les restrictions de latence au fil du temps pour trouver plus de joueurs,

  • augmentez lentement la différence de rang autorisée pour trouver plus de joueurs,

  • augmentez le temps entre les expansions pour les rangs les plus élevés (les challengers), car il y a moins de joueurs disponibles.

Créez des tickets avec un rang plus élevé pour les matchs de promotion, afin de vous mesurer à des adversaires plus coriaces.

Définissez des profils de tricheurs distincts pour vous assurer que les tricheurs signalés ou les joueurs ayant un grand nombre de rapports de modération n'impactent pas négativement l'expérience des joueurs légitimes dans les matchs classés.

Gestion sémantique des versions

Chaque nouvelle version utilise la Gestion sémantique des versions pour communiquer clairement l'impact des changements en interprétant le format majeur.mineur.correctif :

  • les versions majeures incluent des changements majeurs et nécessitent une révision de l'intégration,

  • les versions mineures incluent des améliorations substantielles rétrocompatibles,

  • les versions de correctif incluent des corrections de bugs et des améliorations mineures.

Certains déploiements peuvent générer des erreurs. Nous tentons de résoudre ce problème en réessayant automatiquement le déploiement jusqu'à max_deployment_retry_count fois (sans confirmation du client).

Pour s'assurer que les plantages inattendus du client ou les tickets abandonnés ne s'éternisent pas et ne consomment pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, faisant passer leur statut à CANCELLED, puis définitivement supprimés après ticket_removal_period.

Le cœur de notre logique de matchmaking est configuré dans les Profils de Matchmaking. Chaque profil est une file d'attente de matchmaking complètement isolée, pointant vers des Versions d'application avec une quantité prédéfinie de ressources CPU et de mémoire (RAM) requises.

Les Règles de Matchmaking du jeu de règles initial doivent être respectées pour que les joueurs soient regroupés, chacune étant définie par trois propriétés :

  • le nom de votre choix, par exemple - match size,

  • le type de règle, également appelé opérateur, par exemple - player_count,

  • et enfin les attributs de l'opérateur, par exemple team_count ou team_size.

Règle de nombre de joueurs (Player Count)

Il s'agit d'une règle spéciale définissant le nombre de joueurs requis pour lancer une attribution :

  • team_count fait référence au nombre d'équipes, 1 équipe pouvant être utilisée pour les modes coopératifs ou chacun pour soi,

  • team_size fait référence au nombre de joueurs par équipe.

Notre exemple simple illustre un jeu coopératif à 2 joueurs.

Veuillez noter que la règle « Player Count » est requise et ne peut être définie qu'une seule fois dans vos règles de configuration initiales.

Règle de latences (Latencies)

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de trajet aller-retour (ping) par rapport à toutes les balises disponibles, Gen2 ne prendra en compte que les matchs situés dans une difference spécifique de valeurs de ping, mesurée par rapport aux Balises de Ping. Cela représente une solution « douce » pour diviser votre base de joueurs, permettant de jouer avec des régions voisines, ce qui améliore particulièrement la vitesse de matchmaking pour les régions moins peuplées. Utilisez max_latency pour éviter de jouer contre des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle beacons ci-dessus avec "difference": 50, "max_latency": 200 au départ :

  • Alice et Bob correspondront, puisque Pékin est écarté (>200) et le reste est dans les limites | A-B | < 50 :

    • Alice {Montréal : 12.3, Newark : 45.6, Dallas : 59.9, Pékin : 264.4} ; et

    • Bob {Montréal : 27.3, Newark : 32.4, Dallas : 23.1, Pékin : 252.2}.

  • Charlie et Dave ne correspondront pas, puisque | C-D | > 50 pour la balise Dallas :

    • Alice {Montréal : 5.7, Newark : 44.2, Dallas : 59.5, Pékin : 263.2} ; et

    • Bob {Montréal : 57.8, Newark : 32.0, Dallas : 24.2, Pékin : 272.3}.

Veuillez noter que les « Règles de Latences » ne peuvent être définies qu'une seule fois dans vos règles de configuration initiales.

3. Examiner les détails de l'instance​

Examinez les détails de votre nouveau matchmaker dans notre tableau de bord une fois qu'il est initialisé :

L'état (Status) indique la santé du service, il peut être ONLINE, OFFLINE ou ERROR.

  • L'identifiant (Identifier) aide l'équipe d'Edgegap à trouver rapidement votre matchmaker si vous avez besoin d'aide pour le dépannage.

  • Démarré à (Started at) peut être utile pour suivre l'heure de la dernière mise à jour.

  • La taille (Size) correspond à l'un de nos Niveaux de tarification.

  • L'URL de l'API (API URL) sera utilisée par les clients de jeu et les serveurs de jeu pour communiquer avec Gen2.

  • L'URL Swagger (Swagger URL) est une interface graphique openAPI pratique que nous fournissons pour explorer le schéma de l'API.

  • Le jeton d'authentification (Auth Token) est un jeton secret unique utilisé par les clients de jeu et le serveur de jeu pour l'authentification.

Pour tester votre nouveau matchmaker à l'aide de l'API, vous aurez besoin de l'URL Swagger, de l'URL de l'API et du jeton d'authentification.

Vous pouvez maintenant passer à l'étape suivante.

4. Tester l'API des tickets

Tout d'abord, ouvrez votre URL Swagger pour inspecter votre schéma openAPI dans l'interface utilisateur de Swagger.

Cliquez sur l'URL /...swagger.json sous le titre « Matchmaker » pour ouvrir le schéma JSON brut :

Enregistrez cette page sous forme de fichier sur votre disque (CTRL/CMD+S).

Ouvrez votre application Postman et connectez-vous à votre compte gratuit.

Importez votre fichier swagger.json de l'étape précédente :

  • gardez Postman Collection sélectionné,

  • sélectionnez View Import Settings et remplacez le paramètre Parameter generation par Example.

Confirmez l'importation. Une nouvelle collection intitulée Matchmaker apparaîtra dans la liste des collections à gauche.

Affichez plus d'actions, ouvrez l'onglet Authorization et choisissez :

  • Auth Type - API Key,

  • Key - « Authorization »

  • Value - insérez votre valeur AuthToken ici,

  • Add to - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône d'enregistrement pour enregistrer les modifications. Le point orange dans votre onglet Postman devrait disparaître.

Dans votre collection Matchmaker, sélectionnez tickets et Create a matchmaking ticket, ce qui ouvrira un nouvel onglet.

Sélectionnez l'onglet Body pour prévisualiser votre demande de ticket de joueur :

notez que player_ip est défini sur null. Cela permettra d'utiliser l'adresse IP automatiquement ajoutée à votre demande (voir Intégration de Serveur à Serveur pour des alternatives),

  • profile fait référence à vos Profils de Matchmaking,

  • les attributes comprennent les valeurs pour les règles de votre matchmaker, dans ce cas pour la règle latencies,

    • la règle player_count est la seule règle qui ne nécessite aucun attribut dans les tickets des joueurs.

REMARQUE : Assurez-vous de vous référer à la configuration d'importation de Swagger de l'échantillon. 

Cliquez sur Send et examinez la réponse à votre demande de ticket de joueur :

  • id est l'ID unique de votre ticket de matchmaking, conservez-le pour vérifier votre ticket plus tard,

  • profile confirme le choix des Profils de Matchmaking,

  • group_id est un ID de groupe unique émis pour chaque ticket, un joueur solo étant représenté comme un groupe de 1,

  • player_ip est l'adresse IP publique résolue du joueur, quelle que soit la méthode d'identification utilisée,

  • assignment est défini sur null pour indiquer que le ticket n'a pas encore été mis en correspondance ou attribué à un serveur,

  • created_at fournit des informations sur le moment où le ticket du joueur a été créé pour l'interface utilisateur du jeu,

  • status indique le statut actuel du ticket, tous les tickets commençant par SEARCHING (voir Processus de Matchmaking pour plus de détails).

Créez un deuxième ticket en cliquant à nouveau sur Send, afin que nos deux joueurs correspondent et qu'un serveur soit démarré.

Dans votre collection Matchmaker, sélectionnez {ticketId} et Read a matchmaking ticket.

Saisissez l'ID du ticket de la réponse à l'étape précédente et cliquez sur Send.

Examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est d'abord passé à MATCH_FOUND, tout en maintenant assignment défini sur null pour indiquer que les joueurs ont trouvé une correspondance et qu'un serveur est en cours d'attribution,

Cliquez à nouveau sur Send pour vérifier votre ticket, et examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est passé à HOST_ASSIGNED avec assignment contenant les détails du serveur attribué.

 Inspectez votre nouveau déploiement dans notre tableau de bord :

  • notez que chaque déploiement est étiqueté avec tous les ID de ticket et le profil pour une meilleure traçabilité.

Essayez de vous connecter depuis votre client de jeu au serveur attribué.

Une fois que vous avez vérifié que vous êtes en mesure de vous connecter à votre déploiement sans problème et que vous avez terminé les tests, arrêtez votre déploiement pour libérer de la capacité dans votre compte pour la prochaine version.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrer le Matchmaker dans votre jeu​

Le matchmaking d'Edgegap s'intègre :

  • avec le client de jeu (Game Client), pour gérer les Player Tickets,

  • avec le serveur de jeu (Game Server), pour :

    • traiter les préférences des joueurs transmises par leurs tickets,

    • éventuellement pour prendre en charge le Backfill afin d'ajouter ou de remplacer des joueurs après le démarrage.

Pour le client de jeu, nous recommandons de fournir des mises à jour du statut des tickets tout au long du Processus de Matchmaking aux joueurs via l'interface utilisateur du jeu pour une meilleure expérience joueur. Voir :

Dans le client de jeu, assurez-vous de gérer les erreurs non réessayables :

  • HTTP 404 Not Found - le ticket a été supprimé,

  • HTTP 500 Internal Server Error - interruption temporaire du service.

Dans le serveur de jeu, traitez les préférences des joueurs et le contexte initial du serveur. Aucune intégration d'API n'est requise :

  1. Lisez les variables d'environnement injectées (Gen2) pour récupérer les données de matchmaking initiales des joueurs.

  2. Lisez les variables d'environnement injectées (Versions d'application) pour obtenir les paramètres spécifiques à la version, les réglages (capacité de joueurs) et les secrets.

  3. Lisez les variables d'environnement injectées (Déploiement) pour obtenir des informations sur le déploiement, telles que l'adresse IP, l'emplacement ou autre.

Une fois que les joueurs se connectent, le serveur de jeu et les clients de jeu lancent une scène de chargement pour effectuer les étapes de synchronisation (par exemple, sélectionner et charger une carte/scène/niveau). Nous recommandons une scène 3D complète, une interface sociale de type salon ou un écran de chargement avec une barre de progression pour indiquer que l'initialisation progresse.

Une fois les clients de jeu complètement chargés, les joueurs chargent/se déplacent vers la scène de jeu principale.

En option, le serveur de jeu peut créer et gérer le Backfill et la capacité des joueurs (ajouter ou remplacer les joueurs qui partent).

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l' DELETE_URL injectée, si :

  • aucun joueur ne rejoint la partie,

  • tous les joueurs ont quitté la partie,

  • la partie se termine correctement.

Félicitations, vous avez terminé l'intégration d'Edgegap Matchmaker ! Si vous souhaitez en savoir plus, lisez tout à ce sujet dans notre Learning Center.

Comment intégrer le matchmaking dans votre jeu de combat multijoueur

-> Cet article est basé sur la documentation de Matchmaking. Si vous rencontrez des problèmes ou des divergences, veuillez vous référer au guide original, car il est mis à jour plus fréquemment.

L'exemple suivant vous aidera à tester le flux de joueurs principal du matchmaking, à savoir :

  • Créer l'instance du matchmaker sur le Hosting Cluster partagé,

  • Définir les règles et les paramètres dans la Configuration de votre matchmaker,

  • Et enfin, tester le flux de joueurs et gérer les Player Tickets avec notre API.

Il y a cinq étapes pour implémenter notre matchmaker dans votre jeu :

  1. La première étape consiste à créer un compte et à utiliser notre exemple de jeu de combat. Voilà, vous avez fait (techniquement) la moitié du chemin ! Il ne vous restera plus qu'à intégrer le matchmaker dans votre jeu (voir étape 5).

  2. Maintenant, vous ne devriez jamais suivre aveuglément un exemple JSON trouvé sur Internet, et il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu. L'étape 2 (« Explore Configuration ») est notre guide de lecture qui détaille la fonction de chaque règle de matchmaking (« Explore Configuration »).

  3. L'étape 3 (« Review Instance Details ») couvre les détails de votre matchmaker personnel et spécifique afin de s'assurer qu'il est déployé et qu'il fonctionne avec la conception de votre jeu.

  4. L'étape 4, comme son nom l'indique (« 4. Test Ticket API »), consiste à tester si les demandes de matchmaking de vos joueurs, appelées tickets, sont bien reçues par le matchmaker.

  5. L'étape 5 (« Integrate Matchmaking in your Game ») explique comment intégrer le matchmaker dans le projet de votre moteur de jeu.

Si vous rencontrez des difficultés de dépannage, notre Learning Center détaillé propose des conseils de dépannage supplémentaires.

1. Configuration du niveau gratuit (Free Tier)

Inscrivez-vous pour obtenir votre compte Edgegap gratuit, puis accédez à la page du tableau de bord du Matchmaker.

De là, cliquez d'abord sur Create Matchmaker, puis saisissez :

  • Un nom pour votre matchmaker – uniquement pour votre propre référence, par exemple quickstart-dev,

  • Ensuite, téléchargez l'exemple simple suivant sous forme de configuration JSON ci-dessous pour votre jeu de combat :

{
  "version": "1.0.0",
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "casual-example": {
      "application": {
        "name": "my-game-server=>CHANGE-THIS-NAME-HERE",
        "version": "2024.01.30-16.23.00-UTC=>CHANGE-THIS-HERE "
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 1
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "10": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "30": {
            "beacons": {
              "difference": 50
            }
          },
          "60": {
            "league_rank": {
              "max_difference": 2
            }
          },
          "180": {
            "beacons": {
              "difference": 100,
              "max_latency": 500
            }
          }
        }
      }
    },
    "competitive-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "60": {
            "beacons": {
              "difference": 50
            }
          },
          "180": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    },
    "challenger-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 2,
              "team_size": 5
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 25,
              "max_latency": 100
            }
          },
          "league_rank": {
            "type": "number_difference",
            "attributes": {
              "max_difference": 0
            }
          },
          "selected_maps": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          },
          "selected_beacons": {
            "type": "intersection",
            "attributes": {
              "overlap": 1
            }
          }
        },
        "expansions": {
          "30": {
            "beacons": {
              "difference": 40,
              "max_latency": 150
            }
          },
          "180": {
            "beacons": {
              "difference": 50
            }
          },
          "240": {
            "beacons": {
              "max_latency": 250
            }
          }
        }
      }
    }
  }
}

(rappel amical pour vous assurer de modifier le name et la version de l'application afin qu'ils correspondent à vos Applications et Versions !)

Si aucune erreur de validation n'apparaît, cliquez sur Create and Start et attendez que le processus se termine. Cela lancera un nouveau cluster gratuit avec votre matchmaker Simple Exemple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la Configuration​

Règles uniques pour les jeux de combat

Spécifiquement pour les jeux de combat, vous pouvez définir plusieurs Profils de Matchmaking pour des règles et paramètres spécifiques aux modes de jeu :

  • restreindre le rang dans une certaine limite de différence entre deux joueurs pour des parties plus occasionnelles,

  • restreindre la différence de rang pour n'autoriser que des adversaires de même rang pour les parties classées,

  • permettre aux joueurs d'indiquer leurs préférences de cartes et de choisir une carte qui convient à tout le monde,

  • ajouter une UI de sélection de Hub pour restreindre les adversaires à des Balises de Ping spécifiques,

  • restreindre la latence de matchmaking à un seuil maximal pour éviter de faire correspondre des joueurs trop éloignés,

  • restreindre la latence de matchmaking à une différence maximale afin d'optimiser l'équité du ping,

  • allouer plus de CPU ou de mémoire en utilisant différentes Versions d'application lorsque plus de joueurs sont autorisés,

  • Rejoindre en groupe pour des salons pré-créés ou pour remplir des équipes sans dépasser la taille limite des équipes.

Commencez avec les conditions idéales, puis élargissez les restrictions pour garantir des parties rapides :

  • assouplissez lentement les restrictions de latence au fil du temps pour trouver plus de joueurs,

  • augmentez lentement la différence de rang autorisée pour trouver plus de joueurs,

  • augmentez le temps entre les expansions pour les rangs les plus élevés (les challengers), car il y a moins de joueurs disponibles.

Créez des tickets avec un rang plus élevé pour les matchs de promotion, afin de vous mesurer à des adversaires plus coriaces.

Définissez des profils de tricheurs distincts pour vous assurer que les tricheurs signalés ou les joueurs ayant un grand nombre de rapports de modération n'impactent pas négativement l'expérience des joueurs légitimes dans les matchs classés.

Gestion sémantique des versions

Chaque nouvelle version utilise la Gestion sémantique des versions pour communiquer clairement l'impact des changements en interprétant le format majeur.mineur.correctif :

  • les versions majeures incluent des changements majeurs et nécessitent une révision de l'intégration,

  • les versions mineures incluent des améliorations substantielles rétrocompatibles,

  • les versions de correctif incluent des corrections de bugs et des améliorations mineures.

Certains déploiements peuvent générer des erreurs. Nous tentons de résoudre ce problème en réessayant automatiquement le déploiement jusqu'à max_deployment_retry_count fois (sans confirmation du client).

Pour s'assurer que les plantages inattendus du client ou les tickets abandonnés ne s'éternisent pas et ne consomment pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, faisant passer leur statut à CANCELLED, puis définitivement supprimés après ticket_removal_period.

Le cœur de notre logique de matchmaking est configuré dans les Profils de Matchmaking. Chaque profil est une file d'attente de matchmaking complètement isolée, pointant vers des Versions d'application avec une quantité prédéfinie de ressources CPU et de mémoire (RAM) requises.

Les Règles de Matchmaking du jeu de règles initial doivent être respectées pour que les joueurs soient regroupés, chacune étant définie par trois propriétés :

  • le nom de votre choix, par exemple - match size,

  • le type de règle, également appelé opérateur, par exemple - player_count,

  • et enfin les attributs de l'opérateur, par exemple team_count ou team_size.

Règle de nombre de joueurs (Player Count)

Il s'agit d'une règle spéciale définissant le nombre de joueurs requis pour lancer une attribution :

  • team_count fait référence au nombre d'équipes, 1 équipe pouvant être utilisée pour les modes coopératifs ou chacun pour soi,

  • team_size fait référence au nombre de joueurs par équipe.

Notre exemple simple illustre un jeu coopératif à 2 joueurs.

Veuillez noter que la règle « Player Count » est requise et ne peut être définie qu'une seule fois dans vos règles de configuration initiales.

Règle de latences (Latencies)

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de trajet aller-retour (ping) par rapport à toutes les balises disponibles, Gen2 ne prendra en compte que les matchs situés dans une difference spécifique de valeurs de ping, mesurée par rapport aux Balises de Ping. Cela représente une solution « douce » pour diviser votre base de joueurs, permettant de jouer avec des régions voisines, ce qui améliore particulièrement la vitesse de matchmaking pour les régions moins peuplées. Utilisez max_latency pour éviter de jouer contre des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle beacons ci-dessus avec "difference": 50, "max_latency": 200 au départ :

  • Alice et Bob correspondront, puisque Pékin est écarté (>200) et le reste est dans les limites | A-B | < 50 :

    • Alice {Montréal : 12.3, Newark : 45.6, Dallas : 59.9, Pékin : 264.4} ; et

    • Bob {Montréal : 27.3, Newark : 32.4, Dallas : 23.1, Pékin : 252.2}.

  • Charlie et Dave ne correspondront pas, puisque | C-D | > 50 pour la balise Dallas :

    • Alice {Montréal : 5.7, Newark : 44.2, Dallas : 59.5, Pékin : 263.2} ; et

    • Bob {Montréal : 57.8, Newark : 32.0, Dallas : 24.2, Pékin : 272.3}.

Veuillez noter que les « Règles de Latences » ne peuvent être définies qu'une seule fois dans vos règles de configuration initiales.

3. Examiner les détails de l'instance​

Examinez les détails de votre nouveau matchmaker dans notre tableau de bord une fois qu'il est initialisé :

L'état (Status) indique la santé du service, il peut être ONLINE, OFFLINE ou ERROR.

  • L'identifiant (Identifier) aide l'équipe d'Edgegap à trouver rapidement votre matchmaker si vous avez besoin d'aide pour le dépannage.

  • Démarré à (Started at) peut être utile pour suivre l'heure de la dernière mise à jour.

  • La taille (Size) correspond à l'un de nos Niveaux de tarification.

  • L'URL de l'API (API URL) sera utilisée par les clients de jeu et les serveurs de jeu pour communiquer avec Gen2.

  • L'URL Swagger (Swagger URL) est une interface graphique openAPI pratique que nous fournissons pour explorer le schéma de l'API.

  • Le jeton d'authentification (Auth Token) est un jeton secret unique utilisé par les clients de jeu et le serveur de jeu pour l'authentification.

Pour tester votre nouveau matchmaker à l'aide de l'API, vous aurez besoin de l'URL Swagger, de l'URL de l'API et du jeton d'authentification.

Vous pouvez maintenant passer à l'étape suivante.

4. Tester l'API des tickets

Tout d'abord, ouvrez votre URL Swagger pour inspecter votre schéma openAPI dans l'interface utilisateur de Swagger.

Cliquez sur l'URL /...swagger.json sous le titre « Matchmaker » pour ouvrir le schéma JSON brut :

Enregistrez cette page sous forme de fichier sur votre disque (CTRL/CMD+S).

Ouvrez votre application Postman et connectez-vous à votre compte gratuit.

Importez votre fichier swagger.json de l'étape précédente :

  • gardez Postman Collection sélectionné,

  • sélectionnez View Import Settings et remplacez le paramètre Parameter generation par Example.

Confirmez l'importation. Une nouvelle collection intitulée Matchmaker apparaîtra dans la liste des collections à gauche.

Affichez plus d'actions, ouvrez l'onglet Authorization et choisissez :

  • Auth Type - API Key,

  • Key - « Authorization »

  • Value - insérez votre valeur AuthToken ici,

  • Add to - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône d'enregistrement pour enregistrer les modifications. Le point orange dans votre onglet Postman devrait disparaître.

Dans votre collection Matchmaker, sélectionnez tickets et Create a matchmaking ticket, ce qui ouvrira un nouvel onglet.

Sélectionnez l'onglet Body pour prévisualiser votre demande de ticket de joueur :

notez que player_ip est défini sur null. Cela permettra d'utiliser l'adresse IP automatiquement ajoutée à votre demande (voir Intégration de Serveur à Serveur pour des alternatives),

  • profile fait référence à vos Profils de Matchmaking,

  • les attributes comprennent les valeurs pour les règles de votre matchmaker, dans ce cas pour la règle latencies,

    • la règle player_count est la seule règle qui ne nécessite aucun attribut dans les tickets des joueurs.

REMARQUE : Assurez-vous de vous référer à la configuration d'importation de Swagger de l'échantillon. 

Cliquez sur Send et examinez la réponse à votre demande de ticket de joueur :

  • id est l'ID unique de votre ticket de matchmaking, conservez-le pour vérifier votre ticket plus tard,

  • profile confirme le choix des Profils de Matchmaking,

  • group_id est un ID de groupe unique émis pour chaque ticket, un joueur solo étant représenté comme un groupe de 1,

  • player_ip est l'adresse IP publique résolue du joueur, quelle que soit la méthode d'identification utilisée,

  • assignment est défini sur null pour indiquer que le ticket n'a pas encore été mis en correspondance ou attribué à un serveur,

  • created_at fournit des informations sur le moment où le ticket du joueur a été créé pour l'interface utilisateur du jeu,

  • status indique le statut actuel du ticket, tous les tickets commençant par SEARCHING (voir Processus de Matchmaking pour plus de détails).

Créez un deuxième ticket en cliquant à nouveau sur Send, afin que nos deux joueurs correspondent et qu'un serveur soit démarré.

Dans votre collection Matchmaker, sélectionnez {ticketId} et Read a matchmaking ticket.

Saisissez l'ID du ticket de la réponse à l'étape précédente et cliquez sur Send.

Examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est d'abord passé à MATCH_FOUND, tout en maintenant assignment défini sur null pour indiquer que les joueurs ont trouvé une correspondance et qu'un serveur est en cours d'attribution,

Cliquez à nouveau sur Send pour vérifier votre ticket, et examinez l'attribution mise à jour pour votre ticket de joueur :

  • le statut est passé à HOST_ASSIGNED avec assignment contenant les détails du serveur attribué.

 Inspectez votre nouveau déploiement dans notre tableau de bord :

  • notez que chaque déploiement est étiqueté avec tous les ID de ticket et le profil pour une meilleure traçabilité.

Essayez de vous connecter depuis votre client de jeu au serveur attribué.

Une fois que vous avez vérifié que vous êtes en mesure de vous connecter à votre déploiement sans problème et que vous avez terminé les tests, arrêtez votre déploiement pour libérer de la capacité dans votre compte pour la prochaine version.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrer le Matchmaker dans votre jeu​

Le matchmaking d'Edgegap s'intègre :

  • avec le client de jeu (Game Client), pour gérer les Player Tickets,

  • avec le serveur de jeu (Game Server), pour :

    • traiter les préférences des joueurs transmises par leurs tickets,

    • éventuellement pour prendre en charge le Backfill afin d'ajouter ou de remplacer des joueurs après le démarrage.

Pour le client de jeu, nous recommandons de fournir des mises à jour du statut des tickets tout au long du Processus de Matchmaking aux joueurs via l'interface utilisateur du jeu pour une meilleure expérience joueur. Voir :

Dans le client de jeu, assurez-vous de gérer les erreurs non réessayables :

  • HTTP 404 Not Found - le ticket a été supprimé,

  • HTTP 500 Internal Server Error - interruption temporaire du service.

Dans le serveur de jeu, traitez les préférences des joueurs et le contexte initial du serveur. Aucune intégration d'API n'est requise :

  1. Lisez les variables d'environnement injectées (Gen2) pour récupérer les données de matchmaking initiales des joueurs.

  2. Lisez les variables d'environnement injectées (Versions d'application) pour obtenir les paramètres spécifiques à la version, les réglages (capacité de joueurs) et les secrets.

  3. Lisez les variables d'environnement injectées (Déploiement) pour obtenir des informations sur le déploiement, telles que l'adresse IP, l'emplacement ou autre.

Une fois que les joueurs se connectent, le serveur de jeu et les clients de jeu lancent une scène de chargement pour effectuer les étapes de synchronisation (par exemple, sélectionner et charger une carte/scène/niveau). Nous recommandons une scène 3D complète, une interface sociale de type salon ou un écran de chargement avec une barre de progression pour indiquer que l'initialisation progresse.

Une fois les clients de jeu complètement chargés, les joueurs chargent/se déplacent vers la scène de jeu principale.

En option, le serveur de jeu peut créer et gérer le Backfill et la capacité des joueurs (ajouter ou remplacer les joueurs qui partent).

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l' DELETE_URL injectée, si :

  • aucun joueur ne rejoint la partie,

  • tous les joueurs ont quitté la partie,

  • la partie se termine correctement.

Félicitations, vous avez terminé l'intégration d'Edgegap Matchmaker ! Si vous souhaitez en savoir plus, lisez tout à ce sujet dans notre Learning Center.

Écrit par

l'équipe Edgegap

Intégrer Edgegap facilement en quelques minutes

Commencez l'intégration maintenant!

Commencez l'intégration maintenant!

Intégrer Edgegap facilement en quelques minutes