Studio X Labs a eu le privilège d'assurer l'intégralité de la conception sonore, de la programmation audio, du mixage in-game et des systèmes de lecture pour Reverse Collapse : Code Name Bakery. Ce projet a marqué notre première collaboration à long terme avec un développeur d'origine chinoise. L'utilisation de Wwise comme moteur audio a été déterminante pour offrir une solution audio optimale.

Le défi et le plaisir de créer des sons pour les jeux vidéo résident souvent dans la résolution de problèmes et le développement des pipelines, systèmes et structures nécessaires pour obtenir le meilleur mixage possible de tous les éléments audio. Pour Reverse Collapse, notre aventure s'est étalée sur quatre ans, avec une pause de huit mois en 2022 pour permettre une expansion significative de l'histoire et des missions.

Malgré les défis posés par les différences de fuseaux horaires et de langues, nous avons mis en place un processus qui a permis au jeu d'être bien accueilli par les fans de la franchise Girls Frontline.

Critiques presse :

« Reverse Collapse : Code Name Bakery est un jeu divertissant et visuellement captivant. Mais en plus de son aspect visuel soigné, sa conception sonore a également été particulièrement travaillée. La musique donne le ton, tandis que la conception sonore apporte toute la puissance nécessaire. Même sans dialogues traduits en anglais, le jeu bénéficie d'un doublage solide, les coups de feu sont aussi percutants qu’on s’y attend et les explosions ont beaucoup d'intensité, ce qui offre une expérience immersive parfaitement adaptée à l'environnement et à ce genre de jeux. » 4/5 - Hardcore Gamer


« Avec un équipement audio adapté, vous pouvez profiter pleinement des excellents effets sonores du jeu. Grâce à ses explosions et ses coups de feu incisifs, le jeu offre une immersion d’une intensité presque divine. De plus, la manière dont chaque soldat ennemi se déplace sur le champ de bataille, avec des pas lourds, rythmés et presque menaçants, ajoute une tension tout à fait adaptée à chaque mission. »  92/100 - Game8

Création du pipeline d'implémentation du contenu :

Au début du projet, nous avons dû développer un pipeline de contenu robuste afin de fournir efficacement le contenu audio de plusieurs domaines clés :

• Conception sonore : Créer des sons pour les personnages, les armes et les environnements afin d'accompagner des milliers d'animations personnalisées.
• Localisation : Garantir une lecture fluide des dialogues japonais du jeu.
• Système de musique interactive : Implémenter un système de musique dynamique capable de s'adapter en temps réel aux changements de gameplay, minute par minute.

Animations des personnages :

Reverse Collapse est un jeu qui propose un grand nombre de personnages et d'animations personnalisées. Afin de gérer efficacement ce volume important d'animations nécessitant des effets sonores, nous avons implémenté un système de dossiers basé sur des Switch Containers imbriqués. Cette méthode nous a permis de réduire au minimum le nombre d'AKEvents appelés depuis Unity, ce qui a grandement simplifié le processus tout en offrant une plus grande flexibilité dans la conception sonore pour chaque personnage de base. Grâce aux Switch Containers imbriqués, nous avons pu diriger efficacement les Events de chaque personnage vers leurs dossiers respectifs. Ce système s'est avéré indispensable au vu du nombre d'animations à gérer.  On comptait 27 personnages jouables et 72 personnages ennemis, tous partageant la même structure de dossiers de Switch Containers imbriqués. Voici le dossier de Switch Containers du personnage principal, Mendo : 

Chacun des Switch Containers du dossier de Mendo est associé à un type d'Event spécifique, comme « Run » (courir), « Grab » (saisir) ou « Putback » (déposer). Pour les actions de type « Run », nous avons également intégré toutes les variations liées aux différentes surfaces environnementales. Pour les animations de type « Death » (mort), chaque Blend Container contient des assets SFX organisés dans des dossiers de Random Containers, permettant d'obtenir des variations et un timing adaptés aux animations personnalisées des personnages. Les actions de type « Grab » regroupent des animations pour chacun des 52 objets utilisables.

