Comment intégrer le matchmaking à votre jeu multijoueur Unity Engine

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

L'exemple suivant vous aidera à tester le flux de joueur principal du matchmaking pour un jeu multijoueur Unity Engine, à 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 joueur 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 simple. Voilà, vous avez (techniquement) fait la moitié du chemin ! Il ne vous reste plus qu'à intégrer le matchmaker dans votre jeu (voir l'étape 5).

2. Maintenant, vous ne devriez jamais suivre aveuglément un exemple JSON trouvé sur Internet, c'est pourquoi il est fortement recommandé d'adapter les règles ci-dessus à votre jeu au tour par tour. 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 votre matchmaker spécifique et personnel afin de s'assurer qu'il est déployé et 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 ») met en évidence la manière d'intégrer le matchmaker au sein du projet de votre moteur.

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

Tutoriel Unreal - Ajouter le Matchmaking d'Edgegap

Si cela vous semble intimidant, ne vous inquiétez pas - regardez la vidéo d'intégration étape par étape :

1. Configuration de l'offre gratuite (Free Tier)

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

À partir de là, cliquez d'abord sur Create Matchmaker, puis saisissez :

• Un nom pour votre matchmaker – qui sert uniquement de référence pour vous, par ex. quickstart-dev,

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

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "simple-example": {
      "application": {
        "name": "my-game-server",
        "version": "2024.01.30-16.23.00-UTC"
      },
      "rules": {
        "initial": {
          "match_size": {
            "type": "player_count",
            "attributes": {
              "team_count": 1,
              "team_size": 2
            }
          },
          "beacons": {
            "type": "latencies",
            "attributes": {
              "difference": 50,
              "max_latency": 200
            }
          }
        },
        "expansions": {}
      }
    }
  }
}

(rappel amical pour vous assurer de modifier le nom (name) et la version (version) de l'application afin de correspondre à vos Application and 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 Example.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la configuration​

Gestion sémantique de version (Semantic Versioning)

Au fur et à mesure que nous publions des mises à jour pour le Matchmaker, chaque nouvelle version utilise le Semantic Versioning pour communiquer clairement l'impact des changements en interprétant le format major.minor.patch :

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

• Les versions minor incluent des améliorations substantielles rétrocompatibles,

• Les versions patch incluent des corrections de bogues et des améliorations mineures.

Certains déploiements peuvent entraîner des erreurs. Nous tentons de résoudre ce problème en réessayant le déploiement automatiquement 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 persistent pas et ne consomment pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, ce qui fera passer leur statut à CANCELLED, puis seront définitivement supprimés après ticket_removal_period.

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

Les Matchmaking Rules de l'ensemble de règles initiales 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 ex. - match size,

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

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

Règle du nombre de joueurs (Player Count Rule)

Il s'agit d'une règle spéciale définissant le nombre de joueurs nécessaires pour lancer l'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 avec 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 des latences (Latencies Rule)

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients ont mesuré et soumis leur temps d'aller-retour (ping) pour toutes les balises disponibles, Gen2 ne prendra en compte que les correspondances comprises dans une difference spécifique de valeurs de ping, mesurées par rapport aux Ping Beacons. Cela présente une solution « douce » pour diviser votre base de joueurs, permettant le matchmaking avec des régions voisines, améliorant particulièrement la vitesse de recherche de partie pour les régions moins peuplées. Utilisez max_latency pour empêcher le matchmaking avec des joueurs situés trop loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle beacons ci-dessus avec initialement "difference": 50, "max_latency": 200 :

• Alice et Bob correspondront, puisque Pékin est écarté (>200) et le reste est compris dans | 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 de 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 la règle « Latencies Rules » ne peut être définie 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é :

Le Status indique l'état de santé du service, qui peut être ONLINE, OFFLINE ou ERROR.

• L'Identifier aide le personnel d'Edgegap à trouver rapidement votre matchmaker si vous avez besoin d'aide pour le dépannage.

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

• La Size correspond à l'un de nos Pricing Tiers.

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

• La Swagger URL est une interface graphique pratique de spécification openAPI que nous fournissons pour explorer le schéma de l'API.

• L'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 la Swagger URL, de l'API URL et de l'Auth Token.

Vous pouvez maintenant passer à l'étape suivante.

4. Tester l'API des tickets

Tout d'abord, ouvrez votre Swagger URL pour inspecter votre schéma openAPI dans l'interface graphique 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 l'option Postman Collection sélectionnée,

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

Confirmez l'importation, cela fera apparaître une nouvelle collection dans la liste des collections sur la gauche, intitulée Matchmaker.

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

• Auth Type - API Key,

• Key - « Authorization »

• Value - insérez votre valeur d'AuthToken ici,

• Add to - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône d'enregistrement pour sauvegarder 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 entraînera l'utilisation de l'adresse IP automatiquement ajoutée à votre demande (voir Server to Server Integration pour des alternatives),

• profile fait référence à vos Matchmaking Profiles,

• attributes inclut les valeurs de vos règles de 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 de joueur.

REMARQUE : Veillez à vous référer à la configuration d'importation 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 confirmant le choix de Matchmaking Profiles,

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

  • voir Join as Group pour faire du matchmaking avec vos amis ou des salons (lobbies),

• 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é associé ou attribué à un serveur,

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

• status indique le statut actuel du ticket, tous les tickets commençant par SEARCHING (voir Matchmaking Process 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 de ticket de la réponse de 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 de 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 marqué avec tous les ID de tickets et le profil pour une traçabilité accrue.

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

Une fois que vous avez vérifié que vous pouvez 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 build.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrer le Matchmaker dans votre jeu​

Le matchmaking d'Edgegap s'intègre :

• avec le Game Client, pour gérer les Player Tickets,

• avec le 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 Game Client, nous recommandons de fournir aux joueurs des mises à jour sur le statut des tickets tout au long du Matchmaking Process en utilisant l'interface utilisateur du jeu pour une meilleure expérience joueur. Voir :

• Edgegap - Unity Gen2 Matchmaking SDK,

  • importez l'exemple simple et personnalisez-le selon vos besoins,

• Betide Studio - Unreal Engine Edgegap Integration Kit,

  • téléchargez l'exemple de projet et personnalisez-le selon vos besoins.

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

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

• HTTP 500 Internal Server Error - panne de service temporaire.

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

1. Lisez les Injected Environment Variables (Gen2) pour récupérer les données de matchmaking initiales des joueurs.

2. Lisez les Injected Environment Variables (App Versions) pour les paramètres spécifiques à la version, les réglages (capacité de joueurs) et les secrets.

3. Lisez les Injected Environment Variables (Deployment) pour obtenir des informations sur le déploiement, telles que l'adresse IP, l'emplacement, etc.

Une fois les joueurs connectés, le Game Server et les Game Clients commencent 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 (lobby) ou un écran de chargement avec une barre de progression pour indiquer que l'initialisation progresse.

Une fois les Game Clients entièrement chargés, les joueurs chargent/se déplacent vers la scène de jeu principale.

Optionnellement, le Game Server peut créer et gérer le Backfill et la capacité de joueurs (ajouter ou remplacer les joueurs qui partent).

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l'URL Injected DELETE_URL, 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, découvrez tout à ce sujet dans notre Learning Center.