Déploiements
En savoir plus sur les déploiements et leur cycle de vie - concepts et bonnes pratiques pour une compréhension approfondie.
🗺️ Orchestration
Démarrez de nouveaux serveurs en quelques secondes pour répondre aux besoins en capacité grâce à notre approche cloud native d’edge computing. Nous considérons les serveurs comme du bétail plutôt que comme des animaux de compagnie - en remplaçant entièrement les instances défaillantes au lieu de s’occuper manuellement de chacune d’elles.
Votre choix d’orchestration va avoir un impact sur votre coût DevOps, le coût des serveurs et la scalabilité.
Contactez-nous sur Discord pour en savoir plus sur les options d’orchestration hybrides et optimiser vos coûts d’hébergement.
Pour bien comprendre tous les avantages et inconvénients, comparons différentes méthodes d’orchestration.
Match-Bound
La référence pour les studios modernes offrant l’intégration la plus simple avec le meilleur rapport coût-efficacité.
👍 Avantages
Meilleur rapport coût-efficacité - mise à l’échelle en temps réel pour répondre à la demande des joueurs minute par minute.
Coût DevOps le plus faible grâce à un hébergement sans région, Edgegap automatise 99 % des tâches.
Ping le plus faible grâce à plus de 615 sites dans l’infrastructure cloud publique d’Edgegap.
Mise à l’échelle la plus rapide (capacité de pointe) en cas de pic de trafic inattendu.
Niveau de sécurité et de prévention de la triche des joueurs le plus élevé (autorité serveur).
Impact minimal d’un crash serveur inattendu sur les joueurs, n’affectant qu’un seul match.
👎 Inconvénients
L’adoption d’un nouveau modèle mental d’orchestration nécessite au départ un certain effort d’apprentissage.
Les serveurs fonctionnant plus de 24 heures seront automatiquement arrêtés.
🧩 Particulièrement adapté pour
Les jeux sensibles à la latence - lorsque l’optimisation du netcode ne peut pas surmonter un ping élevé :
FPS, jeux de combat, VR et XR (réalité virtuelle et réalité étendue), …
Les jeux avec une limite supérieure de durée de match par conception,
Battle Royale, PvPvE, jeux de tir coopératifs, MOBA, jeux de sport, ARPG et dungeon crawlers, …
🔎 Découvrabilité
Démarrer de nouvelles parties lorsque suffisamment de joueurs rejoignent Appariement.
Ajouter des joueurs pour remplacer les joueurs qui quittent les matchs existants grâce au backfill.
Permettre aux joueurs de parcourir les serveurs et d’en choisir un dans une liste avec Navigateur de serveurs.
Edgegap fait automatiquement évoluer à la hausse/à la baisse tous les 615+ emplacements de serveurs en fonction de l’activité des joueurs dans chaque région. Préparez-vous au succès - montez en charge jusqu’à 14 millions d’utilisateurs concurrents en 60 minutes.
Veille régionale
Modèle traditionnel pour mondes persistants avec contenu généré par les utilisateurs et jeux MMO sociaux.
👍 Avantages
Familier et facile à comprendre, approche à l’ancienne pour les vétérans endurcis.
Niveau de sécurité et de prévention de la triche des joueurs le plus élevé (autorité serveur).
Coût facilement prévisible basé sur un engagement mensuel.
👎 Inconvénients
Coût d’hébergement plus élevé - chaque région nécessite un ou plusieurs serveurs de veille inactifs (capacité de pointe).
Coût DevOps plus élevé - mise à l’échelle, opérations et maintenance dupliquées par région.
Les régions avec une base de joueurs plus réduite subissent un ping élevé en raison de la connexion à des serveurs éloignés.
🧩 Particulièrement adapté pour
Mondes persistants avec contenu généré par les utilisateurs stocké sur le serveur même lorsque les joueurs se déconnectent.
MMO, sandbox avec construction de base ou placement d’objets, extraction shooters, ...
jeux tolérants à la latence - lorsque la physique en temps réel sous autorité serveur n’est pas requise:
jeux mobiles, jeux coopératifs, TCG/CCG, stratégies au tour par tour, …
Multijoueur asynchrone, où les crashs serveur ont un impact minimal sur l’expérience des joueurs :
courir contre des fantômes, piller une base ennemie, jeux de construction/agriculture basés sur des temporisateurs, …
applications avec un processus d’initialisation lourd - lorsque la préparation des serveurs prend plusieurs minutes.
🔎 Découvrabilité
Permettre aux joueurs de parcourir les serveurs et d’en choisir un dans une liste avec Navigateur de serveurs.
Voir Clusters gérés pour l’hébergement autonome de vos microservices et services backend sur Edgegap.
Pair à pair
Réorientez les efforts de développement des serveurs dédiés vers le netcode relais pour les jeux non compétitifs.
Sujets connexes : serveurs d’écoute, autorité côté joueur, traversée NAT.
👍 Avantages
Coût d’hébergement le plus faible, nécessitant uniquement des serveurs relais pour résoudre la traversée NAT.
Coût DevOps le plus faible - maintenance requise uniquement pour les builds clients et les canaux de distribution.
Impact minimal d’un crash serveur inattendu sur les joueurs, n’affectant qu’un seul match.
Facile à mettre en œuvre et rapide à prototyper, sans aucun développement backend requis.
👎 Inconvénients
Effort de développement netcode pair à pair accru nécessitant des compétences en programmation concurrente.
Les pires temps de ping et la plus grande sensibilité aux conditions réseau défavorables (par exemple Internet mobile).
Sécurité la plus faible, vulnérable aux attaques de l’homme du milieu et au détournement de session.
Risque de perte de session lorsque l’hôte quitte, sauf si vous implémentez une migration d’hôte personnalisée.
🧩 Particulièrement adapté pour
Jeux coopératifs et casual - lorsque la triche ne gâche pas le plaisir ni ne casse le jeu,
Jeux pour enfants, jeux d’exploration, aventures, …
🔎 Découvrabilité
Voir notre Relais distribués pour un service permettant le pair à pair avec la meilleure latence et la meilleure sécurité de sa catégorie.
📍 Placement des serveurs
Quelle que soit la méthode d’orchestration choisie, sélectionner le bon emplacement de serveur pour un groupe de joueurs est essentiel pour garantir le meilleur ping possible et une expérience optimale pour les joueurs. Découvrez différentes stratégies de placement des serveurs et leur impact sur vos joueurs.
Votre stratégie de placement des serveurs va avoir un impact sur l’expérience de vos joueurs, leur rétention et les avis sur votre jeu.
Edgegap déploie dans le meilleur emplacement possible avec capacité disponible, pour des matchs rapides et à faible latence.
Voir Déploiements vers analyser le placement des serveurs en temps réel, à grande échelle.
Score du serveur
La stratégie de score du serveur utilise la méthodologie brevetée d’Edgegap, qui optimise individuellement le placement des serveurs pour chaque match. Effectue une télémétrie non intrusive pour approximer la proximité réseau de chaque joueur par rapport à nos emplacements de serveurs et choisir le serveur qui offre le meilleur :
réactivité - fournit le ping moyen le plus faible pour tous les joueurs,
équité - fournit un ping équilibré et équitable pour tous les joueurs.
Notre Matchmaker utilise par défaut la stratégie de score du serveur, afin de garantir la meilleure expérience possible. Pour utiliser cette stratégie avec les API de déploiement, indiquez les IP publiques des joueurs ou leurs coordonnées géographiques dans votre requête de déploiement.
Placement non réactif - le serveur est loin, ping élevé pour tous les joueurs :
Placement injuste - ping inégal, un joueur est désavantagé :
Exemple de bon placement - ping réactif et équitable pour tous les joueurs :
Cette stratégie est particulièrement efficace pour héberger un groupe de joueurs éloignés les uns des autres (Amérique du Nord vs Europe, ou côte Ouest vs côte Est), ce qui est souvent le cas avec des salons préformés.
Géolocalisation
Alternativement, fournissez les coordonnées de latitude et de longitude des joueurs ou les coordonnées d’un emplacement de serveur préféré au lieu de recourir à la télémétrie automatisée. Cette approche nécessite une implémentation supplémentaire de géolocalisation côté client, reposant entièrement sur la solution du développeur du jeu.
La stratégie de géolocalisation n’est pas recommandée pour Match-Bound l’orchestration, sauf pour les applications soumises à des exigences réglementaires strictes concernant les transferts de données interrégionaux, ou lorsque l’IP du joueur n’est pas disponible.
Pour utiliser cette stratégie avec les API de déploiement, indiquez les IP publiques des joueurs ou leurs coordonnées géographiques dans votre requête de déploiement.
Verrouillage régional
Les serveurs peuvent être placés à l’aide d’un paramètre régional grossièrement généralisé, soit :
choisi automatiquement pour le joueur, en fonction de ses métadonnées (base de données du compte joueur), soit
sélectionné par le joueur pendant le matchmaking, permettant un placement avec une latence client-serveur élevée.
L’utilisation de cette stratégie seule n’est pas recommandée car elle peut entraîner de mauvaises performances réseau.
Utiliser la sélection de région comme préfiltre en combinaison avec une autre stratégie est une meilleure alternative.
🟢 Qualité de connexion
Certains jeux (et certains joueurs) sont plus sensibles à la latence ou au lag que d’autres. Bien que les rapports des joueurs soient un excellent indicateur d’incidents ou de bugs de régression à grande échelle, les joueurs peuvent manquer d’une compréhension approfondie des concepts réseau et attribuent rapidement la responsabilité aux studios, au netcode ou aux serveurs.
La cause racine de certains problèmes peut être cachée aux joueurs, donc la coopération entre le studio et le fournisseur d’hébergement peut être cruciale. La priorité d’Edgegap est toujours de fournir le meilleur service possible.
Si vous recevez de nombreux signalements de joueurs, si vous subissez des pannes généralisées ou des problèmes répétés, veuillez nous contacter immédiatement via un ticket d’assistance sur notre plateforme.
Faible latence
La latence du joueur est une combinaison des latences liées au transfert de données entre :
dispositifs physiques - le signal physique se déplaçant à travers la topologie du réseau Internet,
hôte à hôte - résultant des mesures de protocole, de transport et de sécurité,
processus à processus - résultant de l’encapsulation/désencapsulation et du traitement des données côté client/serveur.
Edgegap réduit la latence physique en plaçant les serveurs plus près de vos joueurs pour des réponses plus rapides et moins de sauts réseau. Avec des emplacements chez 17 fournisseurs cloud et bare metal, vous obtenez le meilleur ping de sa catégorie pour les joueurs partout dans le monde.
La couverture des serveurs et d’Internet dans le monde (pas seulement avec Edgegap) est limitée en raison de facteurs tels que :
disponibilité de l’infrastructure - la qualité de la connexion Internet dans une région donnée peut ne pas être suffisante,
facteurs naturels - des baies de serveurs très complexes nécessitent surtout un environnement stable.
Haute disponibilité
La disponibilité des serveurs dans différents emplacements à travers le monde varie au fil du temps, changeant plusieurs fois au cours de la journée. Edgegap fait automatiquement évoluer à la hausse/à la baisse les emplacements à la demande, en tenant compte de :
trafic de pointe - déploiements effectués dans une période de 15 minutes,
exigences en vCPU - davantage de vCPU par déploiement augmente la demande globale pour un emplacement spécifique,
offre du fournisseur - certains emplacements éloignés disposent de moins d’options de fournisseurs disponibles,
disponibilité des machines - certains emplacements ne proposent que des machines 4 vCPU ou 8 vCPU,
demandes du studio pour les tests, l’assurance qualité, l’accès anticipé, les bêtas fermées ou les tournois.
Les requêtes de déploiement de toutes les applications sont combinées pour évaluer la demande d’emplacement. Toutes les organisations ont par défaut la même priorité d’allocation, avec la possibilité d’ajouter des pools de serveurs privés pour les clients entreprise nécessitant du matériel ou des emplacements spécifiques.
Veuillez nous contacter pour planifier une sortie, ou si vous avez des demandes concernant la disponibilité des emplacements.
Résolution des problèmes des joueurs
Les problèmes des joueurs peuvent être liés à des bugs serveur ou à des incidents chez le fournisseur, mais peuvent aussi provenir de tiers tels que les FAI locaux, les services de jeu, des bugs dans des bibliothèques bas niveau, des fournisseurs d’infrastructure ou d’autres sources.
Lors du dépannage des signalements ou incidents des joueurs, tenez compte des facteurs suivants :
qualité du matchmaking - les joueurs doivent être proches les uns des autres (même région) pour Déploiements donner les meilleurs résultats :
voir Appariement et Balises Ping pour nos recommandations,
voir Vue approfondie pour apprendre comment trouver les journaux serveur liés aux signalements des joueurs,
problèmes régionaux :
les fournisseurs d’accès Internet (FAI) locaux peuvent être en train de résoudre un incident momentanément,
certaines régions (par ex. Chine, Russie) peuvent être restreintes en raison de sanctions localisées,
niveau de cache - Edgegap donnera la priorité aux déploiements rapides dans les emplacements mis en cache :
délai maximal de déploiement - les déploiements peuvent échouer en raison d’un processus d’initialisation lent et lourd :
voir Applications et versions pour augmenter le délai d’attente,
retardez les étapes d’initialisation jusqu’à ce qu’elles soient absolument nécessaires,
problèmes d’image serveur ou d’intégration.
Afficher les ID de déploiement dans l’interface d’historique des matchs côté client pour retracer les signalements des joueurs lors du dépannage.
Informez les utilisateurs des bugs généralisés, des problèmes temporaires et des pannes afin d’atténuer les sentiments négatifs.
🔄 Cycle de vie du déploiement
Les déploiements Edgegap passent par plusieurs étapes de cycle de vie, indiquées par le statut du déploiement.
1. Démarrer un déploiement
Un déploiement à des fins de test peut être lancé avec :
Unreal Engine - l’extension Docker ou un plugin pour les projets Unreal Engine,
Unity - un plugin pour les projets Unity,
interface Web du tableau de bord - interface web facile à utiliser pour tester l’intégration serveur.
Un déploiement à des environnement de production réel doit être lancé avec :
Appariement - trouver d’autres joueurs et démarrer des serveurs à la demande (Match-Bound).
Navigateur de serveurs - préchauffer des serveurs avec une longue initialisation (Déploiements).
API de déploiement - intégration personnalisée serveur à serveur (mise à l’échelle personnalisée).
Enregistrez request_id (ID de déploiement) et étiquetez les déploiements pour identifier et résoudre les problèmes plus tard.
Lors des tests avec API de déploiement, vous pouvez remplacer le CMD Dockerfile par une commande personnalisée.
2. Déploiement en cours
Une fois un déploiement lancé, notre système effectuera une série d’étapes en rapide succession :
Télémétrie - nous mesurons la réactivité réseau depuis les centres de données disponibles vers chaque joueur,
Déploiement - nous réservons de la capacité et préparons le lancement de votre conteneur serveur,
Démarrage du conteneur - nous lançons le conteneur, installons les dépendances et initialisons,
Post-traitement - nous ajoutons le stockage des journaux, la surveillance et finalisons le déploiement.
Trop de requêtes 429 - pour garantir la stabilité et éviter les factures surprises, nous limitons le débit de votre organisation à 40 req/s. Contactez-nous pour planifier les sorties, estimer le trafic de lancement et préparer le succès.
3. Déploiement prêt
Votre conteneur est entièrement initialisé et votre serveur démarre maintenant. Pendant quelques secondes à une minute, votre serveur peut encore être en cours d’initialisation et ne pas répondre aux requêtes des joueurs tant que votre moteur de jeu (ou runtime personnalisé) n’est pas complètement prêt à accepter les connexions des joueurs.
Une fois le déploiement prêt, réessayez la connexion du joueur jusqu’à ce qu’elle réussisse, ou jusqu’au délai d’attente client prédéfini.
4. Erreur de déploiement
Votre déploiement peut passer à l’état Erreur à tout moment, pour des raisons inattendues. Cela est plus susceptible de se produire lors des tests de votre intégration ou des nouveaux builds serveur.
Vous n’êtes pas facturé pour les déploiements en Erreur, qui sont automatiquement arrêtés après 24 heures.
Étapes de dépannage :
Vérifiez le statut du service Edgegap avec notre page de surveillance de la disponibilité.
Essayez de tester localement votre conteneur serveur à l’aide de Docker Desktop pour écarter les problèmes liés à Edgegap.
Lorsque vous demandez de l’aide, incluez l’ID de votre déploiement et tout détail utile afin que nous puissions enquêter rapidement !
5. Déploiement arrêté
Nous n’arrêtons jamais vos serveurs sans votre directive, afin d’éviter d’affecter négativement l’expérience de vos joueurs. Votre déploiement peut être arrêté pour les raisons suivantes :
Arrêt automatique via DELETE_URL - le déploiement s’est arrêté de lui-même après le départ des joueurs et la fin du match,
voir Unreal Engine et Unity guides pour arrêter correctement les déploiements,
Arrêt depuis votre backend - votre backend a arrêté ce déploiement à l’aide de l’API Deployments,
Durée maximale du jeu - le temps alloué dans votre Applications et versions a expiré,
Flottes privées L’hôte exécutant votre déploiement a été supprimé via une action planifiée.
Une fois un déploiement arrêté, nous déclenchons une terminaison gracieuse en envoyant SIGTERM à votre processus principal, ce qui permet une courte période de terminaison. Une fois ce délai expiré, un signal SIGKILL est envoyé pour arrêter le déploiement.
👀 Observabilité
Permettez aux serveurs de jeu d’interopérer avec des tiers et d’obtenir des informations opérationnelles.
Découvrabilité
Une fois prêt, un déploiement se voit attribuer une URL (fqdn) et un port externe pour chaque port interne.
Utilisez des étiquettes de déploiement pour marquer facilement vos déploiements et Déploiements.
Le trafic sortant (vers les clients ou le backend) provenant de vos serveurs de jeu n’est jamais bloqué ni filtré.
WebSockets (WS) et WebSockets sécurisés (WSS)
Pour utiliser un netcode basé sur les WebSockets avec Edgegap, vous avez deux options :
certificat géré, configuré en 1 minute sans écrire de code :
configurez votre Applications et versions vers utilisez WebSocket (WS) et activez la mise à niveau TLS,
utilisez l’URL Edgegap pour connecter les clients (par ex.
https://5fa53fa00a57.pr.edgegap.net/)
certificat autogéré, si vous souhaitez utiliser votre propre domaine personnalisé :
configurez votre Applications et versions vers utilisez WebSocket sécurisé (WSS),
configurez votre propre flux de certificat TLS avec un enregistrement DNS personnalisé (par ex. sur Cloudflare).
Les exceptions serveur non interceptées entraîneront le redémarrage du conteneur du déploiement et invalideront la sécurité TLS. Dans ce cas, arrêtez votre serveur et recréez les parties vers un nouveau déploiement. L’état du serveur peut être perdu.
Variables injectées
Les serveurs de jeu ont souvent besoin d’informations supplémentaires, comme l’IP du serveur, les valeurs de port interne ou autres. L’injection de variables d’environnement en lecture seule est une méthode fiable, indépendante du cloud, pour transmettre des paramètres.
Obtenez les valeurs des variables à l’aide de GetEnvironmentVariable en C# ou GetEnvironmentVariable en C++.
Voir Variables de version de l’application et Variables du Matchmaker en plus des variables de déploiement ci-dessous.
Variables personnalisées
Définissez jusqu’à 20 variables personnalisées pour chaque déploiement, chacune pouvant contenir jusqu’à 4 Ko de données de type chaîne.
Évitez d’utiliser des noms réservés (ci-dessous), sinon vos variables personnalisées seront écrasées !
Accédez aux informations importantes en lisant les variables injectées dans vos serveurs par Edgegap :
Identifiants
ARBITRIUM_REQUEST_ID- par ex.f68e011bfb01.ID de déploiement unique, également appelé ID de requête. Utilisé pour récupérer plus d’informations.
Les URL de déploiement ont toujours le format
{ARBITRIUM_REQUEST_ID}.pr.edgegap.net.
ARBITRIUM_PUBLIC_IP- par ex.162.254.141.66.Adresse IP publique de cet hôte, peut être utilisée pour se connecter à la place de l’URL.
ARBITRIUM_HOST_ID- par ex.alpha-north-america-70364ef8.Identifiant unique de la machine hébergeant votre déploiement, partagé avec d’autres déploiements.
ARBITRIUM_DEPLOYMENT_TAGS- par ex.tag1,tag2.Étiquettes de déploiement définies par l’utilisateur et délimitées par des virgules, utiles pour rechercher et filtrer facilement.
ARBITRIUM_PRIVATE_FLEET_ID- par ex.PUBLIC_CLOUD, ou ID de flotte si hébergé sur Flottes privées.
Spécifications des ressources
ARBITRIUM_HOST_IN_PRIVATE_FLEET- par ex.false, indiquant si hébergé sur Flottes privées.ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY- par ex.2000, fréquence du processeur en MHz.ARBITRIUM_DEPLOYMENT_VCPU_UNITS- par ex.256, unités vCPU allouées (1024 = 1 vCPU).ARBITRIUM_DEPLOYMENT_MEMORY_MB- par ex.512, RAM allouée en Mo (1024 = 1 Go).
Gestion du cycle de vie
ARBITRIUM_DELETE_URL- par ex.https://api.edgegap.com/v1/self/stop/9f511e17/660.Appelable depuis le déploiement, le déploiement sera arrêté proprement.
Nécessite un unique
ARBITRIUM_DELETE_TOKENdans l’en-têteAuthorization.
ARBITRIUM_DELETE_TOKEN- par ex.7df4cd933df87084b34ae80d8abde293.ARBITRIUM_CONTEXT_URL- par ex.https://api.edgegap.com/v1/context/9170f5211e17/17.Appelable uniquement depuis le déploiement, renvoie plus de détails sur le déploiement.
Nécessite un unique
ARBITRIUM_CONTEXT_TOKENdans l’en-têteAuthorization.
ARBITRIUM_CONTEXT_TOKEN- par ex.dfaf50b9333b9ee07b22ed247e4a17e6.
Découvrabilité
ARBITRIUM_PORT_GAMEPORT_INTERNAL- par ex.7777, port interne pour l’écoute du serveur.ARBITRIUM_PORT_GAMEPORT_EXTERNAL- par ex.31504, port externe pour les connexions client.Les valeurs des ports externes sont randomisées pour chaque déploiement à des fins de sécurité.
ARBITRIUM_PORT_GAMEPORT_PROTOCOL- par ex.UDP, protocole de transport de votre netcode.
Les exemples supposent que vous avez nommé votre port gameport (par défaut). Chaque port ajoute un ensemble supplémentaire de variables Applications et versions nettoyées : @Super Port ! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .
ARBITRIUM_BEACON_ENABLED- par ex.true, si vous déployez sur Flottes privées avec Balises Ping.ARBITRIUM_HOST_BEACON_PUBLIC_IP- par ex.139.177.198.69, IP publique de la balise la plus proche.ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL- par ex.30199, pour la mesure du ping via UDP.ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL- par ex.30456, pour la mesure du ping via TCP.
Informations structurées (JSON en tant que chaîne)
Les variables d’environnement sont stockées sous forme de JSON sérialisés en chaîne, analysez-les à l’aide d’un SDK ou d’une méthode personnalisée.
Surveillance du tableau de bord
Notre Le tableau de bord fournit des utilitaires pour surveiller la scalabilité de votre serveur et assister les opérations.
Analytique
Trouver les tableaux de bord d’analyse dans le menu latéral sous la catégorie Hébergement et orchestration de serveurs.
🌟 Passez au niveau Paiement à l’utilisation pour débloquer des métriques et des analyses détaillées des performances du serveur :
Aperçus généraux : suivre les versions avec le nombre de serveurs en direct par version + aperçu de l’utilisation des ressources,
Aperçus CPU: dépanner les serveurs en ralentissement en raison d’opérations gourmandes en processeur,
Aperçus mémoire: atténuer les redémarrages de serveur dus au dépassement de la mémoire allouée,
Aperçus réseau : détecter les schémas réseau inefficaces et optimiser le netcode.
Carte de déploiement
Trouver la carte de déploiement dans la page des détails de votre déploiement dans le tableau de bord.
Prévisualisez l’emplacement du déploiement, les emplacements disponibles et les emplacements estimés des joueurs sur la carte :
Points d’équilibre du déploiement
Trouver la carte thermique des points d’équilibre du déploiement dans la page des détails de votre application dans le tableau de bord.
Prévisualisez la carte thermique des points d’équilibre du déploiement et filtrez par Applications et versions. Les points d’équilibre sont des emplacements approximatifs ayant une proximité réseau égale pour chaque joueur dans un déploiement donné :
Des points chauds d’équilibre dans des endroits étranges (par ex. le Groenland) indiquent un matchmaking de joueurs éloignés les uns des autres. En savoir plus sur Déploiements et Balises Ping pour optimiser votre matchmaking.
Journaux de déploiement
Trouver les journaux de déploiement dans la page des détails de votre déploiement dans le tableau de bord.
Les journaux de déploiement affichent des informations sur Déploiements:
Journaux du conteneur
Trouver les journaux du conteneur dans la page des détails de votre déploiement dans le tableau de bord.
Inspectez les journaux de votre serveur de jeu en cas de problème, ou lors du débogage :
Une fois le déploiement arrêté, les journaux du conteneur sont supprimés. Configurez un stockage de journaux S3 tiers pour enregistrer les journaux.
Métriques du conteneur
Trouver les métriques du conteneur dans la page des détails de votre déploiement dans le tableau de bord.
Examinez les métriques du conteneur (processeur, mémoire, réseau) pour :
identifier les problèmes de connexion courants lorsque Déploiements,
détecter les schémas d’implémentation inefficaces provoquant des pics d’utilisation des ressources,
repérer l’utilisation inefficace des ressources dans des scénarios particuliers,
vérifier les changements dans l’utilisation des ressources de votre serveur pendant l’optimisation,
étalonner la consommation de ressources et la durée d’initialisation de votre serveur.
Les métriques historiques affichent des moyennes de valeurs avec une période de 1 minute, disponibles dans le niveau Gratuit.
🌟 Passez au niveau Paiement à l’utilisation pour débloquer des métriques précises avec des intervalles de 1 seconde.
Contactez-nous avant votre lancement pour demander une assistance d’hébergement en direct pour les lancements à grande échelle.
Contexte et statut
Des informations supplémentaires sur le déploiement peuvent être obtenues au format JSON :
depuis l’intérieur du déploiement (serveur de jeu), en utilisant API de contexte du déploiement,
depuis l’extérieur du déploiement (backend / tiers), en utilisant API de statut du déploiement.
L’API de contexte (depuis le déploiement) nécessite un jeton d’API de contexte, tandis que l’API de statut utilise votre jeton Edgegap.
Trop de requêtes 429 - nous limitons le débit de votre organisation à 20 req/s pour les points de terminaison des API de contexte et de statut. Utilisez Variables injectées et Webhooks pour une solution évolutive.
Filtrer les déploiements
Pour rechercher rapidement parmi tous les déploiements, vous pouvez utiliser notre tableau de bord:
Lister les déploiements avec l’API et appliquer des filtres avec les intégrations backend :
dans l’en-tête ou nin
[ "7e709a0d8efd", "4ba353100b4b" ]
dans l’en-tête ou nin
[ "tagA", "tagB" ]
dans l’en-tête ou nin
[ "my-app", "my-other-app" ]
dans l’en-tête ou nin
[ "1.0.0", "prod" ]
Chaque attribut peut avoir au maximum 1 opérateur de filtre dans une seule requête. Voir Référence de l’API pour en savoir plus.
Triez les résultats par plusieurs champs dans l’ordre où ils apparaissent dans la requête :
asc ou desc
asc ou desc
Exemples de requêtes de filtre :
Lister les déploiements en erreur pour dépanner et supprimer.
URL encodée :
Requête JSON formatée :
Lister Déploiements avec une version d’application obsolète pour confirmer qu’un lancement est terminé.
URL encodée :
Requête JSON formatée :
N’oubliez pas d’ajouter le Authorization en-tête avec votre jeton API Edgegap dans la requête.
Webhooks et postbacks
Recevez de simples notifications HTTP dans le backend de votre jeu pour les changements dans Déploiements en spécifiant une URL de webhook dans votre requête API de déploiement. Disponible pour :
À l’état prêt : conteneur de déploiement démarré avec succès (le serveur commence son initialisation après cela),
En erreur : le déploiement n’a pas pu être démarré et une Déploiements s’est produite,
À la terminaison : Déploiements et le serveur de jeu n’est plus joignable.
Les webhooks Ready et Error ne seront jamais déclenchés pour le même déploiement.
Les webhooks ne sont pas renvoyés, donc si votre backend ne traite pas la requête en raison d’une limitation de débit ou d’une erreur, le webhook peut être perdu. N’utilisez les webhooks que pour des cas d’utilisation non critiques ou à des fins de débogage.
Les webhooks observent le cycle de vie du déploiement, mais ne connaissent pas l’état d’initialisation de votre scène/niveau. Pour observer la progression du chargement de votre scène/niveau, implémentez un webhook personnalisé dans votre serveur de jeu.
🚨 Dépannage
Lors du dépannage des déploiements :
vérifiez qu’il n’y a aucune erreur dans votre Déploiements et Déploiements,
exécutez votre serveur localement pour écarter les bugs d’intégration,
consultez les étapes de dépannage sur cette page,
contactez-nous sur Discord de la communauté et incluez l’ID de votre déploiement.
Voir Déploiements pour nos recommandations sur la gestion des retours de la communauté des joueurs.
Impossible de connecter les clients au serveur - Délai de requête dépassé., 请求超时 , ConnectionFailed , ou Échec de la vérification du port.
Tout d’abord, assurez-vous que le déploiement est prêt et qu’il n’y a aucune exception d’exécution ni erreur dans le journal de déploiement. Si votre déploiement s’est arrêté, inspectez les journaux dans notre Le tableau de bord.
Si vous utilisez le netcode Mirror, vous devez avoir "Auto Start Server" sélectionné dans votre
NetworkManager, rebuild, push et redeploy your server.Si vous utilisez le netcode FishNet, vous devez activer "Start on Headless" dans votre
ServerManager, rebuild, push et redeploy your server.Si vous utilisez le netcode Photon Fusion 2, assurez-vous que votre serveur transmet l’IP publique du déploiement, le port externe et le
roomCodesur le serveur, ainsi que le même code de salle dans le client dans le "NeworkRunner.StartGame" paramètreStartGameArgs. L’ID de déploiement (par ex.b63e6003b19f) est un excellent choix car il est mondialement unique et facilement accessible au client par Matchmaker attribution et au Vue approfondie.Ensuite, vérifiez que le paramètre de port dans les paramètres netcode de votre build serveur correspond au port interne de votre Version de l’application. Vous pouvez modifier le mappage des ports en éditant le Version de l’application sans reconstruire. Trouvez votre protocole dans votre intégration netcode.
Assurez-vous que votre client de jeu se connecte au port externe indiqué sur la page des détails de votre déploiement ; cette valeur sera toujours randomisée pour des raisons de sécurité.
Si vous utilisez le protocole Secure Websocket (WSS) dans votre intégration netcode, assurez-vous que votre Version de l’application configuration de port pour le port WSS a l’option TLS Upgrade activée.
Êtes-vous situé en Chine et utilisez-vous Fleets intelligentes? Votre connexion peut être bloquée par le Grand Firewall. Envisagez d’ajouter à votre flotte un serveur situé en Chine, ou d’utiliser un VPN pour vous connecter.
Mon déploiement s’est arrêté/redémarré et je ne peux plus accéder à ses journaux.
En cas de plantage du processus serveur en raison d’une exception, notre système tentera de redémarrer automatiquement le serveur. Envisagez de tester votre serveur localement pour en découvrir la cause première.
Nous conservons les journaux uniquement pendant la durée du déploiement ; si vous souhaitez inspecter les journaux après l’arrêt du déploiement, veuillez intégrer un stockage de journaux tiers.
Voir Déploiements pour découvrir toutes les causes de l’arrêt de votre déploiement.
Mon déploiement s’est arrêté automatiquement après X minutes.
Les déploiements du niveau Gratuit ont une limite de temps de 60 minutes ; veuillez envisager de mettre à niveau votre compte.
Tous les déploiements seront terminés après 24 heures d’exécution conformément à notre politique de nettoyage des serveurs, pour la maintenance de l’infrastructure, et pour éviter d’engendrer des coûts inattendus lorsqu’un déploiement n’a pas été arrêté correctement. Pour les serveurs de longue durée, envisagez d’utiliser Flottes privées avec Persistance.
Voir Déploiements pour découvrir toutes les causes de l’arrêt de votre déploiement.
Mon déploiement est prêt, mais je ne parviens pas à m’y connecter pendant plusieurs minutes après.
Une fois qu’un déploiement est prêt, l’initialisation de votre moteur de jeu commence. Ce processus peut prendre de quelques secondes à plusieurs minutes, et le serveur n’accepte pas les connexions des joueurs pendant cette période.
Envisagez d’optimiser l’initialisation de votre serveur pour réduire cette durée.
Les clients de jeu doivent réessayer la connexion à intervalles de 1 seconde pendant une durée limitée (selon la durée de votre initialisation), après quoi ils reviennent au matchmaking.
Envisagez d’ajouter une scène de chargement afin que le serveur puisse effectuer l’initialisation (et le déplacement dans le cas d’Unreal Engine) en même temps que les clients, tout en synchronisant l’état des deux.
Mon appareil Meta Quest affiche HTTP 0: Impossible de résoudre l’hôte de destination .
Lors de la création de builds d’applications Unity pour la cible Android, votre autorisation d’accès à Internet peut être supprimée automatiquement de l’artefact de build APK client de sortie.
Réajoutez les autorisations dans (nécessite de reconstruire le client ensuite) :
Paramètres du projet / OpenXR / ⚙️ Support Meta Quest / Forcer la suppression des autorisations Internet (décocher).
Paramètres du joueur / Accès Internet (définir sur requis).
Que se passera-t-il si un joueur quitte mon déploiement ?
Par défaut, les serveurs ne rejettent pas les connexions des joueurs. L’authentification des joueurs dépend de vos développeurs, car de nombreuses méthodes différentes et fournisseurs d’authentification des joueurs peuvent être utilisés.
Les clients de jeu peuvent stocker localement les informations de connexion afin de tenter une reconnexion en cas de plantage inattendu du client.
Pour permettre aux joueurs de rejoindre des parties en cours, envisagez d’utiliser Vue approfondie ou Sessions.
Mon serveur affiche une utilisation CPU de 100 % après être devenu prêt.
Cela peut ne pas être un problème, car les moteurs de jeu ont tendance à effectuer des opérations gourmandes en CPU pendant l’initialisation du serveur. Si l’utilisation du CPU ne baisse pas 2 à 3 minutes après le début du déploiement, vous devrez peut-être optimiser votre serveur ou augmenter les ressources de la version de l’application.
Réduire le taux de tick peut avoir un impact sur l’utilisation du CPU, car le serveur effectue moins d’opérations de messagerie.
Si vous utilisez le netcode Mirror, vous devez avoir "Auto Start Server" sélectionné dans votre
NetworkManager, rebuild, push et redeploy your server.Si vous utilisez le netcode FishNet, vous devez activer "Start on Headless" dans votre
ServerManager, rebuild, push et redeploy your server.Dans le niveau Gratuit, vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM).
Vous pouvez augmenter les ressources allouées lors de la création d’une nouvelle version d’application. Vous pouvez dupliquer votre version d’application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ni votre image.
Mon déploiement redémarre à répétition et affiche l’erreur `OOM kill` .
Ce comportement est causé par un dépassement de la quantité de mémoire allouée. Envisagez d’optimiser l’utilisation de la mémoire avec le pooling d’objets, la compression ou la suppression des objets inutiles dans votre scène.
Assurez-vous que votre projet charge la scène par défaut contenant votre
NetworkManageret que la scène est incluse dans les paramètres de build de Unity.Dans le niveau Gratuit, vous êtes limité à 1,5 vCPU et 3 Go de mémoire (RAM).
Vous pouvez augmenter les ressources allouées lors de la création d’une nouvelle version d’application. Vous pouvez dupliquer votre version d’application dans notre tableau de bord et ajuster ces valeurs selon vos besoins, sans reconstruire votre serveur ni votre image.
Parfois, l’utilisation de la mémoire (RAM) de mon serveur augmente brusquement jusqu’à une valeur élevée, est-ce un problème ?
Tant que vous restez dans la quantité de mémoire allouée à la version de l’application, ce n’est pas un problème.
Dépasser la quantité de mémoire allouée à la version de l’application entraînera un `OOM kill` (voir ci-dessus).
Les performances de mon serveur seront-elles affectées par d’autres serveurs exécutés sur la même machine ?
Non, notre plateforme garantit que les ressources allouées ne seront pas utilisées par d’autres studios ni par d’autres serveurs sur une infrastructure partagée. Avec Edgegap, il n’y a pas de voisins bruyants.
Mis à jour
Ce contenu vous a-t-il été utile ?