Cette structure peut se développer de manière significative ; par exemple, avec 27 personnages manipulant chacun 52 objets, cela représente 1 404 animations de type « grab » et 1 404 animations de type « putback » supplémentaires pour l'ensemble des personnages jouables. L'utilisation de Switch Containers imbriqués a grandement simplifié la gestion de ces appels d'Events. 

Étant donné que de nombreux personnages partagent des types d'animations similaires (comme courir, tomber, mourir ou saisir des objets), nous avons optimisé l'utilisation de la mémoire en réutilisant une grande quantité des assets SFX pour tous les types de personnages. Les sons tels que les bruits de pas, les froissements de vêtements (foley) ou l'utilisation d'objets ont été efficacement dupliqués pour tous les personnages, une fois les assets de base créés.

Le travail le plus chronophage a été de tester et d'ajuster chaque animation de personnage et d'ennemi dans le parking de personnages, en apportant des réglages précis sur le timing des effets sonores pour correspondre aux animations personnalisées. Avec littéralement des milliers d'animations de personnages, notre choix d'utiliser des Switch Containers pour gérer et répartir les Events de personnages et d'ennemis s'est révélé être la solution la plus efficace.

Armes :

Pour les armes, nous avons également utilisé des Switch Containers, mais comme les personnages jouables peuvent manipuler n'importe lequel des 52 objets, nous avons inversé la logique d'organisation des dossiers en les basant sur les personnages.  Ainsi, dans chaque Switch Container d'objet, on retrouve des Blend Containers de personnages, ce qui apporte la même flexibilité et permet à chaque interaction avec un objet d'être spécifique au personnage.  Comme le jeu comportait de nombreuses animations personnalisées, nous avons pu réduire le nombre d'Events de compétences appelés par le jeu et laisser Wwise déterminer automatiquement la destination de l'Event à jouer via l'objet global référencé.

Système de musique interactive

Reverse Collapse est un jeu reconnu pour ses compositions musicales intenses et soigneusement élaborées, qui renforcent à la fois l'immersion dans le gameplay et la vision artistique globale. Pour ce projet, nous avons travaillé en étroite collaboration avec le talentueux compositeur chinois G.K., surtout connu pour son travail sur Girl's Frontline et Project Boundary.

Le système de musique a été conçu pour être interactif et évolutif, afin de s'adapter à la grande diversité des niveaux du jeu. Chaque niveau comporte jusqu'à 3 phases et, pendant les tours ennemis, le mixage musical présente des modifications spécifiques afin de refléter le basculement de gameplay et d'enrichir l'expérience de jeu pendant que les unités ennemies exécutent leurs actions. En outre, certains cas particuliers, comme les musiques des combats de boss ou la restauration fidèle de la musique des niveaux du jeu original de 2013 utilisés dans ce remake, ont nécessité un traitement particulier.

Pour atteindre cet objectif ambitieux, nous avons exploité au maximum les outils proposés par Wwise. Ces outils incluent une Interactive Music Hierarchy très flexible, comprenant notamment des Music Switch Containers imbriqués et des States permettant de contrôler la musique à jouer. Nous avons aussi intégré des Music Cue personnalisés pour les musiques de boss en complément des States de musique, ainsi que des RTPC connectés de manière fluide aux Music Tracks, en les intégrant directement dans le code du jeu.

Music Switch Containers et States

Reverse Collapse propose plus de 60 heures de contenu et plus de 60 niveaux distincts. Pour gérer cette grande quantité de données, nous avons choisi de faire correspondre les noms de notre contenu musical aux noms utilisés dans chaque niveau, comme illustré dans l'image ci-dessous.

L'image ci-dessus illustre un exemple de configuration du système de musique interactive pour le Chapitre 1 du jeu. Des configurations similaires on été utilisées dans les dossiers suivants. Au départ, nous avions envisagé d'identifier des pistes uniques afin de réduire le nombre de Music Playlist Containers nécessaires. Cependant, après avoir évalué les avantages et les inconvénients, nous avons décidé d'attribuer trois Music Playlist Containers pour chaque niveau. Voici quelques-unes des raisons qui ont motivé ce choix :

