Architecture des opérations live d'Ares Interactive : gestion de Baseball Hits 26 et de The Walking Dead: Aftermath

Ares Interactive développe deux projets mobiles distincts avec des services live, ayant des exigences architecturales spécifiques. Baseball Hits 26, développé par le studio 7th Inning, est étroitement lié au calendrier réel de la MLB, nécessitant des mises à jour rapides pour refléter la forme actuelle des joueurs. The Walking Dead: Aftermath, de Swift Games, est un RPG d'action de type roguelite, où le défi principal consiste à étendre le contenu sans perturber la boucle de jeu principale. Les deux équipes misent sur des systèmes permettant des changements constants : elles équilibrent les nouveaux événements et offres tout en maintenant des normes strictes de performance et de stabilité sur les appareils mobiles.

L'infrastructure des opérations live pour Baseball Hits 26 repose sur un back-end et un système de livraison de contenu sur mesure. Ce système gère plus de 50 domaines de configuration couvrant les joueurs, les événements, les articles de la boutique et les passes de combat. Les modifications sont validées via un panneau d'administration et reprises par les serveurs en quelques secondes, sans redémarrage. Toutes les configurations sont versionnées et journalisées, permettant des retours en arrière faciles et des tests sur des comptes internes avant la mise en production. Un moteur de segmentation alimente les tests A/B, permettant à l'équipe d'essayer d'abord de nouvelles offres auprès d'un petit public. Cette configuration permet de mener jusqu'à quatre événements distincts par semaine, tels que Prime Club et Tower Club, chacun avec ses joueurs bonus et ses offres uniques.

Pour la livraison des assets dans Baseball Hits 26, Unity Addressables est utilisé, en particulier pour les bundles de stades. Un stade par défaut est inclus dans le téléchargement initial de l'application afin d'éviter toute friction pour les nouveaux utilisateurs. Tous les autres stades sont packagés en bundles séparés, téléversés sur le serveur et téléchargés à la demande lorsque le joueur les sélectionne. Chaque bundle est soumis à des tests de charge sur des appareils de basse gamme pour s'assurer qu'il respecte les budgets stricts de taille et de mémoire. Un bundle commun partagé contient les assets réutilisés sur différents stades, ce qui empêche la duplication des données. Cette approche permet au client de rester léger tout en offrant une grande variété d'environnements visuels.

The Walking Dead: Aftermath adopte une stratégie différente, en réutilisant des systèmes éprouvés d'un titre précédent, Heroes vs Hordes, pour la boutique, l'économie et l'authentification. Le noyau roguelite nouveau a été prototypé séparément puis fusionné sur cette base. Le contenu censé changer chaque semaine est créé dans des tableurs et publié sous forme de bundles distants, chacun étant marqué avec les versions du client prises en charge. Les données de sauvegarde utilisent une chaîne de migration versionnée pour éviter d'abandonner les joueurs de longue date, et l'heure est récupérée depuis le serveur pour garantir la précision des événements chronométrés. L'architecture repose sur une injection de dépendances à portée limitée avec quatre contextes imbriqués : racine, partie sauvegardée, écran principal et gameplay. Cela garantit que les événements en direct, structurés comme des installateurs plus des fichiers de configuration, sont proprement nettoyés lors de la fermeture de leur contexte.

Pour The Walking Dead: Aftermath, Addressables sont utilisés pour la gestion de la mémoire et le chargement, avec vingt-neuf groupes correspondant à des fonctionnalités individuelles. Le contenu en direct, en revanche, suit un pipeline distinct construit sur l'API AssetBundles. Ces bundles sont compilés pour chaque plateforme et incluent des hachages, des sommes de contrôle et des données de version de compatibilité. L'équipe adhère à une règle stricte : si les concepteurs doivent le modifier chaque semaine, cela va dans un bundle ; s'il s'agit d'art ou de code, cela est livré dans la build. Cette limite maintient la surface en direct petite et gérable. La variété visuelle est obtenue grâce à des arènes construites à la main, modifiées via des matériaux, de l'éclairage et environ 35 graphes de shaders, plutôt que par génération procédurale. Cela permet de mesurer et d'optimiser précisément chaque élément visuel.