De la flotte à la demande : des serveurs pour le jeu d’un développeur solo
Rédigé en collaboration avec
iScoot, LLC
Points clés
Abdul Alzenki, cofondateur d’iScoot, a évalué plusieurs plateformes et est resté bloqué sur chacune d’elles pendant des jours à la fois. Avec Edgegap, il a mis en place le matchmaking et le pipeline de déploiement en environ une journée, grâce à une documentation claire et à une intégration qui avait tout simplement du sens.
Le modèle de rassemblement social d’iScoot, où les joueurs rejoignent une session pour rouler ensemble dans un skate park, n’a pas besoin de grandes instances dédiées qui restent inactives en attendant de l’action. L’orchestration conteneurisée d’Edgegap a permis à iScoot d’exécuter des serveurs environ 10x plus petits que ce qu’exigeait son fournisseur précédent, une amélioration fondamentale de l’adéquation pour un jeu conçu autour de petites sessions occasionnelles auxquelles on peut se joindre à tout moment.
Le modèle de tarification à la demande et basé sur l’utilisation d’Edgegap signifie qu’iScoot paie la puissance de calcul lorsque des sessions sont en cours d’exécution, et non pour de la capacité en attente. Pour un jeu en accès anticipé où le trafic des joueurs est imprévisible et où chaque dollar d’infrastructure compte, ce modèle est nettement mieux adapté que les alternatives basées sur des flottes qui facturent des nœuds inactifs réservés.
Le studio
iScoot est cofondé par Abdul & Ayas Alzenki. Le jeu, iScoot, est une expérience de rencontre multijoueur se déroulant dans un skatepark. Les joueurs arrivent, roulent ensemble et coexistent en ligne. Il n'y a pas d'élimination, pas de boucle d'objectif exigeant une précision côté serveur à grande échelle. L'expérience est sociale, décontractée et construite autour de la présence. La démo est actuellement disponible sur Steam tandis que le jeu approche de son lancement en accès anticipé.
Cette prémisse façonne tout ce qui concerne les exigences d'infrastructure. Les sessions sont petites. Le trafic est imprévisible. La priorité est de faire entrer rapidement les joueurs dans une session, de garder l'expérience réactive une fois qu'ils y sont, et de maintenir des coûts viables pour un jeu indépendant.
Le défi
Le fournisseur précédent d'iScoot utilisait un modèle de flotte, ce qui signifiait qu'il devait maintenir des serveurs complets en permanence. Cela faisait supporter à iScoot le coût de serveurs inactifs, ce qui est une manière coûteuse d'exploiter un jeu où les sessions sont petites et décontractées par conception.
Comme l'explique Abdul :
"Multiplay d'Unity, avant la cession du service à un tiers, était coûteux pour la façon dont notre jeu fonctionne, parce que nous devions conserver trop de capacité inactive."
Au-delà du coût, l'équipe avait besoin de quelque chose de réellement exploitable sans expérience en infrastructure backend. Cela impliquait une documentation claire, un système de matchmaking qui s'intègre naturellement, et aucune obligation de construire une logique d'orchestration à partir de zéro. Abdul a évalué plusieurs services, en passant des jours sur chacun avant de se retrouver bloqué.
La solution
L'orchestration moderne basée sur des conteneurs d'Edgegap permet aux développeurs de jeux avec des sessions liées aux matchs de déployer chaque serveur de jeu juste à temps, en le lançant exactement lorsqu'il est demandé et en l'arrêtant lorsque la session se termine, optimisant ainsi l'utilisation et les coûts. Cela diffère de l'hébergement traditionnel basé sur des flottes, où les studios réservent et paient des grappes de machines virtuelles complètes ou des nœuds bare metal, que les joueurs les utilisent ou non.
Pour iScoot, cela a débloqué quelque chose de précis : la capacité d'exécuter des serveurs à une fraction de la taille requise par les plateformes basées sur des flottes. Comme l'infrastructure conteneurisée d'Edgegap peut allouer une partie d'un vCPU plutôt qu'un nœud complet, les sessions d'un petit jeu social de rencontre peuvent être dimensionnées en fonction de la charge de travail réelle.
"Cela nous a permis d'exécuter des serveurs environ 10 fois plus petits que ceux que nous utilisions, ce qui correspond beaucoup mieux à iScoot."
De petites sessions accessibles à tout moment, exécutées uniquement lorsque des joueurs sont présents, facturées uniquement pour ce qu'elles utilisent. Ce qui correspondait parfaitement à la réalité du développement d'iScoot.
La migration elle-même reflétait ce dont une petite équipe a réellement besoin de la part d'un partenaire d'infrastructure. La documentation couvrait les fondamentaux sans obliger Abdul à développer des connaissances de base en systèmes distribués. Les éléments de matchmaking et de déploiement s'assemblaient d'une manière intuitive.
"Edgegap a rendu la migration pratique. La documentation était bonne, les éléments de matchmaking et de déploiement avaient du sens, et nous l'avons fait fonctionner en environ une journée. Avant cela, nous avons essayé quelques autres services pendant quelques jours chacun et nous restions bloqués."
Conclusion
La migration d'iScoot a aidé le studio à trouver un service d'orchestration correspondant à l'ampleur de son jeu et à sa réalité commerciale. Un titre social de rencontre avec de petites sessions accessibles à tout moment n'a pas besoin de grandes instances réservées. Il a besoin de serveurs qui démarrent quand les joueurs arrivent, s'arrêtent quand ils partent, et ne coûtent rien entre-temps.
L'orchestration conteneurisée juste à temps d'Edgegap a livré exactement cela : des serveurs fonctionnant à un dixième de la taille auparavant requise, une migration qui a pris une seule journée, et un modèle de coûts qui, comme le dit Abdul, "semble déjà mieux adapté que ce que nous avions avant."
À mesure qu'iScoot se rapproche de son lancement en accès anticipé, le studio peut se concentrer sur ce pour quoi il a été conçu, créer une expérience de scooter amusante et sociale, tandis qu'Edgegap gère l'infrastructure sous-jacente.
