Emplacements mondiaux de l'Edge Cloud
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.

Migration
/
PlayFab
Conservez PlayFab. Votre système de matchmaking, votre économie, votre authentification et vos données de joueur (Player Data) restent exactement là où ils sont : seuls les serveurs bougent, et avec eux la facture des machines virtuelles Azure que vous payez pour la capacité de secours qui attend entre les pics de charge.
Supprimez le GSDK, conteneurisez la version que vous possédez déjà, et laissez une fonction Cloud Script se déployer sur Edgegap dès qu'un match est trouvé. Les Private Fleets prennent en charge votre infrastructure de base sur du matériel dédié, et la demande qui dépasse la capacité de la flotte déborde sur plus de 615 emplacements Edge Cloud, positionnés au moment de la demande et mesurés à partir des joueurs présents dans le match.
Ce qui change (et ce qui ne change pas)
Une migration de serveurs de jeu multijoueurs PlayFab est un changement d'hébergement, pas un changement de backend. Voici à quoi vous attendre lors de votre migration.
Une analyse détaillée, fonctionnalité par fonctionnalité, est présentée à l'étape Étape 3 : Identifier et remplacer les fonctionnalités ci-dessous.
Ce qui reste inchangé
Votre netcode et transport
Edgegap ne touche jamais à votre transport, à votre sérialisation ou à votre boucle de tick. Le conteneur exécute le même binaire de serveur que vous construisez aujourd'hui.
Votre backend PlayFab
Les files d'attente et les règles de Matchmaking, les données des joueurs, l'économie, l'authentification, les classements et CloudScript restent tous dans PlayFab. Cette migration concerne les serveurs multijoueurs (Multiplayer Servers) et rien d'autre dans votre titre.
Votre flux de connexion client
Votre client reçoit toujours une adresse et un port et s'y connecte. Dans le pont documenté, il les lit toujours à partir des données de joueur PlayFab (PlayFab Player Data), exactement comme il le fait aujourd'hui.
Moteur, versions & CI
Même moteur, même version, même pipeline de build. Rien dans votre CI ne nécessite d'étape supplémentaire au-delà du push de l'image.
Qu'est-ce qui change
Le GSDK est disponible
Le SDK PlayFab Game Server s'intègre à votre binaire : le démarrage de l'agent, les rappels de disponibilité et de session, ainsi que les rapports d'état et de santé qu'il exécute en boucle. Edgegap ne nécessite aucun SDK serveur. Votre serveur lit son adresse IP publique et ses ports à partir des variables d'environnement lors du déploiement.
Un seul appel de déploiement remplace le pool de réserve
Au lieu de demander un serveur à partir d'une capacité que vous avez provisionnée à l'avance, une fonction PlayFab Cloud Script envoie une requête unique au point de terminaison de déploiement lorsqu'une partie est trouvée, et le déploiement est créé pour cette partie.
Les régions cessent d'être un facteur de décision d'achat
Vous n'avez plus besoin de dimensionner la capacité des machines virtuelles région par région. Chaque déploiement est placé au meilleur emplacement disponible sur le réseau Edge Cloud au moment de la demande, mesuré à partir des joueurs de la partie.
Le calcul de veille disparaît
Aucune cible de réserve à calculer, aucun seuil de pourcentage et multiplicateur à ajuster par région, aucune fenêtre de réduction d'activité, et aucun pool à maintenir actif entre les pics. La gestion de la capacité n'est plus de votre ressort : Private Fleet est redimensionné avec nous au rythme de l'évolution de votre courbe de trafic, et Edge Cloud ne nécessite absolument aucun pré-approvisionnement.
Calendrier prévu
Étape 1
Supprimez le SDK PlayFab Game Server : le démarrage de l'agent, les rappels de disponibilité et de session, ainsi que la boucle de rapport d'état et de santé.
~2 heures
Étape 2
Si vous livrez déjà une build de conteneur Linux, l'artefact reste inchangé. Les builds uniquement destinées à Windows nécessitent d'abord une build de serveur Linux, ce qui constitue la seule tâche véritablement importante de cette migration.
~30 min à 2 h
Étape 3
Le registre d'Edgegap est disponible gratuitement, ou conservez ACR, DockerHub, GitLab, etc.
~30 min.
Étape 4
Une fonction Cloud Script sur la règle match_found effectue une publication sur le point de terminaison de déploiement (deploy), et votre serveur réécrit l'adresse dans les données du joueur (Player Data).
environ 1 jour
Étape 5
Déployez à l'échelle mondiale sur Edge Cloud, et réduisez éventuellement encore plus vos coûts grâce à un hébergement sans frais d'egress sur Private Fleets.
Déploiement instantané
Étapes de migration détaillées
Si vous cherchez à migrer vos serveurs de jeu de PlayFab Multiplayer Servers tout en conservant le reste de PlayFab, les étapes simples suivantes vous permettront de démarrer en un rien de temps. Instructions complètes, y compris un exemple Unity fonctionnel : PlayFab Bridge.
Avant de commencer, il est utile de savoir clairement ce qui change et ce qui ne change pas.
Seuls les serveurs Multiplayer Servers sont concernés : PlayFab conserve votre matchmaker, vos données de joueur (Player Data), votre économie et votre authentification, tandis qu'Edgegap devient l'endroit où le serveur de match s'exécute. Edgegap est une API, sans SDK de serveur.
Nous partons du principe que : vous utilisez actuellement PlayFab Multiplayer Servers, vous disposez d'une version fonctionnelle de votre serveur de jeu, et vous pouvez modifier le CloudScript de votre titre.
Edgegap ne requiert pas de SDK pour l'intégration. La première étape consiste à supprimer le code qui initialise le SDK PlayFab Game Server dans votre serveur de jeu : l'appel de démarrage de l'agent, les callbacks enregistrés pour l'activation du serveur et l'attribution des sessions, les gestionnaires d'arrêt et de maintenance, ainsi que les rapports d'état de santé et de joueur que l'agent attend en boucle. Rien ne les remplace. Sur Edgegap, votre serveur lit ce dont il a besoin à partir des variables d'environnement injectées lors du déploiement, y compris son adresse IP publique et son mappage de ports, et il est prêt pour les joueurs dès qu'il est à l'écoute. Si vous avez utilisé le wrapper GSDK plutôt qu'une intégration directe, cela s'applique également, et la documentation propre de PlayFab note que le wrapper « n'est pas destiné à une utilisation en production ».
Si vous effectuez déjà des builds de conteneurs Linux sur PlayFab, cette étape est une simple vérification plutôt qu'une reconstruction : confirmez que l'image se construit et démarre localement, puis poussez-la vers le registre gratuit d'Edgegap, ou conservez ACR, DockerHub, GitLab ou tout autre registre compatible OCI.
Si votre titre utilise des builds de VM Windows, vous devez d'abord créer un build de serveur Linux. C'est un travail conséquent, mais les plugins dédiés d'Edgegap pour Unity, Unreal Engine et Godot vous aident à construire l'image automatiquement une fois que vous disposez d'une cible de serveur Linux.
Fonctionnalité GSDK | Remplacement par Edgegap |
|---|---|
Game Server SDK (GSDK) | Aucun SDK de serveur. Les ports et les variables sont injectés lors du déploiement. |
Builds et tailles de VM | Applications et versions. Choisissez le vCPU et la mémoire par version, fractionnables à partir de 0,25 vCPU. |
Régions de build | Aucune configuration de région. Placement au moment de la demande sur plus de 615 sites Edge Cloud pour du calcul à la demande, Private Fleets disponibles pour de la capacité réservée. |
Serveurs de secours et calcul des cibles de secours | Mise à l'échelle automatique pour le calcul à la demande (Edge Cloud). Private Fleets pour une base de référence persistante, ajustée mensuellement. |
Secours dynamique et planifié | Non requis. Le Burst to Edge Cloud est automatique. |
RequestMultiplayerServer | Un POST vers l'endpoint de déploiement, depuis CloudScript ou votre backend. |
Matchmaker PlayFab | Inchangé. Une règle match_found déclenche le déploiement. |
Détails de connexion au serveur | Écrits dans les données de joueur PlayFab par votre serveur, lus par votre client, exactement comme dans l'exemple de pont publié. |
Journaux de serveur et serveurs archivés | Journaux de déploiement, API d'état de déploiement et Webhook de déploiement. |
Gestion des serveurs dans Game Manager | Tableau de bord Edgegap, API de déploiement et Analyse et surveillance des déploiements. |
Private Fleets sont ce qui se rapproche le plus de la capacité que vous gérez aujourd'hui : des hôtes dédiés et persistants avec un hébergement sans frais de sortie (egress-free).
La différence réside dans le travail nécessaire pour les gérer. Il n'y a pas de cible de secours à calculer, pas de seuils ou de multiplicateurs par région à ajuster, et pas de fenêtre de réduction progressive. Vous redimensionnez la flotte mensuellement, et tout dépassement bascule automatiquement sur Edge Cloud.
Prix
Découvrez comment l'orchestration d'Edgegap est plus rentable par rapport à votre facture actuelle de serveurs de jeu Multiplay (PlayFab Multiplayer Servers).
Les propres directives de PlayFab consistent à dimensionner un pool de serveurs en veille en fonction du temps de préparation et du taux d'allocation, et elles indiquent que les serveurs dans les états de préparation et de veille sont facturés à votre titre.
Serveurs multijoueurs PlayFab | Edgegap | |
|---|---|---|
Capacité inactive | Facturée. Les serveurs de veille et de préparation fonctionnent et facturent entre les pics | Non facturée sur Edge Cloud. Zéro déploiement actif coûte 0 $ |
Méthode de dimensionnement | Cible de veille calculée à partir du temps de préparation et du taux d'allocation cible, par région | Rien à dimensionner sur Edge Cloud. Les Private Fleets sont dimensionnées mensuellement |
Mode de défaillance | Épuisement du pool de veille : les requêtes de serveur échouent lorsque la demande dépasse l'approvisionnement | Les déploiements sont créés par match, provisionnés à partir de zéro en 2 secondes, médiane, jusqu'à ce que le conteneur soit prêt |
Vous achetez un type de machine sur PlayFab. Vous achetez de la puissance de calcul sur Edgegap.
Serveurs multijoueurs PlayFab | Edgegap | |
|---|---|---|
Unité | Taille de VM choisie par cœurs, RAM et stockage, par région de build | vCPU-minute, fractionnable à partir de 0,25 vCPU |
Granularité | Machines entières, plus la répartition des serveurs par machine que vous gérez | Par déploiement, sans décision de répartition à prendre |
Tarif | Par taille de VM, par région, selon la liste de prix publiée par PlayFab | 0,00115 $ par vCPU et par minute dans le monde entier, tarif unique |
Une flotte dimensionnée pour les pics est inactive la majeure partie de la semaine. Une flotte dimensionnée au minimum, avec une mise à l'échelle à la demande, ne l'est pas.
Serveurs multijoueurs PlayFab | Edgegap | |
|---|---|---|
Base de référence | Pools de veille que vous dimensionnez par région, ajustés avec des seuils et des multiplicateurs | Private Fleets, dimensionnées mensuellement au fur et à mesure que la courbe de trafic évolue |
Débordement (Burst) | La veille dynamique multiplie la veille cible que vous avez configurée, jusqu'à votre nombre maximal de serveurs | Débordement automatique sur Edge Cloud, plus de 615 emplacements, placé au moment de la demande |
Effet net à des milliers de CCU | La planification de la capacité comme tâche opérationnelle continue | 25 à 35 % de moins que le cloud pur avec une répartition correctement optimisée. Modélisez-le dans le calculateur de prix |

