Gérez votre propre cimetière anglais du XIXème siècle !
Locksgate a été conçu dans le cadre de la Game Jam des Rendez-vous de l'Histoire : l'une des particularités de cette game jam est d'associer chaque équipe à un.e jeune chercheur.euse, dont le sujet de thèse sert d'inspiration. Dans le cas de Locksgate, c'est Tristan Portier, jeune docteur en Histoire, qui faisait partie de notre équipe. Il étudie les aspects sociopolitiques de la gestion des corps en Angleterre au XIXème siècle - une période où la construction des cimetières devient un authentique business.
Design des évènements narratifs
Locksgate a été développé sur Unity par une équipe de 7 personnes - dont 2 développeurs. C'est un jeu de gestion de cimetière au tour par tour. Je me suis chargé de concevoir l'interface graphique, et notamment le système permettant de générer aléatoirement des évènements narratifs à chaque tour :
- J'ai utilisé des Scriptable Objects pour attacher à chaque évènement une image, un son, un titre et un texte, ainsi que deux choix permettant d'affecter la réputation ou l'argent du joueur (SOevent.cs)
- A chaque tour, un évènement est choisi au hasard dans une liste de SOevents. L'évènement est ensuite retiré de la liste ; d'autres éléments peuvent y être ajoutés en cours de partie, par exemple des évènements de difficulté intermédiaire à élevée. Ce comportement est piloté par un script (ManageEvent.cs).
Système d'implémentation de l'audio
J'ai également conçu l'intégralité du système permettant d'implémenter les sons et la musique dans le jeu. Pour cela, je me suis principalement appuyé sur trois patterns :
- Des Scriptable Objects permettant d'attacher plusieurs sons du même type de manière à créer une sound pool. Lorsque le son est joué, un des sons est choisi au hasard dans la sound pool avant d'être joué (SOSoundPool.cs).
- Une event queue dédiée au son, ici appelé sound queue. Lorsqu'un son est appelé, il est rajouté dans la sound queue. Puis, si la sound queue atteint une longueur pré-établie, le prochain son remplace le premier élément de la sound queue. Cela permet de gérer l'encombrement lorsque de nombreux sons sont joués en même temps. De la même manière, j'ai créé une event queue pour la musique, que j'ai utilisée pour implémenter des transitions lors des changements de musique. Notez que chaque type de sound queue possède sa propre variable de contrôle du volume.
- Enfin un Sound Manager qui, pour des raisons pratiques liées au format de la jam, prend la forme d'un singleton. Chaque son est joué dans la sound queue, et peut être appelé à l'aide d'une fonction publique ( SoundManager.cs). Idéalement, j'aurais exposé ces fonctions au travers d'une interface.
Équilibrage des tombes
L'un des principaux challenges lors de l'équilibrage du jeu était lié à la rentrée d'argent à chaque tour. Plusieurs facteurs entraient en ligne de compte : le prix de chaque type de parcelle, la capacité de chaque parcelle, mais également le nombre d'enterrements à chaque tour, ainsi que leur prix - fixé par le joueur. Sachant qu'il y avait 3 types de tombes aux comportements différents (inspirés de la réalité historique), calibrer le jeu pour une victoire en 20 tours était un exercice complexe.
Afin d'aider notre game designer, j'ai conçu un document R markdown permettant d'illustrer le nombre de mort et l'argent gagné pour chaque type de tombe, à chaque tour ainsi qu'en 20 tours de jeu. J'ai choisi d'utiliser R car c'est un langage adapté aux études statistiques, et pour lequel je dispose d'une forte expérience (>10 000 heures de programmation).
Ces simulations nous ont permis de trouver des équations de comportement des tombes adaptées. Elles nous ont également suggéré qu'étendre la limite du nombre de tours à 30 permettrait d'augmenter l'accessibilité du jeu - ce que les premiers tests ont confirmé.