Comment intégrer le matchmaking dans votre jeu multijoueur MMORPG

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

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

• Création de l'instance de matchmaking sur le cluster d'hébergement partagé,

• Définition des règles et paramètres dans votre Configuration de matchmaking,

• Et enfin, test du flux de joueurs et gestion des tickets de joueurs avec notre API.

Il y a Cinq étapes pour intégrer notre matchmaking dans votre jeu :

1. La première étape consiste à créer un compte et à utiliser notre exemple de jeu MMORPG. Voilà, vous êtes (techniquement) à mi-chemin ! Il vous suffit d'intégrer le matchmaking dans votre jeu (voir étape 5).

2. Maintenant, vous ne devez jamais suivre aveuglément un exemple JSON trouvé sur Internet, il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu au tour par tour. L'étape 2 ("Explorer la configuration") est notre "comment lire" qui explique la fonction de chaque règle de matchmaking ("Explorer la configuration").

3. L'étape 3 ("Examiner les détails de l'instance") couvre votre matchmaker personnel et spécifiquement pour 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. Tester l'API des tickets"), concerne tout le test de vos requêtes de matchmaking que les joueurs envoient au matchmaker, appelées tickets.

5. L'étape 5 ("Intégrer le matchmaking dans votre jeu") met en lumière comment intégrer le matchmaker dans le projet de votre moteur.

Si vous avez des difficultés liées au dépannage, notre Centre d'apprentissage contient des conseils supplémentaires pour le dépannage.

1. Configuration de la version gratuite

Inscrivez-vous pour votre compte Edgegap gratuit, et naviguez vers la page du tableau de bord du matchmaker.

À partir de là, cliquez d'abord sur Créer un matchmaker , puis saisissez :

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

• Ensuite, téléchargez l'exemple simple suivant en tant que configuration JSON ci-dessous pour votre jeu MMORPG :

{
  "version": "2.1.0",
  "inspect": true,
  "max_deployment_retry_count": 3,
  "ticket_expiration_period": "5m",
  "ticket_removal_period": "1m",
  "profiles": {
    "custom-lobby-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": 4
            }
          },
          "lobby_id": {
            "type": "string_equality"
          }
        },
        "expansions": {}
      }
    }
  }
}