Avantages :

• Cette solution est universelle. Chaque niveau peut comporter jusqu'à 3 phases ; certains n'en ont qu'une ou deux. Dans ce cas, il suffit de réutiliser les mêmes Music Segments pour les phases qui ne sont pas nécessaires. Cette approche s'avère à la fois efficace et adaptable.
• Elle correspond au tableau de données du jeu, ce qui nous permet d'utiliser la variable levelId, déjà intégrée dans l'ensemble du jeu, également pour le système de musique. Cela garantit une cohérence dans l'intégration.
• Elle facilite également l'intégration avec nos systèmes de gestion des SoundBanks, chaque niveau disposant de ses propres SoundBanks pour les fichiers musicaux et les cinématiques. Cela simplifie le processus et assure une organisation efficace.
• Cette configuration offre la flexibilité nécessaire pour traiter un niveau de manière spécifique sans affecter les autres, ni risquer de provoquer des conséquences indésirables.
• Compte tenu de notre collaboration à distance avec l'équipe de Shanghai, une communication fluide et une itération rapide sont essentielles en raison du décalage horaire. Comparativement au rythme habituel de travail en présentiel, la communication peut s'avérer plus lente. Pour optimiser ce processus, nous avons dressé la liste de tous les niveaux du jeu afin que toute personne travaillant sur l'Interactive Music Hierarchy puisse s'y retrouver rapidement. Cette méthode facilite la gestion et la modification des fichiers pour le compositeur comme pour le concepteur sonore.
• Le code requis est considérablement réduit, car il n'est pas nécessaire de sélectionner individuellement de manière interactive les morceaux de musique à jouer. Grâce à cette configuration, dès qu'un niveau est chargé, la musique correspondante est automatiquement lue. Cela simplifie le développement et allège la charge de codage.

Inconvénients :

• Le processus de configuration initiale dans Wwise peut être long et fastidieux, mais une fois mis en place, le système est très simple à utiliser.
• Il existe un risque d'erreurs dues à la similarité des noms et des structures, ce qui rend les problèmes plus difficiles à repérer et à tester rapidement.
• Les modifications apportées au contenu musical situé dans la structure du système de musique de Wwise prennent plus de temps, car il faut les répercuter à tous les Containers utilisant les même Music Tracks modifiées.

RTPC pour les tours ennemis

Les tours ennemis sont fréquents dans le jeu, en particulier dans les niveaux avancés, et peuvent prendre du temps pour les joueurs qui observent les actions sur la carte. Même si ce processus peut être accéléré en appuyant sur un bouton, nous avons souhaité améliorer l'expérience de jeu en modifiant la musique, par l'usage d'un mix alternatif pour les joueurs qui choisissent de suivre attentivement les déplacements ennemis.

Le processus commence par l'alternance des Music Tracks d'origine. Le compositeur G.K. a brillamment relevé le défi en s'adaptant rapidement aux imprévus et en nous livrant des morceaux remixés pour les tours ennemis, d'une durée identique à celle des morceaux des tours de combat habituels.

De notre côté, nous avons appliqué un traitement spécial en dupliquant la structure et en implémentant un RTPC avec un temps d'interpolation pour assurer un fondu enchaîné fluide entre les musiques des tours joueur/allié et des tours ennemis. Lorsque le tour ennemi débute, ce RTPC passe progressivement de 0 à 1, et inversement, passant ainsi progressivement à un mix alternatif.

La capture d'écran ci-dessus montre comment le RTPC est ajusté. Dans le code, nous avons lié cet appel de RTPC au début du tour ennemi, et nous le réinitialisons au début du tour joueur ou allié.