Clients
15 études de cas sont disponibles auprès de studios qui ont migré vers Edgegap depuis une autre plateforme.

Migration d'un jeu LiveOps pour solutioner la charge de travail DevOps
Découvrez pourquoi le tireur d'extraction VR n°1 est alimenté par l'hébergement et l'orchestration de serveurs de jeu d'Edgegap.
Case Study

Serveurs persistants qui "scale" & améliorent l'expérience des joeurs
Découvrez comment The Isle a amélioré l'expérience de ses joueurs grâce aux déploiements mondiaux de serveurs persistants d'Edgegap.
Case Study

Un MMO cosy migré en quelques jours grâce à l’orchestration d’Edgegap
Comment Qloud Games a migré l’hébergement des serveurs de jeu de Loftia chez Edgegap en moins de 24 heures et a lancé une bêta avec des milliers de joueurs.
Case Study

Guerre VR à grande échelle : Triangle Factory lance Forefront 1.0 sur Edgegap
Comment Triangle Factory a migré son jeu de tir en VR le plus ambitieux vers Edgegap et a lancé sa version 1.0 complète en toute confiance.
Case Study

Du Peer-to-Peer aux combats équitables : Bloody Bastards sur serveurs dédiés
Comment Tibith Ltd a migré Bloody Bastards, un succès mobile, du peer-to-peer vers les serveurs dédiés et le matchmaking d'Edgegap, garantissant que chaque match soit géré côté serveur.
Case Study

