Créer le FPS rythmique parfait

BPM : Bullets Per Minute est un jeu d'action rythmique de type FPS dans lequel vous devez tirer, recharger, sauter et esquiver, le tout en rythme.

Lorsque nous nous sommes assis pour commencer à réaliser le jeu, nous avions plusieurs options pour aborder sa conception :

1. Diagramme de notes (par exemple Guitar Hero, Rock Band, Frets on Fire). Chaque musique possède des métadonnées qui définissent sur quels temps doivent se produire les « attaque », « esquive » et « rechargement ». Ces métadonnées informent le comportement des ennemis. Les diagrammes de notes indiquent à l'IA ce qu'elle doit faire.

Avantages : Possibilité de créer des expériences élaborées avec précision, potentiel pour du contenu généré par l'utilisateur de haute qualité.

Inconvénients : Très coûteux à produire par minute de jeu. Faible potentiel de rejouabilité.

2. Musique procédurale (par exemple, PaRappa the Rapper ou Wii Music). La musique est constituée de segments de musique. Ces segments de musique sont dynamiques et un algorithme sélectionne le prochain segment à jouer. L'IA attaque ensuite sur des marqueurs spécifiques pour chaque segment.

Imaginez un segment de roulement de batterie joué alors que les ennemis attaquent rapidement sur les doubles croches, suivi d'un contretemps où les ennemis attaquent sur les coups de caisse claire.

Avantages : Dynamique, bonne rejouabilité.

Inconvénients : Musique potentiellement de faible qualité. La musique est définie par le joueur, plutôt que par une structure de chanson, ce qui rend le voyage musical médiocre.

3. Temps musical uniquement (par exemple, Crypt of the NecroDancer). L'IA se fixe au rythme de la chanson, mais ses actions ne dépendent pas de l'état de la musique.

Avantages : Dynamique, bonne rejouabilité, la musique peut avoir son propre voyage musical, plus facile de créer plus de contenu, le game design ne dépend pas du contenu musical. 

Inconvénients : La musique n'est pas taillée sur mesure à votre expérience.

En tant que petite équipe, nous voulions faire un jeu assez gros auquel nous pourrions jouer pendant de nombreuses heures ; nous avons donc décidé d'adopter l'approche « Temps musical uniquement ». Nous voulions également profiter de notre jeu tout en le développant, c'est pourquoi nous avons choisi une structure de type roguelike. La génération aléatoire des niveaux d'un roguelike nous a permis de profiter du développement du jeu, car l'expérience de jeu était toujours originale. Puisqu'un roguelike exige une grande rejouabilité, nous savions que l'approche en « Diagramme de notes » ne nous donnerait pas les 30 heures (au maximum) de jeu dont nous avions besoin pour BPM. 

Nous avons cependant décidé d'utiliser quelques fragments de musique procédurale dans BPM, principalement comme stingers pour les boss de fin de niveau. Ils prennent la forme d'un crescendo contrôlé par le-la joueur-euse une fois un boss vaincu.

Coordination du gameplay

Le gameplay de BPM fonctionne essentiellement comme un step-sequencer en 4/4 à 88 bpm. Un ennemi peut demander de jouer une « attaque » dans une fenêtre de quelques temps. Pour cela, il interroge le séquenceur pour savoir si une attaque sur ce temps serait trop cacophonique.

Les ennemis disent au séquenceur : « Je souhaite attaquer le joueur dans les deux prochains temps, le forçant à esquiver ». Le step-sequencer répond « oui » ou « non ». La réponse du séquenceur se base sur le nombre d'attaques prévues sur ce temps, ou si un autre ennemi a un accès « exclusif » à ce temps. De cette façon, le step-sequener dirige l'ensemble du gameplay de BPM.

