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.

​

​​

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.​​​​