My games
*Vous êtes présentement en train de visualiser cette page en anglais. Basculer au français.
*This page was not designed to be viewed on a mobile device. Some elements may not appear correctly.*
The Worlds of Dreams and Nightmares are getting mixed up following the explosion of the Dream Factory’s central infuser. Two employees are sent to contain the leak and repair the infuser…
But it’s not easy to work together when we end up in two different worlds.
My role: UX designer, puzzle designer
The Dream Factory is a project realized in 10 weeks in collaboration with students from ÉTS, University of Sherbrooke and UQAT in Rouyn-Noranda as part of the Ubisoft Gamelab 2024 competition.
The game received 5 nominations and 3 prizes for Best Game Design, Best Technical Challenge/Innovation and the Audiance Award.
The Dream Factory is a two-player cooperative puzzle game based on a central mechanic of Dynamic Splitscreen. The game’s screen is split in two, with the world of Dreams on one side and the world of Nightmares on the other. Each player finds themselves in their respective world, and the line between the two worlds constantly moves in such a way as to always pass through the central point between the two players, who can then use this splitscreen to reveal passages, interact with the environment and solve puzzles.
Le game can be downloaded and played for free on itch.io.
What I did in this project
As a UX and puzzle designer, it was my role to think of puzzle mechanics that would not only be fun and engaging, but that would also add value to our dynamic splitscreen mechanic, all while meeting the requirements of the contest. It was also my role to ensure that the mechanics would be taughtto the player in a simple and meaningful way.
One of the first thing I did very early on was to come up with concepts for different mechanics that would create fun puzzles and add value to the splitscreen, using visual diagrams to examplify them. This immediately gave the team a more concrete idea of what could be achieved with a thoughtful implementation of our splitscreen.
A few example of diagrams of mechanics and how they could have been used.
We also wanted the game to be as accessible and easy to use as possible, so that it could be played by everyone, regardless of age or familiarity with video games. I worked closely with our programmers and artists throughout production to develop several strategies, such as having only one controller input to play the whole game, using affordances with shapes, colors, sound effects and even more subtle elements like screenshake or particle effects, and even adding menu options for color blindness.
Even more importantly, I made sure that all our puzzle mechanics were as clear and obvious as possible, so that they didn’t have to be explained through conventional tutorials, and could insted be taught through discovery. My aim was for players to try things out for themselves and see how the game would react. I made sure that the progression of puzzles would create a learning curve that would accomplish this.
Four rules for our puzzle design
Designing puzzles with out dynamic splitscreen mechanic was a particular challenge, as it could very easily become confusing or even nauseating for the players if not used judiciously. Following our first playtests very early in production, I then established four rules to follow to ensure that the experience remained as we had imagined it.
These rules are as follows:
As few controller inputs as possible
We wanted the players to focus on solving the puzzles, not on learning the keys and the gameplay. We also wanted to offer the most intuitive and easy-to-access experience possible, one that could be enjoyed by everyone. That’s why the player can only do one action in the whole game: move.
Not only does this allow the player to understand the game without a tutorial or prior explanation, but it also allowed us to choose which puzzle mechanics to keep and which to discard among all the ideas we had.
Using pressure plates on the ground instead of switches to activate is an example of a choice that made it possible to avoid additional inputs.
Only one common objective at all times
The use of pressure plates on the floor also gives one of the players a precise location where he knows to position himself so that the other player can look for the other part of the solution.
In early tests of the game, we quickly realized that when both players tried to perform an action on their own, it created some kind of tug-of-war for splitscreen control, which led to a lot of confusion and frustration. That’s why we decided to use a step-by-step puzzle-solving approach, where each step is a common objective for both players.
At each step of the puzzle, one of the two characters is trapped and has to wait for the other player to clear the path. That way the former player has time to observe the level and help his teammate, while the latter can move around and try to solve the puzzle step, without the splitscreen moving in all directions.
Every puzzle element must interact with the splitscreen
The Dynamic Splitscreen was not only the central idea of the game, but also a rather risky mechanic to produce since it’s relatively complex and there are few similar games we could use as reference. If we wanted to justify spending time to develop it, we had to ensure that it was at the core of every level, and that it was used judiciously.
Whether it’s lasers that bounce off the splitscreen line or enemies and platforms that change behavior as they move from one world to another, every puzzle element was designed to interact in some way with this central game mechanic.
An example of a level containing most of the game’s mechanics.
Just the right amount of exploration in each level
The level layout changes, but the puzzle elements are always in the same place in both worlds. For us, this seemed like the ideal amount of exploration without being too hard to keep track of the level.
We spent a long time thinking about which level elements should only appear in one world or both, and whether these could be different from one level to the next.
On one hand, we didn’t want everything to be visible in both worlds at all times since we wanted a certain amount of exploration to be required by the players in order to reveal the solution bit by bit. For example, we didn’t want the players to be able to find the solution to a level without either of them moving around. On the other hand, we also didn’t want players to forget where the puzzle elements were and have to keep retracing their steps.
What I learned
The Dream Factory was my first project where I was purely a designer and didn’t do any of the coding. I learned the importance of communicating design ideas clearly so that they could then be implemented by other people according to the original vision.
I also learned how to be the “bridge” between programmers and designers. Since I had programming experience, I still attended the programmer’s meetings on a regular basis, in order to fully understand how the game worked, as well as to share what we, the designers would think the best way to implement certain mechanics was.
The team
Artists:
Valentin Guiller (UQAT Rouyn-Noranda)
Alycia Castonguay (UQAT Montreal)
Designers:
Louis Lefebvre (UQAT Montreal)
Samuel Séguin (UQAT Montreal)
Programmers:
Alexandre Demers-Roberge (UQAT Rouyn-Noranda)
Maximilien Harvey (ÉTS)
Loïc Cyr (ÉTS)
Jeanne Castonguay (ÉTS)
Music and SFX:
Isaac Lavoie (UdeS)
Competition requirements
- Theme: Dreams
- 10 minutes of gameplay
- Coop online multiplayer
- One gameplay element that must be manipulated by 2 players at the same time
- One element that varies with each new game session depending on the previous session
- One AI mechanic
- A design concept of “exhaustion”
- One accessibility feature
- Rated “E for Everyone”
Tools and software used
- Unity
- Clickup
- Miro
- Canva
- Git (using Github Desktop)
- Discord
Use your gadgets and the powers of a magical mask, and prove to your parents that you are ready to climb The Tower in this Celeste-inspired platforming game.
My role: UX designer, gameplay and systems programmer
Background art by Cameron Lamoureux
The game can be downloaded and played for free on itch.io.
Sonrise is a game created in 8 weeks as a university project at UQAT.
Sonrise is a 2.5D sidescroller Die-and-Retry type platformer that focuses on precise and deliberate movement mechanics that will require a certain degree of mastery from the player. The aim of this project was to make a game whose main character was inspired by a pop culture character imposed on the team. In our case, this caracter was Madeline, protagonist of the game Celeste.
The game’s main mechanic is the use of a magic mask, which the player can put on and remove at will to alternate between using magical abilities and using gadgets.
My role in this project
As a UX designer, my role was primarily make the overall experience feel as good as possible and to ensure that the mechanics were understood by the players. As such, I had to work closely with our art team to ensure that each gameplay element had a distinct look that stood out and would be easily recognizable. One of the ways we achieved this was by using a distinctly different color for each of the character’s main movement abilites. For example, the grappling hook and everything that goes with it is green, the dash is pink and the double jump is orange.
Furthermore, as one of the very few programmers on this project, I spent a lot of time working on the character’s controls and movements, to ensure that they were as fluid and responsive as possible and would have a good “feel” to them. To achieve this, I used techniques such as input buffers and coyote time, as well as a lot of micro-adjustments to delays, movement speeds, character physics and more.
I also programmed most of the game’s systems, such as the checkpoint and respawn system, dialogue boxes, the camera system, the end boss’ behavior and even a speedrun mode.
Character design and ludonarrative consonance
One of the most important parts of this project was to work on the character’s ethos, i.e. his personality, appearance and place in the game, both gameplay-wise and narrative-wise. It was therefore important for us to conceptualize a character with as much consonance as possible between his mechanics and his place in the narrative.
One of the best examples of this consonance, in my opinion, is the main character’s use of his mask. This mask not only serves to illustrate the game’s main narrative theme of masking (i.e. assuming a false personality in order to please the people around us), but it also defines the abilites the character can use. For example, wearing the mask allows him to perform a dash and a magic tail kick to bounce higher, but prevents him from using his grappling hook or cling to walls. This is because while the character wears the mask to please his parents, this mask is not tailor-made for him, and so he has to use his hands to hold it to his face, making it uncomfortable for him to wear.
Tutorials and teaching the mechanics
It was important for me to find an effective way of teaching the player the controls and various mechanics, all while trying to keep everything as diegetic as possible. That’s why I decided to teach the mechanics through the various characters’ dialogues.
Since the Mother and Father characters are as much antagonists as they are mentors, it was only natural that the game should be learned through them.
In addition to directly explaining the controller inputs to the player at the appropriate moment, these dialogues are also used to explain level mechanics. For example, the father will tell the player about areas where wearing a mask is mandatory by explicitely threatening the player about catching him without his mask.
What I learned
With this project, I learned how to communicate with a team of artists to ensure that the visual elements of the game correspond to the overall vision, without detracting from the gameplay.
This project also allowed me to hone my skills with Unreal Engine 5 and programming with blueprints, as well as learn some of the engine’s more advanced features.
The team
Designers:
François Marie-Morin
Rachel Boulay
Samuel Séguin
Artists:
Cameron Lamoureux
Eddy Iv
Émile Lehouillier
Félix Simard-St-André
Ulric Boucher
Vincent Lalancette
Integrator:
Rémi Therrien
Tools and software used
- Unreal Engine 5
- Notion
- Miro
- Perforce (using P4V)
- Discord
You crash landed on a strange, desolate planet. Will you be able to escape or will you remain forever trapped in this ruined world?
My role: systems designer, systems programmer
Far Away From Us is a short, 5 minute long third-person atmospheric exploration game created in 8 weeks as a university project at UQAT in which you play as an alien who has to find the scattered parts of his spaceship to escape from a post-apocalyptic world.
The game can be downloaded and played for free on itch.io.
What I did in this project
I was mainly responsible for designing and implementing the game’s various systems, including the collection of spaceship parts, the checkpoint system, health, death and respawn and the acid rain that happends towards the middle of the game.
This project was my introduction to Unreal Engine 5 and my first experience with Blueprint programming. Since I already had prior experience with more conventional coding, I had some initial difficulties adapting to the engine’s drag-and-drop style system. In the end, however, it made me learn a lot about how to use Unreal Engine and made me more confident in my technical abilities.
The team
Designers / programmers:
Adel Garneau-Ricart
Samuel Séguin
Tristan Lapointe
Artist:
Benjamin Romano
Tools and software used
- Unreal Engine 5
- Notion
- Miro
- Perforce (using P4V)
- Discord
Run, dash and fight through the levels of this 2D top-down platformer. Be careful, however, as one single mistake could be your undoing.
Sector is a game I developed in solo in my spare time over a period of around 10 months, and was the very first game I ever worked on. It’s a 2D pixel-art die-and-retry platformer in which the player has to perfect his movements in order to survive and reach the end of the levels.
Everything was made by me except for the music and SFX (whichI commissioned).
The game can be downloaded and played for free on itch.io.
What I learned
This project taught me the basics of designing and programming games, as well as the basics of pixel-art and 2D animation.
More specifically, however, it taught me the importance of a good user experience and how to teach mechanics to players through tutorials, user interfaces and affordances.
I used a variety of Youtube tutorials, as well as online documentation to learn how to use Gamemaker Studio 2 and all that comes with it to complete this project.
Slime Eater
Shoot, Absorb, Grow!
The game can be downloaded and played for free on itch.io.
Slimer eater is a game created in 6 weeks as a university project at UQAT.
In this twinstick shooter where you play as a ball of slime, you’ll need to constantly stay in movement and absorb your enemies if you hope to survive the ever-growing hordes of monsters.
It’s up to you to choose how you want to upgrade your slime. Be careful though, as the wrong combination of upgrades can quickly lead to your downfall.
The team:
- Tristan Lapointe : Gameplay designer, general programmer
- Samuel Séguin : Gameplay designer, general programmer
Software used
- Unity
- Git (using Github Desktop)
- Discord
And much more!
Every game project I’ve worked on are on my itch.io page.