GAME DESIGN

It's difficult to reduce an area as broad as game design in a simple summary. Design is by essence subjective and adaptative, every project needs tailored design thinking and approach. That being said, here are some key design guidelines that comes to mind:

A game designer needs to keep learning; I've been designing games for years now, and am still only scrapping the surface to game design. I'm naturally curious, so this is one of my favourite aspects of game design!
A game designer needs to have excellent communication skills; both to externalise their ideas and to take critical feedback from others.
A game designer is a problem solver; fixing two solutions with one problem, and taking into account not only the game, but also the production context in which the game is made.
A game designer thinks with the player in mind; making a game that is fun to design doesn't mean it will be fun to the players.
Design is narrative, a game is an experience; ideas might exist within a narrative that would not otherwise make sense out of context.
Design is elegant; features must be intuitive and be meaningful to add to the game.
Design is beautiful. I'm never as proud as when I witness excitment, surprise, joy in the eyes of someone playing something my collegues and I made.

PUZZLE DESIGN

My puzzle design process is similar to my level design process, and on many aspects, the two are closely intertwined. Puzzle design requires great care when it comes to introducing game mechanics and teaching them to the player gradually.

From my experience working on puzzles for both Labsterium and Littlefield Studio, I wrote a Puzzle Design Masterclass for the students of LISAA School of Art & Design.

Key principles I keep in mind when creating puzzles:

Build the game around one core mechanic: a strong puzzle game is often built around a single core mechanic, explored in varied ways (think Portal or The Witness). When designing puzzles, the first thing to do is listing every possible interaction and iteration that mechanic could have. This is also a good way to get a sense if the core mechanic is rich enough to support a whole game.

Ensure the victory conditions are unambiguous: no matter how complex the resolution, the final expected result must be clear for the player to begin crafting a solution.

Ensure puzzles are solved through reasoning: if a puzzle overwhelms the player with complexity, they may abandon reasoning and simply test random solutions. I aim to design puzzles where logical deduction is always more effective than brute force experimentation.

Take time to teach the players: introducing mechanics requires careful pacing; too slow, and the player gets bored. Too fast, and the player may not grasp the mechanic fully. If a player misunderstands or forgets a mechanic, the game becomes much harder to enjoy or master.

Surprise the players: once a player understands a mechanic, I look for ways to surprise them with new uses. A common technique I enjoy is the catch-revelation design: teach the player a solution in Level A, and make them to apply it in Level B, where this solution will fail, and then reveal an unexpected, innovative way to overcome the challenge. This makes the player stop and think about what they're actually doing rather than mindlessly following the game, and rewards them with a sense of discovery.

A puzzle I made for Machinika Atlas:

This puzzle takes place at around 65% of the game and is supposed to be the 5th chapter's toughest puzzle. This chapter's theme is gravity, so I opted for a cinematic feel by making the player fly 360° around the puzzle.

The objective is simple and intuitive: a classic pattern completion puzzle. Pentagonal objects must be rotated and all linked to each other. But because the player cannot see the whole puzzle at once, the solution becomes harder to figure out.

Players can try solutions at random, but the camera once again makes brute forcing the puzzle more tedious than actually solving it. Players can find two clues on this puzzle: there are two special pentagones, one with links in every direction, and one with no links at all. Starting from there, each adjacent pentagone's position can be deduced step by step, with no need for a complexe mental map or memory overload. The rest of the solution is easy enough, players work towards victory making visible progress and are rewarded with a cutscene upon success.

Programming

While working at Littlefield Studio, I spent countless hours working in the game engine. In addition to my design responsibilities, I was also responsible for implementing puzzle behaviors and player navigation in Unity, using a custom-made blueprint system inspired by Unreal Engine.

I have also worked on several projects in Unreal Engine, including my graduation project, gaining experience with its Blueprint system and overall workflow.

Since joining YSO Corp, I have made significant progress coding in C# for Unity. I created one game prototype every week and took weekly feedback from programmers at my workplace to improve my skills.

LEVEL DESIGN

My approach to level design may change depending on the game and situation I'm working with, but following here is my general design process. I'll take my graduation project Twin Cores for example, as I feel I've grown a lot as a level designer from this experience. If you play the game, I was responsible for the part in which both players are fused in a single ship.

Step 1: What's the narrative context?

Is the game set in a cramped cave, or an open field?

Is the intent to scare the player, or make them feel powerful?

What comes before and after this situation?

The context will shape the overall experience expected for this level.

For Twin Cores, I needed to make an environment challenging for both the players in control of the ship and the player in control of the weapon, so I needed to have dangers to dodge and targets to shoot at all at once. On top of that, the environmental corruption players were fighting needed to be more present than in other areas of the game. I decided to make the environnment ravins as opposed to the open sky previously explored. Having close walls and ground helped with speed perpsective, visual identity, and narrative situations with enemies jumping in and out of cover.

Step 2: What are the game mechanics?

What are the abilities available to the player at this point?

What are the level design bricks specific to this environment?

