It Takes Two de Hazelight Studios est un jeu de plateforme et d'action-aventure intégralement coopératif en écran partagé. Il se distingue des autres jeux d'action-aventure par l'importante variété de son contenu, ainsi que par son style d'animation original et ludique. Quand il a été question de développer l'ambiance sonore pour un jeu de ce genre, le défi le plus important a été le partage d'écran et ses implications en audio. 

Rejoignez nos amis de Hazelight Studio pour cette discussion dans laquelle ils répondent aux questions concernant les défis et les opportunités qu'ils ont rencontrés lors du développement audio de It Takes Two. L'équipe audio - Philip Eriksson (Lead Sound Designer), Joakim Enigk Sjöberg (Technical Sound Designer), Göran Kristiansson (Audio Programmer), et Anne-Sophie Mongeau (Senior Sound Designer), explorent leur approche de l'écran partagé, du mixage, de la conception sonore, de la performance et de la musique. Cette discussion met en lumière les solutions techniques qui leur ont permis d'offrir une expérience audio de haute qualité tout en établissant de nouveaux standards en termes d'audio pour les jeux de la même catégorie.

Partage d'écran

Pouvez-vous résumer votre choix de solution technique pour gérer le partage d'écran vertical dans It Takes Two ?

PHILIP : La manière dont nous avons traité le partage d'écran à la verticale a été de diviser également le mixage sonore en deux moitiés. Nous avons utilisé les haut-parleurs de gauche, du centre et de droite comme base pour tous les sons, et nous avons privilégié toujours les haut-parleurs avant par rapport aux haut-parleurs arrière. Nous avons réparti les sons qui appartenaient à la moitié gauche de l'écran entre les haut-parleurs gauche et central, avec une légère diffusion sur le haut-parleur droit. Nous avons utilisé cette astuce pour les mouvements des joueurs, les sons des différentes capacités et même les voix. Nos ambiances étaient en format quad et étaient donc également diffusées dans les haut-parleurs arrière. Lorsque les personnages entendaient des sons d'ambiance différents parce qu'ils jouaient dans des endroits différents, nous baissions l'ambiance du personnage de droite dans les haut-parleurs gauche avant et arrière, et vice versa, ce qui permettait de créer une expérience toujours conforme à ce que l'on pouvait voir à l'écran.

Image 1 : Panoramique des ambiances

Avez-vous géré le partage d'écran de manière différente lorsqu'il n'était pas divisé en deux ? Par exemple, lorsque le côté d'un joueur devient plus grand, ou lorsque la division devient horizontale, ou même lorsque le jeu passe en plein écran ?

JOAKIM : La situation où les deux joueurs partagent un espace d'écran égal sur une division verticale était de loin le scénario le plus répandu, et c'est là que nous avons le plus investi de temps et d'efforts pour le développement technique. Une autre situation fréquente dans le jeu est celle où les deux joueurs partagent la même vue en plein écran. Il était important pour nous que la perspective choisie concernant le placement dans l'espace ne soit pas complètement bouleversée durant ces scènes. Même si la perspective visuelle est différente, les règles de comportement audio ne sont que légèrement modifiées, au point que les joueurs ne le remarquent pas. La principale méthode employée pour une section en plein écran consiste à suivre les sources sonores par rapport au point central de l'écran, à partir duquel nous effectuons une panoramique correspondante sur le plan horizontal. Ceci est lié à notre philosophie globale de gestion de l'espace de l'écran, ce qui nous permet d'améliorer grandement la netteté durant ces phases de jeu qui sont par nature souvent chaotiques et intenses.

GÖRAN : L'une des solutions techniques qui a mis de l'ordre dans ce chaos a été notre plug-in de filtrage. Il s'agit d'un filtre biquad par canal comprenant des faders de volume et une valeur pour le facteur Q du filtre. Nous avons utilisé le plug-in pour avoir un contrôle clair sur chaque canal, et il a été utilisé lorsque les joueurs meurent et réapparaissent. Nous avons créé un effet cool en effectuant un balayage des filtres passe-bas sur la moitié du mixage, ce qui permet d'avoir également une distinction claire pour chaque joueur. En raison des limitations du gameplay (par exemple, la possibilité d'avoir peu de santé pendant de longues durées), nous ne pouvions pas appliquer un effet similaire de passe-bas constant sur la moitié du mix, car il commençait à sonner faux lorsqu'il était appliqué trop longtemps. Nous ne l'avons donc utilisé que pour les moments de mort et de réapparition qui étaient plus drastiques et plus courts. Grâce aux ressources existantes dans le code de Wwise, les fonctionnalités du plug-in ont été faciles à implémenter.

Qu'en est-il des sons entièrement spatialisés (3D) ? Comment avez-vous réussi à éviter toute confusion lorsqu'il s'agit de localiser ces sons spatialisés dans le monde, alors que les deux joueurs peuvent se trouver à une position différente par rapport à la source sonore ? 

PHILIP : Cela a été un peu plus délicat à résoudre que pour les sons 2D. Nous avons réalisé ce problème très tôt lors du processus de création de sons pour le jeu, mais ce n'est qu'assez tard que nous l'avons corrigé. L'un des exemples les plus simples de ce problème était qu'un joueur pouvait se tenir très près d'une source sonore mais avec sa caméra détournée du son, alors que l'autre joueur était plus éloigné de la source sonore mais regardait droit dessus. Dans ce cas, le mixage résultant faisait apparaître le son à la fois dans les haut-parleurs avant et arrière, créant ainsi un son perçu comme très large et massif (plus qu'il ne devrait l'être). Pour moi, cela brisait l'illusion. Je ne pC'était une chose avec laquelle je ne pouvais pas livrer le jeu. L'une de nos règles les plus strictes concernant la panoramique et le mixage était de favoriser le joueur ayant la source sonore dans son champ de vision, et ce problème venait briser cette règle, nous devions donc faire quelque chose à ce sujet.