Comment Noodlecake propose le mode multijoueur tout en oubliant l'existence des serveurs
Comment Noodlecake a migré Super Flappy Golf vers l'orchestration automatisée d'Edgegap et s'est recentré sur le développement du jeu.
Case Study

Breachers migre vers Edgegap
Comment Triangle Factory a adapté son jeu de tir VR compétitif en 5v5 à une infrastructure conçue pour la précision qu'exige ce genre.
Case Study

Comment Blue Duck utilise les Fleets d'Edgegap pour l'orchestration de son MMO
Découvrez comment Blue Duck Studios utilise l'API Fleets d'Edgegap pour orchestrer les serveurs de son jeu de football.
Case Study

1047 Games sur Edgegap : une migration et un lancement fluides
Comment 1047 Games a migré Splitgate: Arena Reloaded vers Edgegap et a lancé Empulse sur son orchestration, avec un hébergement resté fiable tout au long.
Case Study

De l'orchestration homebrew à 50 000 joueurs du jour au lendemain
Comment Slipstream Games a réduit ses coûts de serveur de 50%, a diminué son ping de 200-250 ms à 100-110 ms et a lancé sur CrazyGames atteignant 50 000 joueurs en 24 heures.
Case Study

De la flotte à la demande : des serveurs dédiés pour un jeu de scooters
Comment iScoot est passé à une orchestration à la demande basée sur des instances, aboutissant à des serveurs dédiés 10 fois plus petits en terme de modèle de coûts
Case Study

