Les Schtroumpfs – Mission Malfeuille est le quatrième et dernier projet auquel j’ai eu l’occasion de prendre part lors de mon aventure à OSome Studio, sur la période s’étalant de juin 2020 à octobre 2021.
Dans la continuité de mon travail sur Astérix & Obélix XXL 3 et Astérix & Obélix XXL Romastered, j’ai été chargé de concevoir le système de création et d’exécution des cinématiques, ainsi que de mettre au point et de maintenir différents outils nécessaires à la production du jeu.
- Cinématiques : un système pour les contrôler toutes
- Définition des cinématiques
- Un système modulaire
- Le carnet de Poète
- Des « levels » à la pelle
Cinématiques : un système pour les contrôler toutes
Définition des cinématiques
Contrairement au développement de Astérix & Obélix XXL 3, c’est à Laura Garcin que fut confiée la conception des cinématiques des Schtroumpfs, et non à moi : je ne fus chargé « que » de la conception des outils, pour aider Laura à créer ces cinématiques.
Pour remettre les choses dans leur contexte, il faut savoir que les cinématiques de Astérix & Obélix XXL 3 ont toutes été réalisées avec l’éditeur de cinématiques de OEngine. Cet éditeur donne une grande liberté créative : chaque élément composant ces cinématiques (mouvement de caméra, fondu au noir, déplacement de personnages) sont des blocs à placer sur une timeline, ce qui permet en principe de faire ce que l’on souhaite sans contrainte.
Malheureusement, ce manque de contrainte a rendu la production de ces cinématiques difficile à uniformiser, à maintenir et à peaufiner. Par exemple, obtenir un effet redondant (comme un fondu au noir au début et à la fin) ou ajouter n’importe quel détail pour chaque cinématique demandait de le refaire pour chacune d’entre elles manuellement et à l’identique. De plus, excepté la caméra en vue de dessus, il n’y avait aucune contrainte artistique imposée, pas de cadre ni de limites imposées à la création de ces cinématiques.
Pour ne pas réitérer les erreurs commises sur notre projet gaulois, nous avons convenu dès le début du projet avec Laura de mettre au point un nombre précis de types de cinématique, avec pour chacun d’entre eux un cadre et un intérêt narratif clairement défini :
- Les cinématiques « poème », inspirées des introductions de certains films Disney et centrées sur le carnet de Schtroumpf poète, marquent un changement narratif important.
- Les cinématiques « quête » interrompent le jeu et mettent en scène une conversation entre Schtroumpfs, à l’occasion d’une progression dans l’histoire et des objectifs du joueur.
- Les cinématiques « talkie-walkie » et « monologues », conversation à distance entre Schtroumpfs ou simple aparté solitaire, ponctuent l’aventure sans entraver les mouvements du joueur. Certaines le font tout de même parfois lors d’un mouvement de caméra mettant en avant un élément particulier.
- Les cinématiques « secondaires » définissent les bavardages avec les personnages non joueurs.
Un système modulaire
Techniquement, tous ces types de cinématiques utilisent le même système modulaire : l’idée est qu’une cinématique est composée d’un enchaînement de répliques, qui sont jouées les unes à la suite des autres. Sur ces répliques peuvent venir se brancher différents comportements : animations de personnages, positionnements de la caméra, affichage de la réplique dans l’interface…
Pour faciliter la tâche de Laura, chaque type de cinématique dispose de son propre modèle avec un comportement bien défini :
Une cinématique de type « talkie-walkie » est très simple à concevoir : il est seulement nécessaire de renseigner les répliques que l’on souhaite, tous les autres détails étant déjà paramétrés dans le modèle. Pour une cinématique de type « monologue » et « secondaire », la conception est identique, les modèles sont simplement configurés différemment.
Pour une cinématique de type « quête », en plus de renseigner les répliques, il suffit de placer les personnages impliqués dans la conversation, et de créer les caméras qui seront liées à une ou plusieurs répliques. Le fondu au noir en début et fin de cinématique, la mise en sommeil des ennemis, ainsi que le verrouillage des actions du joueur sont quant à eux déjà paramétrés. Il est aussi possible de choisir les animations jouées par chaque Schtroumpf présent, pour toute la cinématique ou plus spécifiquement pour chaque réplique.
De plus, pour tous les types de cinématique, les Schtroumpfs bénéficient d’animations supplémentaires :
- La bouche du Schtroumpf qui parle s’anime automatiquement.
- Si deux Schtroumpfs discutent, ils se regarderont automatiquement. S’ils sont trois ou plus, tous regarderont leur interlocuteur : il ne restera plus qu’à définir le membre de la conversation que l’interlocuteur doit regarder. Il est bien sûr possible de forcer un personnage à en regarder un autre, si ce comportement ne convient pas à certaines répliques.
Ces automatismes fonctionnent grâce à des informations contenues dans les identifiants des répliques : par exemple, la réplique « QUEST_Z4_01_COST_L2 » est la deuxième réplique (L2) de la première cinématique « quête » de la zone 4 (QUEST_Z4_01), dictée par Schtroumpf Costaud (COST). Cet identifiant de personnage est utilisé pour retrouver son GameObject et l’animer, via une base de données qui associe pour chaque personnage leur identifiant à leur GameObject. Ce système étant centralisé, il est donc seulement nécessaire de renseigner un personnage dans cette base de données pour qu’il soit animé, pour toutes les cinématiques où il apparaîtra, peu importe leur type. De la même manière, l’effet sonore « talkie-walkie » est appliqué sur la voix d’un personnage si l’identifiant de la réplique contient l’information « _TW ».
Enfin, un système de priorité a été mis en place pour que les cinématiques ne puissent se superposer. Si une cinématique se joue et qu’une autre de priorité supérieure ou identique doit débuter, cette dernière démarrera et la précédente sera stoppée. À l’inverse, si une cinématique se joue et qu’une autre de priorité plus basse doit débuter, elle sera ignorée. Les cinématiques de type « quest » prendront toujours le pas sur les cinématiques de type « talkie-walkie » et « monologue », qui elles-mêmes surpasseront toujours les cinématiques de type « secondaires ».
Le carnet de Poète
Les cinématiques de type « poème » sont elles aussi construites avec le système modulaire décrit précédemment. Mais ici, à la différence des autres types de cinématique, ce ne sont pas de simples caméras qui sont liées à chaque réplique, mais des objets de cinématiques, éditables grâce à l’éditeur de cinématiques « classique » de OEngine (celui utilisé pour Astérix & Obélix XXL 3). Ce système hybride permet de bénéficier du meilleur des deux mondes :
- L’exécution de la cinématique est gérée par le système modulaire, qui dispose d’un modèle paramétré à l’avance pour ce type de cinématique, et il est aisé d’y renseigner les répliques.
- L’utilisation d’objets de cinématiques donne accès à la souplesse créative offerte par le placement de simples blocs sur une timeline. Il est donc possible d’utiliser le bloc d’animation de caméra (décrit ici), ainsi qu’un autre bloc spécialement conçu pour ce projet, qui permet d’animer le carnet de poète comme bon nous semble (l’ouvrir, le fermer, tourner ou animer une page).
Ce système hybride apporte également une solution à un des problèmes de conception des cinématiques de Astérix & Obélix XXL 3 : la gestion de la durée variable des répliques localisées. En effet, en fonction de la langue d’un jeu, la durée des répliques n’est jamais identique, ce qui pose problème quand les cinématiques sont conçues avec des blocs de durées fixes dans une timeline de durée fixe, tels que fonctionnent les objets de cinématique de OEngine. Après coup, un algorithme avait été mis en place pour adapter automatiquement la durée et la disposition des blocs en fonction de la langue, mais les cinématiques étant composées d’enchaînements de blocs complexes, il était impératif de vérifier le résultat obtenu pour chaque cinématique dans chaque langue, et si nécessaire de modifier la disposition initiale des blocs, pour que l’algorithme puisse fonctionner correctement. Un travail très fastidieux.
Grâce au système modulaire, il est inutile de se soucier de la durée des répliques : elles seront jouées les unes à la suite des autres. De plus, si un objet de cinématique est lié à une ou plusieurs répliques consécutives, sa durée sera automatiquement identique à celle des répliques auxquelles il a été lié. Les blocs placés se joueront ainsi toujours uniformément, peu importe la langue et la durée des répliques (mouvement de la caméra, animation du carnet, …). Une fois de plus, et contrairement à Astérix & Obélix XXL 3, toute la conception des cinématiques a donc été pensée pour être la plus simple et la plus automatisée possible.
Enfin, éléments centraux de ces cinématiques, les 30 pages du carnet de Poète sont complètement éditables dans l’éditeur de OEngine ! Chaque page est en réalité un canvas d’UI, constitué de 4 layers superposés, chacun d’entre eux étant composé d’un « albédo », et d’un masque utilisé pour animer l’apparition du layer. L’albédo et le masque sont créés à partir de simples éléments d’UI, c’est-à-dire d’images ou de textes.
Pour les 4 layers d’une page, l’albédo et le masque sont rendus séparément dans un total de 8 textures par page, envoyées à un shader qui gère l’apparition de l’albédo de chaque layer en fonction d’une valeur et du masque associé. Cette valeur est animable dans le bloc de cinématique décrit plus haut.
Il est aussi possible de travailler avec 2 éditeurs (ou plus !), pour éditer les pages du carnet et vérifier en temps réel le résultat dans la cinématique finale.
L’un des intérêts de composer les pages directement dans l’éditeur (et non pas directement dans Photoshop) est que la localisation des textes est gérée naturellement en temps réel, comme les autres parties de l’interface.
Des « levels » à la pelle
Indépendamment des cinématiques, des améliorations de l’éditeur et du portage PS5 et Xbox Series de OEngine, j’ai aussi mis en place quelques outils pour aider à la conception des niveaux du jeu.
Dans OEngine, un niveau de jeu peut être composé de multiples fichiers « .level », ce qui est plutôt pratique pour travailler à plusieurs sans se marcher les uns sur les autres. Habituellement, nous mettons ainsi en place un découpage des niveaux en différents fichiers « .level » thématiques, que nous nommons la « nomenclature des niveaux ». Afin d’aider à respecter cette nomenclature pour l’ensemble du jeu, j’ai créé un outil qui génère automatiquement tous les fichiers « .level » nécessaires, et qui permet également de vérifier ultérieurement si la nomenclature n’a pas été altérée par inadvertance, comme en supprimant un fichier « .level », ou en modifiant la hiérarchie…
Pour la nomenclature des niveaux des Schtroumpfs, nous avons convenu que chacun d’eux serait composé de fichiers « .level » spécifiques pour le blockout et pour l’habillage graphique. Les fichiers blockout ont été utilisés par les level designer pour créer la structure des niveaux, tandis que les fichiers d’habillage graphique ont été utilisés par les level artist pour… habiller les niveaux. Ce sont ces derniers qui sont chargés et jouables dans le jeu final. Pour faciliter le travail des designers, j’ai donc introduit dans l’éditeur un bouton permettant d’alterner facilement entre les deux versions.