Are there underused or overused mechanics in other parts of the game? Why?

Thinking early about the mechanics available for my level design help me create a coherent environemnt as well as identity.

For Twin Cores, I exploited the ravins for cover for enemies and obstacles to dodge. I also made heavy use of the snake-like enemy, representing heavily corrupted enemies and barely seen in other sections of the game, thus tying that enemy to this environment. Its snake body felt like a natural fit with the long ravin corridors, and their attack pattern as well as durability were perfect for the player's fused ship.

Step 3: List interesting situations

Now that I have the context and game mechanics, it's time to go wild; I make a list of design situations and iterations, with as few constraints as possible. At this step I'm usually working with a pen and paper first for quick ideas, but Illustrator or Figma for more complex depictions and in the game engine for ideas that require three-dimensional thinking are good too so as not to limit my imagination.

This is also important to share those ideas with the rest of the team, so artists and programmers can share their technical points of view on those situations and everybody can share ideas and feedbacks, as well as to help build a coherent global understanding of the game within the team.

For Twin Cores, I had a lot of wild ideas with enemies jumping into the ravins, players making short fast-paced turns and flying between rocks and projectiles. This is where most of the cinematic gamefeel comes from.

Step 4: Build the gameflow

This is a crucial step, because there are many factors to take into account. New mechanics and level design bricks need to be introduced progressively to the player The pacing must alternate between discovery, mastery, and resting. Environmental story telling must be coherent with narrative intentions as declared in step 1. Depending on the gameflow needs, I choose the best and most appropriates ideas from step 3, and make others as they naturally come to mind. At this point, I'm making the first overall level schematics.

For Twin Cores, this step was very delicate to balance. I had to introduce a number of mechanics (the snake enemies, the close ravins, and above all the fused-ship mechanic). I took the time to create several gameflow experiences, mixing and matching them until I was satisfied with the result, and continued to improve upon it later on with proper playtests.

Step 5: Assemble the level

It's time to greybox the level. I have an overall idea of each situation's intention, but there is still a lot to do.

While I'm doing the greybox, I keep in mind the design intentions, gameflow, and narrative behind every scene. I use level design to guide the player where I need, using landmarks, information priorization, guiding geometry and features. While building the greybox, I stay in close communication with the artists and narrative designer.

For Twin Cores, I worked in close colaboration with our artists to ensure we shared a common artistic direction.

As a sidenote, we had another challenge at this point: our professors advised against making a rail-shooter because there had been many unsuccessful attempts in the past years. When we started the project, we took that advice in consideration and analysed those previous games; we noticed that those games felt "empty", with unfinished environment. For that reason, we decided to make our rail-shooter loop into a closed environment rather than going in a straigth line, giving our artists and level designers less space to fill. In my greybox, I did so by making the players go into the ravins first, then fly back above it a second time. We're very happy with the results!

Step 6: Playtest

As soon as I have a coherent section of gameplay, I try to put it in another player's hands. It helps me catch issues early and prevent wasting effort later on.

From this point onward, repeat steps 5 and 6 until the result is satisfying, tweaking the level design and replacing placeholders with more advanced assets as time goes on.

For Twin Cores, I spent a lot of time watching playtesters go through my portion of level design and tweaking the level afterwards. One issue I had was a long ravin with turrets at the end shooting the players. Because the projectiles were coming from upfront, the player controlling the weapon was hiding the enemy's projectiles with their cursor, making dodging nearly impossible for the other player in control of the ship's movements. My solution was to move the enemies above the ravin, so their projectiles would be seen crossing the screen instead. I also dispresed them along the ravin, so targetting them was easier and more rewarding while pushing the weapon's wursor away from the screen center.

LEVEL DESIGN

My approach to level design changes depending on the game and the specific situation.

My general level design workflow:

Step 1: Define the narrative context

Is the game set in a cramped cave or an open field?
Is the intent to scare the player, or make them feel powerful?
What comes before and after this section?

The narrative context shapes the experience the level should deliver.

Step 2: Identify the game mechanics

What abilities does the player have at this point?
What level design bricks are specific to this environment?
Are there mechanics that have been overused or underused elsewhere?

Thinking about mechanics early helps create a coherent and memorable environment.

Step 3: Generate interesting situations

With the context and mechanics defined, I brainstorm situations with as few constraints as possible. I usually start with pen and paper for speed, then move to Illustrator or Figma for more complex layouts, or directly into the engine for 3D ideas. This step is also key for sharing ideas with the rest of the team. Early feedback from artists, programmers, and other designers helps refine concepts and keep the project cohesive.

Step 4: Build the gameflow

At this stage, I balance multiple factors:

Introducing new mechanics progressively.
Alternating pacing between discovery, mastery, and rest.
Ensuring environmental storytelling aligns with the narrative.

I select the most fitting ideas from Step 3 and arrange them into an initial level schematic.

Step 5: Assemble the level

I greybox the level with the intentions, gameflow, and narrative in mind, guiding the player through landmarks, geometry, and visual cues. Communication with artists and narrative designers remains constant during this stage.

