For the complete documentation index, see llms.txt. This page is also available as Markdown.

Navigateur de serveurs

Démarrez rapidement avec le Navigateur de serveurs et explorez des scénarios d'exemple pour divers genres.

Le Navigateur de serveurs est un service géré pour Déploiements et Persistant serveurs:

  • aider les joueurs à rechercher et rejoindre des serveurs adaptés en fonction de la capacité, de la latence ou des paramètres du jeu ;

  • préchauffer de nouveaux serveurs pour servir des audiences mondiales à grande échelle et éviter des files d'attente frustrantes ;

  • simplifier les opérations des serveurs y compris les mises à jour, les redémarrages, la persistance, le maillage et plus encore.

✔️ Préparation

Tester ce service est entièrement gratuit, aucune carte de crédit requise.

Le niveau gratuit permet jusqu'à 3 heures d'exécution sur notre cluster de test partagé, après chaque redémarrage.

Ce tutoriel suppose que vous avez déjà :

Fonctions et déroulement

Navigateur de serveurs : déroulement et hiérarchie

Le Navigateur de serveurs offre deux fonctionnalités principales :

Navigateur de serveurs avec les clients de jeu pour :

  • Découvrir et trouver des instances de serveur adaptées, afficher les emplacements et réserver la capacité disponible.

  • Réserver des sièges 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.

Navigateur de serveurs (facultatif) avec les politiques de mise à l'échelle pour :

  • Surveiller les instances de serveur disponibles, les emplacements et la capacité - par région et/ou selon d'autres critères.

  • Déployer des serveurs pour augmenter la capacité avec du préchauffage ou une mise à l'échelle juste à temps.

  • Automatisez 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 sortie, votre navigateur de serveurs devra fonctionner 24 h/24, 7 j/7 afin de garantir que les joueurs du monde entier puissent rejoindre les serveurs.

▶️ Commencer à parcourir

Découvrez le cycle de vie serveur/joueur et leurs responsabilités afin d'assurer une utilisation efficace des serveurs.

Authentifier

Toutes les requêtes doivent envoyer un Autorisation entête HTTP avec votre secret Jeton d'authentification :

Le Navigateur de serveurs génère automatiquement deux types de jetons :

Découvrir l'instance

Voir Navigateur de serveurs pour en savoir plus sur les politiques de mise à l'échelle et lancer automatiquement les déploiements.

Informations requises pour chaque instance de serveur incluent :

  • 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 le filtrage, le tri et la navigation des joueurs ; par exemple :

  • informations sur l'emplacement - capacité de l'équipe et métadonnées spécifiques à l'équipe (par ex. nom de l'équipe),

  • nom et balises - étiquettes 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 de ping détails ;

  • paramètres du 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 adapté.

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.

Les serveurs peuvent mettre à jour à tout moment les métadonnées de l'instance ou de l'emplacement 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 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 siège en attente.

Voir Persistance pour gérer l'état persistant du monde et Applications et versions pour des déploiements plus rapides.

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

  • Navigateur de serveurs pour choisir un serveur démarré avec une politique de mise à l'échelle spécifique,

  • Navigateur de serveurs pour permettre au joueur de définir des filtres et de parcourir les serveurs adaptés parmi lesquels choisir.

Réservation à attribution automatique

Implémentez cette fonctionnalité si vous souhaitez choisir automatiquement le serveur, en fonction de la capacité régionale.

Les joueurs peuvent créer une réservation à attribution automatique, en fournissant uniquement les IDs des joueurs et le nom d'une politique de mise à l'échelle. Le Navigateur de serveurs trouvera automatiquement une instance avec un emplacement offrant une capacité joignable 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 adapté pour cette réservation, la réponse :

  • le code de statut indique si la politique est en cours de montée en capacité et davantage de capacité sera ajoutée,

  • en-tête Retry-After indique le temps d'attente (en secondes) avant de réessayer, si la requête peut être retentée.

Une fois une réservation effectuée, vous pouvez passer à Navigateur de serveurs.

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 les instances de serveur et paginer dans les résultats 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 métadonnées indexées:

Propriété
Type de données
Instance
Emplacement

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 :