JOAKIM : Le problème que nous avions venait de notre configuration spécifique de listeners, et cela créait deux points problématiques majeurs. Le premier reposait sur la façon dont les sons spatialisés étaient positionnés. Étant donné que le joueur le plus proche de la source spatiale est généralement celui dont le son est le plus fort dans le mix, sa perspective a la plus grande influence sur le placement des haut-parleurs. Son champ de vision ne représente généralement pas fidèlement ce sur quoi nous voulons, en tant que concepteurs, focaliser l'attention, mais nous n'avions pas encore les outils pour contrôler ce résultat. 

Le deuxième problème reposait sur la manière dont Wwise combinait intrinsèquement les canaux pour nos listeners. Lorsque la sortie correspondant aux sons spatialisés était activement mixée par les deux listeners, le résultat multipliait par deux la quantité de signal audio ; ce qui entraînait une augmentation du volume de sortie par rapport à la situation où le même son était entendu par un seul joueur. La quantité de signal du résultat final serait de fait très imprévisible puisqu'elle dépendrait de la combinaison de la relation des deux joueurs avec la source sonore. 

Nous avons clairement vu le problème de l'amplitude des émetteurs spatialisés dès que nous avons commencé à intégrer des sons dans le jeu. Notre première méthode pour le contourner a été d'implémenter un RTPC très simple, lié au make-up gain d'un Actor-Mixer de haut niveau hiérarchique. Pour chaque émetteur jouant un son spatialisé, nous suivions la proximité avec les listeners, et lorsqu'ils étaient tous deux à portée, ce RTPC était continuellement mis à jour pour diminuer le volume en fonction de leur distance - tout cela pour contrebalancer l'intensité supplémentaire de nos canaux dont le son serait doublé. Il s'agissait, bien sûr, d'un « correctif » très approximatif. Et puisqu'on ne pouvait jamais vraiment prédire la quantité exacte de signal qui finirait par être combinée par les listeners, l'intégration dans son ensemble donnait des résultats moins convaincants que la normale pour homogénéiser l'amplitude.

Ensemble, ces deux problèmes signifiaient que nous ne pouvions en aucun cas contrôler le mixage spatialisé du jeu. Nous avons donc décidé de plonger plus profondément dans la configuration de Wwise afin d'établir nos propres règles de gestion des sources sonores spatialisées pour It Takes Two.

Images 2 et 3 : une source sonore unique, routée à travers deux listeners

GÖRAN : Avant de configurer nos propres règles dans le système de Wwise, nous devions d'abord connaître les règles de Wwise. Nous les avons parcourues étape par étape pour voir ce qui existait déjà, ce qui devait être modifié et où cela devait se faire. 

Comme mentionné précédemment, nous avons commencé cela tardivement et nous avions donc l'approche suivante : comment atteindre le résultat dont nous avons besoin sans prendre de retard sur le projet ? Pour résumer nos besoins de conception, notre objectif était d'éliminer le dédoublement du signal et de resserrer le signal basé sur la focalisation directionnelle, ce qui nous imposait d'élaborer notre propre système de Spatial Panning. 

Avec cela en tête, nous avions besoin de tous les listeners dans la plage d'atténuation et de leurs orientations respectives pour chaque émetteur. Nous avons choisi d'atténuer le signal principalement en fonction de la distance. Mais nous avons aussi indirectement laissé le gameplay contrôler la vitesse de l'atténuation du signal directionnel, puisque dans la plupart des situations, les changements de rotation étaient plutôt contrôlés et progressifs. Pour limiter les pics de performance et, bien sûr, pour avoir les données dans un format dont nous avions besoin, nous avons dû grandement étendre notre pipeline dans le système de Wwise pour atteindre le résultat et la performance souhaités.

Avez-vous trouvé que cette solution de Spatial Panning, tout en étant très utile, a créé d'autres problèmes ? Si oui, quels étaient-ils, et quelle a été votre approche pour les éviter ?

PHILIP : Je suis sûr à 100% qu'un joueur peut clairement entendre notre solution au problème s'il-elle fait bien attention, mais cette solution a résolu plus de problèmes qu'elle n'en a créés. Comme notre solution implique des sons en mouvement qui, par exemple, « devraient » se déplacer des haut-parleurs arrière vers les haut-parleurs avant, nous avons dû créer une interpolation pour que cette transition se fasse en douceur. Cela signifie que si un joueur fait des mouvements très rapides et extrêmes avec son personnage, notre interpolation risque d'être lente, même si nous l'avons soigneusement ajustée pour tenir compte de tous les scénarios possibles. Cependant, les joueurs ne sont jamais en mesure d'écouter une seule source sonore par eux-mêmes, il serait donc très difficile dans le mixage final du jeu d'entendre distinctement une situation problématique. 

JOAKIM : La fonction de Spatial Panning a été faite à partir de zéro afin de résoudre les problèmes spécifiques que nous avons vus dans It Takes Two. Toutes les méthodes employées pour aboutir au résultat final au cours de ce projet, y compris le Spatial Panning, n'ont pas été conçues pour s'adapter parfaitement à n'importe quel type de jeu d'action à écran partagé ; au contraire, elles ont été spécifiquement adaptées pour fonctionner dans les limites de notre jeu, It Takes Two. Un exemple illustrant cela repose sur la linéarité du gameplay ; les joueurs avancent toujours en avant et les sons spatialisés qu'ils rencontrent sont tous conçus pour exister dans le monde dans lequel ils voyagent. Même si notre solution a bien fonctionné dans le contexte d'un tel jeu, il ne faut pas s'attendre à ce qu'elle se traduise très bien dans un jeu dont le monde est plus ouvert ou dans un jeu où les perspectives entre deux joueurs sont plus asymétriques. Alors que l'idée du Spatial Panning est un point de départ à partir duquel nous pourrions continuer à explorer pour de futurs projets, un autre jeu nécessitera probablement de repenser quel est l'objectif que nous voulons atteindre lorsque nous joignons deux moitiés d'écran et que nous faisons des compromis sur les perspectives dans l'idée de rendre un ensemble cohérent.

