Comment intégrer le matchmaking dans votre jeu Battle Royale

-> Cet article est basé sur la documentation du Matchmaking. Si vous rencontrez des problèmes ou des divergences, veillez à 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 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 BR. Voilà, vous avez (techniquement) fait la moitié du chemin ! Il ne vous reste 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, il est donc fortement recommandé d'adapter les règles ci-dessus à votre jeu. L'étape 2 (« Explorer la configuration ») est notre guide de lecture qui détaille le rôle de chaque fonction des règles de matchmaking (« Explore Configuration »).

3. L'étape 3 (« Examiner les détails de l'instance ») couvre votre matchmaker personnel et spécifique 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. Tester l'API des tickets »), consiste à tester la bonne réception par le matchmaker des demandes de matchmaking envoyées par les joueurs, appelées tickets.

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

Si vous rencontrez des difficultés de dépannage, notre Centre d'apprentissage complet contient des conseils de dépannage supplémentaires.

1. Configuration du niveau gratuit

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 – servant uniquement pour votre propre référence, par ex. quickstart-dev,

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

{
  "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 : veillez à modifier le nom et la version de l'application pour qu'ils correspondent à vos Applications et Versions !)

Si aucune erreur de validation n'apparaît, cliquez sur Create and Start et attendez la fin du processus. Cela lancera un nouveau cluster gratuit avec votre matchmaker Simple Example.

Vous pouvez maintenant passer à l'étape suivante.

2. Explorer la configuration​

Règles spécifiques au jeu BR

Plus particulièrement pour les jeux Battle Royale, vous pouvez définir plusieurs Matchmaking Profiles pour les règles et paramètres propres aux modes de jeu :

• restreindre l'écart de rang entre deux joueurs pour des parties plus détendues,

• restreindre l'écart de rang pour autoriser uniquement des adversaires de même niveau en parties classées,

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

• ajouter une interface de sélection de hub pour limiter les adversaires aux Ping Beacons spécifiés,

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

• restreindre la latence de matchmaking à un écart maximal pour optimiser l'équité de ping,

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

• Rejoindre en groupe pour les salons prédéfinis ou pour compléter les équipes sans dépasser leur taille limite.

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

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

• augmentez progressivement l'écart de rang autorisé pour trouver plus de joueurs,

• augmentez le délai entre les élargissements pour les rangs les plus élevés (challengers), car moins de joueurs sont disponibles.

Créez des tickets avec un rang plus élevé pour les matchs de promotion, afin d'affronter des adversaires plus coriaces.

Définissez des profils de tricheurs distincts pour vous assurer que les tricheurs signalés ou les joueurs faisant l'objet de nombreux signalements de modération ne nuisent pas à l'expérience des joueurs légitimes dans les matchs classés.

Gestion sémantique des versions

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

• les versions majeures incluent des changements cassants 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 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 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 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 des Versions d'application avec une quantité prédéfinie de ressources processeur et mémoire (RAM) requises.

Les règles de Matchmaking de l'ensemble initial doivent être satisfaites 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

Il s'agit d'une règle spéciale définissant le nombre de joueurs devant correspondre pour initier l'attribution :

• team_count désigne le nombre d'équipes, 1 équipe pouvant être utilisée pour les modes coopératifs ou chacun pour soi,

• team_size désigne le nombre de joueurs par équipe.

Notre exemple simple illustre une partie en coopération à 2 joueurs.

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

Règle de latence

Utilisez cette règle pour offrir le ping le plus bas possible à tous les joueurs. Une fois que les clients mesurent et transmettent leur temps d'aller-retour (ping) par rapport à toutes les balises disponibles, Gen2 ne prendra en compte que les correspondances respectant une difference spécifique de ping, mesurée par rapport aux Ping Beacons. Cela représente une solution « douce » pour segmenter votre base de joueurs, permettant le rapprochement avec des régions voisines, améliorant notamment la rapidité de création de partie pour les régions moins peuplées. Utilisez max_latency pour empêcher l'association avec des joueurs situés trop 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 seront associés, car Beijing est écarté (>200) et le reste est compris dans | A-B | < 50 :

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

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

• Charlie et Dave ne seront pas associés, car | C-D | > 50 pour la balise de Dallas :

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

  • Bob {Montréal : 57.8, Newark : 32.0, Dallas : 24.2, Beijing : 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​

Consultez les détails de votre nouveau matchmaker dans notre tableau de bord une fois initialisé :

L'état indique la santé du service, qui peut être ONLINE, OFFLINE ou ERROR.

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

• La date de démarrage peut être utile pour déterminer l'heure de la dernière mise à jour.

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

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

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

• Le jeton d'authentification est un jeton secret unique utilisé par les clients et le serveur de jeu pour s'authentifier.

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 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 :

• laissez Postman Collection sélectionné,

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

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

Cliquez sur View more actions, ouvrez l'onglet Authorization et choisissez :

• Type d'authentification - API Key,

• Clé - « Authorization »

• Valeur - insérez votre valeur AuthToken ici,

• Ajouter à - Header.

Appuyez sur (CTRL/CMD+S) ou sur l'icône Enregistrer 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 ouvre un nouvel onglet.

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

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

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

• 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 : 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 votre identifiant unique de ticket de matchmaking, conservez-le pour vérifier votre ticket ultérieurement,

• profile confirmant le choix des Profils de Matchmaking,

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

  • voir Rejoindre en groupe pour le matchmaking avec vos amis ou des 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é associé ou assigné à un serveur,

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

• status indique l'état actuel du ticket, tous les tickets commençant par SEARCHING (voir le 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 de ticket provenant 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 passe d'abord à MATCH_FOUND, tout en conservant assignment défini sur null pour indiquer que les joueurs ont trouvé une partie 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 passe à 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 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 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 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 :

• au Client de jeu, pour gérer les Tickets de joueur,

• au Serveur de jeu, pour :

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

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

Côté Client de jeu, nous recommandons de fournir des mises à jour sur l'état des tickets tout au long du Processus de matchmaking aux joueurs via l'interface du jeu pour une expérience optimale. Voir :

• Edgegap - Unity Gen2 Matchmaking SDK,

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

• Betide Studio - Unreal Engine Edgegap Integration Kit,

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

Dans le Client de jeu, assurez-vous de gérer les erreurs non reproductibles :

• 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 d'API n'est requise :

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

2. Lisez les Variables d'environnement injectées (Versions d'application) pour les paramètres propres à la version, les configurations (capacité des joueurs) et les secrets.

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 les joueurs connectés, le Serveur de jeu et les Clients de jeu lancent une scène de chargement pour effectuer les étapes de synchronisation (par exemple, la sélection et le chargement d'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 l'avancement de l'initialisation.

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

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

Assurez-vous que votre déploiement sera arrêté correctement à l'aide de l'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 tous les détails dans notre Centre d'apprentissage.