Étude de cas
Audio interactif & systèmes temps réel
AMS
J’ai co-conçu AMS comme système de musique adaptative pour Unreal Engine, en développant l’architecture musicale, les compositions et les règles d’interaction pendant que mon collaborateur construisait l’implémentation Blueprint.
Conception audio interactive, composition & R&D produit
Période de participation–
Retour au profil Unreal
AMS, ou Adaptive Music System, a débuté en 2019 lorsque Jorge, développeur Unreal Engine chez Coqui Games, m’a proposé de collaborer sur un concept de musique adaptative.
Jorge avait posé les bases de l’idée technique : un système Unreal Engine capable de réagir au gameplay grâce à la logique Blueprint. Sachant que je composais et produisais de la musique, il m’a demandé si je souhaitais explorer ce concept avec lui.
Le système détaillé a émergé de ces premières discussions.
Nous avons commencé à étudier le fonctionnement musical autant que technique de la musique adaptative : remixage vertical au moyen de couches compatibles, états de jeu comme l’exploration, la tension et le combat, transitions entre tempos et sections, et moyens d’éviter les ruptures audibles produites par un simple changement de morceau complet.
Nous avons également examiné les approches existantes, notamment Elias et les systèmes de musique adaptative déjà proposés sur l’Unreal Marketplace, afin de comprendre la place que pourrait occuper une solution plus simple fonctionnant directement dans le moteur.
La collaboration a rapidement trouvé une répartition naturelle des responsabilités. Jorge prenait en charge l’implémentation principale dans Unreal Engine et Blueprint, tandis que je me concentrais sur la composition, la production, la conception audio interactive et l’architecture musicale nécessaire pour rendre le système convaincant.
Au lieu de considérer la musique comme une collection de morceaux terminés, j’ai commencé à la composer comme un système interconnecté de matériaux musicaux compatibles. Des pistes individuelles pouvaient être ajoutées, retirées ou mises en avant selon l’intensité du gameplay, permettant à une même composition de passer de l’exploration à la tension puis au combat.
Nous avons aussi expérimenté les transitions entre sections musicales et tempos, des sons de diagnostic pour tester le système, des techniques procédurales et différentes méthodes pour rendre les sections interchangeables sans rupture musicale évidente. Lors de certains essais, j’ai volontairement imposé des propriétés communes, comme une même tonalité et une mesure en 4/4, afin de pouvoir échanger les sections tout en conservant la continuité harmonique et rythmique.
Cela exigeait une autre manière de penser la composition. Il ne suffisait plus de se demander si un morceau fonctionnait du début à la fin. Je devais envisager ce qui se passerait si le système commençait en son milieu, retirait plusieurs couches, remplaçait une section ou changeait d’intensité à cause d’un événement imprévisible au moment de l’écriture.
Nous avons créé du matériel de test et des démonstrations de plus en plus abouties autour de ces idées, avec des états d’exploration, de tension et de combat, ainsi qu’un exemple fantastique montrant comment le système pouvait remodeler une bande-son en temps réel.
Le concept produit s’est développé en parallèle du travail technique et musical. Nous avons envisagé de proposer le projet comme ressource Unreal Engine réutilisable plutôt que de le lier à un seul jeu. Le framework Blueprint principal aurait pu être vendu avec une musique de démonstration de haute qualité, puis complété par des bandes-son compatibles proposées séparément sous forme d’extensions.
L’objectif était de donner aux développeurs Unreal Engine certaines capacités adaptatives associées à des systèmes spécialisés comme Elias, mais au moyen d’un workflow directement intégré au moteur.
Cette combinaison m’intéressait particulièrement parce que le logiciel et le contenu pouvaient être conçus ensemble. Au lieu de créer un middleware auquel les compositeurs devraient ensuite s’adapter, nous pouvions développer en parallèle les règles musicales et le comportement technique, chaque aspect enrichissant l’autre au fil de l’évolution du prototype.
AMS a atteint un stade avancé de prototype et de développement de contenu, mais n’a jamais été commercialisé. J’ai tenté de relancer le développement en 2020, mais Jorge a ensuite rejoint Epic Games. Nous avons convenu de respecter les éventuelles implications liées à son emploi et aux conflits d’intérêts concernant la poursuite ou la publication d’un travail collaboratif sous Unreal Engine. Le projet a donc été mis en pause pour une durée indéterminée.
Même si AMS n’est jamais devenu le produit commercial envisagé à l’origine, cette R&D s’est révélée précieuse en elle-même. Elle m’a apporté une expérience pratique de la conception musicale comme système interactif plutôt que comme ressource fixe, du travail avec une logique de gameplay pilotée par Blueprint, de la traduction d’exigences créatives en comportements techniques et de la transformation d’une technologie spécialisée en produit réutilisable par d’autres développeurs.
Elle a également établi une approche que je continue d’appliquer dans mes projets de jeu : les systèmes créatifs et techniques fonctionnent mieux lorsqu’ils sont conçus ensemble plutôt que lorsque l’un est ajouté après l’autre.