(Petit rappel de bien vouloir changer le nom de l'application name et version pour correspondre à votre application et versions!)

Si aucune erreur de validation n'apparaît, appuyez sur Créer et démarrer et attendez que le processus se termine. Cela aboutira à un nouveau cluster gratuit démarrant, avec votre matchmaker d'exemple simple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la configuration​

Règles de jeux multijoueurs MMORPG uniques

Des salons personnalisés (salons privés, niveaux en bac à sable) sont une option très populaire pour le multijoueur sur canapé mais aussi pour tester les nouvelles fonctionnalités dans des jeux compétitifs ou coopératifs avant d'entrer dans les modes de jeu principaux. Ces jeux nécessitent généralement le moins de restrictions, mais visent à garantir que les joueurs peuvent Rejoindre en groupe.

Les tickets Backfill peuvent utiliser des profils de salons personnalisés pour soutenir l'invitation fiable d'amis, tant que les tickets Backfill sont valides.

• Conseil: Ajoutez le profil custom-lobby-example à votre configuration en plus de vos autres profils pour soutenir les salons personnalisés.

Versioning sémantique

À mesure que nous publions des mises à jour pour le matchmaker, chaque nouvelle version utilise le versionnement sémantique pour communiquer clairement l'impact des changements en interprétant le format majeur.mineur.patch :

• Les versions majeures comprennent des changements qui brisent la compatibilité et nécessitent une révision de l'intégration,

• Les versions mineures incluent des améliorations compatibles importantes,

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

Certaines déploiements peuvent entraîner des erreurs. Nous tentons de résoudre cela en réessayant le déploiement jusqu'à max_deployment_retry_count fois automatiquement (sans confirmation du client).

Pour garantir que les plantages inattendus des clients ou les tickets abandonnés ne persistent pas et n'occupent pas vos ressources de matchmaking, les tickets seront annulés après ticket_expiration_period modifiant leur état en ANNULÉ et ensuite définitivement supprimés après ticket_removal_period.

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

Règles de matchmaking dans l'ensemble de règles initial doit être satisfaites pour que les joueurs soient regroupés, chacune définie par trois propriétés :

• nom de votre choix, par exemple - taille de match,

• type de règle, également connu sous le nom d'opérateur, par exemple - nombre_de_joueurs,

• et enfin, les attributs de l'opérateur, par exemple nombre_d'équipes ou taille_d'équipe.

Règle du nombre de joueurs

C'est une règle spéciale définissant combien de joueurs doivent correspondre pour initier l'attribution :

• nombre_d'équipes se réfère au nombre d'équipes, 1 équipe peut être utilisée pour des modes coopératifs ou en free-for-all,

• taille_d'équipe se réfère au nombre de joueurs par équipe.

Notre exemple simple démontre un jeu coopératif avec 2 joueurs.

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

Règle de latences

Utilisez cette règle pour fournir le ping le plus faible possible pour tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de réponse aller-retour (ping) contre tous les balises disponibles, Gen2 ne considérera que les matchs dans une différence spécifique dans les valeurs de ping, mesurées par rapport à les balises de ping. Cela constitue une solution « douce » pour diviser votre population de joueurs, permettant de jumeler avec des régions voisines, améliorant particulièrement la rapidité des matchs pour les régions moins peuplées. Utilisez max_latency pour éviter de jumeler des joueurs situés trop loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple balises ci-dessus avec "difference": 50, "max_latency": 200 initialement :

• Alice et Bob seront jumelés, puisque Pékin est écarté (>200) et le reste est 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 seront pas jumelés, 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 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é :

Statut indique la santé du service, peut être EN LIGNE, HORS LIGNE ou ERREUR.

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

• Démarré à peut être utile pour retrouver l'heure de la dernière mise à jour.

• Taille correspond à l'un de nos niveaux de tarification.

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

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

• Token d'authentification est un jeton secret unique utilisé par les clients de jeu et les serveurs de jeu pour l'authentification.

Pour tester votre nouveau matchmaker en utilisant l'API, vous aurez besoin de l'URL Swagger, de l'URL de l'API et du Token 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 Swagger

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

Enregistrez cette page en tant que fichier sur votre disque (CTRL/CMD+S).

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

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

• maintenez Postman Collection sélectionné,

• sélectionnez Voir les paramètres d'importation et changez le paramètre Génération de paramètres à Exemple.

Confirmez l'importation, cela aboutira à une nouvelle collection apparaissant dans la liste des Collections à gauche, intitulée Matchmaker.

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

• Type d'auth - Clé API,

• Clé - “Autorisation”

• Valeur - insérez votre valeur AuthToken ici,

• Ajouter à - Header.

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

Dans votre collection de matchmaker, sélectionnez tickets et Créer un ticket de matchmaking, en ouvrant un nouvel onglet.

Sélectionnez l'onglet Body pour prévisualiser votre requête de ticket de joueur :

remarquez que player_ip est défini sur null- cela vous fera utiliser l'adresse IP automatiquement ajoutée à votre requête (voir intégration serveur à serveur pour des alternatives),

• profil se réfère à vos Profils de matchmaking,

• attributs incluent des valeurs pour vos règles de matchmaker, dans ce cas pour la règle de latences,

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

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

Cliquez sur Envoyer et examinez la réponse à votre requête de ticket de joueur :

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

• profil confirmant le choix des Profils de matchmaking,

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

  • voir Rejoindre en groupe pour le matchmaking avec vos amis ou lobbys,

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

• created_at fournit des informations sur la date de création du ticket de joueur pour l'utilisation dans l'interface du jeu,

• status indique l'état actuel du ticket, tous les tickets commencent en SEARCHING (voir Processus de matchmaking pour les détails).

Créez un second ticket en cliquant à nouveau sur Envoyer, de sorte que nos deux joueurs se correspondent et qu'un serveur soit démarré.

Dans votre collection de matchmaker, sélectionnez {ticketId} et Lire un ticket de matchmaking.

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

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

• le statut a changé en MATCH_FOUND au début, tout en gardant assignment défini sur null indiquant que les joueurs ont été jumelés et qu'un serveur est en cours d'attribution,

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

• le statut a changé en HOST_ASSIGNED avec assignment contenant les détails du serveur attribué.

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

• remarquez que chaque déploiement est étiqueté avec tous les ID de tickets et les profils 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èmes 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 Client de jeu, pour gérer tickets de joueurs,

• avec Serveur de jeu, pour :

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

  • optionnellement pour soutenir Backfill pour ajouter ou remplacer des joueurs après le démarrage.

Pour le Client de jeu, nous recommandons de fournir des mises à jour sur l'état des tickets tout au long du Processus de matchmaking aux joueurs à l'aide de l'interface utilisateur in-game pour la meilleure expérience possible. Voir :

• Edgegap - SDK de matchmaking Unity Gen2,

  • importer l'exemple simple et personnaliser selon vos besoins,

• Betide Studio - Kit d'intégration Unreal Engine Edgegap,

  • télécharger le projet d'exemple et personnaliser selon vos besoins.

Dans Client de jeu, assurez-vous de gérer les erreurs non récupérables :

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

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

Dans Serveur de jeu, traitez les préférences des joueurs et le contexte initial du serveur. Aucune intégration 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 de l'application) pour les paramètres spécifiques à la version, les paramètres (capacité des 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, etc.

Une fois les joueurs connectés, le Serveur de jeu et les Clients de jeu démarrent 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 utilisateur sociale de style salon, ou un écran de chargement avec une barre de progression, pour indiquer que l'initialisation progresse.

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

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

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

• aucun joueur ne rejoint le match,

• tous les joueurs ont quitté le match,

• le match se termine correctement.

Félicitations, vous avez complété l'intégration du Matchmaker Edgegap ! Si vous souhaitez en savoir plus, lisez tout à ce sujet dans notre Centre d'apprentissage.