Triangle Factory migre Hyper Dash chez Edgegap
Comment un jeu de tir en VR gratuit reste rapide, mondial et rentable grâce à une infrastructure à la demande qui s'adapte à ses joueurs.
Case Study
Découvrez l’impact de l’orchestration automatisée des serveurs de jeu d’Edgegap pour une expérience multijoueur impeccable.
Méthodologie
Chaque métrique indique ce qui est mesuré, sur quelle période et ce qui est exclu. Les résultats de référence sont datés du test qui les a produits et ne sont pas reformulés en tant que chiffres actuels.
Où les serveurs peuvent fonctionner et combien nous en avons exploités.
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.
Emplacements où un studio peut réserver des hôtes dédiés (bare-metal ou VM) pour son usage exclusif.
Nombre total de déploiements de serveurs de jeu orchestrés depuis février 2019, y compris les déploiements qui n'ont pas réussi à démarrer, selon la même méthode de calcul que nos concurrents.
La rapidité avec laquelle notre orchestration déploie un serveur, et ce qu'elle soutient en condition de test.
Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Started deployments per second, averaged over a continuous 60-minute benchmark. Available to each game from confirmed studios with live traffic.
Concurrent sessions reached on real game server containers, at 100 players per server.
Ce à quoi nous nous engageons contractuellement pour notre orchestration, et ce que les moniteurs enregistrent.
Committed under our SLA. Trailing 90-day measured uptime: 99.999%.
Cloud and bare-metal providers under contract and carrying production traffic. Failover is automatic.
L'état des composants en direct est publié sur status.edgegap.com.
One entry per metric: what is measured, how, and over what window.
Un emplacement correspond à une cible de déploiement distincte : un site de centre de données chez l'un de nos fournisseurs d'infrastructure, dans lequel un conteneur de serveur de jeu peut être planifié à la demande. Les sites ne sont comptabilisés qu'une seule fois, quel que soit le nombre de fournisseurs présents dans la même zone métropolitaine, et uniquement lorsqu'ils acceptent des déploiements.
Back to the metric ↑Le sous-ensemble des 615+ où un studio peut réserver des hôtes physiques (bare-metal) ou des machines virtuelles dédiés pour son usage exclusif, plutôt que de déployer sur une capacité partagée à la demande. Publié en direct sur la page Fleet Manager. Ce nombre correspond également à celui qui comprend le volume de transfert sortant inclus.
Back to the metric ↑Comptabilisé comme le nombre total de déploiements enregistrés depuis février 2019, y compris les déploiements qui n'ont pas pu démarrer, selon la même méthode que celle utilisée par nos concurrents.
Back to the metric ↑Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Back to the metric ↑The orchestrator started real game server containers continuously for 60 minutes, averaging 40 started deployments per second over the full hour, counted at deployment start rather than at ready state. Measured across 550+ locations and 17 providers in November 2023. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑In November 2023, the platform sustained 40 game server deployments per second for 60 minutes across 550+ locations and 17 providers, reaching 14 million concurrent sessions at 100 players per server. Game servers were real containers; player clients were simulated. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑Availability is committed at 99.99% under our SLA and measured continuously against five independently monitored components: Container Registry, Dashboard, Public API, Public Documentation and Website. Trailing 90-day measured uptime: 99.999%. The live figure is published on status.edgegap.com.
Back to the metric ↑Distinct suppliers under contract and carrying production traffic, counted at corporate-entity level. Failover across providers is automatic; it is the premise of the multi-cloud architecture.
Back to the metric ↑What gets reviewed, on what cadence, and what carries its own date.
Platform figures on this page are reviewed and refreshed quarterly. Metrics drawn from live sources (availability and game server deployments) carry their own as-of dates and are updated as measured. Benchmark results are dated to the test that produced them and are not restated as current figures.
Edgegap est l'expert de l'hébergement et de l'orchestration. Notre plateforme est conçue sur mesure pour vous aider à accélérer votre processus de développement, ce qui vous permet de vous concentrer sur ce dans quoi vous excellez : le développement.
Non. Cette migration déplace uniquement les Multiplayer Servers. Vos files d'attente et règles de matchmaking, vos données de joueur (Player Data), votre économie, votre authentification, vos classements et votre CloudScript restent dans PlayFab et continuent de fonctionner exactement comme aujourd'hui. L'intégration consiste en une fonction CloudScript sur la règle match_found qui déploie un serveur sur Edgegap, et en quelques lignes dans votre serveur qui réécrivent l'adresse et le port dans les Player Data pour que le client puisse les lire. Nous publions l'ensemble, y compris un exemple Unity, dans le guide PlayFab Bridge.
Il disparaît et rien de propriétaire ne le remplace. Le démarrage de l'agent, les rappels de disponibilité et de session, le gestionnaire d'arrêt et la boucle de rapport d'état, tout s'en va. Sur Edgegap, votre serveur lit son adresse IP publique et son mappage de ports à partir des variables d'environnement lors du déploiement, et il est prêt dès qu'il est à l'écoute. Si vous avez effectué l'intégration via le wrapper GSDK de PlayFab plutôt que directement, cela disparaît également ; leur propre documentation indique que le wrapper « n'est pas destiné à être utilisé en production ».
Aujourd'hui, vous calculez une cible de mise en veille à partir du temps d'attente et du taux d'allocation, vous définissez le nombre maximal de serveurs par région, et vous ajustez les seuils et multiplicateurs de veille dynamique pour que le pool ne s'épuise pas, les serveurs en état d'attente et de veille restant à votre charge tout au long du processus. Sur Edge Cloud, il n'y a pas de pool : chaque match bénéficie d'un déploiement, provisionné à partir de zéro en 2 secondes, valeur médiane, mesuré jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu. Si vous souhaitez disposer d'une capacité qui vous appartient déjà, les Private Fleets vous l'offrent, dimensionnées mensuellement plutôt qu'ajustées par région.
C'est la seule chose sur cette page qui peut représenter un véritable travail, alors le voici clairement : Edgegap exécute des conteneurs Linux, donc un serveur uniquement sous Windows nécessite une build Linux avant toute autre chose. Pour la plupart des projets Unity et Unreal, il s'agit d'une cible de build et d'un passage sur le code spécifique à la plateforme. Si votre serveur dépend de bibliothèques exclusivement Windows, c'est un projet en soi, et cela nécessite un examen honnête de ce que cela implique pour votre architecture. C'est une discussion que nous serons ravis d'avoir : parlez à nos ingénieurs et nous travaillerons avec vous à la transition vers des instances de serveur de jeu sous Linux. Si vous livrez déjà des builds de conteneurs Linux sur PlayFab, rien de tout cela ne s'applique et votre artefact reste inchangé.
Oui. Les files d'attente, les règles, les tickets et le comportement du matchmaking que connaissent vos joueurs restent inchangés, car PlayFab continue de gérer le matchmaking. Ce qui change, c'est ce qui se passe à la fin : au lieu de demander un serveur à partir de votre capacité provisionnée, la règle match_found exécute une fonction CloudScript qui publie une fois vers le point de terminaison de déploiement d'Edgegap avec la localisation des joueurs, de sorte que le serveur soit placé pour les joueurs réellement présents dans ce match. Si vous préférez consolider plus tard, le matchmaker sans code d'Edgegap est à votre disposition, mais rien dans cette migration ne l'exige.
Principalement à partir de la capacité pour laquelle vous cessez de payer pendant qu'elle attend. PlayFab facture les serveurs dans les états d'approvisionnement et d'attente, de sorte qu'un pool dimensionné pour votre taux d'allocation maximal fonctionne et facture à chaque heure creuse. Sur Edge Cloud, zéro déploiement actif coûte 0 $, et le calcul est de 0,00115 $ par vCPU et par minute, fractionnable à partir de 0,25 vCPU, plutôt qu'une taille de machine virtuelle que vous choisissez par région. À des milliers de CCU, une répartition correctement optimisée entre Private Fleets et Edge Cloud se situe de 25 à 35 % en dessous du cloud pur. Modélisez votre propre trafic dans notre calculateur de prix plutôt que de croire cette fourchette sur parole.