Ce séquenceur est également impliqué dans le gameplay côté joueur-euse. Les actions du-de la joueur-euse ne peuvent être effectuées que sur chaque demi-temps. Par exemple, il est possible de tirer, sauter ou lancer de la magie tous les demi-temps. Mais sur chacun de ces temps, il n'est possible d'effectuer qu'une action : recharger, esquiver, tirer ou lancer de la magie. (Il est cependant possible de sauter à tout moment, car l'expérience n'était pas convaincante lorsque le saut devait obligatoirement se faire sur un temps). 

Donc, pour nous, le problème majeur d'un point de vue technique était de nous assurer que nous savions à quels moments les « temps » se produisaient dans chaque morceau de musique. Nous avons expérimenté quelques solutions avec Unreal Engine, mais à l'époque, nous n'étions pas en mesure de synchroniser l'horloge audio et l'horloge du jeu. Nous voulions également faire des transitions entre les pistes sans que des échantillons manquants ne provoquent de clics.

Nous avons choisi d'utiliser Wwise car il nous permettait de résoudre trois problèmes :

1. Avoir des pistes qui effectuent des transitions propres.

2. Être capable de mixer un jeu nécessitant que la musique tape fort et que les effets sonores soient toujours audibles.

3. Synchroniser le rythme.

Transitions et effets

Josh Sullivan : J'étais en charge de l'intégralité du son pour BPM. Mon processus de création/mixage du son est peu commun. Comme j'ai à mon actif plus de dix ans d'expérience en production vidéo, j'ai choisi d'utiliser Sony Vegas (logiciel de montage vidéo) et non une véritable suite de logiciels audio lorsqu'il a fallu choisir un programme pour mixer et éditer les sons destinés à BPM. De toute manière, j'ai toujours considéré Vegas comme une version de Sound Forge (la suite de montage audio de Sony) avec juste une fenêtre de prévisualisation vidéo en plus.

Heureusement pour moi, la bande sonore de BPM est à 88 bpm. En raison de ce tempo constant dans l'ensemble du jeu, j'ai pu facilement couper toutes les séquences audio qui devaient être en rythme sur une piste clic à 88 bpm. Par exemple, les différentes étapes de rechargement d'une arme dans BPM sont toutes synchronisées avec le rythme (ce qui donne l'impression d'être dans Baby Driver). Pour y parvenir, j'ai placé une piste clic dans la timeline de Vegas, puis j'ai édité chaque son pour qu'il soit synchronisé avec cette piste clic. Chaque son se produit sur chaque temps du tempo. Cependant, il est important de noter que cette méthode n'aurait pas fonctionné si nous avions eu plusieurs tempos différents.

Une fois les sons terminés, je les importe simplement dans Wwise et je leur donne des données de spatialisation (si besoin). Ensuite, je limite l'instance du son si nécessaire. Un exemple où cela est absolument indispensable est le minigun, qui tire sur chaque noire. En raison de cette cadence de tir, le mixage peut devenir trop confus, il est donc préférable de limiter le son à un seul tir de minigun à la fois. Ensuite, je modifie les paramètres généraux (voice volume, pitch, etc.). Enfin, j'assigne au son le bon Output Bus. Il convient de noter que, pour des sons comme les coups de feu, j'ai au moins quatre sons uniques pour chaque arme. Puis je les place tous dans un Random Container, afin que les coups de feu ne soient pas perçus de manière répétitive par le-la joueure-euse.

Une fois cela fait, il ne reste plus qu'à créer un Event dans Wwise assigné à l'audio correspondant. Je ne me suis pas trop compliqué la vie avec les Events. Je les ai notamment utilisés pour arrêter les sons précédents avant d'en commencer de nouveaux. Par exemple, lorsque les ennemis font leurs bruits vocaux (sons de grognements en rythme). Lorsque l'Event Wwise associé au son de douleur de l'ennemi est déclenché, non seulement il joue le Random Container « ouch », mais il arrête les bruits de voix de l'ennemi.

Pour ce qui est de la musique, l'utilisation des Music Switch Containers et des Music Playlist Containers de Wwise m'a permis de faire une transition relativement simple d'un morceau de musique à un autre, le tout de manière synchronisée sur le rythme grâce aux réglages de paramètres temporels.

