The Dream factory est un projet réalisé en 10 semaines en collaboration avec des étudiants de l’ÉTS, de l’Université de Sherbrooke et de l’UQAT à Rouyn Noranda dans le cadre du concours Ubisoft Gamelab 2024.

Le jeu a reçu 5 nominations et 3 prix, notamment le prix du meilleur design de jeu, le prix du meilleur défi/innovation technique et le prix du publique.

Le jeu peut-être téléchargé et joué gratuitement sur itch.io.

Mon rôle dans le projet

En tant que designer UX et designer de puzzles, c’était ma tâche de penser à des mécaniques de puzzle qui seraient amusantes et engageantes, mais qui ajouteraient aussi de la valeur à notre mécanique de splitscreen dynamique, tout en répondant aux contraintes du concours. C’étais aussi mon rôle de m’assurer que les mécaniques seraient enseignées au joueur de façon simple et significative.

Quelques examples de schémas de mécaniques et comment elles pourraient être utilisées.

Nous voulions aussi que le jeu soit le plus accessible et facile à utiliser possible, pour qu’il puisse être joué par tout le monde, peu importe l’âge ou la familiarité avec les jeux vidéos. J’ai donc travaillé de près avec nos programmeurs et artistes durant tout la production afin de développer plusieurs stratégies telles que le fait de n’avoir qu’un seule touche à utiliser dans tous le jeu, utiliser des affordances avec les formes, les couleurs, les effets sonores et même des éléments plus subtiles comme du screenshake ou des effets de particules, et même rajouter un mode daltionien dans le menu d’options.

Encore plus important cependant, je me suis assuré que toutes nos mécaniques de puzzle soient les plus claires et évidentes possibles à utiliser, afin de ne pas avoir à les expliquer au travers de tutoriels conventionnels, et qu’elles soient plutôt enseignées par la découverte. Mon but était que les joueurs essaient des choses par eux-même et voient comment le jeu réagissait. Je me suis donc assuré de créer des puzzles avec une progression d’apprentissages qui permettraient d’accomplir celà.

Quatre règles de conception de puzzles

Concevoir des puzzles avec notre mécanique de splitscreen dynamique était un défi particulier, car ça pouvait très facilement rendre le joueur confus ou même étourdi s’il n’était pas utilisé judicieusement. À la suite de nos premiers playtests très tôt dans la production, j’ai donc établi quatre règles à suivre pour garantir que l’expérience reste conforme à ce que nous avions imaginé.

Ces règles sont les suivantes :

L’utilisation de plaques de pression au sol au lieu d’interrupteurs à activer est un exemple de choix qui ont permis d’éviter les touches additionnelles.

Un seul objectif commun en tout temps

Dans les premiers tests du jeu, nous avons vite réalisé que lorsque les deux joueurs tentaient chacun d’effectuer une action de leur côté, ça créait une sorte de conflit pour le control du splitscreen, ce qui menait a beaucoup de confusion et de frustration. C’est pourquoi nous avons décidé d’utiliser une approche de résolution de puzzle par étape, où chaque étape correspond à un objectif commun.

De manière générale, à chaque étape, l’un des deux personnage est bloqué et doit attendre que l’autre joueur lui ouvre la voie. Ainsi, l’un des deux joueurs a le temps d’observer le niveau et d’aider son coéquipier pendant que celui-ci peut se déplacer et tenter de résoudre l’étape du puzzle, sans que le splitscreen ne se déplace dans tous les sens.

Un exemple de niveau contenant la plupart des mécaniques du jeu.

Un certain degré d’exploration dans chaque niveau

Nous avons longtemps réfléchi à quels éléments de niveau devraient ne se trouver que dans un monde ou dans les deux, et si ceux-ci pourraient être différents d’un niveau à l’autre.