Dans l'onglet Events, notre Event musical principal déclenche simultanément deux Switch Containers, chacun avec des propriétés de mixage différentes. Nous pouvons déterminer à tout moment lequel jouer en utilisant le RTPC mentionné plus haut. Comme les deux versions musicales ont exactement la même durée, les déclencher simultanément et les alterner avec un RTPC nous permet d'obtenir des transitions parfaitement fluides entre le mix du tour ennemi et celui du tour joueur/allié.

Transition des Music Segments de boss

Pour gérer le cas particulier des combats de boss, nous avons intégré un RTPC dans le système de musique interactive à 3 phases déjà en place. Cette configuration permet une transition fluide entre le Music Segment de combat classique et celui du boss à tout moment du jeu.

L'un des défis majeurs de cette configuration est que les Music Segments de boss peuvent avoir une durée différente de ceux de la musique de combat classique. Cela peut poser problème si le Segment cible est plus court que le Segment en cours, risquant de provoquer un moment de silence indésirable dans la bande musicale.

L'image ci-dessus illustre ce problème de transition entre deux Music Segments. Étant donné que les deux Segments sont lus simultanément pendant la transition, si nous tentons de passer à RC_RW_B10_pre_Upver à la fin de RC_Boss3_preV2, un bref silence peut se produire, ce que nous voulons éviter.

Pour contourner ce problème, nous avons utilisé la fonction Seek() (Seek (audiokinetic.com)) et deux Music Cues personnalisés fournis par Wwise : NormalExitCue, qui indique que la piste normale est la plus courte, et BossExitCue, qui indique que la piste de boss est plus la courte. Nous avons ajouté un segment de code capable de détecter de quel type d'Exit Cue nous sommes en train de faire une transition, Normal ou Boss. Ensuite, nous utilisons une recherche rapide (seek) vers le début de la piste cible avec un fondu enchaîné et la mettons en lecture.

Dans cet exemple, nous avons conçu une fonction wrapper simple permettant d'extraire la valeur de sortie du modificateur de paramètre et de l'utiliser dans la zone où cette fonctionnalité est requise.

public float GetGlobalRTPC(string rtpcName)
{
    int rtpcType = 1;
    float acquiredRtpcValue = float.MaxValue;
    AkSoundEngine.GetRTPCValue(rtpcName, null, 0, out acquiredRtpcValue, ref rtpcType);

    if(acquiredRtpcValue >= 0.25 && acquiredRtpcValue <= 16).
    {
        return acquiredRtpcValue;
    }
    else
    {
        return 1.0f;
    }
}

En plus de définir le RTPC de manière globale, la fonction ci-dessus veille également à ignorer toute valeur incorrecte détectée et à réinitialiser le RTPC à sa valeur par défaut, soit 1.0f.

public void MusicSegmentSwitch(object in_cookie, AkCallbackType in_type, object in_info)
{
    if (in_type == AkCallbackType.AK_MusicSyncUserCue)
    {
        var musicInfo = in_info as AkMusicSyncCallbackInfo;
        if(musicInfo != null)
        {
            if (musicInfo.userCueName == “BossExitCue”) 
            {
                if (GetGlobalRTPC(“BossBattleMusic”) > 0.5f)
                {
                        AkSoundEngine.Seek(musicPlayingID, 0, false);
                }
            }

            if (musicInfo.userCueName == “NormalExitCue”)
            {
                if (GetGlobalRTPC(“BossBattleMusic”) <= 0.5f)
                {
                        AkSoundEngine.Seek(musicPlayingID, 0, false);
                }
            }
        }
    }
}

Le segment de code ci-dessus illustre un exemple d'utilisation du RTPC BossBattleMusic, dont la plage est limitée entre 0 et 1, pour basculer de façon interactive entre différents Music Segments ; lors de ce basculement, le Music Segment redémarre depuis le début, avec un effet de fondu enchaîné.

Avertissement : Les extraits de code utilisés dans cet article sont des versions génériques reconstituées et destinées uniquement à des fins d'illustration. La logique sous-jacente a été vérifiée pour fonctionner correctement. Les appels et fonctions API spécifiques au projet ont été omis des exemples en raison de restrictions potentielles en matière de droits d'auteur.