Il y a un cas dans le jeu où une partie de la musique n'est pas censée être en rythme avec la musique, il s'agit des Finishers de boss. Lorsque vous battez un boss, vous avez la possibilité de l'achever sans qu'aucun tempo ne soit joué ; vous décidez du rythme de chaque tir de note, et chaque note doit jouer en boucle à l'infini jusqu'à ce que vous tiriez le coup suivant. Même s'il s'agit techniquement de « musique », je les ai traités comme des « SFX » dans Wwise, car ils étaient plus faciles à implémenter dans des Events Wwise.

Mixer pour un jeu d'action rythmique

Sam Houghton : Mon objectif principal lors du mixage de BPM était de donner au joueur l'impression d'être à la tête d'un orchestre rock infernal. Les armes sont l'instrument principal du mixage, l'objectif étant de créer un sentiment exceptionnel de satisfaction lorsque vous entrez dans le rythme du jeu et commencez à enchaîner les séries de kills. À l'inverse, lorsque vous ne parvenez pas à effectuer un tir, un rechargement ou une capacité en rythme et qu'aucun son ne retentit, le vide sonore crée une sensation de déception. 

Parce que j'ai également composé la musique (aux côtés de Joe Collinson), nous avons laissé de l'espace dans les arrangements précisément pour ces sons. Par conséquent, il y a beaucoup de commentaires en ligne sur le fait que la bande originale sonne bien, mais qu'elle sonne encore mieux dans le jeu lorsque vous y ajouter les coups de feu. Ces commentaires étaient vraiment passionnants à lire, ainsi que de voir que les joueurs-euses avaient perçu cette intention. Après tout, c'est exactement à cela que sert la bande-son d'un jeu, à soutenir le gameplay. Elle le fait juste plus ouvertement dans BPM que dans de nombreux autres genres de jeux. 

Au début, j'ai joué un peu avec les effets de side-chain du canal de musique quand un joueur fait une « interaction sur le temps », mais la légère atténuation n'a vraiment rien fait pour augmenter la sensation de satisfaction, et ne faisait au mieux que retirer une partie de l'énergie du jeu. Donc, tout ce que je fais dans Wwise, ce sont quelques ajustements de niveau ici et là pour m'assurer que tout soit clair et percutant par rapport à la musique. Josh Sullivan a fait un excellent travail en créant tous les sons du jeu, ce qui a vraiment facilité les choses au moment du mixage. 

Synchronisation du rythme

David Jones : Pour synchroniser l'horloge du jeu avec le rythme, j'ai pensé que la meilleure implémentation serait la solution utilisée dans Borderlands, c'est-à-dire des modifications de Wwise pour détourner les appels MIDI afin d'interrompre la logique du jeu. A la fin de chaque temps, on pourrait demander l'état de l'entrée à ce moment précis. 

La solution parfaite serait qu'à chaque appel de l'Event « beat » dans Wwise, les entrées du contrôleur soient consultées presque immédiatement. Il s'agit quasiment d'une approche basée sur les échantillons. Verrouiller l'entrée et l'audio très étroitement ensemble dans l'intégration permet d'obtenir le maximum de précision possible et de juger si les entrées du joueur sont « en retard » ou « en avance », et de combien de millisecondes. On rejette ensuite les entrées qui sont trop décalées par rapport à la musique. Cette solution était toutefois ingérable pour une équipe de notre taille. C'est le genre de travail qui nécessiterait un-e programmeur-euse audio à temps plein, car cela interférerait avec l'ensemble du système d'entrée d'Unreal Engine et nécessiterait des modifications de Wwise. Nous avons donc décidé de prendre une autre direction.

Hack sans complexe

