Groupe de IndépendantElectronicGame.com

Le son de LUMA évolue ! 🎶

Aujourd’hui, j’avais envie de revenir sur un détail qui n’en est pas un : le son de la console LUMA. Pendant longtemps, LUMA n’avait qu’une seule “corde vocale” : un petit piezo branché sur une seule sortie. Ça faisait le job, ça bipait, ça vivait un peu, mais soyons honnêtes : le rendu était plat, très mono, très sec. Ça donnait un côté “prototype” qui collait bien au début du projet, mais plus la console avance, plus j’ai envie qu’elle raconte des choses aussi avec le son.

C’est là qu’arrive la grosse nouveauté : la console utilise maintenant deux sorties audio, sur le pin 12 et le pin 21 de l’ESP32, chacune reliée à un piezo. Dit comme ça, ça a l’air anodin – deux petits haut-parleurs au lieu d’un – mais en pratique, ça change complètement la sensation de jeu. D’abord, très simplement, le son est plus plein, plus présent dans la pièce. Les petites musiques retro, les bips et les effets prennent une autre dimension. Là où avant tout sortait d’un seul coin de la console, maintenant on a l’impression que la machine “parle” vraiment, qu’elle a une petite présence physique, presque comme un vieux jouet électronique mais en version 2.0.

Techniquement, sur l’ESP32, ça signifie que je peux piloter deux canaux sonores séparés. Dans mon code, le son est généré via du PWM (avec les fonctions ledc d’ESP32), et maintenant je peux décider indépendamment de ce qui sort sur le canal gauche (pin 12) et sur le canal droit (pin 21). Pour l’instant, je m’en sers surtout pour doubler le son : même fréquence sur les deux piezos, même volume → un son plus puissant, plus clair, très utile pour les bips de tir ou les sons d’alerte dans le jeu. Mais la vraie magie commence quand je commence à les différencier un peu.

Par exemple, sur un nouveau jeu comme CRATÈRE-7, mon mini-DOOM en raycasting que tu vois dans le code ci-dessus, le fait d’avoir deux sorties audio ouvre beaucoup de portes. Je peux associer un son spécifique à chaque type d’événement : un tir de blaster bien sec, un “bip” grave quand le joueur prend des dégâts, un son plus joyeux pour la prise de clé, une petite montée de notes quand le sas s’ouvre enfin, un son plus sombre pour l’activation du boss… Tout ça existait déjà dans ma tête, mais avec un seul piezo, si je voulais tout faire, ça devenait vite confus. Avec deux sorties, je peux mieux séparer les couches : par exemple, garder un canal pour les effets rapides (tir, dégâts, ramassage d’objet) et utiliser l’autre pour des petits motifs musicaux ou des bips d’ambiance.

Concrètement, dans le code, je commence à organiser le son autour d’une fonction centrale du genre playSFX(id) que j’appelle dans les bons moments : quand fireShot() est déclenchée, quand la vie du joueur diminue dans updateEnemies(), quand hasKeyA ou hasKeyB passe à true, ou quand on entre en ST_OVER (game over). Le moteur de jeu ne s’occupe pas de “comment” le son est généré, il se contente de dire : « là, je veux un son de tir », « là, un son de clé », « là, un son de game over ». Derrière, le “moteur son” choisit la fréquence, la durée, et sur quel canal ça sort (pin 12, pin 21, ou les deux). C’est là qu’on s’amuse : un tir peut être joué fort et court sur les deux piezos ; un dégât peut être un bip plus grave ; une clé peut être un petit enchaînement de deux notes ; l’ouverture du sas, une mini montée en trois paliers. C’est tout bête, mais dès que tu rajoutes ces repères sonores, le cerveau comprend mieux ce qui se passe dans le jeu, même sans lire le HUD.

Pour l’instant, je reste sur des sons assez simples, mais l’architecture est prête pour aller plus loin. Le fait d’avoir deux sorties me permet aussi d’envisager une pseudo stéréo : par exemple, dans CRATÈRE-7, si un ennemi se trouve plutôt sur la gauche du champ de vision, je peux donner légèrement plus de volume au piezo connecté sur le pin 12 ; s’il est à droite, un peu plus au pin 21. Ce n’est pas de la vraie spatialisation, mais ça donne une impression de direction, et dans un FPS, même minimaliste, ça apporte beaucoup à l’ambiance. Je peux aussi imaginer, plus tard, des petits motifs rythmiques alternés : note à gauche, note à droite, pour donner un côté un peu “danse de pixels” aux musiques.

L’autre gros avantage pour moi en tant que développeur, c’est que ce système audio évolue avec la console. Plus le projet grossit (menu déroulant, raycasting, boss, clés, sas, etc.), plus le son devient un outil pour expliquer au joueur ce qu’il vit sans surcharger l’écran. Comme la console reste très compacte – petit écran, HUD minimal – le son est un allié précieux pour compenser : il prévient, confirme, rassure, surprend. Et comme tout est en C dans un code que je maîtrise, je peux l’adapter à chaque nouveau jeu, chaque nouvelle interaction.

Ce qui me fait plaisir, c’est de voir que ce n’est pas juste un “délire de bidouilleur”. Quand je teste la console avec les enfants du fablab, ils réagissent tout de suite à ces nouveaux sons. Le tir paraît plus “vrai”, les clés font “objet important”, le game over est plus marquant. Pour eux, ce n’est pas l’histoire de deux piezos sur les pins 12 et 21, c’est juste : « ah, ça sonne mieux ! » Et c’est exactement ce que je cherchais. Pour moi, comme pour eux, cette LUMA qui commence à chanter un peu mieux, c’est une façon de montrer que la console grandit, qu’elle se rapproche de plus en plus d’une vraie petite machine de jeu, tout en restant artisanale, open source, et construite à la main.

Et le plus beau dans tout ça, c’est qu’on n’en est qu’au début. Ce système à deux voix sur 12 et 21, c’est la base sur laquelle je vais pouvoir ajouter, dans les prochains devlogs, des petits thèmes musicaux, des ambiance loops, peut-être même un mini “moteur musical” pour les menus et les écrans titres. Bref, LUMA n’est plus seulement une console qu’on regarde : c’est une console qu’on écoute. Et pour un projet né dans un fablab, entre deux soudures et trois bips, je trouve ça plutôt symbolique.