Merci aux équipes de Rainbow Six Siege UI et du Groupe technologique Pheonix, pour la réalisation de cet article.
Rainbow 6 Siege a été lancé il y a bien longtemps, du moins pour l’univers du jeu vidéo. Quand tu entames un jeu, tu rêves qu’il prospérera pour nombre d’années, toutefois peu de jeux relèvent ce défi. Et quand ça marche, tu dois envisager un nouveau problème, un bon problème: ton jeu doit pouvoir évoluer et s’adapter aux nouvelles technologies.
En 2018, Rainbow 6 Siege a pronostiqué un problème pour son jeu live. L’interface utilisateur (IU) roulait principalement sur Flash, notamment pour la création de menus et d’affichages heads-up («heads-up displays», ou HUD). D’autres entreprises utilisaient aussi principalement Adobe Flash, donc la plupart des artistes y étaient formés. Comme vous savez, Adobe a mis fin au soutien pour Flash et ne produit plus de mises à jour de l’application. Puisque notre IU a été conçue à base de Fire, une solution produite à l’interne qui ressemble à Scaleform (Scaleform fournit des API pour une communication directe entre le contenu Flash et le moteur de jeu, ainsi que des intégrations préfabriquées pour les moteurs plus populaires tels que Unity ou Unreal Engine), et donc indépendante des mises à jour d’Adobe, nous ne ressentions pas une urgence d’agir tout en étant au courant que l’échéance était à l’horizon et se rapprochait. Pendant ce temps, le Groupe technologique Ubisoft entamait un nouveau projet, une solution complète qui ne dépendait d’aucune technologie externe pour créer des IU: Phœnix Studio.
La mission du Groupe technologique est d’améliorer la productivité et l’efficacité des divers pipelines de jeu vidéo d’Ubisoft. Un des défis auxquels nous sommes fréquemment confrontés est celui d’anticiper les changements dans l’industrie, et la dépréciation de Flash par Adobe était inévitable. Mais il ne s’agissait pas d’un mince problème. Une solution externe voulait dire plusieurs choses sur plusieurs années et, même si elle était accompagnée de plusieurs inconvénients, elle présenterait de nombreux avantages que nous devrions pourvoir au sein d’Ubisoft: principalement la création d’un éditeur intuitif et flexible, afin de continuer de tirer parti de notre bassin de concepteurs IU talentueux.
Donc, tout en maintenant et soutenant un logiciel existant, une petite équipe du Groupe technologique s’est mise à œuvrer sur la conception de la plateforme Phoenix. Phoenix est une application dotée de nombreuses fonctionnalités et bâtie pour concevoir et intégrer du contenu IU de jeu (HUD, menus, signes et feedbacks), gardant le partage et l’extensibilité à l’esprit. Elle est composée de Phoenix Studio, d’un éditeur IU à base de nœuds, d’une bibliothèque Runtime à intégrer dans nos divers moteurs de jeu, ainsi que de la bibliothèque de widgets Phoenix pour partager les éléments de base communs déjà existants.
Aujourd’hui, elle évolue toujours vers la maturité, offrant une fonctionnalité plus avancée, mais a déjà été éprouvée en production par l’entremise de plusieurs jeux Ubisoft dont: For Honor, Trials, Anno, Hyper Scape et la franchise Ghost Recon.
Tandis que Phoenix grandissait et devenait un excellent outil pour créer, maintenir et déboguer l’IU, un nombre croissant de projets se sont mis à l’adopter plutôt que Fire. Et qu’advient-il de Rainbow 6 Siege? À l’époque, Rainbow 6 Siege était déjà live, avec une IU complète et fonctionnelle en Flash. Mais pour demeurer au sommet, nous devions faire une mise à niveau vers la meilleure et plus récente technologie pour l’avenir. Nous savions que nous devions faire le saut!
Phoenix permet à nos équipes et à toutes les autres équipes d’Ubisoft d’être plus créatives que jamais, tout en livrait des contenus IU qui peuvent être travaillés et mis à jour plus facilement. Évidemment, un important avantage de cette solution est qu’elle appartient à 100 % à Ubisoft. Ceci nous accorde plus de contrôle sur les fonctionnalités fournies par le Groupe technologique aux équipes comme la nôtre. Ça nous permet de partager et d’améliorer les outils à travers nos marques et aide à stabiliser nos versions. Le Groupe technologique est inspiré par les normes de l’industrie et fait une priorité de les suivre et d’offrir un outil de calibre mondial que nous utilisons sur Rainbow 6 Siege tous les jours.
Tandis que nous nous penchions sur le fonctionnement de la technologie, la nécessité d’améliorer le cadre d’application est devenue évidente, puisqu’il nous permettrait de faciliter la migration de Fire vers Phoenix et d’améliorer nos méthodes de travail. Nous avons pris le temps de déterminer les points faibles de notre pipeline et ce qui serait nécessaire pour les améliorer.
Ce cadre était nécessaire pour supporter les vues multiples (Fire, Phoenix) pour toute IU donnée. Ça s’imposait afin de rendre la migration possible et de «facilement» prendre en charge les changements de direction artistique, les événements spéciaux, les changements de design et plus encore.
Il devait être axé sur la stabilité et l’optimisation. L’inclusion d’un cadre de test afin de nous aider à saisir les problèmes plus rapidement a été ajoutée à la liste de caractéristiques. Nous voulions que ça roule mieux que la version Fire.
Il devait présenter une bonne séparation entre le code-cadre et le code du jeu et offrir les éléments de base nécessaires pour bâtir l’IU de n’importe quelle sorte de jeu. Nous avons opté pour une architecture modèle-vue—vue modèle (MVVM) afin d’aider à mettre en place une structure et une cohérence améliorées sur l’ensemble du code. Le MVVM est une architecture de logiciel qui permet de séparer la conception de l’interface graphique (la vue), de la conception de la mécanique de jeu ou du back end (le modèle), pour que la vue demeure indépendante de toute plateforme précise de modèle.
Ultimement, nous ressentons que le produit «final» atteignait nos requis et les objectifs que nous nous étions initialement fixés.
Une fois les fondements prêts et en place, c’était le moment de migrer les éléments de menu et de HUD vers Phoenix de Fire. Puisque la migration devait être faite en parallèle au maintien du jeu, nous devions recruter de nouveaux programmeurs et de nouveaux artistes. Au départ, nous avons commencé avec une migration facile — les gens s’habituaient encore à Phoenix et au nouveau cadre.
Puis le travail de migration majeur a démarré.
La première étape de tout portage informatique est de créer un nouvel aiguillage (switch) pour le module qui se fait transporter. Ceci nous permet d’être en mesure de rapidement retourner vers une version Fire en cas de problème.
Les modules d’IU vivent typiquement sur leur propre écran. Pour la plupart des portages de menu, nous avons réutilisé les écrans existants, mais dans certains cas (principalement les HUD), un nouvel écran devait être ajouté à la User Interface Factory. Cette Factory est responsable de la création et l’hébergement de tous les différents séquenceurs, compositions et écrans vus dans le jeu. C’est exécuté dans le code et, une fois dans Anvil, le programmeur ou la programmeuse est aussi chargé·e de soumettre les données d’écran.
La prochaine étape est d’arriver à comprendre si la nouvelle vue modèle est nécessaire pour chaque écran qui se fait transporter. Nous tentons de réessayer les vues-modèles si elles sont accessibles au sein du contexte de l’écran et elles contiennent déjà les informations nécessaires. Dans la plupart des cas, nous devions créer de nouvelles vues modèles dédiées.
Une fois créées, nous soumettons typiquement les vues-modèles au code base sans connexion au gameplay pour que les artistes puissent commencer leur travail le plus rapidement possible.
Pendant que les artistes travaillent fort sur l’intégration d’actifs et la création de liaisons de données, le programmeur ou la programmeuse ajoutera des signaux aux différents systèmes de jeu pour que la nouvelle vue-modèle puisse se connecter aux mises à jour des différentes valeurs qu’elle détient pour la vue. Par exemple, chaque fois qu’un·e joueur·se change de direction, un signal est envoyé à la boussole de la vue-modèle pour que les bonnes valeurs soient mises à jour et que la boussole pivote en conséquence.
Une fois que toutes les caractéristiques du modèle sont transportées au nouveau système, les testeur·ses de développement IU y mettent la main. Si aucun problème n’est révélé et que le comportement demeure 1:1, nous activons la switch pour que tou·tes les testeur·ses puissent tester le portage. Si tout est beau, nous gardons le portage activé et l’envoyons aux mains de nos joueur·ses!
Nous atteignons maintenant la fin de ce périple. Au moment d’écrire ces lignes, nous avons transporté et rendu actifs pour les joueur·ses 90 % des éléments de menus et de HUD.
Nous voyons que les pannes majeures de Fire diminuent et se ferment tandis que nous retirons tous les menus Fire. Nous voyons rapidement les mises à jour et les améliorations des menus Phoenix prendre forme.
Et pour la suite? Peut-être un robot IU pour tester chaque menu automatiquement, mais ça, c’est pour un autre billet!
