Comment intégrer le matchmaking à votre jeu multijoueur MMO

-> Cet article est basé sur la documentation Matchmaking. Si vous rencontrez des problèmes ou des divergences, veuillez vous assurer de consulter le guide original, car ils sont plus fréquemment mis à jour.

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

• Créer l'instance de matchmaker sur le cluster d'hébergement partagé,

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

• Et enfin, tester le flux des joueurs 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 consiste à créer un compte et à utiliser notre exemple de jeu MMO. Voilà, vous êtes (techniquement) à mi-chemin ! Il vous suffira d'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, 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 fonction de règles de matchmaking.

3. L'étape 3 (« Revoir les détails de l'instance ») concerne votre matchmaker personnel et spécifique pour s'assurer qu'il est déployé et fonctionne avec la conception de votre jeu.

4. L'étape 4, comme le nom l'indique (« 4. Test de l'API des tickets »), porte sur le test de vos demandes de matchmaking reçues par le matchmaker, appelées tickets.

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

Si vous avez des problèmes de dépannage, notre centre d'apprentissage en profondeur contient des conseils supplémentaires de dépannage.

1. Configuration du niveau gratuit

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

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

• Un nom pour votre matchmaker – purement pour votre propre 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 MMO :

{
  "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 pour veillez à modifier le nom de l'application et la version pour qu'ils correspondent à vos applications 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 se traduira par 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 de jeu multijoueur MMO uniques

Les lobbies personnalisés (lobbies privés, niveaux sandbox) sont une option très populaire pour les jeux multijoueurs sur canapé, mais aussi pour tester de nouvelles fonctionnalités dans des jeux compétitifs ou coopératifs avant qu'ils n'entrent dans les modes de jeu principaux. Ces jeux nécessitent généralement le moins de restrictions possibles, mais visent à s'assurer que les joueurs peuvent rejoindre en groupe.

Remplir les tickets peuvent utiliser des profils de lobby personnalisés pour inviter des amis de manière fiable, tant que les tickets de Backfill sont valides.

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

Gestion des versions sémantiques

Lorsque nous publions des mises à jour pour le Matchmaker, chaque nouvelle version utilise la gestion des versions sémantiques pour communiquer clairement l'impact des changements en interprétant le format major.minor.patch :

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

• les versions mineures incluent des améliorations substantiellement compatibles vers l'arrière,

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

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

Pour s'assurer que les plantages inattendus des clients ou les tickets abandonnés ne persistent pas et n'occupent pas les ressources de votre matchmaker, les tickets seront annulés après ticket_expiration_period, modifiant leur statut en CANCELLED puis supprimés définitivement 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 d'applications avec une quantité prédéfinie de ressources CPU et mémoire (RAM) requises.

Les règles de matchmaking dans l'ensemble de règles initial 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 des matchs,

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

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

Règle de comptage des joueurs

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

• le team_count désigne le nombre d'équipes, 1 équipe peut être utilisée pour des modes coopératifs ou de type chacun pour soi,

• le team_size se réfère au nombre de joueurs par équipe.

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

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

Règle des latences

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 considérera que les matchs dans une différence spécifique de valeurs de ping, mesurée par rapport aux balises de ping. Cela présente une solution « douce » pour diviser votre base de joueurs, permettant l'appariement avec des régions voisines, améliorant notamment la vitesse d'appariement pour les régions moins peuplées. Utilisez max_latency pour éviter le matchmaking avec des joueurs situés très loin.

Vous pouvez maintenant passer à l'étape suivante.

Notre exemple de règle de balises ci-dessus avec "différence" : 50, "max_latency" : 200 initialement :

• Alice et Bob se correspondront, car Pékin est éliminé (>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, car | 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 des latences" ne peuvent être définies qu'une seule fois dans vos règles de configuration initiales.

3. Révision des détails de l'instance​

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

Le statut indique l'état de santé du service, qui peut être EN LIGNE, HORS LIGNE, ou ERREUR.

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

• Commencé à peut être utile pour suivre la dernière heure de mise à jour.

• La taille correspond à l'un de nos niveaux de tarification.

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

• URL Swagger est une interface utilisateur openAPI pratique que nous fournissons pour explorer le schéma API.

• Token d'authentification est un jeton secret unique utilisé par les clients et le serveur de jeux 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 Token d'authentification.

Vous pouvez maintenant passer à l'étape suivante.

4. Test de l'API des Tickets

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 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 à partir de l'étape précédente :

• gardez Postman Collection sélectionné,

• sélectionnez Afficher les paramètres d'importation et modifiez le paramètre Génération de paramètres en Exemple.

Confirmez l'importation, cela se traduira par une nouvelle collection apparaissant dans la liste des collections à gauche, intitulée Matchmaker.

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

• Type d'authentification - Clé API,

• Clé - « Autorisation »

• Valeur - insérez ici votre valeur du Token d'authentification,

• Ajouter à - En-tête.

Appuyez (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 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 player_ip défini à null - cela va utiliser automatiquement l'adresse IP ajoutée à votre demande (voir Intégration serveur à serveur pour des 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 latencies,

  • 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 du Swagger de l'échantillon.

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

• id est votre ID de ticket de matchmaking unique, gardez-le enregistré 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é en tant que groupe de 1,

  • voir Rejoindre en groupe pour le matchmaking avec vos amis ou 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 l'état actuel du ticket, tous les tickets commencent dans SEARCHING (voir Processus de matchmaking pour les détails).

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

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

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

Vérifiez l'attribution mise à jour pour votre ticket de joueur :

• le statut est passé à MATCH_FOUND d'abord, tout en gardant assignment défini à null pour indiquer que des joueurs ont été apparié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 est passé à HOST_ASSIGNED avec assignment contenant des détails sur le serveur attribué.

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

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

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

Une fois que vous vérifiez 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.

Vous pouvez maintenant passer à l'étape suivante.

5. Intégrez le Matchmaker dans votre jeu​

Le matchmaking Edgegap s'intègre :

• avec le client de jeu, pour gérer les tickets de joueur,

• avec le serveur de jeu, pour :

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

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

Pour le client de jeu, nous recommandons de fournir des mises à jour du statut du ticket tout au long du processus de matchmaking aux joueurs en utilisant l'interface utilisateur en jeu pour une meilleure expérience des joueurs. Voir :

• Edgegap - SDK de matchmaking Unity Gen2,

  • importer un exemple simple et personnaliser selon vos besoins,

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

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

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

• HTTP 404 Non trouvé - le ticket a été supprimé,

• HTTP 500 Erreur interne du serveur - panne de service temporaire.

Sur 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 (App Versions) pour les paramètres de version, les réglages (capacité des joueurs) et les secrets.

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

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

Une fois que les clients de jeu sont complètement chargés, les joueurs chargent/voyagent vers la scène principale de jeu.

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

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

• aucun joueur ne rejoint le match,

• tous les joueurs ont quitté le match,

• le match se conclut correctement.

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