*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.*
My games
You crash landed on a mysterious planet. What’s even stranger, the planet itself seems to be able to speak to you. She tells you her name is Sirenis and that she can help you find your missing brother, the whole reason you came here in the first place.
But who knows what she might ask of you in return?
My role: Technical designer, AI programmer/integrator
15-20
The Signal : Stranded on Sirenis is the game I worked on while I was employed at Goose Byte Studios. I worked on the project for about 6 months.
It is a first-person game combining elements of survival craft and looter shooter where you must explore, fight, build your base, gather resources, craft equipment, and go on expeditions in order to find your missing brother on an alien planet. All this with the help of Sirenis, the disembodied voice of the planet, who always seems to know more about you than you know about her.
The game is still in development but a demo is currently playable on Steam.
What I did in this project
When I arrived at Goose Byte, the project’s general direction had just undergone drastic changes. Certain aspects of the game had to be rebuilt almost entirely from scratch, including the AI characters systems.
I was therefore tasked with developing new systems for the use of AI characters, then integrating these characters in-game and ensuring that they all worked as intended.
I was essentially responsible of anything related to non-player characters on the tech side of the project.
Developing new systems
I designed, implemented, and maintained several systems necessary for the proper functioning of enemies and other creatures in the game, including a target detection and prioritization system, a patrol system, an attack selection system, a team management system, and a behavioral archetype system.
All creatures in the game (except for a few unique cases) operated on the same Behavior Tree, and their behavior could be modified with a variety of parameters such as their team, their type of aggression, or the different attacks at their disposal.
Example of the target prioritization system in action.
Some enemies can have multiple attacks. Selecting between these attacks depends on several modifiable parameters such as distance from their target for example.
Integrating enemies and other AI creatures
I was generally responsible for integrating creatures into the game and programming their behavior. I worked closely with artists to properly integrate their models and animations, as well as with gameplay designers to ensure that all creatures acted according to their needs and were well balanced.
I exposed several parameters into data tables so that anyone could easily modify the characters’ values. These values included, for example, the number of health, the movement speed, the behavior archetype, the attack types, and much more.
Combat encounters
I was also responsible for creating tools that would allow level designers to have options on when and how to spawn enemies in the game so that they could create interesting combat situations.
Among the options I gave them, they could, for example, spawn different waves of enemies, place nests that spawn enemies regularly, create groups that patrol certain areas, or simply place creatures that roam more randomly throughout the levels.
What I learned
With The Signal: Stranded on Sirenis, I was able to greatly deepen my technical knowledge of Unreal Engine, especially in terms of implementing AI characters. I learned a lot more about Behavior Trees, AI navigation, and the Gameplay Ability System, among other things.
This project also allowed me to become a lot more familiar with C++ coding, which, to be honest, was something I lacked a bit of experience with before that. Since most of the previous mechanics and systems of the game had been written in C++, working on this project made me have to come out of my comfort zone and really familiarize myself a lot more with this programming language.
What’s more, working at Goose Byte gave me the opportunity to experience what it’s like to work on a real game production within a real indie studio, with everything that entails. Including, for example, milestones, publisher expectations, following tasks using Jira, etc…
Tools and software used
- Unreal Engine 5
- Confluence
- Jira
- Miro
- Github Desktop
- Discord
When Noah’s peaceful life is disrupted by the threat of pesticides, he must embark on an adventure with his faithful caterpillar companion to save the inhabitants of this world in this larger-than-life first-person shooter game.
My role : Lead technical designer, programmer
20
All Abug! is a student project completed in approximately 6 months as the final project for the Bachelor’s Degree in Video Game Design at the University of Quebec in Abitibi-Témiscamingue.
The main particularity of this project was the way the teams were managed. At the beginning of the school term, we were divided into about 8 teams of 5 to 6 people, and each team had to come up with a different game project.
As the semester progressed, projects were cut and members of those teams were reassigned to the remaining projects. This continued until only two projects remained at the end. So we had to get used to managing increasingly larger teams and ensure that we were always ready to bring new people on board.
I was fortunate enough to be part of the original All Abug! team, which meant that I was able to participate in this project from the beginning of the design phase all the way to the end of production.
The game can be downloaded and played for free on Steam
All Abug! is a first-person adventure game set in a world of insects, where you play as a lizard named Noah.
Noah has a very long tongue that serves as his main gameplay mechanic. He can use it to destroy obstacles, retrieve items from a distance, fight enemies, and even use it as a grappling hook.
Noah is also accompanied by a giant caterpillar that he uses as a means of transportation, much like a train. Throughout his adventure, he must manage this caterpillar-train and ensure that it and its passengers reach their destination, while keeping it healthy and steering it clear of dangers and obstacles along the way.
What I did in this project
As the lead of the technical team and one of the few programmers on this project, I’ve had the opportunity to work on almost every mechanic and system in the game in one way or another throughout its development.
However, here are the main elements I have been working on:
Enemies
The enemies posed quite a big risk for the game, as no one on the team had any previous experience with AI programming in Unreal Engine. In the end, implementing the enemies became my responsibility and is probably what I spent the most time on during the development.
I used online tutorials and documentation to teach myself the basics of using Behaviour Trees and worked closely with artists to integrate character models and animations.
There are three types of enemies in the game: ants, moths, and mosquitoes, all with different appearances and behaviors.
Mosquitoes in particular were a real challenge for me. Since they moved by flying rather than walking, they couldn’t use Unreal Engine’s simple AI navigation to move around, so I had to create my own logic for their movement and positioning.
Debug options
I was responsible for creating a debug menu to make it easier to test the game and all its systems, which really ended up helping speeding up production. I continued to add new features to this menu as the project progressed and new systems were introduced.
This menu could be used at any time during gameplay and allowed players to spawn items or characters, add or remove health or wagons from the caterpillar, hide the interface to take photos or marketing videos. Most importantly though, it allowed people to teleport to any checkpoint in the game to easily test any segment of gameplay.
Dialogue system
I created a system to allow narrative designers to easily trigger lines of dialogue and conversations between characters anywhere throughout the game.
The narrative designers could add different triggers and choose which line of dialogue would be spoken by which character at which moment, such as when that character reaches a certain location or when the player performs certain actions.
I also made sure to add a priority system so that characters couldn’t talk over each other and so that voice lines that were more important to the story couldn’t be interrupted by other, more random voice lines.
Gameplay design
Since I was a part of the original 6-people team on the project, I was very involved in the design of the game, its gameplay, and its mechanics throughout the development.
My contribution as a designer included, for example:
- Proposing new mechanics by illustrating ideas as clearly and simply as possible;
- Writing documentation for a variety of gameplay elements and keeping it up to date throughout the project;
- Participating in designer meetings and helping to find solutions to problems arising from the game’s design;
- And much more…
Example of a One Pager used to propose a system for the caterpillar’s health
What I learned
All Abug! is a project where I learned a lot, both in terms of technical skills and project management.
It was the first project where I participated as the lead of a small team, so I was able to learn how to manage that team, discuss the direction of the project with other leads, create and assign tasks, and ensure that my team members always had a reasonable amount of work on their plate.
I was also able to expand my technical skills with Unreal Engine 5. Since this was my first time programming AI characters with this engine, I learned a lot about behavior trees and AI navigation, as well as integrating character models and animations.
I also got to learn more about other features of the engine, such as optimization tools and data management using data tables and data assets.
Tools and software used
- Unreal Engine 5
- Notion
- Miro
- Perforce (using P4V)
- Discord
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
9
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.
The 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 our 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
10
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
1
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!
2
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!
I invite you to consult my itch.io page where you can see every project and game jams I’ve participated in.