Step 6: Playtest and iterate

As soon as a playable section exists, I put it in front of players to identify issues early. I then repeat Steps 5 and 6 until the level is both functional and polished, gradually replacing placeholders with final assets.

My creative process for Twin Cores:

I chose to use my graduation project Twin Cores as an example, as I feel this was a major step forward in my growth as a level designer.

I needed to create an environment that challenged both the player controlling the ship and the player controlling the weapon. That meant including both hazards to dodge and targets to shoot. The “environmental corruption” that players were fighting also had to feel more present here than in other areas. I decided to set the level in deep ravines rather than the open skies seen earlier. The close walls and ground enhanced the sense of speed, provided a distinct visual identity, and supported narrative moments with enemies jumping in and out of cover.

I used the ravines to provide cover for enemies and create obstacles to dodge. I also featured the snake-like enemy type, representing heavily corrupted foes. This enemy was made with this section in mind, and was purposfully rare in other areas of the game so as to give it a strong association with this environment. Its long body fit naturally into the ravine corridors, and its attack patterns worked well with the fused-ship mechanic.

I imagined sequences with enemies ambushing from the ravines, fast-paced turns, and weaving between rocks and incoming fire. These ideas became the basis for the cinematic feel of the level.

Balancing the introduction of the snake enemy, close-quarters ravines, and the fused-ship mechanic was a delicate task. I built several versions of the gameflow, mixing and matching sequences until I was happy, then refined it further through playtesting.

One challenge was our professors’ warning about rail-shooters, as previous student rail-shooter projects had struggled with “empty” environments. To address this, we created a looping environment instead of a straight path, reducing unused space and increasing density. My greybox had players first flying inside the ravines, then looping back above them for the return.

I noticed during playtesting an issue where turrets at the end of a ravine fired directly toward the players. The weapon player’s targeting cursor often blocked these projectiles from the pilot’s view, making them nearly impossible to dodge. I solved this by moving the enemies above the ravine so their shots crossed the screen visibly, and by spreading them out along the path, making them easier and more satisfying to target.

PUZZLE DESIGN

My puzzle design process is somewhat similar to my level design process. In many cases, both find themselves intertwined. However, making a puzzle needs even more care to slowly introduce game mechanics and teach them to the players.

There is much more to say about puzzle design. After my experiences working on puzzle design for both Labsterium and Littlefield Studio, I wrote this Puzzle Design Masterclass for the students of LISAA School of Art & Design. I believe teaching is one of the best ways to learn. If you check it out, feel free to give me feedbacks!

Here are some key design features I always try to keep in mind when making a puzzle:

What's the narrative context?

As always, narrative context is a good starting point, and can create new kinds of puzzles that would otherwise be impossible.

Can my puzzle be solved with reflexion, rather than trial and error?

If the puzzle takes too much mental overload, and thinking about the solution is harder than trying out a bunch of solutions at random, then the players most likely wont solve the puzzle the way I intend them to.

How can I exploit my game mechanics?

Ideally, a puzzle game is built around a single main mechanic, and exploits it in varied ways. When building puzzles around a mechanic, I try to list every way the mechanic could be used, and how it would interact with differrent mechanics.

Teaching players

The hardest part of puzzle design is arguably teaching mechanics to players.

Too slow, and the player will get bored.

Too fast, and the players might not understand them properly. Once the players misunderstand or forgets a game mechanic, the game becomes increasingly harder to master.

Surprising players

Once a player understands a mechanic, I introduce them to new ways to exploit them. The ideal way to achieve that is to teach a solution to the player in level A, then trick the player into using this solution in level B, only to make them realise there is a new innovative way to overcome this level. This is known as the catch-revelation design.

Puzzle Design Masterclass

PROGRAMMING

When working at Littlefield Studio, I spent countless hours working within the game engine. Aside from my deisgn responsibilities, it was also my job to implement puzzles behavior and player navigation within Unity, using a custom made blueprint system inspired from Unreal Engine. I'm always happy to learn and quick to adapt!

The image below is a screenshot of a few nods I I was working with.

Since I've began working at YSO Corp, I've also made huge progress coding in C# in Unity. I make one game prototype every week, and happily take feedbacks from professionnal programmers in my workplace to help me improve.

Communication is key!

Especially for a game designer, who must interact daily with varied specialists. Back when I was a student, I often mediated communication between my classmates. Bad communication invariably leads to problems that could've been prevented.

Communication happens at multiple scales, all equally important to me:

First is team organization. Being socially proactive, knowing when to call for a meeting, using the organization tools at my disposal, and knowing my responsibilities within the team.
Then is information transmition. Knowing how to give and recieve information and criticism, remove miscommunications, knowing how to brainstorm and present ideas.
And then is empathy and the more social aspect. More than information, this is about giving people room to speak, showing them they are heard, being easy to approach so others won't hold back interacting with you, resolving conflicts, and motivating those around you.

There is a lot more to communicating than first meets the eye!