Bubble Buds is a 3D Co-op puzzle prototype created for the Ubisoft 2024 Game Lab Competition. We were nominated for 5 awards including » Best Prototype « , » Best Game Design » and » Best User Experience « . In this project, I had the role of puzzle-oriented level designer, UX designer and game designer.
One of our goals as a team was to have tutorials in-game to explain the controllers to the players and not just have the controls displayed in the pause menu. The manipulation system in the prototype is unusual since our characters don’t have hands. Games use a lot of different techniques to bring these tutorials in the game world. Our first inspiration was the tutorials in the game Kena: Bridge of Spirit (Ember Lab, 2021) (see left image). The game pause the time of the game world to have a widget appear at the right of the screen, describing the mechanic to the players and showing a small video of how to use it (see image 1). These tutorials are placed in significative places in the world where players will need to immediately use the mechanic shown when the time resumes. I liked the idea of having a video to show the mechanic, but since the prototype was made for a competition in which the jury had approximately 10 minutes to test the game, I didn’t want them paused all the time and reading. This brought on the idea of our black board tutorials. All mechanics are shown on black boards in the game world, with GIFs showing how the mechanics works. With this technique, we didn’t have to stop the player flow to show new mechanics, the players had visual information on how to use the controllers and all that while being fully integrated in the environment of the dream world (see image 2).
The next process in the onboarding creation was to know when new mechanics would be introduced to the players. It also was the first step toward the level design, but I am going to circle back to that in the level design section. To make a solid onboarding plan, I used the onboarding plan that Celia Hodent showed in the chapter about the design thinking methodology in the book Dans le cerveau du gamer : neurosciences et UX dans la conception de jeux vidéo (p.210, 2020). With this plan, a list of all the elements that the players needed to learn, why they need to learn it and how I want them to learn it. With these information, I place them in order of priority and divided them between the different levels. After all that, I worked with our narrative designer for this project and we established how it would be woven in the story (see image 3).
The first step for the level design was to create a flowchart of the prototype. In this prototype, we placed the levels since we already had an idea of how many levels we wanted, the important narrative moments and the mechanics onboarding. As explained in the Onboarding plan section, knowing when new mechanics should be introduced to the player was important since I needed to know which mechanics were available at each level and to know how much time the players had to practice each mechanic, since the use of each mechanic would be a different challenge for the players. With that in mind, I designed our intensity graph of the levels. One of our challenges was that we wanted to make a game created for players who love coop-puzzle games, but we didn’t know who the members of the jury were and if they were our kind of players. We decided to follow a low-difficulty curve at the beginning, but that the last two levels would be a bigger challenge destined for the players that love this type of game.
For the level design, I shared that role with one of my collegues on the project. As I began to specialize in puzzle-oriented level design, I was in charge of making the plans and the blocking of the levels. For this task, I based my design on the theories of Jesse Schell in his book The art of game design: A book of lenses (2014) and of Wallace Wang The structure of game design (2023).
For each level, I began with listing the intention of the level, so what the players needed to learn based on the onboarding plan and if the level was supposed to be more difficult or easy. After that, I made a « paper » plan of the level, beginning by establishing the start position of the players and where their final goal was. To build the steps to the resolution of the puzzle, I needed to know how many steps I needed since, according to Wallace Wang, the difficulty of a puzzle can be determined by the number of steps needed to complete it and the time that each of these steps required of the player. When this paper plan was finished, I would go in the engine to build the blocking of each level, tested it and reworked some details before asking my teammates to also test it on their side.
For the first to levels, I needed to keep the difficulty low because the players had a lot to learn. They needed not only to learn new gameplay elements, but learn the rules of the game world and their place in it. Their challenge was in these levels to learn how to manipulate the keys with their bubbles. For the third level, they had a little challenge with the environment that was different for each of them.
The fourth level was a level in a new physical environment, since the players were now in the « nightmare » part of the game. They needed to acclimate to that and also 3 new mechanics were introduced. This level was tone-down in its difficulty because one of the elements that we introduced was our AIs, that are little creature that can interact with the keys and bubbles of the player. We affectionately called them « Puzzle fuckers », since their main goal was to cause chaos in the game world. It was a risky design choice, but with a lot of playtesting we achieved to make them one of the most loved elements of the prototype according to our players. So beginning with this level, players could have their bubbles popped or their keys remove from their sockets by these creatures.
Finally, since we wanted the last two levels to be more difficult than the others, the players had little visibility to each other’s side of the level, the number of steps needed to clear the room was bigger and we played with all the mechanics, introducing the final two at the fifth puzzle. Initially, the fifth puzzle was a greater challenge than now, but was considered too stiff a step in the difficulty curve compared to the fourth, so I designed an entirely new puzzle that made it to the final product.
The final puzzle was the most difficult and the one I had the needed to bring the most modifications to. I wanted to use the mechanics in ways that the players hadn’t seen before and sometimes it didn’t work according to my initial plans. I think with the comments from our playtesters and players that it was a welcomed challenged and a good way to finish the main game.
In one of my precedent projects, my labyrinth, my main conclusion was that, especially with a puzzle-oriented level, testing and modifying it was essential since no puzzle is perfect at first. They can be a great source of frustration for the players and a moment when players’ flow can easily break. To maintain it, we need to perfect the puzzles’ design to help the player toward its resolution. So, for this project, I wanted to try the design thinking methodology of Celia Hodent in her book Dans le cerveau du gamer : neurosciences et UX dans la conception de jeux vidéo (p.203-215, 2020). This method is centralized on the human that will play our game and is based on an iterative cycle where we design, prototype, test and analyze. We repeat this loop until the design of our product is satisfactory from a UX point of view. To help with that, it was recommended in the book to use great affordances to make the game intuitive to players and to build a onboarding plan as soon as possible, which we did.
For this protocol to work, I decided to make the design thinking loop five times. I would design some puzzles, implement them, proceed with a playtest and amass a lot of data from questionnaires given to playtesters and data I had taken during the playtests that I supervised. With this data, I made a list of UX problems that we met during the testing session and discuss of a solution for each of them with the rest of the team. All this testing made our game one of the best at the competition, earning a nomination for the « Best User Experience » award.