Paramètre
Opérateurs
Exemple de filtre (basé sur l'exemple simple)

chaîne

égal à ou différent de ou

inférieur à ou inférieur ou égal à ou

supérieur à ou supérieur ou égal à ou contient

entier, flottant

égal à ou différent de ou

inférieur à ou inférieur ou égal à ou

supérieur à ou supérieur ou égal à

booléen

égal à ou différent de

Découvrez le filtrage basé sur le 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 nécessaire pour garantir que l'instance offre une capacité disponible suffisante. Les réservations peuvent inclure un groupe de joueurs ou une seule personne.

Identité fédérée : les joueurs doivent fournir un identifiant unique de joueur tiers dans leur réservation. Envoyer le même ID une fois qu'ils Navigateur de serveurs permettra au serveur de vérifier leur identité.

Une fois une réservation effectuée avec succès (200 OK) les joueurs doivent tenter de se connecter immédiatement. Les réservations en attente 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 modifier de force la capacité de n'importe quel emplacement, ainsi qu'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 adaptée, il récupère les détails de connexion requis à partir de (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 ID 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.

Pour authentifier les nouvelles connexions, votre serveur doit envoyer une requête de confirmation de réservation en masse avec les IDs de tous les 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'IDs de joueurs inconnus.

Votre serveur peut décider comment gérer chaque groupe de joueurs et s'il faut autoriser ou expulser/interdire 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 pour garantir que les réservations futures ne dépasseront pas la capacité de l'emplacement.

Abandonner le serveur

Lorsque les joueurs quittent, votre serveur doit augmenter la capacité de places disponibles pour l'emplacement attribué.

Lisez Persistance pour éviter des retours en arrière persistants frustrants sur le serveur.

🚀 Mise à l'échelle automatisée

Le Navigateur de serveurs est compatible avec plusieurs méthodes différentes de mise à l'échelle automatique :

Le guide suivant se concentrera sur le préchauffage avec les politiques de mise à l'échelle comme méthode principale.

Surveiller la capacité

Les politiques de mise à l'échelle actualisent en continu la liste de vos instances de serveur (déploiements découverts), en répétant toutes les monitoring_interval . Chaque politique nécessite un filtre utilisant la même syntaxe de filtrage que les joueurs lorsqu'ils recherchent des instances - par région, capacité ou autre critère.

Votre minimum_active_instances quantité peut être considérée soit comme une :

  • capacité fixe de déploiements que vous souhaitez maintenir en cours d'exécution en permanence,

  • veille de préchauffage tampon de déploiements pour masquer les délais d'initialisation.

Capacité fixe

Conservez une quantité fixe de serveurs actifs pour les jeux avec Persistance, Persistance.

Ce type de configuration de politique est aussi 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 de préchauffage

Démarrez les serveurs avant la demande des joueurs si :

  • vous lancez une grosse version et vous attendez un afflux rapide de joueurs en peu de temps,

  • ou si l'initialisation du serveur nécessite plus de 30 secondes (hors temps de déploiement),

  • ou si le jeu implémente 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 le nombre d'instances de serveur surveilléess descend 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é.

Les politiques lancent des déploiements avec Flottes privées (avec Overflow to Cloud) ou directement dans le 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 ensemble unique de coordonnées géographiques pour le placement du serveur,

  • IDs d'hôtes privés - laissez vide pour le Cloud, ou spécifiez des hôtes dans la région souhaitée,

  • balises - étiquetez avec le nom de la politique pour retrouver plus tard les déploiements lancés avec cette politique,

  • variables d'environnement - transmettez des paramètres et des secrets personnalisés aux serveurs,

  • webhooks - avertissez votre backend de jeu (ou votre système de matchmaking) des événements du cycle de vie du déploiement,

  • exiger des emplacements mis en cache - si vous préférez des déploiements plus rapides uniquement dans les emplacements mis en cache.

Politiques d'exemple

Testez et modifiez ces politiques selon vos besoins. La plupart des jeux utiliseront plusieurs politiques.

Une politique simple pour conserver en permanence un serveur déployé pour les tests.

⚙️ 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 le redémarrez rapidement). Vous pouvez spécifier l'expiration des serveurs et des emplacements, ainsi que des métadonnées personnalisées :

Pour de meilleures performances, é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 des 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 et 7 j/7 par Edgegap.

Choisissez l'option d'hébergement la mieux adaptée à votre objectif :

  • Cluster gratuit (partagé) pour tester toutes les fonctionnalités et explorer les synergies avec votre conception,

    • s'éteint automatiquement après 3 heures, nécessitant un redémarrage pour continuer les tests.

  • Cluster privé (dé dédié) pour garantir un environnement stable pour vos besoins de production,

    • choisissez votre région et obtenez un support 24/7 pour les jeux en direct afin de publier en toute confiance.

Niveaux de cluster privé

Nous proposons actuellement 3 niveaux de cluster privé pour répondre aux besoins de chacun :

Niveau
Niveau Hobbyiste
Niveau Studio
Niveau Entreprise

Le mieux adapté pour

les passionnés, les développeurs solo

les lancements commerciaux

les lancements à fort trafic

Ressources

1 vCPU + 2 Go de RAM

6 vCPU + 12 Go de RAM

18 vCPU + 48 Go de RAM

Redondance

1 nœud virtuel

3 nœuds virtuels

3 nœuds virtuels

Limite de débit (req/s)

200

750

2,000

Prix, à l’heure

$0.0312

$0.146

$0.548

Prix, sur 30 jours (utilisation sans interruption)

$22.464

$105.12

$394.56

Passez à un cluster privé en un clic pour bénéficier d'un hébergement hautement disponible, maintenu par l'équipe Edgegap avec une assistance en direct 24 h/24 et 7 j/7 pour les jeux publiés au public.

Les besoins en ressources de votre instance dépendront des facteurs suivants :

  • nombre de joueurs - davantage 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 - davantage de serveurs entraînent davantage de données stockées et davantage de requêtes API,

  • logique de repli des nouvelles tentatives du client - réessayer avec un backoff à jitter aide à répartir les pics de trafic,

  • durée moyenne d'une partie - des sessions plus courtes nécessitent une interaction plus fréquente avec le navigateur de serveurs.

Nos clusters utilisent des machines cloud équipées de processeurs AMD/Intel avec une fréquence d'horloge de 2,4 à 3,2 GHz.

📗 API

Envisagez d'utiliser notre SDK pour Unreal Engine ou Unity pour démarrer rapidement avec des exemples prêts à l'emploi.

Les clients de jeu et les serveurs dédiés envoient des requêtes API tout au long de leur cycle de vie vers Server Browser.

Unity/Android - envisager d'utiliser l'interpolation de chaîne brute pour empêcher la suppression de code des JSON codés en dur.

Importez la spécification de l'API dans le client Web Scalar API ou Swagger Editor pour examiner les détails.

Limites de débit

Pour protéger votre cluster contre le dépassement de sa capacité de pointe et les plantages, nous limitons le nombre de requêtes client par seconde, par adresse IP publique du client.

La limite est configurée par ⚙️ Configuration le paramètre rate_limits.per_client_ip.

Tests de charge

Les tests de charge dans un environnement similaire à la production entraînent un coût d’hébergement du déploiement. Consultez les ressources et les prix associés à chaque niveau sur notre page de tarification.

Lors de la conception de votre test de charge, veuillez prendre en compte des comportements de joueurs réalistes:

Scénario réaliste
Schéma de trafic irréaliste

✅ Les joueurs rejoignent la partie progressivement, augmentant les requêtes/s sur plusieurs heures.

❌ Tous les joueurs se coordonnent et sollicitent l’API exactement à la même seconde.

✅ Les joueurs attendent un temps croissant entre leurs nouvelles tentatives (p. ex. 1 s - 5 s - 10 s - 10 s).

❌ Tous les joueurs réessaient immédiatement après avoir reçu 429 Trop de requêtes la réponse.

✅ La plupart des joueurs recevront leur affectation en peu de temps (10 à 60 s) et cesseront d’interroger le serveur.

❌ Tous les joueurs continuent d’interroger le serveur pendant une durée déterminée même après avoir reçu leur affectation.

✅ La plupart des joueurs terminent leur partie (en prenant du temps) avant de redémarrer une nouvelle session.

❌ Tous les joueurs redémarrent immédiatement leur session dès qu’ils reçoivent l’affectation du serveur.

✅ Le trafic de pointe est maintenu pendant environ 6 heures par jour, après quoi certains fuseaux horaires se déconnectent.

❌ Le trafic de pointe est maintenu 24 heures sur 24, avec tous les joueurs jouant jour et nuit.

Comportement sous charge

Si un client atteint la limite de débit configurée par IP, il reçoit une 429 Trop de requêtes réponse et est censé réessayer avec un délai de backoff croissant.

Si les politiques de mise à l'échelle déclencheraient plus de déploiements que la limite req/s autorisée de votre organisation, votre navigateur de serveurs réessaiera automatiquement à chaque intervalle de surveillance, en utilisant une stratégie de round-robin pondéré basée sur le nombre de déploiements prévus, afin de répartir équitablement le quota de déploiement disponible entre toutes les politiques de mise à l'échelle.

Pagination

Server Browser fournit une pagination par curseur pour récupérer progressivement des données filtrées dans un ordre spécifique. 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 récupération de résultats supplémentaires, 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 hautement dynamiques.

Notre objectif est que les utilisateurs trouvent un serveur adapté dès 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 ne rafraîchir les résultats que lorsque l'utilisateur clique sur Rechercher.

🔖 Journal des modifications

Versionnage sémantique

Nos outils de développement et nos services managés utilisent les officielles Versionnage sémantique, indiquant quelles mises à jour sont ✅ sûres (mineures, correctifs) et lesquelles peuvent contenir des ⚠️ changements incompatibles (majeurs).

Une fois qu'une version est publiée, elle ne sera jamais modifiée/changée.

La dernière version de Server Browser est 1.0.0 . Restez à l'affût de mises à jour et annonces.

Mis à jour

Ce contenu vous a-t-il été utile ?