First Teaser of Miraculous Rise of the Sphinx.
From November 2021 to August 2022, I was in a work-study program at Magic Pockets as a Level Designer and Builder. Magic Pockets is an indie video game studio based at Torcy in France.
I worked on the game Miraculous: Rise of the Sphinx which comes from the series Miraculous Tales of Ladybug and Cat Noir.
It's a 3D action adventure game at the third person with narrative.
It's a 3D action adventure game at the third person with narrative.
The game has released the october 25 2022, on PC, Switch, Xbox One, Xbox Series, PS4 and PS5.
Missions:
- Game Design
- Level Design and Integration
- Camera Design
- Combat Design
- Barricade, Zone In, Plans and Lines
- Falling and Mobile Platforms
- Teleporters
- Collectibles
- Quest Markers
- Checkpoints
- Tortoise SVN
- Level Design and Integration
- Camera Design
- Combat Design
- Barricade, Zone In, Plans and Lines
- Falling and Mobile Platforms
- Teleporters
- Collectibles
- Quest Markers
- Checkpoints
- Tortoise SVN
Game Design
One of the most important parts of my alternation was the creation of "puzzles", "enigmas" or "level design challenges". It is about the player using his four exploration skills, two for each playable character, to interact with certain level design elements. Thus, the player can discover new places and access certain objects.
I first helped to define the four skills, then I entirely imagined situations that I detailed on words documents. After validation of their feasibility and relevance by the Lead Game Designer, I could create these situations in game, in Unity.
Level Design and Integration
Using the Words previously created, I used the "Blocking" method. This "method" consists in using and placing blocks of different sizes and colors in order to create puzzles. This allows me to have a first concrete idea of how the puzzles will work and where they will be placed.
While I was creating the blockings, I also made new Google Slide documents. These documents allowed me to better classify the puzzles according to the episode (chapter of the game) where it was located. I also added some screenshots to help you find your way around and I detailed more precisely each step to do with the skills until you get the reward of the puzzle.
Indeed, at the end of all the puzzles the player can systematically get a high value collectible. Once all the puzzles were done in Blocking, I created a new scene in Unity, called "Exploration Skills". In this scene I made in Blocking all the different situations for each of the four skills so that the programmers could develop them. Once this was done, I was able to integrate the different situations (composed of blocks that react to the skills, and that can now fall, be shot, destroyed etc) in all the puzzles of the seven levels.
Once the puzzles were working, the QA was able to test them and the environment artists were able to start creating props to "dress up" the blocking. Then we started to have real elements of the game (example: a big block replaced by a wall, or a square block replaced by a paper plane that the player can jump on). Once these elements were created I was able to place them where they were needed in the puzzles.
This whole part of creating and integrating the puzzles was one of the most important and challenging aspects of my work. But that's not all I did in terms of pure level design. I also participated (to a lesser extent) in the actual level design of some chapters. Mainly by placing blocking elements to create the path the player would follow.
Camera Design
Even before creating the puzzles, I started by learning how to create and place cameras. This has definitely been the hardest part of my work-study (so far) to learn and perform.
In this Miraculous game, the player does not have the freedom to control their camera. The camera, which is always in third person, changes position and adapts according to the area where the main character is.
So first I had to create zones (represented by geometric shapes whose points can be moved) with which cameras are associated. I placed a zone, then one (or two or three but not more) cameras in the same zone. The camera is controlled by two parameters: the camera angle and the position of the player. So I had to put an avatar of the player in the camera area and orient it towards the direction the player is moving. And also to orient the camera (in relation to the avatar) so that the player only sees what I want him to see.
After creating and modifying several cameras in several levels, the lead game designer took over and left me with a more classic level design.
Combat Design
In this game, in addition to the bosses at the end of the levels, the player regularly faces classic enemies (minions, henchmen).
The work I did in Combat Design was to place these enemies, modify their number per zone, and define the type of enemy for each of them. The fights are triggered in certain defined areas (like cameras). When the player enters a certain area, a fight is triggered and he can't leave the area until he wins or loses the fight.
So I placed the enemy zones in the same way as the camera zones, then I placed the enemies one by one, before deciding on the type of enemy for each. Indeed, there are several different enemies. Without listing them all, let's just say that there are enemies that are more resistant than others, some that are faster, that do more damage, that attack from a distance or in close combat, that charge at us, etc.
Barricades, Zone In and Planes
As a level designer, I also modified these elements a lot during my internship: barricades, zone in, planes and lines. I'm going to detail each of these elements.
Barricades are green lines, at least in the Unity scene because in game they are invisible, and prevent the player from crossing to the other side of this line. You can increase the size of this line as well as its orientation by adding modifiable points on it. I used these barricades to block some passages in the level design, or to direct the player in some puzzles. However, you should not abuse this solution because it creates an "invisible wall" in the levels.
The Zone In is a very important element since it delimits the game levels. It is represented by a square of green lines, such as combat zones or cameras. You can, just like with the barricades, add points on the zone in order to modify its shape and size. The playing field is located inside this geometrically shaped area, the player cannot leave it. So I participated in determining the boundaries of each level. I also placed objects that are called "Planes".
The planes are represented by grey grids with holes. Their length and width can be changed. The Planes are placed at the edges of the high surfaces from which the player can fall. In fact, in the seven levels, the player moves on roofs.
If he falls in the void, the character will actually fall into a Plane that is invisible in game (but visible in the Unity scene in order to place and modify it). When the player 6 touches the plane with his character, he will automatically be teleported to the last place where he was before falling. You don't lose the game (game over), nor life points or collectibles when you fall into the void.
Falling and Mobile Platforms
While I was working on the level design, I also had to place and modify falling and mobile platforms, especially in the different puzzles.
Falling platforms are platforms that fall into the void when the player touches them. The player has to jump on them without staying too long, or else he will fall into the void and hit a plane. I had a problem with this aspect. Indeed, as explained before, when the player touches a plane, he is teleported to the last place where he was. But if this last place was a falling platform, it is no longer present since it fell into the void and disappeared when the player touched it.
The result of the combination "Falling Platform + Plane + Player Falling" was that the player was teleporting into the void over and over again without being able to do anything. The fix for this problem was found on the side of the programmers, who had to exclude falling platforms from the "last places the player was before touching a Plane". This meant that when touching a plane, the player was teleported to the last place visited outside of dropping and mobile platforms.
Mobile Platforms are moving platforms, which move from left to right (or vice versa) or from bottom to top (or vice versa). I used them to add a little more difficulty in the exploration and puzzle phases. They also had the same problem as the falling platforms with the maps because the player could reappear at a location where a moving platform was before it moved and changed position.
Teleporters
Teleporters (TP) are small objects that are placed in the scene. They work in pairs and are represented by green squares with a red arrow on them (which indicates the direction the character will face when using the TP). The player can use one of them to teleport to the second one. I had to place these teleporters in several places so that the player could reach very distant areas that he could not reach by moving. The animation of the character taking a teleporter is such that the character jumps off the first teleporter and lands on the second. So I had to pay attention to the orientation of these objects because depending on that, the character can jump from 7 the first teleporter in one direction (you have to orient it to the direction of the level) and land on the second teleporter in a different direction.
In order for two teleporters to communicate with each other without understanding other teleporters, it is necessary to use what was called "tokens". That is to say, a number in a dedicated slot of the inspector of the first teleporter that is also put in the second. So, each pair of teleporters has its token (example: "token_40" is a token which can be in the inspector of two teleporters which communicate together).
Collectibles
In this game, there are only free currencies that the player can find by exploring the different levels.
One of my most common tasks was to create and place these currencies. In this Miraculous game, they are called Collectibles and are divided into two parts: Shiny Orbs and Macaroons.
There are also three different values for the two types of collectibles. So we have Shiny Orbs and Macaroons with values of 1, 5 and 10 only. Shiny Orbs of 1, 5, 10 and Macaroons of 1 are scattered throughout the different levels, on the player's path, on rooftops or somewhat hidden. The higher the value of the collectible, the fewer collectibles of that value are hidden in the seven episodes of the game (prologue plus the six episodes). Macaroons of value 5 and 10 are only found at the end of the puzzles. They are the rewards.
So I placed all the collectibles of the game (prologue and six episodes) by hand, one by one, knowing that there is a quota to respect: for each episode, I had to put 450 worth of shiny orbs (broken down into 1, 5 and 10 shiny orbs) and 150 worth of macaroons (broken down into 1, 5 and 10 macaroons). For the Prologue the quota was a little different: 150 worth of shiny orbs and 50 worth of macaroons.
Quest Markers
I also had the task of placing the quest markers. They are represented in the scene by grey cubes (in the same way as the collectibles) and by orange arrows in the game. These markers (arrows) show the player the direction to take to reach the end of the level. I have placed each of the markers one after the other. This way, in the game, the arrows pass invisibly one after the other. In fact, the player sees only one arrow that moves along with the main character's movements, in order to adapt to his position and show him the way to finish the current episode.
There was a peculiarity when I wanted to put quest markers on objects that you can interact with, in order to indicate them precisely to the player. I had to add tokens (like teleporters) to the marker and the same tokens to the object associated with the marker. Without these tokens, the quest marker would remain stuck on the interactive object and would not indicate the next level. These objects could be a teleporter, a breakable object or something else. In addition to having a token on the marker and its associated object, I also had to create a zone (like a zone in or a combat zone but without their script) around the object, and put the same token on it.
To recap the token part: the player normally follows the quest markers (arrows) until he gets to an object he has to destroy. If he does not destroy this object and continues or turns back, the marker continues to indicate the object and does not move. Once the player has entered the area (invisible in game and visible in the scene) and destroyed the object in question, the marker moves to the next marker and thus moves normally to continue to indicate the direction of the level by passing through the different markers placed.
Checkpoints
Like many games, Miraculous contains checkpoints in all levels. In the Unity scene, the checkpoints are represented by a green line (similar to a mobile platform line) that I had to place at strategic locations such as the beginning or end of a difficult fight (so that the player could restart the game right before a fight if he lost it, instead of having to move to the fight again). I also had to place these checkpoints after places where the player was likely to lose so that they wouldn't have to restart the challenge they had already completed if they had a problem of some sort.
Tortoise SVN
Since everyone works and modifies scenes or prefabs in Unity, we used the Tortoise SVN software. This allowed us to receive these changes and work with them. Thanks to this tool, we were all up to date on the different builds.
I didn't know Tortoise SVN before my internship. Indeed, at the IIM we were using Github, GitKraken or SourceTree. So it took me a little time to get used to the different uses of the software.
Communication
Communication was an essential part of my work as a level design - building student. Of course I had to communicate with my Lead Game Designer who gave me my missions, who explained them to me and who also helped me with some tasks. But not only.
I also communicated with the QA Analyst who told me about bugs that needed to be fixed, and I also asked him to test some of the changes I made.
I also communicated with the producer assigned to the project who also gave me some missions or asked me some information about my progress or some features, some level design elements.
On the puzzles and exploration skills, I was in contact with a developer from Kalank, a programming studio that worked with Magic Pockets on the game. So I created a scene specifically for the programmers where I prototyped the four different exploration skills and we tested different settings.
The people other than the Lead Game Designer with whom I communicated a lot were the environment artists. Indeed, one of their missions was to graphically dress up the blocking I was doing and the exploration skills I was creating and placing.
In order to help them, I made several documents presenting the explorations skills, as well as the elements to be dressed and some graphic ideas.
I also communicated with the producer assigned to the project who also gave me some missions or asked me some information about my progress or some features, some level design elements.
On the puzzles and exploration skills, I was in contact with a developer from Kalank, a programming studio that worked with Magic Pockets on the game. So I created a scene specifically for the programmers where I prototyped the four different exploration skills and we tested different settings.
The people other than the Lead Game Designer with whom I communicated a lot were the environment artists. Indeed, one of their missions was to graphically dress up the blocking I was doing and the exploration skills I was creating and placing.
In order to help them, I made several documents presenting the explorations skills, as well as the elements to be dressed and some graphic ideas.
