Développé par OSome Studio et édité par Microids, Astérix & Obélix XXL Romastered est le remaster du jeu du même nom sorti le 21 novembre 2003 sur PS2. Un jeu auquel j’ai beaucoup joué à l’époque (sur sa version PC) ! C’est donc avec un grand plaisir que j’ai contribué au développement de cette version « romastered », sur la période s’étalant d’octobre 2019 à juin 2020.
J’ai été chargé de mettre en place et de maintenir les outils nécessaires au bon déroulement de la production : de la remise en marche à la maintenance de l’éditeur du jeu de l’époque, ainsi que par la création et l’amélioration d’outils existants (comme un plug-in C++ pour Maya et autres script Python). J’ai aussi œuvré entre autres à l’élaboration du mode rétro et au fignolage général post-release du jeu.
- Comment fonctionne le remaster ?
- Le retour de Kal
- Le format KIF
- Des animations retravaillées
- Un hommage au jeu d’origine
Comment fonctionne le remaster ?
De la même façon que le remaster d’Astérix & Obélix XXL 2 sorti en 2018, Astérix & Obélix XXL Romastered est un projet techniquement atypique, qui fonctionne avec deux moteurs de jeu : OEngine et K. OEngine est le moteur propriétaire d’OSome Studio, utilisé pour Astérix & Obélix XXL 3 ou encore White Night. K est le moteur propriétaire d’Étranges Libellules, utilisé pour la plupart de leurs jeux, y compris XXL. C’était d’ailleurs le premier pour lequel il a été utilisé : le moteur ayant été conçu en parallèle du jeu !
Mais comment peut-on utiliser 2 moteurs à la fois pour un seul jeu ? En fait, ce n’est pas tout à fait exact : c’est bel et bien OEngine qui est utilisé pour le remaster. Simplement, comme un marionnettiste et son pantin, il exécute le code du jeu d’origine, c’est-à-dire celui de K et de XXL lui-même.
Le schéma ci-dessus illustre cela. À gauche, la structure du code du jeu d’origine : K, composé de ses différents modules (Renderware pour le rendu graphique, DirectInput pour les inputs, etc.) exécute le jeu. À droite, c’est la structure du remaster : K est maintenant inclus dans OEngine et amputé de ses modules. OEngine exécute K, qui lui même exécute le jeu. De plus, OEngine prend en charge le rendu graphique, le rendu sonore, la détection des inputs, rendant l’ensemble fonctionnel sur nos Switch, PS4, Xbox One et PC modernes.
Quand j’évoque « le jeu » qui est exécuté par K, je veux bien sûr parler de la boucle de gameplay : déplacement des personnages, comportement de l’IA, etc. K s’occupe de son côté de tâches plus génériques, comme de jouer les animations 3D des personnages, entre autres.
Pour dessiner une image à l’écran, OEngine réplique la scène de K dans sa propre scène, et place tous les éléments au bon endroit. Si K instancie 10 romains dans sa scène, OEngine va instancier 10 romains identiques dans la sienne. Si l’animation de course d’Astérix est jouée par K, chaque os de son squelette suivra dans OEngine. L’idée est de laisser K exécuter le jeu comme à l’époque, pendant que OEngine se contente d’imiter l’action pour la rendre à l’écran.
La particularité de ce remaster est de pouvoir passer en temps réel du rendu visuel et sonore remastérisé au rendu visuel et sonore original. Contrairement à ce que l’on pourrait penser, le rendu original n’est pas du tout géré par K, mais bel et bien par OEngine, exactement comme le rendu remastérisé.
Intéressons-nous plus particulièrement au rendu visuel : comment fonctionne-t-il ? Précédemment, j’expliquais que pour dessiner une image à l’écran, OEngine répliquait la scène de K dans sa propre scène. En fait, il le fait 2 fois : une fois pour le rendu visuel original, et une autre pour le rendu visuel remastérisé. Les objets originaux et remastérisés sont dessinés dans deux passes de rendus différentes. Ces passes (qui sont des images) sont ensuite blend avant que le résultat ne soit affiché à l’écran.
Le retour de Kal
De la même manière que Unreal Editor permet de concevoir les jeux fonctionnant avec Unreal Engine, K va de pair avec son propre éditeur : Kal.
Le remaster comporte de nombreuses améliorations, comme 2 nouveaux modes de jeu, des modes de difficultés, des nouvelles animations, etc. Pour les intégrer dans le jeu d’origine, il était donc impératif d’utiliser Kal pour modifier les données de l’époque.
C’est à moi qu’a été confiée la tâche de raccommoder Kal : à partir du code source d’origine, de nouvelles versions de l’éditeur ont pu être compilées, puis livrées aussi souvent que nécessaire à Corentin Loth-Guillon, notre level designer sur le projet. Cependant, tout ne fut pas si simple : variables non initialisées, crashs mémoire ou asserts en tout genre ont rythmé la production, ce qui n’a pas aidé à ce que Corentin puisse travailler dans les meilleures conditions. Afin qu’il puisse éditer tout ce dont il avait besoin (placer de nouvelles caisses, de nouveaux romains et j’en passe), beaucoup de temps a donc été consacré à améliorer la stabilité de Kal, et nous avons étroitement travaillé ensemble pour réussir à dompter la bête.
Entre quelques résolutions de bugs, j’ai eu l’occasion d’ajouter quelques fonctionnalités à l’éditeur, par exemple la possibilité de modifier la rotation d’un objet via les angles d’Euler. Très commune dans nos éditeurs modernes, cette fonctionnalité n’existait pas dans Kal, fut-elle pourtant bien pratique !
Bien que tout ce travail ne connaîtra jamais la postérité, défricher un éditeur vieux de 17 ans était un défi très intéressant en tant que programmeur ! De plus, voir l’envers du décor d’un jeu de mon enfance était tout aussi émouvant ! Un vrai travail d’archéologie !
Le format KIF
Aujourd’hui, le format FBX est couramment utilisé pour exporter les modèles et animations 3D créées depuis les logiciels Blender ou Maya vers les éditeurs de jeu comme OEngine ou Unity. Toutefois, pour concevoir les modèles 3D de XXL et leurs animations, les graphistes d’Étranges Libellules avaient à l’époque utilisé un logiciel 3D propriétaire au studio. Ces ressources étaient exportées vers Kal dans un format lui aussi propriétaire : le format KIF.
Tout comme ce fut le cas pour le code, nous avions à notre disposition les ressources du jeu d’origine comme matière brute, incluant tous les modèles 3D dans des fichiers KIF. Pour permettre aux graphistes de les remastériser et de les exporter au format FBX vers OEngine, il nous fallait être capables d’importer ces fichiers KIF dans Maya.
Coup de chance, pour la production de XXL 2 en 2004, le logiciel 3D propriétaire avait été abandonné au profit de Maya… mais pas le format KIF, toujours utilisé par Kal ! Les programmeurs de l’époque avaient donc conçu un plug-in C++ pour Maya, permettant d’importer et d’exporter des géométries ou des animations au format KIF. Pour la production du remaster, l’un de ces programmeurs, devenu cofondateur d’OSome Studio depuis, m’a passé le flambeau : j’ai donc été chargé de maintenir et de faire évoluer ce plug-in Maya.
Très tôt dans le projet, je me suis attelé à écrire un script Python permettant d’importer un à un chaque fichier KIF dans Maya pour les exporter en FBX. Une fois la synchronisation entre K et OEngine (évoquée dans la première partie de cet article) rendue fonctionnelle par Pierre Sénéclauze, j’ai pu vérifier directement en jeu si tous mes imports et exports étaient corrects… Ce qui n’était évidemment pas le cas !
Plusieurs raisons à cela : la première est que le plug-in C++ avait été conçu à l’époque pour importer et exporter des géométries créées dans Maya. Ce qui n’était pas le cas ici, les fichiers KIF de XXL ayant été exportés depuis le logiciel propriétaire d’Étranges Libellules. Bones renommés, rigs non centrés, problèmes d’échelle… entre ces problèmes d’import et les crashs de Kal évoqués dans la précédente partie de cet article, je ne risquais pas de m’ennuyer !
La seconde raison est plus triviale : depuis 2004, les techniques 3D ont quelque peu évolué ! En particulier, l’import du skin des géométries n’était plus du tout fonctionnel. Il a donc fallu que je réécrive entièrement cette partie du plug-in C++. C’était très intéressant et enrichissant : j’ai ainsi eu l’occasion d’apporter ma pierre à l’édifice, au lieu de simplement corriger des problèmes épars.
Une fois que tous les problèmes liés à l’import des fichiers KIF dans Maya furent résolus, les graphistes ont ainsi pu débuter la conception des modèles 3D remastérisés !
Des animations retravaillées
Le remaster comporte quelques animations retravaillées par rapport au jeu original, notamment la course d’Astérix et d’Obélix. Un apport sympathique pour le joueur qui ne fut pas si simple à concrétiser ! Car comme expliqué précédemment, c’est K qui est chargé de jouer les animations. Pour ajouter de nouvelles animations au jeu, il fallait donc comme à l’époque les importer dans Kal… ce qui implique d’être capable de les exporter au format KIF.
Dans la continuité de mon travail de dépoussiérage du plug-in C++ utilisé pour importer des fichiers KIF dans Maya, j’ai donc également été chargé de remettre en état l’export de géométries et d’animations 3D de Maya vers un fichier au format KIF, pour les intégrer dans Kal.
Le défi, c’est qu’il ne suffisait pas d’exporter chaque animation dans un fichier KIF séparé. En fait, un fichier KIF contient la géométrie (le mesh, le rig, le skin), mais aussi toutes les animations utilisées par le modèle 3D. À titre d’exemple, asterix.kif ne contient pas moins de 80 animations ! Pour en ajouter rien qu’une seule, il fallait donc réexporter le fichier KIF au complet. C’est précisément ce qui m’a causé le plus d’ennui, Kal n’ayant pas apprécié que je modifie des fichiers KIF vieux de 17 ans. Parmi les conséquences : le changement d’ordre des os du squelette, qui détacha les éléments qui étaient liés au squelette des personnages par l’index des os (par exemple, des effets de trainées).
Le code exécuté pour importer des animations d’un fichier KIF vers Maya n’était pas non plus exempt de souci : les courbes d’animations n’étaient pas correctement interprétées (clés manquantes, rotations cassées…). Il a aussi fallu entièrement écrire le code d’import des « points chauds » (des attaches sur le squelette des personnages), qui n’existait pas et dont Kal avait besoin !
Le second challenge consistait à intégrer les animations retravaillées uniquement dans le rendu visuel remastérisé, et conserver les animations de l’époque dans le rendu visuel original. Pour ce faire, j’ai opéré directement dans le système d’animation de K, en remplaçant le dictionnaire d’animations par un dictionnaire de paires d’animations. Sans toucher au code gameplay, j’ai ainsi dédoublé chaque animation, permettant de switcher de l’une à l’autre à chaque changement de rendu visuel.
Un hommage au jeu d’origine
Dès le début du projet, notre intention était de redonner vie au jeu d’origine, en permettant de passer à tout moment du rendu visuel et sonore remastérisé au rendu visuel et sonore original. Ayant été chargé d’importer les modèles 3D d’origine au format KIF dans Maya (pour que les graphistes puissent concevoir les modèles 3D remastérisés), c’est naturellement moi qui me suis occupé de réexporter tous les modèles 3D d’origine au format FBX, pour les intégrer dans OEngine.
Pour que ces modèles 3D aient le même rendu visuel qu’à l’époque, il était impératif de configurer fidèlement leurs matériaux et leurs textures dans OEngine. Pour ce faire, j’ai exporté depuis Kal toutes les informations qui m’ont été nécessaires : types des matériaux (opaque, cutout, brillant ou non, animé ou non), filtrage de chaque texture (pixelisées ou non), à quel matériau est associé quel KIF, quelles textures sont associées à chaque matériau, etc.
Basé sur ces données, j’ai ensuite créé plusieurs outils me permettant de paramétrer automatiquement chaque matériau et chaque texture dans OEngine. Tout cela s’est fait par itération : tout ce processus d’intégration étant automatisé, il me suffisait d’ajuster ma moulinette pour retranscrire le plus fidèlement possible le rendu visuel de l’époque.
Certains éléments visuels ont cependant demandé un effort supplémentaire : c’est le cas de l’eau. Contrairement au reste des objets, celle-ci n’était pas un objet KIF, mais générée directement dans Kal. Partant du travail initial de Pierre Sénéclauze, qui avait exporté les surfaces d’eau d’origine comme autant de plans d’une taille correspondante (qui ont été utilisés dans le rendu visuel remastérisé), je me suis amusé à exporter directement les meshs d’eau générés dans Kal au format FBX (incluant les jolies petites vagues). J’ai ensuite pris un soin tout particulier à les intégrer dans le rendu visuel original de OEngine, en concevant un shader d’eau reproduisant même une erreur de colorimétrie présente dans le jeu d’origine.
Le ciel était lui aussi un cas particulier, qu’il nous fallait reproduire dans OEngine. Thomas Bonis s’est chargé de créer le shader ainsi que les outils permettant aux graphistes de colorer le ciel comme bon leur semble dans le rendu visuel remastérisé. Pour le rendu visuel original, je me suis occupé d’insérer les couleurs du ciel calculées par K dans le shader du ciel. Mais aussi de synchroniser la distance d’affichage de la caméra et du brouillard du jeu d’origine avec celles du remaster. Sous potion, sous twister, en Égypte ou en Normandie, le ciel est donc totalement identique à celui que l’on pouvait observer en 2003 sur PS2 !