GÖRAN : Comme la fenêtre de sortie de notre jeu correspondait à la sortie des nouvelles consoles, nous avons dû mettre à jour les versions de Wwise assez fréquemment pour des raisons de compatibilité et de fonctionnalité des nouvelles consoles, ce qui impliquait à son tour de prendre beaucoup de temps simplement pour garder nos systèmes, tel que Spatial Panning, actifs et efficaces. C'est une chose courante lorsqu'on utilise des logiciels tiers et cela ne devrait pas nous surprendre, mais il est bon de garder à l'esprit, lorsqu'on modifie un logiciel existant, de créer des outils (ou d'utiliser ceux qui existent déjà) pour faciliter ce processus autant que possible, et de marquer clairement vos changements dans le code de base. Cela permet de réduire les frais généraux lors de la migration entre les versions. 

Mixage

Le mixage de It Takes Two est très convaincant, homogène, propre et clair, malgré l'écran partagé. Quelle a été votre approche concernant le mixage du jeu ? Quelle vision aviez-vous et comment l'avez-vous mise en application concrètement ?

PHILIP : Nous voulions créer un mixage intéressant avec des changements drastiques, en nous concentrant toujours sur quelque chose de nouveau et de convaincant. Notre jeu est assez linéaire, il était donc plus facile d'y parvenir que pour un jeu de type monde ouvert. Lorsque le joueur se déplace d'une pièce à l'autre ou suit le chemin principal, nous veillons à toujours nous concentrer sur le prochain son ou événement intéressant. La plupart du temps, cela se fait par le biais de décisions de mixage, en sélectionnant soigneusement les sons que les joueurs doivent pouvoir entendre et ne pas entendre. C'est quelque chose que nous avons fait consciemment lors d'une session de repérage de l'équipe audio, depuis la création des effets sonores jusqu'au mixage final. Fait intéressant, nous avons dû faire le mixage à deux joueurs pour que le jeu se comporte comme prévu. Cela a rendu le processus de mixage beaucoup plus amusant et il était également très utile de toujours avoir une autre paire d'oreilles dans la pièce, et quelqu'un avec qui discuter des décisions de mixage.

ANNE-SOPHIE : L'écran partagé a eu un impact significatif sur certaines de nos décisions de mixage. Par exemple, au lieu d'essayer de séparer les deux écrans à tout moment et de lutter contre le partage d'écran, nous avons choisi d'en tirer parti, et d'utiliser le son de manière narrative en renforçant les éléments les plus importants qui se produisaient à un certain moment dans le gameplay (dans l'un ou l'autre des écrans), en les soulignant à travers le mixage. En nous concentrant sur un élément important à la fois, nous indiquons aux joueurs à quoi ils doivent faire attention. C'est particulièrement important pendant les séquences épiques, les phases de combat ou les séquences très chargées. Parfois, cela signifiait qu'il fallait être assez drastique concernant les sons qui devaient ressortir ou non du mixage, mais cela s'est avéré payant en termes de clarté et de cohérence de mixage.

Avez-vous envisagé de livrer des mixages différents en fonction de la configuration de l'installation ? Par exemple, avoir des mixages différents au casque pour chaque joueur, ou un mixage différent selon que les joueurs jouent en mode « couch co-op » ou séparément en réseau ?

PHILIP : Au début de la production audio, c'est quelque chose auquel j'ai pensé et j'ai eu quelques idées. L'une d'elle était de baisser les sons de mouvements et de la voix du personnage que vous ne jouez pas. Une autre idée était de couper les sons du monde que l'autre joueur entendrait. En imaginant l'expérience côté joueur, je me suis rendu compte qu'aucune de ces idées ne serait utile. Puisque la représentation visuelle du jeu est la même quelle que soit la façon dont vous jouez, il semblait logique de traiter le son de la même façon. Cela nous aurait également donné plus de travail afin de maintenir tous ces différents types de mixage. Nous nous sommes efforcés de faire en sorte que l'expérience sonne bien lorsque la scène est partagée entre les deux joueurs partageant un même paysage sonore. En particulier pour It Takes Two, qui est un jeu qui, selon moi, devrait être partagé quelle que soit la façon dont vous jouez.

HDR

Avez-vous utilisé la HDR de Wwise pour It Takes Two ? Quelle a été selon vous la meilleure stratégie pour répondre à vos besoins et servir au mieux l'écran partagé ?

PHILIP : Nous avons en effet utilisé la HDR de Wwise. C'était un choix facile à faire, nous voulions utiliser la HDR pour nettoyer le mixage, et comme outil pour optimiser notre jeu, en triant les sons qui ne sont pas entendus. Avec notre historique de EA DICE ayant déjà utilisé la HDR sur des titres précédents, il nous a fallu quelques essais pour nous familiariser avec la HDR de Wwise. Voici quelques conseils et astuces :

• Normalisez vos sons ;
• Créez un guide pour les valeurs de voice volume à utiliser sur différentes catégories de sons, ou choisissez les sons les plus importants de votre mixage (il n'est pas nécessaire que ce soit le son le plus fort, mais cela peut être le son le plus intéressant) ;
• Essayez de laisser la valeur de voice volume statique, à l'exception de l'atténuation de la distance. N'appliquez donc pas, par exemple, un LFO RTPC aléatoire sur la valeur de voice volume, car cela signifiera que votre son va atténuer d'autres sons (ou être atténué par d'autres sons) différemment au fil du temps, et ce n'est peut-être pas le résultat que vous voulez ;
• Utilisez le make-up gain pour tous les volumes variables et pour le mixage général ;
• Si vous travaillez avec plusieurs couches audio pour le même effet sonore, soyez conscient que chaque voix peut avoir une valeur de voice volume différente, et donc également atténuer des couches audio qui sont supposées jouer ensemble. Une bonne méthode consiste à définir la même valeur de voice volume sur les couches qui doivent jouer ensemble, et à mélanger le panning entre ces couches en utilisant le make-up gain ;
• Sachez que si le voice volume est réglé sur une valeur inférieure à la valeur minimum de votre plage HDR, votre son sera très probablement coupé, s'il s'agit de l'option que vous avez choisie dans les réglages de Virtual voice behavior. Cela peut être utilisé délibérément, mais vous devez en être conscient.

Une autre observation intéressante que nous avons remarquée est que, lorsque vous avez deux listeners, vous avez également deux instances HDR en même temps. Cela signifie que si un listener se trouve, par exemple, à côté d'un son ayant un voice volume élevé, et que l'autre listener est en dehors de la plage d'atténuation, l'atténuation HDR additionnée sera inférieure à celle obtenue si les deux listeners étaient proches de la source. Il peut s'agir d'un comportement pertinent, mais, encore une fois, ce n'est peut-être pas le résultat que vous souhaitez.

Image 4 : Visualisation HDR à l'aide du Voice Monitor

Réverbération / Environnement

La réverbération et l'univers général de It Takes Two sonnent de manière très réaliste et immersive. Quel type de réverbération avez-vous utilisé, et quelles autres solutions avez-vous développées pour rendre ces environnements si convaincants ?

PHILIP : Un pilier essentiel de la direction audio de It Takes Two était de faire une expérience immersive pour les joueurs, et de faire en sorte que le monde réagisse aux sons, qu'il parle aux joueurs. Nous voulions être en mesure de concevoir des environnements créatifs avec, par exemple, les tuyaux d'aspirateur, les bocaux en verre, ainsi que les effets de réverbération bizarres utilisés dans le niveau du monde du kaléidoscope. Nous avons essayé de travailler avec le plug-in Wwise RoomVerb mais ce n'était pas suffisant pour nous, nous avons donc choisi de n'utiliser que des réverbérations à convolution pour pouvoir être plus créatifs. Nous avons fait des enregistrements poussés de réponses impulsionnelles de différents environnements avec un fouet ainsi que des feux d'artifice, et nous avons créé des impulsions avec une très forte signature sonore pour l'eau et d'autres lieux imaginaires.

En plus de ces réverbérations à convolution, nous avons également créé un système de 'Type d'Environnement' afin de pouvoir jouer différentes queues de résonnances de réverbération. Nous avons principalement utilisé ces queues pour les explosions et les armes, mais aussi pour quelques autres sons pour lesquels une résonnance plus longue permettait de suggérer la grandeur et l'intensité sonore du son. Nous avions en fait deux versions différentes de résonnances pour les bruits de pas, directement exportées dans le son, une pour les petites pièces et une pour les grandes pièces.

Pour créer des mondes encore plus réalistes, nous avons réalisé un système de délai fonctionnant lors de l'exécution du jeu qui utilisait des raycasts afin de mesurer la distance entre les personnages et les surfaces réfléchissantes, ainsi que les différents types de surface. Cela permet d'ajouter des réflexions variables très agréables aux autres réverbérations plus statiques et aux réflexions directement exportées dans les sons, et permet de faire rapidement réagir l'environnement à des changements sonores très subtils.

Image 5 : Réglages d'une réponse impulsionnelle de la réverbération à convolution spécifique à un niveau.

JOAKIM : Lors de la conception de systèmes pour simuler les effets environnementaux sur les sons du jeu, une bonne question à se poser est de savoir si le spectre d'un son est conçu pour être prédéterminé et fixe, par rapport à un son conçu pour se produire au moment de l'exécution du jeu et avec des résultats plus dynamiques et momentanés. Essayez de trouver un juste milieu entre les deux, en fonction des ressources disponibles et des considérations idéales tant d'un point de vue de la technique que de la créativité. Pour donner un bon exemple illustrant la base fondamentale des systèmes environnementaux dans It Takes Two, nous pouvons citer l'implémentation de la réverbération par convolution. Même si nous acheminons dynamiquement les signaux dans ces bus au moment de l'exécution, les caractéristiques de l'effet même sont soigneusement modélisées en amont afin de rendre un type d'environnement spécifique. En dehors de la collecte de données sur l'emplacement des joueurs lorsqu'ils se déplacent dans le monde et de la gestion du routage résultant dans les bus de réverbération, le son de la réverbération elle-même est très déterministe. 

En revanche, une fois que nous avions un support de réverbération dense et fiable, nous pouvions nous aventurer dans la représentation du phénomène physique des premières réflexions en utilisant des délais variables qui étaient programmés par des calculs en temps réel pilotés par toutes sortes de données collectées dans le jeu, comme la distance par rapport aux murs, les matériaux autour du joueur, et la relation avec les objets qui l'entourent.

Tout type de système, qu'il soit prédéterminé ou qu'il utilise un résultat construit au fur et à mesure du déroulement du jeu, héritera de ses avantages et de ses inconvénients naturels ; mais une fois combinés, ils peuvent créer des résultats capables de faire passer un monde numérique pour un monde réel de manière convaincante.

GÖRAN: Malheureusement, une fonctionnalité manquante dans les plug-ins de délai de Wwise est le délai variable ou, en d'autres termes, le support des changements de délai lors de l'exécution au moyen de RTPC. Ceci était une nécessité pour notre système de premières réflexions.

Au départ, lors du prototypage, nous avons utilisé Pure Data. Nous avons également conçu un plug-in Wwise à partir des patchs Pure Data en utilisant le compilateur Heavy, maintenant abandonné, afin de pouvoir tout tester dans le moteur de jeu. Il faut noter ici que toutes les plateformes ne sont pas prises en charge, et peut-être que ce qui fonctionne aujourd'hui ne fonctionnerait plus du tout de manière autonome.

Tout d'abord, nous avons essayé d'utiliser un délai à bande, mais celui-ci produisait un changement de hauteur lors de la mise à jour du temps de retard. Nous avons également essayé d'utiliser une ligne de délai avec un temps de délai variable, mais cela a généré des artefacts tels que des clics lors de la mise à jour du temps de retard. Cependant, le résultat était suffisant pour mettre en avant le potentiel du système et pour continuer dans ce sens avec la conception de notre propre plug-in Wwise. 

Finalement, nous avons fini avec une une ligne de retard fractionnelle avec interpolation bicubique afin de lisser le bruit qui pourrait se produire lors de la modification du temps de retard.

Image 6 : Plug-in Wwise de Hazelight, « Haze Delay », ligne de retard fractionnelle pour lisser les changements de temps de retard.

L'écran divisé signifie que vous pouvez vous retrouver à traiter plusieurs instances de réverbération à convolution en même temps, de même pour le délai. Ces systèmes ont-ils posé des problèmes de performance ? Si oui, comment les avez-vous résolus ?

PHILIP : Il y a une possibilité importante que nous ayons deux personnages situés dans des zones d'ambiance différentes et même, dans le pire des cas, dans les zones de transition entre différentes zones d'ambiance, ce qui signifierait que le seul son du personnage serait mixé à quatre réverbérations à convolution en même temps. Nous laissons également les sons situés dans d'autres zones d'ambiance se mixer à la réverbération d'une zone adjacente, ce qui implique que nous pouvons avoir beaucoup d'instances de réverbération en même temps. Avec les systèmes de délai utilisés lors de d'exécution, c'est un peu plus simple. Le délai est uniquement centré autour du personnage, il ne peut donc y avoir que quatre instances de délai en même temps, soit deux par personnage.

JOAKIM : Dans It Takes Two, les bus de réverbération occupent des espaces compartimentés du monde (les « zones d'ambiance ») et ne s'activent que lorsqu'un joueur entre dans la zone qu'ils représentent. De même, lorsqu'il n'y a plus de joueurs dans cette zone particulière, les envois de réverbération associés sont supprimés et le bus retourne à l'état inactif. Durant l'exécution du jeu, les joueurs voyagent continuellement à travers différentes instances de réverbération en transition les unes avec les autres, amenant le joueur dans l'environnement suivant et se mettant en veille lorsqu'elles ne reçoivent plus de signal d'entrée des joueurs présents. Ce système était aussi intriqué que possible tout en supportant la prise en charge des deux joueurs dans des endroits potentiellement très différents ; et même ainsi, il n'est pas rare de voir sept ou huit bus de réverbération à convolution uniques actifs simultanément en fonction de l'emplacement des joueurs et des autres sons de l'environnement. Au cours du développement du jeu, Audiokinetic a également publié ses propres optimisations de performance pour l'effet de réverbération à convolution – ce qui a été très apprécié !

GÖRAN : Une chose que nous avons faite tout au long du développement afin de réduire la quantité de travail nécessaire à tout traitement, mais qui a grandement affecté la réverbération, a été de limiter les objets actifs traités, en éliminant ceux jugés inactifs. Par exemple, ceux qui ne jouent aucun son ou ceux qui sont hors de portée. 

Nous nous sommes également assurés de ne mettre à jour les données que lorsque nous pensions que c'était nécessaire. Par exemple, avec le système de délai, nous avons utilisé des raycasts asynchrones, et ce n'est que lorsque suffisamment de données avaient changé que nous mettions à jour notre plug-in de délai. Ainsi, lorsque cela était possible, nous avons réduit les modifications de nos lignes de retard variables, mais en sacrifiant certains changements qui n'étaient pas mis à jour à chaque image.

Performance

Mis à part la réverbération, un jeu en écran partagé signifie que deux instances du même jeu fonctionnent en parallèle à tout moment. Cela a-t-il causé des problèmes majeurs de performances ? Quelles étaient les principales sources de préoccupation et comment les avez-vous résolues ?

PHILIP : Nous avons bien sûr toujours gardé cela à l'esprit pendant toute la production audio, ce qui, je pense, devrait toujours être le cas. Ce n'est pas très amusant de faire un jeu au son fantastique puis, vers la fin de la production, de devoir optimiser toutes ces belles créations sonores sur lesquelles vous avez passé tellement de temps. Nous avons surveillé nos données depuis le début pour nous assurer que nous étions toujours dans les limites du raisonnable. Nous avons essayé d'être intelligents et de n'utiliser plusieurs couches audio dans notre conception sonore que lorsque cela était nécessaire, de prendre des décisions de mixage bien réfléchies et d'utiliser la HDR pour supprimer ou éliminer les sons inutiles. Cela n'a jamais été un obstacle pour nous sur le plan créatif, mais nous avons parfois dû ajuster nos techniques de conception sonore afin de respecter les deux conditions d'un son à la fois convaincant et optimisé. Nous avons également utilisé tous les systèmes d'optimisation intégrés de Wwise, comme la HDR, la limitation de lecture (Playback Limit), les fonctionnalités de voix virtuelles (Virtual Voice) et de priorité de lecture (Playback Priority), mais en combinaison avec nos propres systèmes d'optimisation. 

JOAKIM : Avec n'importe quel jeu donné, l'action de base de jouer de nombreux sons simultanément sera presque toujours l'élément le plus coûteux en CPU - un jeu en écran partagé comme It Takes Two ne fait certainement pas exception. La limitation des voix et des bus constituait la base des restrictions, mais il faut également mentionner la HDR et sa fantastique capacité à non seulement obtenir un mixage propre et dynamique, mais aussi à aider à la gestion des sons peu importants au moment du jeu, en leur permettant d'être supprimés lors de leur passage sous le seuil de volume établi.

It Takes Two est sorti pour cinq plateformes différentes qui ont toutes des besoins, des exigences, des faiblesses et des forces différentes. Notre approche était d'identifier et de s'attaquer continuellement aux problèmes les plus extrêmes et de les résoudre dans le contexte de toutes les consoles, par opposition aux réglages individuels propres aux différentes plateformes disponibles dans les hiérarchies de Wwise. Un bon exemple illustrant ces nombreux allers-retours que nous avons dû faire afin de trouver un compromis idéal pour toutes les plateformes a été de catégoriser les archétypes de sons à jouer à partir du disque, car nous avons constaté que c'était un élément qui, dans notre jeu, donnait des résultats immédiats en termes de performance. C'était l'acte d'ajuster toutes les pièces du puzzle ensemble ; le temps que le processeur passe sur votre frame audio, la quantité de données PCM non compressées chargées dans votre RAM, et la quantité de streams gérés par le disque dur. 

Si Wwise n'avait que le profiler et aucune autre fonctionnalité, je l'utiliserais quand même.

GÖRAN : Juste pour clarifier, nous n'avons pas deux instances du jeu mais deux perspectives, et pour l'expérience auditive, au moins toujours deux listeners. Ce qui signifie que nous n'avons qu'une seule source audio mais que le signal est mixés à deux listeners. 

Comme Joakim l'a mentionné précédemment, notre principale préoccupation était la quantité de sons joués simultanément, mais aussi leur complexité individuelle. Certains nécessitaient de multiples RTPCs, de la réverbération et des données de positionnement à mettre à jour à chaque image, donc, afin de séparer clairement les différentes données nécessaires pour chaque objet, nous disposions d'une grande quantité de paramètres et de raccourcis faciles à utiliser pour permettre un processus de développement fluide. Par exemple, les sons Fire-Forget, qui sont activés uniquement pour la durée du son et se désactivent ensuite jusqu'à ce qu'un autre son doive être joué. Pour savoir à quel moment la plupart des objets sonores peuvent être désactivés, nous avons eu fortement recours à la zone d'atténuation, avec un peu d'atténuation supplémentaire pour tenir compte de la vélocité à laquelle nos listeners se déplacent, et afin de préserver l'expérience sonore.

Conception sonore

It Takes Two se caractérise par une grande variété de gameplay, ce qui signifie d'énormes quantités de contenu audio à concevoir. Comment avez-vous réussi à faire cela ? Avez-vous travaillé avec des sous-traitants ?

PHILIP : Nous avons travaillé avec Red Pipe Studios, qui nous ont fourni le son et le mixage pour toutes nos cinématiques. Côté musique, nous avons travaillé avec Kristofer Eng qui s'est associé en duo avec notre compositeur maison Gustaf Grefberg. SIDE a réalisé la quasi-totalité de nos enregistrements de voix in-game ainsi que leur premier nettoyage. En plus de cela, Red Pipe a travaillé avec Foley Walkers pour fournir des sons de foley pour les cinématiques, et j'ai fait une session d'enregistrement de foley très poussée avec Ton & Vision (Patrik Strömdahl).

Pour être honnête, nous n'avions jamais assez de temps pendant la production audio de It Takes Two, on a donc souvent fait la blague de dire « first pass only pass » (premier rendu = rendu final), et ce n'est pas loin de la vérité. Nous n'avions, dans la plupart des cas, qu'une seule tentative pour faire un son convaincant parce que nous n'étions jamais certains de pouvoir revenir en arrière et de faire du polissage. Cependant, je pense que c'est une approche raisonnable ; pour être un peu extrême, je préférerais avoir du son sur tout le jeu plutôt que du son vraiment abouti seulement sur le premier niveau.

Même avec cette approche en tête, nous nous sommes fixé un objectif de qualité très élevé dès le départ, et pour citer notre directeur de studio : « Vous avez placé la barre de qualité très haut, vous l'avez verrouillée là-haut et ne l'avez jamais bougée quoi qu'il arrive. » Notre objectif était simplement de faire le jeu en écran partagé le mieux sonorisé jamais réalisé, et même si nous avions peu de temps pour essayer de le faire, nous avons gardé cet objectif tout au long du projet.

Nous avons eu un peu de temps à la fin pour revenir en arrière et ajouter ou développer quelques sons ainsi que faire un peu de polissage, et nous avons travaillé dur jusqu'à ce que le jeu nous soit essentiellement arraché des mains et expédié aux consommateurs avec le meilleur son que nous avons pu faire.

ANNE-SOPHIE : Je dois féliciter Philip pour sa planification intelligente pendant toute la durée de ce projet, sans laquelle il nous aurait été impossible de produire un contenu de qualité pour l'ensemble du jeu. Et cela vaut pour la production et l'implémentation de notre conception sonore, le développement et l'itération des systèmes techniques, et la sous-traitance de l'audio pour les cinématiques. Nous avons essentiellement alloué des périodes de temps fixes pour chaque niveau et sous-niveau, et prévu un peu de temps supplémentaire pour le polissage et le mixage. Une fois ces périodes écoulées, nous devions simplement passer au niveau suivant. Compte tenu de cette pression temporelle drastique, notre approche a été de tout produire avec une qualité de produit final dès la toute première itération, ce qui inclut la qualité de la conception sonore, mais aussi du mixage - nous étions tous continuellement responsables du mixage et nous devions nous assurer que tout ce qui était intégré dans le jeu respectait les mêmes standards de qualité que le reste. Enfin, nous avons dû faire preuve de créativité et d'imagination pour donner vie à tous ces objets et personnages ! Dans l'ensemble, la variété du contenu a constitué un réel défi, mais aussi l'une des choses les plus amusantes de ce projet. 

Musique

Le niveau musical du Grenier est le dernier niveau du jeu et il sonne remarquablement bien - Comment avez-vous résolu la capacité de chant, et est-ce que la musique dirige une partie du gameplay à travers le beatmatching ?

JOAKIM : Dans le niveau Musique, il y a pas mal d'éléments de gameplay qui, sous une forme ou une autre, sont contrôlés par la musique de fond. À l'avant et au centre, nous avons la Singing Ability (Capacité de chant) de May, qui est utilisée pour résoudre les énigmes et progresser dans le niveau. Chaque fois que le joueur active cette capacité, May se met à chanter en même temps que la musique en cours, en restant synchrone à la fois dans le tempo et la tonalité. Pour ce faire, nous avons demandé à une chanteuse professionnelle d'interpréter la mélodie de la musique en utilisant une piste MIDI comme modèle. Les données MIDI ont ensuite été analysées sous forme de marqueurs et incrustées dans les fichiers sources, pour être plus tard lues par le moteur de jeu et utilisées pour informer nos systèmes.

Lorsqu'il s'agit d'avoir un gameplay synchronisé avec les événements se produisant sur le fil d'exécution audio, il faut considérer le fait que It Takes Two puisse être joué non seulement localement, où les deux joueurs jouent sur le même appareil et partagent une instance Wwise, mais aussi en se connectant en ligne. Dans ce cas, deux instances distinctes du jeu existent, et avec cela, deux instances distinctes de Wwise. L'état de gameplay sera toujours communiqué entre les deux instances du jeu - les deux instances de Wwise, cependant, n'ont aucune connaissance l'une de l'autre et vont simplement jouer et agir sur les sons tels qu'ils se produisent localement. La nature du fil d'exécution audio signifie qu'il fonctionne à une vitesse fixe, mais comme chaque image du fil d'exécution principal prend un nombre inconnu de millisecondes à calculer, les sons peuvent commencer et s'arrêter à des moments différents des deux côtés. Pour la majorité des situations de gameplay, c'est un détail - les deux joueurs verront et entendront leur « vérité », mais si nous attendons que des événements passent sur le fil audio d'un côté et qu'à son tour cela déclenche un événement dans le jeu des deux côtés, alors le timing devient un facteur crucial. 

Pour le niveau musical du Grenier, nous avons été confrontés à ce problème, et avons décidé que nous avions d'autres batailles à mener. Même ainsi, les callbacks musicaux ont massivement été utilisés pour déclencher librement des événements dont le timing n'était pas crucial, tels que des effets en arrière-plan et autres « fluff » visuels. Ceux-ci étaient alors libres de se produire, quand ils se produisaient, et étaient visuellement synchronisés avec ce qui se passait musicalement. 

Les deux joueurs voient leur musique modifier leur environnement - personne n'est contrarié parce qu'un temps fort survenu une fraction de seconde plus tôt dans l'instance de jeu de l'autre joueur aurait déclenché un événement qui l'aurait tué.

Wwise

Pouvez-vous partager une façon dont Wwise, en tant que moteur audio, vous a particulièrement bien servi, et une façon dont il ne l'a pas fait, et comment vous l'avez contourné ou corrigé ?

PHILIP : It Takes Two a été le premier jeu que j'ai réalisé avec Wwise. Je dirais que l'une des meilleures choses de Wwise, c'est qu'il est comme la voiture Lada de l'Union soviétique, ce qui est quelque chose de très positif. Une fois en marche, il continue de fonctionner, encore et encore ! Nous avons bien sûr eu des problèmes techniques avec Wwise, mais nous avons toujours pu poursuivre notre travail et n'avons jamais été complètement bloqués. Une autre très bonne chose est que, en me mettant de côté, nous avions beaucoup d'expertise Wwise au sein de l'équipe avec Anne-Sophie et Joakim, et ils pouvaient donc informer et guider le reste de l'équipe audio. J'ai également trouvé qu'il était assez facile de démarrer avec Wwise, ce n'était donc pas une très grande montagne à gravir pour l'apprendre, et il est possible de se lancer rapidement.

Wwise est utilisé par beaucoup d'équipes audio différentes dans le monde, et c'est plutôt une bonne chose ; mais à cause de cela, Wwise n'a pas non plus ce comportement spécifique qui convient peut-être à une seule équipe ou même à un seul jeu. Bien sûr, pour nous, cela signifie qu'il faut composer avec les écrans divisés dans la plupart des cas. Un exemple très clair pour nous était le problème du routage des sons Balance-Fade (2D) vers le canal central. Nous avons souvent voulu utiliser le canal central dans notre jeu afin de pouvoir diviser le son en deux moitiés, mais en partageant le centre entre les moitiés afin de conserver un format stéréo. Wwise ne supporte pas l'utilisation du Balance-Fade et du pourcentage d'envoi dans le canal central, nous avons donc dû développer une solution alternative en créant de nombreux bus auxiliaires pour envoyer les signaux au canal central à la place.

Image 7 : Création de bus auxiliaires destinés à envoyer du signal sur le canal central comme solution alternative.

JOAKIM : Wwise est une machine fiable, qui fonctionne de manière régulière. Cela signifie que même lorsqu'il fait quelque chose que vous n'attendez pas, ou qu'il travaille différemment de ce dont vous avez besoin, il le fait de manière constante ! En tant que framework, il est évidemment livré avec un grand nombre de fonctionnalités de base que l'on s'attend à avoir avec un moteur audio moderne. Mais pour tout studio souhaitant plus sérieusement développer des expériences ancrées dans un monde sonore fantastique à l'aide de Wwise, je tiens à préciser ce qu'il permet et ne permet pas de faire. Wwise n'est pas offert comme solution tout-en-un pour tous vos besoins sonores.

Un tel outil tiers n'existe pas. Il ne vient pas avec des solutions prêtes à l'emploi pour tous les cas de figures ou toutes les fonctionnalités possibles de gameplay. 

Ce qu'il est, c'est un point de départ fantastique. Il est livré comme une machine qui démarre du premier coup, qui fonctionne à chaque fois, et à partir de laquelle vous pouvez construire votre propre et formidable engin. Si vous n'êtes intéressé que par les pièces détachées qui viennent pré-assemblées dans la machine, alors, tôt ou tard, vous serez déçu. Si vous êtes intéressé par ce que vous pouvez construire à partir de ces pièces, alors il n'y a aucune limite à ce que vous pouvez faire. 

Pour nous, le plus gros changement que nous avons apporté afin d'adapter les fonctionnalités de Wwise à nos besoins a été de modifier la façon dont nous avons combiné les signaux audio spatialisés lorsqu'ils sont traités par plusieurs listeners. Le résultat initial produit dans Wwise par notre configuration à deux listeners ne donnait pas de résultats satisfaisants, car les deux listeners compromettaient en fait la sensation d'immersion dans l'environnement. Un grand nombre de nos premiers tests et efforts n'ont pas abouti, et aucune alternative disponible dans Wwise ne semblait répondre à tous nos besoins.

Heureusement, l'architecture de Wwise est conçue pour être personnalisable par les utilisateurs, tant que l'on est prêt à plonger plus profondément dans le moteur. C'est à ce moment-là que nous avons commencé à apporter des changements fondamentaux aux systèmes de bas niveau et à les adapter à nos besoins spécifiques. Le résultat a été la création de Spatial Panning, où Wwise a été saupoudré d'une touche de Hazelight pour créer la saveur dont nous avions besoin.

GÖRAN : Comme il s'agissait de mon premier projet en tant que programmeur audio et que je suis arrivé tardivement dans la production, une de mes premières priorités a été d'améliorer et de construire des outils d'automation pour Wwise. Une aide majeure à cet égard a été WAAPI, permettant, avec n'importe quel langage de programmation, d'exploiter les fonctions de création de Wwise. Malheureusement, WAAPI n'est pas vraiment exhaustif en termes de fonctionnalités, mais la plupart, sinon tous les usages courants existent tels quels, et Audiokinetic l'améliore et le met à jour constamment.

Lorsque la production a commencé, il n'y avait pas de concept connu sous le nom d'Event-Based Packaging dans Unreal, mais nous avons commencé à élaborer notre propre version très tôt. Même si nous disposons d'une intégration personnalisée pour générer des SoundBanks à base d'Events, nous utilisons simplement toujours la fonctionnalité de génération fournie par Wwise pour générer les fichiers .bnk et .wem. Cela a été très efficace, d'un point de vue à la fois déterministe et de performance, car c'était une de nos plus grandes priorités en raison du temps perdu à travailler de manière itérative. 

Si vous pouviez recommander une ou plusieurs choses à un autre studio utilisant Wwise pour un jeu en écran partagé, qu'est-ce que ce serait ?

PHILIP : Établissez des règles sur la façon dont vous allez traiter la panoramique et le mixage et tenez-vous en à ces règles. Vous devrez faire des compromis lorsque vous ferez de l'audio pour un jeu à écran partagé. Il s'agit simplement de donner la priorité aux bons sons et d'établir des règles garantissant que, au bout du compte, la plupart des sons sonnent bien. Il peut être difficile de faire ces choix, mais ce sera inévitable si vous voulez que le résultat aboutisse à une expérience claire et agréable pour les joueurs.

JOAKIM : Faites un effort, le plus tôt possible, pour considérer le cadre visuel de votre jeu et décider des éléments importants du point de vue de la conception sonore. Essayez d'identifier des points d'ancrage et utilisez-les comme sources de cohérence spatiale lors du positionnement des sons à l'intérieur de ce cadre. Plus les règles et les hiérarchies sont établies tôt, aussi bien dans Wwise que dans la création des assets sources, plus il sera facile de gérer la liste toujours croissante de variables que représente l'audio en écran partagé. Enfin, prenez des risques quand vous le pouvez ! L'audio pour écran partagé est un territoire globalement inexploré dans notre métier, et les possibilités de raconter de nouvelles histoires par le son d'une manière qu'aucun autre type de jeu ne peut le faire sont nombreuses. 

GÖRAN : En tant que programmeur audio, je ne sais pas ce que nous aurions fait sans le code source de Wwise, donc je dirais d'apprendre à connaître le code de base, et de ne pas avoir peur, comme nous le disons ici à Hazelight, de « f**k s**t up ».

ANNE-SOPHIE : J'appuie l'avis de Philip concernant les règles de panoramique et de mixage et la nécessité de s'y tenir. En fin de compte, la façon dont les sons vont être spatialisés constitue l'élément principal qui définira comment un jeu en écran partagé va sonner, et établir cette vision et l'encadrer dans des règles aussi tôt et aussi uniformément que possible vous épargnera beaucoup de maux de tête et de problèmes. Dans le cas de It Takes Two, un exemple de règle de mixage qui a bien fonctionné pour nous était de ne pas nous focaliser sur des sources sonores entièrement spatialisées, mais plutôt d'utiliser l'espace de l'écran comme cadre pour la plupart du paysage sonore. Cela a permis d'améliorer la clarté du mixage et de minimiser la confusion due à la division de l'écran et à l'endroit d'où proviennent les sons par rapport aux joueurs et aux angles de caméra. Par « utiliser l'espace de l'écran comme cadre », je veux dire que nous avons délibérément laissé de nombreux sons au format 2D (non spatialisé) pour qu'ils soient joués dans les haut-parleurs gauche-centre-droit, comme vous le feriez dans un média linéaire comme un film, afin de correspondre aux visuels avec autant de précision et de détails que possible. Bien sûr, cela fonctionne uniquement avec les sons pour lesquels cela fait sens, comme les sons provenant des personnages eux-mêmes (bruitages, véhicules conduits par les personnages, capacités des personnages), ou les sons provenant de sources qui restent dans le cadre visuel à tout moment (comme les sons en one-shots, courts et ponctuels). Donc, dans l'ensemble, pour un jeu linéaire à écran partagé, il est certain que je recommanderais au minimum d'explorer des approches de conception sonore et de mixage plus déterministes que totalement spatialisées. 

En fin de compte, ce qui a permis à l'équipe audio d'Hazelight de surmonter avec succès les défis qui se sont présentés, c'est sa collaboration constante entre les concepteurs techniques et les concepteurs sonores au sein de l'équipe. En effet, les concepteurs sonores, les compositeurs, un concepteur sonore technique et un programmeur audio ont tous contribué avec leurs forces et leurs compétences spécifiques, et se sont appuyés sur les connaissances de chacun pour créer une dynamique de collaboration ininterrompue, avec laquelle ils ont pu mettre la barre au plus haut concernant la qualité audio. Une productivité constante motivée par une vision claire et sans compromis, l'utilisation d'outils fiables et personnalisables, ainsi que le désir de créer le jeu en écran partagé le mieux sonorisé jamais réalisé, sont les principaux facteurs du succès de l'expérience audio de It Takes Two.