Unpacking est un jeu qui reproduit l'expérience bien connue de sortir ses affaires de cartons de déménagement pour les ranger dans une nouvelle maison. À mi-chemin entre le jeu de blocs et la décoration d'intérieur, le jeu vous invite à créer un espace de vie agréable tout en découvrant des indices sur la vie de la personne dont vous déballez les affaires. Au fil de huit déménagements, vous aurez l'occasion de vous attacher à un personnage que vous ne verrez jamais et de découvrir une histoire qui ne vous sera jamais racontée.
Au commencement
L'idée d'Unpacking est née d'une histoire d'amour réelle, lorsque la graphiste de pixel art Wren Brier et le programmeur Tim Dawson, également fondateur de WitchBeam, ont décidé d'emménager ensemble. Inspirés par le processus consistant à ouvrir des cartons, à en sortir des objets et à décider où les ranger, le couple a rapidement commencé à réfléchir à la manière dont cela pourrait se traduire dans un jeu. Très vite, ces réflexions ont donné naissance à un concept, et Unpacking était en passe de devenir un véritable jeu.
Unpacking a remporté de nombreux prix dans tous les domaines de la création de jeux vidéo, y compris dans la catégorie Audio. En 2022, Unpacking a remporté le Game Developer's Choice Award du meilleur son, face à des titres AAA de renom. Mais pourquoi tant d'engouement ?
Peu après le lancement d'Unpacking, un tweet du concepteur sonore Francesco Del Pia est devenu viral. La vidéo saluait la qualité du foley et a rapidement été vue plus d'un million de fois. Voir le tweet de Francesco
Un commentaire a attiré l'attention de Jeff...
…et peu après, les sympathiques collaborateurs d'Audiokinetic ont demandé à Jeff s'il pouvait partager certaines de ses méthodes de travail sur leur blog. Nous y voilà donc.
Le foley a été produit par une petite équipe familiale dirigée par Jeff van Dyck, un vétéran de l'industrie, avec l'aide de sa femme Angela et de sa fille Ella. Ce jeu relativement modeste a eu un impact considérable grâce à son souci du détail et à l'utilisation intelligente de REAPER et de Wwise pour créer et intégrer une grande quantité d'assets audio. Cet article explique comment les van Dyck ont géré la production du foley en créant plus de 14 000 fichiers WAV ayant un niveau de détail impressionnant, avec seulement une petite équipe.
Concept audio
Au début, Jeff a discuté avec Wren et Tim de différents styles audio. Dans un jeu en pixel art, l'audio est généralement de style « chip tune », tant pour la musique que pour les effets sonores, afin de renforcer l'ambiance rétro. Si Jeff trouvait cela parfait pour la musique, il pensait qu'avoir des bips et des blips pour tous les effets sonores serait trop « chip ». Il a décidé que des effets sonores hyperréalistes contrasteraient bien avec le style pixel art.
Prototype 1
Une fois sa décision prise de créer des effets sonores hyperréalistes, Jeff s'est mis au travail sur une première série d'ustensiles de cuisine, qu'il a enregistrés dans sa propre cuisine.
Au départ, il a utilisé un microphone RØDE NT2-A et un enregistreur TASCAM DR-40. Ces deux équipements ont ensuite été remplacés lors des enregistrements suivants pour obtenir un son plus clair et plus transparent. Finalement, l'équipe a utilisé un Sennheiser MKH 8040 branché à une vieille interface audio Steinberg MR816x, elle-même connectée à un Macbook Pro encore plus ancien.
Notes concernant le prototype 1 :
- Il ne se passait pas grand-chose dans le jeu à part la musique, ce qui laissait beaucoup de place pour les détails sonores.
- Le son de la réverbération naturelle de la cuisine ajoutait du réalisme.
- Réutiliser des sons pour plusieurs objets différents brisait l'immersion.
Cela a soulevé quelques questions :
- Comme les objets pouvaient être déplacés d'une pièce à l'autre dans le jeu, tout devait être enregistré dans une pièce sans écho, en ajoutant des réflexions en temps réel avec le moteur audio.
- Comme la réutilisation de sons pour différents objets brisait l'immersion, chaque objet devait être enregistré avec plusieurs variations pour chaque action (poser et ramasser), sur chaque surface du jeu.
- Quelle allait être l'étendue des sons de foley du jeu, et serait-elle être réalisable ? La réponse à cette question était encore inconnue, Jeff s'est donc concentré sur la musique pendant que le jeu continuait à se développer.
Prototype 2
Six mois plus tard, comme le jeu comportait plusieurs pièces, Jeff a demandé à sa fille Ella (également compositrice et conceptrice sonore) si elle pouvait l'aider à enregistrer certains bruitages pendant ses vacances universitaires. Ella a enregistré et édité les objets de la cuisine dans une pièce sans écho (une chambre d'amis), sur de nouvelles surfaces présentes dans le jeu. Mais rapidement, Ella a été trop occupée par la fin de ses études de musique à l'université et le lancement de sa première bande originale de jeu solo pour continuer à travailler sur les bruitages.
Notes concernant le prototype 2 :
- Les accessoires enregistrés étaient les objets réels du jeu.
- La plupart des surfaces du jeu correspondaient à des surfaces réelles (du carrelage utilisé pour le carrelage, de la moquette utilisée pour la moquette, etc.).
- Certaines surfaces ont nécessité d'improviser (l'évier a été remplacé par de grands plateaux métalliques retournés).
- L'ampleur du travail de foley commençait à devenir colossale.
75 000 fichiers WAV ? Non merci
À ce stade, Jeff a pris conscience de deux choses : il ne pouvait pas mener à bien ce projet seul, et la conception devait être intelligente/efficace. Il est arrivé à la même conclusion que beaucoup dans cette situation... À l'aide ! J'AI BESOIN DE MA FEMME.
Angela, la femme de Jeff, a déjà travaillé en audio et vidéo. Chez Electronic Arts Canada, elle gérait les dialogues des commentaires sportifs dans des jeux tels que Triple Play et NBA. Gérer des flux et processus de travail pour des quantités massives de données était son domaine de prédilection. « Elle est parfaite pour ça ! », s'est-il dit.
La première chose qu'ils ont faite a été de réaliser quelques calculs simples. D'après la conception du jeu, ils ont estimé que le jeu final comporterait environ 500 objets différents pouvant être placés sur 15 surfaces différentes, et qu'il faudrait 10 variations de chaque élément sur chaque surface, soit un total de 75 000 fichiers audio. Cette quantité de travail était-elle réalisable ? La réponse était simple : « non ». Ils avaient besoin d'idées de conception pour réduire la quantité de bruitages nécessaires tout en conservant la richesse sonore, et devaient créer des processus pour automatiser et rationaliser la production et l'implémentation.
Efficacité de la conception
La quantité totale de sons de foley a été réduite de 75 000 à moins de 15 000 grâce à trois idées de conception.
Surfaces souples génériques
Ange et Jeff ont réalisé que les objets posés sur des surfaces souples produisaient souvent des sons similaires. Ils ont enregistré des objets légers, moyens, lourds et très lourds posés sur des surfaces souples telles que des tapis et des lits. Ces sons ont ensuite été attribués à la plupart des objets du jeu (à l'exception des objets qui avaient leur propre son même sur une surface souple, comme les ustensiles de cuisine).
Objets génériques
Ange et Jeff ont utilisé des enregistrements génériques pour les objets produisant des sons similaires. Cela comprenait des catégories telles que le verre, le métal, la céramique, le plastique solide, le plastique creux, etc., ainsi que des catégories de poids : léger, moyen, lourd et très lourd. Ces sons ont été enregistrés avec un grand nombre de variations, ce qui a permis à de nombreux objets du jeu d'utiliser ces mêmes sons génériques tout en conservant un effet global naturel.
Textures additionnelles pour les sons uniques
Certains des éléments du jeu ayant un son unique pouvaient être divisés en deux couches sonores : le son de l'objet lorsqu'il était posé et sa sonorité unique inhérente. Le son de tirelire en est un bon exemple. La tirelire est un objet en céramique auquel s'ajoute le bruit des pièces qui s'entrechoquent. Jeff et Ange ont identifié quels éléments pouvaient utiliser des sons génériques (la tirelire utilisait un son générique de céramique déjà enregistré sur toutes les surfaces. Le cliquetis des pièces a été enregistré séparément. Les fichiers WAV ont ensuite été déclenchés ensemble).
REAPER
Ange et Jeff souhaitaient rationaliser la production en exploitant au maximum les fonctionnalités de REAPER et Wwise afin d'automatiser autant que possible le processus de travail. Ils voulaient également un workflow non destructif (à l'exception de la réduction du bruit) et facile à reproduire avec différents réglages audio.
Fonctionnalité Dynamic Split de REAPER
Ils ont commencé par utiliser des fonctionnalité évidentes comme le Dynamic Split pour diviser automatiquement les enregistrements en éléments individuels.
Disposition de REAPER
La disposition du projet REAPER était essentielle à deux processus de rationalisation : le nommage automatisé des fichiers et l'exportation audio dans une structure de dossiers correspondant à la disposition du modèle de Wwise. Ange et Jeff ont configuré les surfaces du jeu verticalement (à l'aide de pistes et de sous-pistes) et les éléments du jeu horizontalement (à l'aide de régions). Chaque piste de surface contenait deux sous-pistes : poser (« place ») et ramasser (« pickup »).
Vue agrandie de la disposition REAPER
région Céramique léger (« Ceramic_Light ») / piste Dessus de banc (« Benchtop ») / sous-piste Poser (« place ») / sous-piste Ramasser (« Pickup »)
Vue globale du projet REAPER montrant les régions, les pistes et les sous-pistes. La liste des régions permettait de trier par colonne, de rechercher par élément et de passer directement à une région dans la timeline.
Automations sur le bus master pour l'égalisation et la gestion des fréquences
Très souvent, avec des sons faibles, le fait de placer le micro près de l'élément à enregistrer créait un « effet de proximité » générant une quantité exagérée de basses fréquences dans l'enregistrement. Ce problème a été facilement résolu à l'aide de deux filtres coupe-bas (appliqués avec les plugins de Fabfilter) à différentes intensités. Ceux-ci ont été activés selon les besoins grâce à une automation sur le bus master. Les enregistrements ayant un son agressif ont été traités avec Soothe2 d'Oeksound, et les sons qui avaient besoin de plus de profondeur dans les graves ont été traités avec ENFORCER de BOOM.
Script REAPER pour nommer automatiquement les fichiers
Ange et Jeff ont utilisé la structure du projet au format régions/pistes/sous-pistes pour créer la nomenclature de fichiers suivante : item_surface_action_variant# (objet_surface_action_variation#)
Ils ont ensuite utilisé le script de X-Raym permettant de renommer avec des combinaisons de mots, en utilisant le nom de la région pour identifier l'objet, puis le nom de la piste pour identifier la surface, puis le nom de la sous-piste pour identifier l'action (poser ou ramasser), puis le numéro de variation (ou prise). Le script a ainsi permis de nommer 14 000 fichiers en quelques secondes.
Correspondance de l'exportation REAPER avec l'importation dans Wwise
Ange et Jeff ont conçu la disposition du projet REAPER en tenant compte de la disposition de Wwise. Ils ont effectué l'exportation depuis REAPER vers une structure de dossiers nommés et imbriqués de manière à correspondre au modèle d'importation de Wwise. L'automatisation et la réduction de la charge de travail que cela a entraîné ont été véritablement magiques.
Les paramètres d'exportation (fenêtre « Render to File ») ont utilisé la disposition « région/piste/sous-piste » pour nommer et imbriquer les dossiers et les fichiers WAV conformément au modèle d'importation de Wwise.
Wwise
Configuration initiale de Wwise
Dans Wwise, Jeff a configuré un Switch Group appelé « action » contenant des Switchs nommés « pickup » (ramasser) et « place » (poser). Il a ensuite configuré un autre Switch Group de surfaces regroupant toutes les surfaces du jeu. Comment tout cela fonctionnait-il ?
Les Switchs étaient activés par Unity lorsque l'Event « Play Event » de Wwise était déclenché. Par exemple :
Play Event Chaussure_Lourde, Surface = DessusDeBanc, Action = Poser
Wwise sélectionnait ensuite de manière aléatoire une des variantes disponibles dans le Container correspondant.
Modèle Wwise pour l'importation de dossiers/fichiers WAV dans une structure désignée
Le processus d'importation a été simplifié en appliquant un modèle à tous les éléments lors de l'importation. Le modèle correspondait à la structure des dossiers créée par REAPER. Ce modèle a permis de gagner beaucoup de temps en créant automatiquement tous les Switch Containers de surfaces, correctement imbriqués, pour chaque élément du jeu.
Processus d'importation
1. Sélectionner les dossiers à importer (la structure de dossiers exportée depuis REAPER).
2. Appliquer le modèle créé précédemment.
Lorsque les structures de dossiers REAPER correspondaient au modèle, le texte de droite était surligné en jaune, indiquant que Wwise avait trouvé un dossier correspondant et allait créer les Containers associés.
Une fois l'audio importé dans cette structure de Containers, des Events de lecture ont été créés individuellement pour chaque élément en sélectionnant tous les Containers. À partir de là, les Switchs étaient connectés et fonctionnaient avec leurs Events de lecture. L'Event Wwise permettait de déclencher le bon Random Container via les Switch Containers.
Si l'on reprend l'exemple précédent :
Play Event Chaussure_Lourde (« Shoe_Heavy »), Surface = DessusDeBanc, Action = Poser
Wwise sélectionnait alors de façon aléatoire une des variantes depuis ce Random Container final.
La feuille de calcul Google
Flexibilité pour l'attribution des sons
Le projet en était à un stade où tous les éléments du jeu nécessitant un son étaient dans Unity, et tous les sons de foley enregistrés étaient dans Wwise. Cependant, il y avait plus d'éléments de jeu que de sons uniques enregistrés - comme vous vous en souvenez peut-être, Ange et Jeff avaient créé des sons génériques et des textures additionnelles devant être partagés entre plusieurs objets. Il fallait organiser tout cela d'une manière facile à gérer. Il était aussi nécessaire de pouvoir attribuer un son à un objet du jeu et entendre les changements en temps réel. Tim a créé un outil dans Unity permettant de télécharger les données directement depuis une feuille de calcul Google vers le projet Unity. D'un simple clic dans Unity, Ange et Jeff pouvaient entendre instantanément les modifications effectuées depuis la feuille de calcul Google. Cette méthode a offert à Ange une grande autonomie (sans dépendre de la disponibilité des programmeurs) pour expérimenter et modifier le son attribué à un objet s'il ne sonnait pas bien. La possibilité de prendre le temps de peaufiner l'attribution des sons a été l'outil de perfectionnement ultime pour le foley.
Outil personnalisé d'audit Unity
Références croisées
La dernière nouveauté très intéressante de la boîte à outils de foley est un outil d'audit sur mesure, également créé par Tim. Le jeu ayant été développé par étapes, avec l'ajout de nouveaux objets et de nouvelles surfaces à différents moments du développement, il devenait rapidement difficile de savoir quels objets avaient été enregistrés et sur quelles surfaces. L'outil d'audit a été conçu initialement pour éviter un travail fastidieux de recoupement manuel lors de la création de nouvelles listes d'éléments à enregistrer. Cependant, ses fonctionnalités étaient très étendues et, selon différents modes, il pouvait afficher des informations telles que :
- Toutes les surfaces sur lesquelles un objet du jeu pouvait être placé à n'importe quel moment du jeu.
- Les fichiers audio manquants par objet/surface.
- Les objets/surfaces dans la feuille de calcul utilisant les allocations prévues ou des exceptions.
On secoue, on secoue, on secoue !
Secouer des objets dans le jeu
De nombreux objets du jeu pouvaient être secoués par le joueur, comme la tirelire, les jeux de société, le pot à crayons et la bouteille d'eau.
Jeff et Ange ont expérimenté différentes méthodes d'enregistrement et d'édition pour obtenir un rendu naturel et réactif aux mouvements de la souris ou de la manette du joueur.
La configuration dans Wwise fonctionnait de la manière suivante (illustrée dans la série de captures d'écran ci-dessous) :
Un Blend Container nommé « Shake Piggybank » (Secouer_Tirelire) contenait les Switch Containers « Left » (gauche), « Right » (droit) et « Stop » (arrêt).
Le type de secousse était déterminé par un paramètre de direction envoyé à Wwise depuis le code de mouvement de la souris.
Ensuite, chaque Switch Container de direction permettait de sélectionner un Random Container selon l'intensité de la secousse.
La vitesse du mouvement de la souris était envoyée à Wwise, qui pouvait alors sélectionner un Container correspondant à une secousse légère (« Soft »), moyenne (« Medium ») ou forte (« Hard »).
En résumé
- Nous avons enregistré une quantité @^#$ énorme de sons !
- Nous avons trouvé quelques raccourcis en cours de route grâce aux surfaces souples, aux sons génériques et aux textures additionnelles.
- Nous avons tiré parti des workflows de REAPER et de Wwise, qui nous ont permis de garder la tête froide.
- La validation dans Unity nous a permis d'apporter de la clarté au milieu de ce chaos.
Pour plus d'informations sur l'audio d'Unpacking, voici quelques liens :
Conférence de Jeff au GDC 2022
Podcast « Level with Emily Reese »
Vidéo youtube « Unpacking Audio Deep Dive » (Plongée dans l'audio d'Unpacking)
Nous espérons que vous avez apprécié cet article !
Angela et Jeff van Dyck
|
|
ANGELA VAN DYCK |
Commentaires