D’une part, nous ne voulions pas que tout soit visible dans les deux mondes en tout temps car nous voulions qu’une certaine exploration de chaque niveau soit nécéssaire par les joueurs afin de révéler la solution au fur et à mesure. Nous ne voulions pas, par exemple, que la solution d’un niveau puisse être comprise sans qu’aucun des deux joueurs n’ait à se déplacer. D’une autre part, nous ne voulions pas non plus que les joueurs oublient où se trouvent les éléments de puzzle et aient à constamment retourner sur leurs pas.

Mes apprentissages

The Dream Factory était le premier projet où j’avais purement un rôle de designer et où je n’ai pas eu à toucher au code du tout. J’ai donc appris l’importance de communiquer clairement les idées de design afin que celles-ci puissent ensuite être implémentées par d’autre gens selon la vision originale.

J’ai aussi appris comment servir de « pont » entre l’équipe de programmeurs et de designers. Comme j’avais de l’expérience en programmation, j’assistais régulièrement aux réunions des programmeurs, afin de bien comprendre le fonctionnement du jeu, ainsi que pour partager comment l’équipe de design pensais être la meilleure façon d’implémenter certaines mécaniques.

L’équipe

Programmeurs :

Alexandre Demers-Roberge (UQAT Rouyn-Noranda)

Maximilien Harvey (ÉTS)

Loïc Cyr (ÉTS)

Jeanne Castonguay (ÉTS)

Musique et SFX :

Isaac Lavoie (UdeS)

Outils et logiciels utilisés

• Unity
• Clickup
• Miro
• Canva
• Git (avec Github Desktop)
• Discord

Sonrise est un jeu réalisé en 8 semaines dans le cadre d’un projet universitaire à l’UQAT.

Le but du projet était de réaliser un jeu dont le personnage principal est inspiré par un personnage de pop culture imposé à l’équipe. Dans notre cas, ce personnage était Madeline, héroïne du jeu Céleste. Sonrise s’agit donc d’un platformer sidescroller en 2.5D de type Die and Retry, qui se concentre sur des mécaniques de déplacement précises et délibérées et qui demanderont une certaine maitrise de la part du joueur.

La mécanique principale du jeu est l’utilisation d’un masque magique, que le joueur peut porter et enlever à volonté afin d’alterner entre des abilités magiques et l’utilisation de gadgets.

Mon rôle dans le projet

Design de personnage et consonnance ludonarrative

L’une des parties importantes de ce projet était de travailler l’éthos du personnage, soit sa personnalité, son apparence et sa place dans le jeu, autant au niveau du gameplay que de la narration. Il était donc important pour nous de conceptualiser un personnage avec le plus de consonnance possible entre ses mécaniques et sa place dans la narrative.

L’un des meilleurs exemples de cette consonnance ludonnarative selon moi est l’utilisation du Masque par le personnage principal. Ce masque vient non seulement illustrer le thème narratif principal du jeu qui  est le masking, soit le fait d’endosser une fausse personnalité afin de plaire aux gens de notre entourrage,  mais il permet aussi de définir les abilités que le personnage peut utiliser. Par exemple, porter le masque permet au personnage d’effectuer un dash et un coup de queue magique pour rebondir plus haut, mais lui empêche d’utiliser son grappin ou de s’accrocher aux murs. Cela est expliqué par le fait que ce masque, bien qu’imposé par ses parents, n’est pas fait sur mesure pour lui et il doit donc utiliser ses mains pour le maintenir sur son visage.

Tutoriels et apprentissage des mécaniques

Mes apprentissages

Dans ce projet, j’ai appris à communiquer avec une équipe d’artistes afin d’assurer que les éléments visuels du jeu correspondent à la vision générale, sans pour autant que cela vienne au détriment du gameplay.

Ce projet m’a aussi permis de rafiner mes compétences avec Unreal Engine 5 et la programmation en blueprint, ainsi que d’apprendre certaines des fonctionnalités plus avancées de l’engin.

L’équipe

Intégrateur :

Rémi Therrien

Logiciels et outils utilisés

• Unreal Engine 5
• Notion
• Miro
• Perforce (avec P4V)
• Discord