Aller au contenu
7 août 2026 · Ingénierie

Un son qui n'est pas des bips

Cet article décrit le produit à sa date de publication. Voir AI Builder et Agent Teams pour les fonctionnalités actuelles.

Un son qui n'est pas des bips

La première fois que nous avons livré un jeu sans revoir le cahier des charges audio, c'était un simulateur de gestion portuaire — grues, cargos, une petite ville côtière — et le son de collecte de pièces était une onde sinusoïdale. Pas parce que quelqu'un l'avait choisi. Personne n'avait rien choisi ; un « bloop » temporaire s'était glissé pendant l'échafaudage initial et n'avait jamais été remplacé, un peu comme une photo de banque d'images qui survit jusqu'au site fini quand personne ne surveille. Les graphismes étaient bons. Eau peinte à la main, mouettes, un petit quai chaleureux au coucher du soleil. Puis on ramassait un conteneur et le jeu émettait un son digne d'un minuteur de jeu Flash de 2007.

Nous avons rouvert le build sur un écran partagé pour comprendre ce qui n'allait pas, et il n'a fallu qu'environ quatre secondes d'écoute réelle — les yeux fermés, quelqu'un a insisté, moitié pour rire — avant que toute la salle ne tombe d'accord : l'ensemble sonnait comme un micro-ondes. Chaque carillon de succès, chaque tic d'interface, tout était synthétisé à la volée, tout était fait de la même matière électronique fine, quel que soit le jeu auquel c'était rattaché. Une ville portuaire chaleureuse et un jeu de tir cyberpunk auraient produit des sons identiques. C'est ça, le signe qui ne trompe pas. Les ondes sinusoïdales ne savent pas dans quel monde elles se trouvent.

Nous sommes donc partis chercher la vraie solution, et elle s'est révélée d'une simplicité rassurante : arrêter de générer des tonalités et commencer à enregistrer de vrais instruments. Pas des packs de samples sous licence achetés ailleurs, ni des approximations synthétisées réglées pour sonner « chaleureux » — de vrais instruments, enregistrés, échantillonnés sur toute leur étendue, de sorte qu'une note rejouée soit une note réellement jouée par un musicien. Nous avons construit tout cela sur plusieurs semaines pour en faire une bibliothèque d'une ampleur difficile à décrire.

84 instruments — un éventail assez large pour couvrir n'importe quel genre qu'un créateur décide d'aborder
Sensation de jeuPalette d'instruments
AventureCordes et cuivres orchestraux
Puzzle cosyCordes pincées et percussions à mailloches
Urgence arcadeBatterie et basse
Ambiance, tempo lentNappes et claviers

En plus des instruments, nous avons enregistré les ambiances séparément, car un monde a besoin d'air, pas seulement d'une bande-son :

  • Pluie
  • Ressac
  • Vent
  • Bruit de fond ambiant
  • Le murmure d'une foule

Nous sommes revenus au jeu portuaire, la bibliothèque désormais disponible, pour refaire entièrement son univers sonore. L'eau clapote sous les quais, des mouettes crient hors champ, et quand on charge avec succès un conteneur sur un navire, un maillet — un vrai, enregistré en frappant une vraie barre — joue les notes qui étaient autrefois un simple bip. Mêmes notes, même moment dans la boucle de jeu. Un jeu complètement différent. Cette comparaison résume tout l'argument en miniature : un carillon joué par un marimba et les mêmes hauteurs jouées par un oscillateur ne sont pas des résultats interchangeables de « faire un son de succès ». Ce sont deux produits différents portant la même fonction.

Une fois la bibliothèque constituée, le problème le plus difficile est apparu : une bibliothèque ne se compose pas toute seule. L'instinct aurait été de créer un dossier de stingers standards et de laisser chaque build piocher dans le même tas, et nous avons délibérément évité cela. Le cahier des charges du directeur artistique, qui fixe la palette de couleurs d'un build, fixe aussi sa palette sonore, si bien que la composition se fait au cas par cas — un jeu policier noir et un simulateur de ferme ne reçoivent pas le même ensemble d'instruments, pas plus qu'ils ne recevraient la même police de caractères. Le placement des effets sonores suit la même logique jusqu'au niveau de chaque objet : quel est l'objet, quelle surface il touche, quelle est sa taille, quelle est l'ambiance de la scène. C'est la même exigence de précision que nous imposerions pour un sprite ou un texte d'interface, simplement appliquée à quelque chose que l'on a l'habitude de traiter comme un détail secondaire.

Et parce que « traiter comme un détail secondaire » est précisément la façon dont l'audio finit par régresser, nous ne l'avons pas laissé sous la forme d'une simple recommandation de style qui espère survivre à une échéance. Cela fait désormais partie de la vérification — le contrôle dans le navigateur qui s'exécute avant la mise en ligne d'un build écoute réellement le résultat, et une couche d'ambiance silencieuse, ou des effets qui basculent discrètement vers un simple oscillateur parce qu'un échantillon n'a pas chargé, font échouer le contrôle exactement comme le ferait un bouton cassé. Pas une remarque dans un rapport de revue, un défaut. L'un de nos propres builds a d'ailleurs été signalé et corrigé automatiquement pour exactement cette raison il y a peu ; le fonctionnement précis de cette détection est expliqué dans Comment les builds se vérifient eux-mêmes.

Le test que nous utilisons nous-mêmes : jouer au build les yeux fermés pendant dix secondes. Si ce que vous entendez pourrait provenir de n'importe quel jeu de 2003, l'audio a échoué, quoi qu'en dise le code.
Ingénierie
PartagerXLinkedInFacebookRedditQuoraWhatsAppTelegramE-mail
← Tous les articles