Notre solution est très simple et légère. Nous enregistrons un callback sur notre Event musical et faisons une recherche de EAkCallbackType::MusicSyncBeat. Chaque fois qu'un de ces Events du Music Switch Container se produit, nous identifions le décalage entre l'horloge du jeu et la progression implicite faite dans le morceau. Si ce décalage est supérieur à 10 msec, nous recalibrons l'horloge de notre jeu et appelons un Event pour tous les actors concernés.

Nous avons choisi cette astuce simple de calibration car cela suffit pour notre gameplay. Cela permet de garder nos ennemis proprement dans le temps avec une erreur de ~10 msec, ce qui est bien plus petit que notre fenêtre test du rythme. 

Cependant, il y a d'autres erreurs que vous devez considérer concernant les entrées du joueur. La fenêtre d'erreur du joueur est :

10 msec par rapport à la calibration de l'horloge, +[temps d'image] msec depuis le temps d'image, +[temps d'image] msec supplémentaires depuis le rendu en différé, +? msec du périphérique d'entrée, +? msec de traitement de la console, +? msec du traitement de la sortie TV/audio.

Cela vous donne une marge d'erreur potentiellement énorme sur certains systèmes. Nous savions que cette erreur serait très variable selon les utilisateurs-ices. Cependant, il y a un problème beaucoup plus grave ici, qui est que les FPS rythmiques ont une « malédiction ». 

Au cours de sa conférence du GDC 2019, Alex Jaffe de Riot Games a défini une « malédiction » (« Cursed Problem ») comme un « problème de conception insoluble, enraciné dans un conflit entre les promesses essentielles des joueurs ». Dans BPM, les promesses des joueurs sont : « vous tirez sur le rythme » et « les balles sont tirées lorsque vous appuyez sur la gâchette » - ces deux choses sont en conflit. La seule façon de résoudre ce problème est de « gagner par l'abandon ».  

Dans un jeu de beat-matching comme Guitar Hero, vos entrées sont décalées par la latence que vous avez définie en calibrant votre contrôleur. Comme vos notes n'ont pas d'effets sur le jeu, elles peuvent être testées en tenant compte de la latence. Le jeu compense la latence vidéo en testant si vous avez réalisé une entrée en rythme dans le passé. Le jeu sait quand la note aurait dû être frappée, quand elle l'a été, et quelle est votre latence vidéo. Le jeu regarde donc dans le passé pour voir si vous étiez à l'intérieur d'une fenêtre à : temps actuel - temps de latence. Cela peut être difficile à comprendre. C'est pour cette raison que, dans Guitar Hero, vous pouvez voir des notes disparaître après la ligne et sembler être « jouées » avec succès bien qu'elles aient dépassé la ligne. Votre téléviseur présente une latence et vous voyez cette latence en temps réel. Ceci n'est cependant pas viable dans un FPS, car votre objectif est défini à chaque instant.

Dans BPM, nous supposons que l'utilisateur a moins de 80ms de latence. Si l'utilisateur a plus de latence que cela, nous le détectons pendant la séquence de calibration de démarrage et activons l'auto-rythme. L'auto-rythme retient les tirs du-de la joueur-euse lorsqu'ils sont entrés jusqu'à ce que le prochain temps se produise. Pour les utilisateurs-ices qui ont moins de 80ms de latence, nous retardons leurs premiers tirs pour qu'ils se produisent sur le prochain temps et laissons leurs derniers tirs se déclencher immédiatement.

BPM a également un tas de trucs cachés permettant de pardonner les joueurs-euses pour certaines actions mal synchronisées au profit du plaisir de jeu. Il y a beaucoup de logique définissant ce qui est considéré comme des actions pardonnables et ce qui ne l'est pas. La plupart de ces éléments visent à permettre à toutes les configurations d'entrée de jouer sans problème. Nous avons préféré offrir une expérience de jeu de tir dans un opéra rock épique plutôt que celle d'un jeu de rythme extrêmement précis.

En fin de compte, BPM a été un succès grâce à sa solide intégration de la musique et du gameplay, et Wwise nous a aidé à réaliser BPM avec rapidité tout en restant constamment en contrôle.