Server Browser
Commencez rapidement avec Server Browser et explorez des scénarios d'exemple pour divers genres.
Server Browser est un service géré pour Déploiements et Persistants serveurs :
aider les joueurs à rechercher et à rejoindre les serveurs appropriés en fonction de la capacité, de la latence ou des paramètres de jeu ;
préchauffer les nouveaux serveurs afin de servir des audiences mondiales à grande échelle et d'éviter des files d'attente frustrantes ;
simplifier les opérations serveur notamment les mises à jour, les redémarrages, la persistance, le meshing, et plus encore.
Vous cherchez à faire correspondre les joueurs selon des règles strictes, sans leur permettre de choisir un serveur ? Envisagez Matchmaking.
✔️ Préparation
Fonctions et flux

Server Browser offre deux fonctionnalités principales :
Server Browser avec les clients de jeu pour :
Découvrir et trouver des instances de serveur appropriées, voir les emplacements et réserver la capacité disponible.
Réserver des places dans un emplacement d'instance, récupérer les détails de connexion et se connecter aux serveurs.
Authentifier les connexions des joueurs dans les déploiements à l'aide de Identité fédérée.
Mettre à jour la capacité disponible et/ou les métadonnées des emplacements d'instance afin de modifier les critères de découverte.
Server Browser (facultatif) avec les politiques de mise à l'échelle pour :
Surveiller les instances de serveur, les emplacements et la capacité disponibles - par région et/ou selon d'autres critères.
Déployer des serveurs pour augmenter la capacité grâce au préchauffage ou à la mise à l'échelle juste-à-temps.
Automatiser les opérations avec des politiques spéciales pour les démos, les mises à jour, les tests, l'assurance qualité, les tournois, et plus encore.
Après la publication, votre navigateur de serveurs devra fonctionner 24 h/24 et 7 j/7 pour garantir que les joueurs du monde entier puissent rejoindre les serveurs.
▶️ Commencer la navigation
Découvrez le cycle de vie serveur/joueur et leurs responsabilités afin d'assurer une utilisation efficace des serveurs.
Authentifier
Server Browser génère automatiquement deux types de jetons :
Jeton serveur - requis pour API serveur méthodes, peut être injecté comme variable de version de l'application.
Accorde l'accès à toutes les méthodes de l'API et est pratique pour les tests, le DevOps ou l'orchestration personnalisée.
Jeton client - requis pour API de surveillance et API de réservation de places utilisé par les clients de jeu.
Nous recommandons de stocker ce jeton dans un coffre-fort de secrets tiers afin de faciliter la rotation des jetons.
Découvrir une instance
Nouveau Déploiements doit créer une nouvelle instance lorsqu'elle est initialisée pour suivre la capacité ajoutée.
Voir Server Browser pour en savoir plus sur les politiques de mise à l'échelle et lancer automatiquement les déploiements.
Informations requises pour chaque instance de serveur comprend :
au moins un emplacement défini lors de l'initialisation de l'instance,
les détails de connexion au serveur - URL, IP, informations de port et emplacement.
Paramètres de métadonnées personnalisées facultatifs pour filtrer, trier et parcourir les joueurs ; par exemple :
informations d'emplacement - capacité d'équipe et métadonnées spécifiques à l'équipe (par ex. nom de l'équipe),
nom et balises - libellés personnalisables, uniques, lisibles par l'humain et recherchables ;
données de compatibilité - version du serveur ou versions client prises en charge ;
qualificatifs de latence - identifiants de ville et de région, et Balises Ping détails attribués ;
paramètres de jeu - niveau/scène/carte, mode de jeu, difficulté, mods utilisés ;
tout autre paramètre personnalisé pour aider les joueurs à filtrer et à trouver un serveur approprié.
Les paramètres de métadonnées ci-dessus ne sont que des exemples ; vous pouvez définir autant de paramètres que nécessaire.
Pour sérialiser des objets imbriqués, essayez d'encoder leur chemin d'accès dans la clé comme "object.child.property".
Les serveurs peuvent mettre à jour les métadonnées de l'instance ou de l'emplacement à tout moment pour modifier leurs critères de découvrabilité. Lors de la mise à jour des métadonnées, toutes les clés indexées doivent être fournies avec des valeurs valides (même si elles ne sont pas modifiées).
Les instances de serveur doivent envoyer périodiquement un battement de cœur de maintien en vie pour vérifier leur disponibilité continue et empêcher les joueurs de rejoindre des serveurs plantés ou hors ligne. L'absence de battement de cœur pendant la période d'expiration configurée supprimera automatiquement l'instance et toute réservation de place en attente.
Voir Persistance pour gérer l'état persistant du monde et Applications et versions pour des déploiements plus rapides.
Allouer la capacité
La capacité de l'instance et de l'emplacement peut être allouée de deux façons, utilisées individuellement ou combinées :
Server Browser pour choisir un serveur lancé avec une politique de mise à l'échelle spécifique,
Server Browser pour permettre au joueur de définir des filtres et de parcourir des serveurs appropriés parmi lesquels choisir.
Nous recommandons de commencer par Server Browser comme option la plus simple.
Réservation attribuée automatiquement
Implémentez cette fonctionnalité si vous souhaitez choisir automatiquement un serveur, en fonction de la capacité régionale.
Les joueurs peuvent créer une réservation attribuée automatiquement, en ne fournissant que les identifiants des joueurs et le nom d'une politique de mise à l'échelle. Server Browser trouvera automatiquement une instance avec un emplacement offrant une capacité de participation suffisante et réservera des places, en répondant immédiatement avec les détails de connexion de l'instance.
S'il n'existe aucun emplacement d'instance approprié pour cette réservation, la réponse :
le code d'état indique si la politique est en train d'augmenter la capacité et davantage de capacité sera ajoutée,
en-tête
Retry-Afterindique la période d'attente (en secondes) avant une nouvelle tentative, si une nouvelle tentative est possible.
Une fois la réservation terminée, vous pouvez passer à Server Browser.
Rechercher et parcourir
Implémentez cette fonctionnalité si vous souhaitez afficher aux utilisateurs une liste de serveurs et permettre des réservations personnalisées.
Les joueurs peuvent lister des instances de serveur et parcourir les résultats par pages pour trouver un serveur qu'ils aimeraient rejoindre.
Les instances et les emplacements peuvent être filtrés et triés avec des paramètres intégrés ou des métadonnées indexées:
request_id
chaîne
✅
❌
total_joinable_seats, total_available_seats
entier
✅
❌
name
chaîne
❌
✅
available_seats, reserved_seats
entier
❌
✅
created_at, updated_at
chaîne
✅
✅
metadata.{index} (personnalisé)
chaîne, entier, flottant, booléen
✅
✅
Les opérateurs de filtrage disponibles dépendent du type de données de la propriété filtrée :
chaîne
eq ou ne ou
lt ou le ou
gt ou ge ou
contient
entier, flottant
eq ou ne ou
lt ou le ou
gt ou ge
booléen
eq ou ne
Filtrez les métadonnées des régions et/ou des villes pour réduire la sélection avant de mesurer la latence des serveurs.
Découvrez le fonctionnement basé sur un curseur Pagination pour permettre aux utilisateurs de récupérer davantage de résultats.
Réserver des places
Avant de rejoindre un serveur, une réservation de place est requise pour garantir que l'instance offre une capacité disponible suffisante. Les réservations peuvent inclure un groupe de joueurs ou une personne seule.
Identité fédérée : les joueurs doivent fournir un identifiant unique de joueur tiers dans leur réservation. En envoyant le même identifiant une fois qu'ils Server Browser auront permis au serveur de vérifier leur identité.
Une fois qu'une réservation est effectuée avec succès (200 OK) les joueurs doivent tenter de se connecter immédiatement. En attente les réservations expirent après 30 secondes (configurable) sauf confirmation par votre serveur.
Les réservations dépassant la capacité de places joignables de l'emplacement seront automatiquement rejetées (409 Conflict). Les places joignables sont toutes les places disponibles qui n'ont pas encore été réservées par d'autres joueurs.
Le serveur peut forcer la modification de la capacité de n'importe quel emplacement, ajouter, supprimer ou mettre à jour n'importe quels emplacements. Toutes les réservations pour un emplacement donné seront supprimées si des réservations en attente dépassent la nouvelle capacité disponible de l'emplacement.
Se connecter au serveur
Une fois qu'un joueur a trouvé une instance appropriée, il récupère les détails de connexion requis depuis (URL ou IP, Port externe). Dès que la réservation de place est effectuée, les joueurs peuvent se connecter au serveur de jeu de votre déploiement et transmettre leur identifiant de joueur.
Pour se connecter depuis PIE (éditeur) pendant le développement et les tests, appuyez sur la touche tilde ~ et tapez open {URL}:{port} et attendez que votre éditeur charge la carte.
En cas d'échec de connexion ou d'écran noir, consultez notre guide de dépannage.
Pour connectez votre éditeur Unity ou client de jeu à votre déploiement cloud, saisissez :
Déploiement URL pointant vers l'IP du serveur, généralement dans le
NetworkManagercomposant.Port externe mappé vers le port d'écoute interne du serveur, généralement dans un composant Transport.
En cas de délai de connexion dépassé ou d'autres problèmes, consultez notre guide de dépannage.
Pour authentifier de nouvelles connexions, votre serveur doit envoyer une confirmation de réservation en bloc avec tous les identifiants des nouveaux joueurs, en recevant les informations dans la réponse de confirmation :
affectation des réservations de joueurs acceptées à leur emplacement préféré,
affectation des réservations de joueurs expirées à leur emplacement préféré,
une liste d'identifiants de joueurs inconnus.
Votre serveur peut décider comment traiter chaque groupe de joueurs et s'il faut autoriser ou expulser/bannir les utilisateurs expirés ou rejetés. Chacun des emplacements de l'instance doit être mis à jour immédiatement avec le nouveau nombre de places disponibles afin de garantir que les réservations futures ne dépasseront pas la capacité de l'emplacement.
Abandonner le serveur
Lorsque les joueurs quittent la partie, votre serveur doit augmenter la capacité de places disponibles pour l'emplacement attribué.
Si la conception de votre jeu autorise une période de reconnexion, votre serveur peut attendre avant de mettre à jour les emplacements.
En savoir plus sur Persistance pour éviter des retours arrière persistants frustrants du serveur.
🚀 Mise à l'échelle automatique
Server Browser est compatible avec plusieurs méthodes différentes de mise à l'échelle automatique :
méthode de préchauffage - démarrer les serveurs uniquement avec des politiques de mise à l'échelle Server Browser,
méthode juste-à-temps - démarrer via Matchmaking et remplir avec Server Browser,
autoscaler personnalisé - démarrer via un backend de jeu personnalisé et remplir avec Server Browser.
Le guide suivant se concentrera sur le préchauffage avec des politiques de mise à l'échelle comme méthode principale.
Découvrez comment arrêter les déploiements dans Unreal Engine, Unity, ou avec l'API pour gérer le cycle de vie de manière fiable.
Surveiller la capacité
Les politiques de mise à l'échelle actualisent en continu la liste de vos instances de serveur (déploiements découverts), en se répétant toutes les monitoring_interval . Chaque politique nécessite un filtre utilisant la même syntaxe de filtrage que celle utilisée par les joueurs lorsqu'ils recherchent des instances - par région, capacité ou autres critères.
Votre minimum_active_instances montant peut être considéré soit comme une :
capacité fixe de déploiements que vous souhaitez maintenir en fonctionnement en permanence,
veille préchauffée tampon de déploiement pour masquer les délais d'initialisation.
Capacité fixe
Conservez un nombre fixe de serveurs actifs pour les jeux avec Persistance, en particulier lorsque ces jeux offrent aux joueurs la possibilité de provisionner Persistance.
Ce type de configuration de politique est également parfois utilisé pour l'assurance qualité, les tournois, les alphas fermées, les démos d'éditeur ou d'autres types d'événements et d'opérations à capacité limitée.
Une politique de mise à l'échelle vous aide à redémarrer et à recycler automatiquement les serveurs plantés à la volée.
Veille préchauffée
Démarrez les serveurs avant la demande des joueurs si :
vous lancez une grande sortie et vous attendez un afflux rapide de joueurs sur une courte période,
ou l'initialisation du serveur nécessite plus de 30 secondes (sans compter le temps de déploiement),
ou le jeu met en œuvre des stratégies de maillage nécessitant des dépendances réseau en couches ou circulaires.
Déployer des serveurs
De nouveaux déploiements seront lancés automatiquement lorsque la quantité d'instances de serveur surveilléess tombe en dessous du minimum configuré d'instances actives. Tous les déploiements sont demandés immédiatement et réessayés indéfiniment à chaque intervalle de surveillance après deployment_registration_period écoulé.
Vérifiez que les nouveaux déploiements effectuent l'auto-découverte et créent des instances correspondant correctement à votre filtre de politique, sinon votre politique peut boucler indéfiniment et créer de grandes quantités de déploiements inutilisés!
Les politiques lancent les déploiements avec Flottes privées (avec Overflow to Cloud) ou directement vers Cloud.
Les paramètres disponibles incluent (voir la spécification de l'API):
application et version - version de build, ressources et autres paramètres d'orchestration,
utilisateurs - un seul ensemble de coordonnées géographiques pour le placement du serveur,
identifiants d'hôtes privés - laisser vide pour le cloud, ou spécifier des hôtes dans la région souhaitée,
balises - baliser avec le nom de la politique pour retrouver plus tard les déploiements lancés avec cette politique,
variables d'environnement - transmettre des paramètres personnalisés et des secrets aux serveurs,
webhooks - notifier votre backend de jeu (ou votre matchmaker) des événements du cycle de vie des déploiements,
exiger des emplacements mis en cache - si vous préférez des déploiements plus rapides uniquement dans des emplacements mis en cache.
Exemples de politiques
Testez et modifiez chacune de ces politiques selon vos besoins. La plupart des jeux utiliseront plusieurs politiques.
Une politique simple pour maintenir en permanence un serveur déployé pour les tests.
Lancez 10 déploiements avant la mise en production en anticipation de la demande. À copier pour chaque région.
Chaque région ajoute des déploiements lorsque la capacité disponible passe sous un seuil.
Une politique par propriétaire de serveur, avec un mot de passe personnalisé utilisé pour l'authentification du serveur.
Une politique par groupe de serveurs. Le backend du jeu démarre un nœud principal, qui crée des réplicas. Chaque nœud lit l'identifiant du groupe maillé injecté et recherche d'autres nœuds avec lesquels se mettre en réseau.
⚙️ Configuration
L'API Server Browser est générée à partir d'une configuration JSON spécifiée lorsque vous créez un nouveau Server Browser (ou lors d'un redémarrage rapide). Vous pouvez définir l'expiration des serveurs et des emplacements, ainsi que des métadonnées personnalisées :
Pour des performances optimales, évitez de spécifier des indices pour les métadonnées qui ne sont pas utilisées pour le filtrage ou le tri. Les paramètres non indexés peuvent toujours être définis et lus avec les méthodes API de détails de l'instance de serveur ou de l'emplacement, voir 📗 API.
☁️ Cluster d'hébergement
Server Browser est hébergé et géré de manière pratique 24 h/24, 7 j/7 par Edgegap.
Choisissez l'option d'hébergement la mieux adaptée à votre objectif :
Niveaux de cluster privé
Passez à un cluster privé en un clic pour bénéficier d'un hébergement hautement disponible, maintenu par l'équipe d'Edgegap, avec une assistance en direct 24 h/24, 7 j/7 pour les jeux publiés.
Les besoins en ressources de votre instance dépendront des facteurs suivants :
nombre de joueurs - plus de joueurs entraînent davantage de requêtes API,
nombre de requêtes par joueur - des tentatives plus rapides augmentent la charge du service et consomment des ressources,
nombre de serveurs - plus de serveurs entraînent davantage de données stockées et davantage de requêtes API,
logique de repli des nouvelles tentatives côté client - le fait de réessayer avec un backoff à délai aléatoire aide à répartir les pics de trafic,
durée moyenne d'une partie - des sessions plus courtes nécessitent des interactions plus fréquentes avec Server Browser.
📗 API
Envisagez d'utiliser notre SDK pour Unreal Engine ou Unity pour démarrer rapidement avec des exemples prédéfinis.
Les clients de jeu et les serveurs dédiés envoient des requêtes API tout au long de leur cycle de vie à Server Browser.
Importez la spécification de l'API dans Scalar API Web Client ou Swagger Editor pour examiner les détails.
Pagination
Server Browser fournit une pagination par curseur pour récupérer progressivement les données filtrées dans un ordre précis. Cette approche nécessite d'envoyer un curseur (point de départ) et une taille de page (nombre d'éléments de réponse) chaque fois que l'on récupère davantage de résultats, contrairement à la pagination traditionnelle par limite et décalage.
Associée à notre système propriétaire d'indexation de base de données développé pour les métadonnées des serveurs de jeu, la pagination par curseur offre une expérience utilisateur rapide, cohérente et flexible pour filtrer des données très dynamiques.
Notre objectif est que les utilisateurs trouvent un serveur adapté sur la première page. Pour une meilleure expérience, nous recommandons d'afficher les résultats mis en cache des pages précédentes et de rafraîchir les résultats uniquement lorsque l'utilisateur clique sur Rechercher.
🔖 Journal des modifications
La dernière version de Server Browser est 1.0.0 . Surveillez les mises à jour et les annonces.
Mis à jour
Ce contenu vous a-t-il été utile ?

