Comment Ares Interactive gère les opérations en direct sans attendre les mises à jour des clients
Adam Axler - Unity
Senior Content Marketing Manager
Cette page a été traduite automatiquement pour faciliter votre expérience. Nous ne pouvons pas garantir l'exactitude ou la fiabilité du contenu traduit. Si vous avez des doutes quant à la qualité de cette traduction, reportez-vous à la version anglaise de la page web.
Faire un jeu en direct signifie construire pour le changement constant. Les équipes doivent maintenir l'engagement des joueurs avec de nouveaux événements, des mises à jour d'équilibre, des offres et du contenu, tout en préservant la performance et la stabilité.
Ares Interactive dirige deux jeux en direct très différents : Coups de baseball 26, développé par son équipe de 7e manche, et The Walking Dead: Aftermath, développé par son studio Swift Games. Baseball Hits 26 reste étroitement lié au calendrier réel du baseball. The Walking Dead: Aftermath construit son service en direct autour d'une base roguelite qui peut s'étendre sans perturber la boucle principale.
Nous avons parlé avec Andre Taube, responsable du studio chez 7th Inning, et Carsten Granig, directeur général de Swift Games Germany. Ils nous ont expliqué comment ils structurent les systèmes de service en direct, gèrent le contenu et la configuration à distance, raccourcissent les cycles d'itération et maintiennent la stabilité des sorties mobiles pendant que les jeux continuent d'évoluer.
Construire les opérations en direct autour des données plutôt que des versions client
Baseball Hits 26 a été conçu pour offrir aux fans de baseball et aux joueurs une expérience de baseball essentielle, facile à prendre en main n'importe quand, n'importe où, en courtes rafales ou lors d'un jeu stratégique plus long. Cette approche convivialité se situe aux côtés des décisions de baseball du monde réel, de la progression, des événements en direct, des clubs sociaux et des fonctionnalités de communication. Maintenir ces systèmes à jour signifie considérer le jeu comme quelque chose qui est toujours en évolution plutôt que quelque chose qui a simplement été livré.
Par exemple, si un joueur licencié par l'MLBPA réalise une performance particulièrement réussie lors d'un match ou d'une série, l'équipe peut mettre en vedette ce joueur lors d'événements en direct au cours de la semaine suivante.
«Ce niveau de pertinence est rendu possible par nos mises à jour de serveurs agiles et axées sur les données, ainsi que par la capacité de notre équipe d'opérations en direct à insérer rapidement les bons affrontements», déclare Taube.
L'équipe a construit son propre backend et son pipeline d'opérations en direct afin de pouvoir modifier les événements, stocker les ventes, les offres, les récompenses et le réglage du matchmaking sans attendre une version client ou un Deployment de serveur.
Au fond se trouve un système personnalisé de diffusion de contenu et de configuration à distance avec plus de 50 domaines de configuration couvrant les joueurs, les événements, les articles de la boutique, les boîtes de récompenses, les passes de combat et d'autres systèmes. L'équipe gère les changements via un panneau d'administration. Le système valide les changements avant de les accepter, et les serveurs les prennent en compte en quelques secondes sans redémarrage.
Tout est versionné et journalisé. L'équipe peut examiner ou revenir à n'importe quel état antérieur, et peut préparer des changements contre des comptes de test internes avant de les promouvoir en production.
La planification d'événements repose sur cette même base. Les événements, les tournois et les ventes à durée limitée ont des Windows de début et de fin définies. Un moteur de segmentation gère le ciblage et alimente les tests A/B, permettant ainsi à l'équipe d'essayer de nouvelles offres ou formats d'événements avec une fraction de l'audience avant un déploiement plus large.
En pratique, cela permet à l'équipe d'organiser jusqu'à quatre événements par semaine, tels que les événements Prime Club et Tower Club, chacun avec ses propres joueurs bonus et offres spéciales associées.
« Posséder toute la pile est le plus rentable lorsque quelque chose tourne mal au milieu d'un événement », dit Taube. L'équipe peut diagnostiquer le problème, corriger la configuration, compenser les joueurs affectés et pousser la mise à jour [config] aux clients, le tout en quelques minutes et depuis un seul endroit.
Maintenir la prévisibilité de la livraison de contenu et des versions mobiles
L'équipe utilise Addressables spécifiquement pour les packs de stade. Un stade par défaut est inclus dans l'application, donc les joueurs débutants n'ont pas besoin d'un téléchargement supplémentaire. L'équipe emballe chaque autre stade en lot, télécharge sur le serveur de l'équipe et télécharge à la demande lorsqu'un joueur le sélectionne.
L'équipe soumet chaque lot de stades à des tests de résistance sur ses appareils les moins performants pour s'assurer qu'il reste dans des budgets de taille et de mémoire stricts. Un paquet commun partagé contient des ressources réutilisées entre les stades, de sorte que les mêmes données ne sont pas dupliquées dans chaque téléchargement.
La même insistance sur la prévisibilité s'applique aux versions d'iOS et d'Android. L'équipe maintient le code spécifique à la plateforme au minimum absolu, et les deux plateformes partagent les jalons et les délais de soumission. L'équipe crée et teste des versions Android et iOS quotidiennement.
Parce que la plupart du contenu est piloté par les données, le calendrier en direct n'a pas besoin d'être étroitement lié au calendrier des examens de l'App Store.
Le client est également conçu en partant du principe que chaque appel de serveur peut échouer.
« Pour les matchs en direct spécifiquement, traitez chaque appel de serveur comme non fiable par défaut », déclare Taube. « Structurer le client de manière à ce qu'un serveur lent, déconnecté ou non réactif ne perturbe jamais l'expérience du joueur. »
Ce principe s'applique au support des appareils. L'équipe utilise le Device Simulator pour vérifier la couverture de l'interface utilisateur sur toute la gamme de tailles et de résolutions d'écran qu'il prend en charge. Le Unity Profiler est utilisé intensivement pour trouver les problèmes de performance pendant le jeu. L'équipe teste également les régressions de performance sur une large gamme d'appareils physiques Android et iOS, avec et sans Wi-Fi.
Pour Taube, les équipes mobiles doivent définir leur stratégie d'appareils tôt.
« Investissez tôt dans un plan architectural solide pour la prise en charge des appareils, en particulier sur Android, où la fragmentation entre les versions matérielles et OS est le véritable risque. »
Construire The Walking Dead: Après-coup afin que les systèmes vivants puissent évoluer indépendamment
Baseball Hits 26 est conçu pour refléter un calendrier sportif réel. Les Morts Vivants : Aftermath a un défi de service en direct différent : ajouter de nouvelles façons de jouer sans perturber son expérience roguelite sous-jacente.
Le RPG d'action roguelite place les joueurs dans le monde de The Walking Dead. Ils forment des équipes de Survivants, y compris Rick Grimes, Daryl Dixon et Michonne, et combattent des hordes de Marcheurs et d'autres ennemis en combat en temps réel. Entre les parties, les joueurs débloquent des Survivants et de l'Équipement, les font monter de niveau, débloquent des compétences et construisent leur base.
« Au fond, nous voulions créer quelque chose qui capture le danger constant et les choix difficiles de The Walking Dead tout en offrant la rejouabilité et la progression que vous attendez d'un roguelite », dit Granig.
Le service en direct s'appuie sur cette base avec des défis et des contraintes, ainsi que des systèmes sociaux tels que les Alliances, les événements coopératifs et les Leaderboards.
D'un point de vue du développement, nous avons construit le jeu de manière à ce que ces systèmes puissent évoluer indépendamment. Cela nous donne la flexibilité de continuer à élargir l'expérience en direct sans perturber la boucle roguelite principale.
Faire la dixième fonctionnalité en direct aussi bon marché que la première
Swift Games n'a pas reconstruit sa base de service en direct à partir de zéro. Il a commencé avec son titre précédent, Heroes vs Hordes. Le stockage, l'Economy, l'Authentication, les Analytics, la configuration à distance et les systèmes de sauvegarde dans le cloud sont apparus comme une technologie éprouvée, tandis que le cœur roguelite nouveau a été prototypé séparément puis fusionné sur cette base.
Tout ce qui était censé changer chaque semaine était conçu pour changer sans une publication client. Les concepteurs rédigent du contenu et équilibrent des feuilles de calcul et les publient en tant que paquets à distance, chaque paquet étant estampillé avec les versions client qu'il prend en charge.
Les données sont versionnées avec une chaîne de migration, de sorte qu'une mise à jour en direct n'abandonne jamais un joueur de longue date. L'heure provient du serveur plutôt que de l'appareil, car les événements et les offres limitées en temps dépendent de celui-ci.
Le compromis est que les fonctionnalités en direct doivent être conçues non seulement pour s'activer, mais aussi pour se désactiver en toute sécurité.
« C'est ce qui permet de garder la dixième fonctionnalité en direct aussi bon marché à expédier que la première », dit Granig.
Le jeu utilise principalement GameObjects et NVIDIA PhysX. Entities et Burst sont réservés au système de recherche de chemin A* qui déplace les ennemis.
Plus important pour le développement est l'injection de dépendances limitée au périmètre. Le jeu possède quatre contextes imbriqués : racine, sauvegarde de jeu, écran principal et jeu. Chaque contexte est responsable de ce qu'il crée et de son nettoyage.
Cela signifie qu'un événement en direct peut être structuré comme un installateur plus un fichier de configuration branché dans un contexte. Lorsque ce contexte se ferme, ses actifs et ses abonnements disparaissent avec lui.
L'équipe sépare également l'interface utilisateur de la logique. Un magasin ou une offre peut exister sous la forme d'une classe C# simple qui peut être testée sans lancer le Moteur, tandis que les concepteurs travaillent directement avec des ressources de configuration.
Tracer une ligne claire entre les données en direct et les actifs du jeu
Dans The Walking Dead: Aftermath, Addressables gère la gestion de la mémoire et le chargement plutôt que la livraison de contenu à distance. Vingt-neuf groupes correspondent à des caractéristiques individuelles, et ils se chargent et se déchargent de manière très similaire aux contextes du jeu.
Le contenu en direct suit un pipeline séparé construit directement sur l'API AssetBundles plutôt que sur Addressables. Les paquets sont construits par plateforme, téléchargés et récupérés par le jeu à l'exécution. Chacun comprend un hachage, une somme de contrôle et la plus ancienne version de client compatible.
La règle de l'équipe est simple : Si les designers veulent le changer chaque semaine, il doit être dans un lot. Si c'est de l'art ou du code, ça va dans le build.
À l'intérieur de cette limite, l'équipe peut toujours déplacer des événements, rééquilibrer les récompenses, ajuster les offres, activer ou désactiver des fonctionnalités ou des comportements d'achat, et exécuter des tests A/B sans retourner aux magasins. De nouveaux arts et de nouveaux codes nécessitent une compilation.
« Nous avons fixé cette limite intentionnellement afin que la surface vivante reste assez petite pour que, lorsqu'un élément casse, nous puissions identifier ce qui a changé », dit Granig.
La variété visuelle suit une approche de contrôle similaire. Les arènes sont construites à la main plutôt que générées de manière procédurale. Au lieu de dupliquer des environnements, l'équipe change leur apparence grâce aux matériaux, à l'éclairage et aux shaders sur la géométrie existante. Environ 35 graphes de shaders et 10 shaders écrits à la main composent ce système.
« Parce que les arènes sont construites à la main, nous pouvons prendre en compte tout ce qu'un joueur pourrait voir et tout mesurer, au lieu d'échantillonner et d'espérer. »
The Walking Dead: Aftermath | Studio Swift Games | Ares Interactive
Raccourcir le chemin de la feuille de calcul au jeu en direct
Une grande partie de la rapidité des opérations en direct de l'équipe provient des outils.
Les concepteurs modifient eux-mêmes la configuration. Les importateurs internes tirent les chapitres, le texte et les tableaux de récompenses directement à partir de feuilles de calcul, et la feuille de calcul reste la source de vérité.
Le résultat : Si l'équipe détecte un problème d'exploitation en direct ou d'équilibrage, elle peut déployer un correctif en environ 15 minutes au lieu de passer par un processus de publication complet.
Le pipeline de construction est également conçu pour raccourcir le temps d'itération. Le profilage approfondi est un commutateur de construction plutôt qu'une branche dédiée, donc les développeurs peuvent demander une version de profilage de ce sur quoi ils travaillent lorsqu'ils suspectent une régression. Travailler sur le cache et les temps de construction aide également l'équipe à gérer le grand nombre de constructions qu'elle produit chaque jour.
Parce que les changements d'interface utilisateur sont déployés chaque semaine, l'équipe s'appuie sur le simulateur d'appareil pour vérifier les encoches et les zones de sécurité sur différentes formes d'écran. Cela ne remplace pas les tests sur appareil physique, mais cela détecte les problèmes de mise en page plus tôt.
Le problème opérationnel le plus difficile provenait de la séparation des environnements de développement et de production. La configuration Firebase est intégrée dans les fichiers de construction, et les clés Firebase, Play Services, la configuration Facebook, les identifiants de paquet, les noms et les icônes doivent tous correspondre.
L'équipe a finalement transféré la responsabilité de ces environnements vers l'intégration continue (CI). Les versions de développement et les versions en direct utilisent des identifiants de paquet, des noms et des icônes différents, afin qu'elles puissent coexister sur le même appareil. Si une version de développement se connecte au serveur en direct, un avertissement dans le jeu apparaît. Les téléchargements échouent lorsque la configuration est manquante, au lieu de cibler silencieusement le mauvais environnement.
« Nous avons transféré la responsabilité dans le CI au lieu de la laisser aux gens », dit Granig.
Baseball Hits 26 | 7e manche | Ares Interactive
Commencez petit, testez tôt
Les deux équipes arrivent à la même leçon de directions différentes : Le développement de vie durable dépend de la décision précoce de ce qui doit changer, de l'isoler de ce qui doit rester stable, et de la construction de systèmes qui supposent que quelque chose finira par mal tourner.
Pour Baseball Hits 26, cela signifie un backend piloté par les données qui peut réagir rapidement à la vraie saison de baseball tout en empêchant les interruptions de jeu dues aux lancements clients, aux appareils et aux pannes de serveur.
Pour The Walking Dead: Après l'événement, cela signifie des systèmes vivants modulaires, une configuration étroitement contrôlée et une frontière délibérée : Le contenu peut changer à distance, tandis que le code et l'art sont livrés dans la construction.
Le conseil de Granig pour les équipes qui abordent leur premier jeu mobile en direct est de prouver l'expérience de base avant de construire la machinerie de service en direct autour.
Préparez un contenu d'un à trois jours et lancez-le avant de travailler sur quoi que ce soit d'autre. Regardez ensuite combien de joueurs reviennent le lendemain. S'ils ne reviennent pas, aucune quantité de contenu de fin de partie ne pourra le sauver, explique-t-il.
Alors refais-le. Ajouter du contenu, regarder le jour trois, et répéter. Commencez petit, testez tôt et laissez les chiffres vous dire si le jeu fonctionne. La partie difficile est de dire non à tout ce que vous voulez construire jusqu'à ce que la boucle principale se prouve.
Coups de baseball 26 et The Walking Dead: Aftermath sont maintenant disponibles sur l'App Store et Google Play. Consultez plus d'histoires de développeurs Unity sur le Blog Unity et le Resource Hub.