Comment intégrer le matchmaking à votre jeu roguelike multijoueur

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

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

• Créer l'instance du matchmaker sur le cluster hébergé,

• 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 tickets de joueur avec notre API.

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

1. La première étape est de créer un compte et d'utiliser notre exemple de jeu roguelike. Voilà, vous êtes (techniquement) à mi-chemin ! Vous devez seulement intégrer le matchmaker dans votre jeu (voir l'étape 5).

2. Maintenant, vous ne devez 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 au tour par tour. L'étape 2 (“Explorer la configuration”) est notre “comment lire” qui explique le fonctionnement de chacune des règles de matchmaking (“Explorer la configuration”).

3. L'étape 3 (“Réviser les détails de l'instance”) couvre votre matchmaker personnel et spécifique pour s'assurer qu'il est déployé et fonctionne avec le design de votre jeu.

4. L'étape 4, comme son nom l'indique (“4. Tester l'API des tickets”), concerne le test de vos demandes de matchmaking de joueurs reçues par le matchmaker, appelées tickets.

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

Si vous avez des défis de dépannage, notre Centre d'apprentissage propose des conseils supplémentaires.

1. Configuration du niveau gratuit

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 purement à votre propre référence, par exemple quickstart-dev,

• Ensuite, téléchargez l'exemple simple suivant comme une configuration JSON ci-dessous pour votre jeu roguelike :

{
  "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, assurez-vous de changer le nom de l'application et version pour correspondre à votre application et versions !)

S'il n'y a pas d'erreurs de validation, cliquez sur Créer et Démarrer et attendez que le processus se termine. Cela entraînera le démarrage d'un nouveau cluster gratuit, avec votre matchmaker d'exemple simple.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la configuration​

Règles uniques pour les jeux roguelike multijoueurs

Des salons personnalisés (salons privés, niveaux de bac à sable) sont une option très populaire pour le multijoueur sur canapé, mais également pour tester de 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 à assurer que les joueurs peuvent Rejoindre en groupe.

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

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

Versioning sémantique

Lorsque nous publions des mises à jour pour le matchmaker, chaque nouvelle version utilise le versioning sémantique pour communiquer clairement l'impact des changements en interprétant le format majeur.minor.patch :

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

• Les versions mineur comprennent des améliorations substantielles compatibles avec les versions précédentes,

• 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 pannes de clients inattendues ou les tickets abandonnés ne restent pas et n'occupent pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period ce qui entraînera un changement de statut à ANNULÉ et ensuite 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 les versions de l'application avec un montant prédéfini de ressources CPU et mémoire (RAM) requises.

Les règles de matchmaking dans l'ensemble de règles initiales doivent être respectées pour que les joueurs soient regroupés ensemble, chacune définie par trois propriétés :

• nom de votre choix, par exemple - taille du 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_equipes ou taille_de_l_equipe.

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_equipes fait référence au nombre d'équipes, 1 équipe peut être utilisée pour des modes coopératifs ou libre,

• taille_de_l_equipe fait référence 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 des latences

Utilisez cette règle pour fournir le ping le plus bas possible pour tous les joueurs. Une fois que les clients mesurent et soumettent leur temps de latence aller-retour (ping) par rapport à tous les bippers disponibles, Gen2 ne considérera que les matchs dans une différence spécifique dans les valeurs de ping, mesurées par rapport à des bippers de ping. 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 des matchs pour les régions moins peuplées. Utilisez max_latency pour éviter le matchmaking contre des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

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

• Alice et Bob se correspondront, 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 se correspondront pas, puisque | C-D | > 50 pour le bipper 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. Réviser les détails de l'instance​

Révisez 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.

• Commencé à peut être utile pour suivre le dernier moment de 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 le serveur 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 le /...swagger.json URL en dessous du 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 fichier swagger.json depuis l'étape précédente :

• gardez Postman Collection sélectionné,

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

Confirmez l'importation, cela entraînera l'apparition d'une nouvelle collection dans la liste des Collections à gauche, intitulée Matchmaker.

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

• Type d'auth - Clé API,

• Clé - “Authorization”

• Valeur - insérez votre valeur de AuthToken ici,

• Ajouter à - En-tête.

Appuyez sur (CTRL/CMD+S) ou l'icône de sauvegarde pour sauvegarder 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, ouvrant un nouvel onglet.

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

remarquez que player_ip est défini sur null - ceci va utiliser l'adresse IP automatiquement ajoutée à votre demande (voir Intégration Serveur à Serveur pour les alternatives),

• profil fait référence à vos profils de matchmaking,

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

  • la règle nombre_de_joueurs est la seule règle qui ne nécessite pas d'attributs dans les tickets de joueur.

REMARQUE : Assurez-vous de consulter la configuration d'importation de l'échantillon Swaggers. 

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

• id est votre identifiant de ticket de matchmaking unique, gardez cela sauvegardé pour vérifier votre ticket plus tard,

• profil confirmant le choix des profils de matchmaking,

• group_id est un identifiant 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 salons,

• 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 assigné à un serveur,

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

• status indique l'état actuel du ticket, tous les tickets commencent dans RECHERCHE (voir le processus de matchmaking pour des détails).

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

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

Saisissez l'ID du ticket provenant 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é pour MATCH_FOUND en premier, tout en maintenant assignment défini sur null pour indiquer que les joueurs se correspondent et qu'un serveur est en cours d'attribution,

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

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

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

• remarquez que chaque déploiement est étiqueté avec tous les IDs de tickets et profils pour plus de traçabilité.

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é sur votre compte pour le prochain 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 client de jeu, pour gérer les tickets de joueurs,

• avec le serveur de jeu, pour :

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

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

Pour dans le client de jeu, nous recommandons de fournir des mises à jour sur l'état des tickets tout au long du processus de matchmaking pour les joueurs utilisant l'interface utilisateur du jeu pour la meilleure expérience joueur. 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 le client de jeu, assurez-vous de gérer les erreurs non répétables :

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

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

Dans le 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 d'application) pour les paramètres, réglages (capacité des joueurs), et secrets spécifiques à la version.

3. Lisez les variables d'environnement injectées (déploiement) pour les informations de déploiement, telles que l'adresse IP, l'emplacement, ou plus.

Une fois que les joueurs se connectent, le serveur de jeu et les clients de jeu commencent une scène de chargement pour effectuer des é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 type hall, ou un écran de chargement avec une barre de progression, pour indiquer que l'initialisation progresse.

Une fois les clients de jeu entièrement chargés, les joueurs se chargent/voyagent vers la scène de jeu principale.

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

Assurez-vous que votre déploiement sera arrêté correctement en utilisant l'URL DELETE injectée, 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 d'Edgegap ! Si vous souhaitez en savoir plus, lisez tout sur cela dans notre Centre d'apprentissage.