Pango

Pango is a third-person skill-based platformer in which you play as Pango, an AI android pangolin that can roll around the temple-like environment where his objective is to learn about the old society. Roll through winding pathways and jump over crumbling pillars as you collect ancient relics and uncover the secrets of an unknown civilization.

About Pango

UI Design

Main menu Background
Controller layout screen
Coins functionality with respawning and going back to the main menu
Special pickup functionality with respawning and going back to the main menu

Pango is a project I worked on in my second year of university where I was responsible for the level design and UI design of the game.

Level Design

Concepting different level structures
Sketching gameplay scenarios
Blocking out levels
Playtesting internally and externally
Iterating playtested levels
Working together with the envrionment artists team to finalize levels

17 Developers

Unreal Engine 5.1

12 Weeks

Project responsibilities

Playstyles

Rolling

The rolling mode is the ''special'' character mode in Pango. By pressing the right trigger the player can transform its body into a ball and traverse through the level in a faster way.

With this mode the player takes more risks with the benefit of getting a higher time at the end of the game.

Walking

The walking mode is the ''normal'' character mode in Pango. It is what you can expect from your usual 3D platformer, a character that can jump and walk through the levels normally.

This mode is the ''safer'' mode for the game, platforming in walking mode will give the player an easier time compared to the rolling mode.

In Pango the player is able to use 2 different character states at all times, walking and rolling. Each state has their negative and positive effects throughout the game and they allow for the game to be played in different ways. The player is always able to roll so we had to work around that while making levels.

Making main level

The level that I worked on the most was the main level with big temple. I knew I wanted to make a nice vista for this temple piece so, I started with the concept of seeing a big temple in the distance with a struggling path towards it. In order for the player to reach the temple I wanted them to choose a path. As seen in the blockouts I used different player mechanics to help the player choose what path they want to take. The ground pound option didn't work out, so I iterated the path decision with one of our level ingredients, the bounce pad.

The temple itself I worked on the most. I wanted the temple to have paths that go outside and back inside multiple times. This was a fun idea and also made it in the full game, but I did have to scale up the temple a lot. Because of the new scale I was able to put more interesting gameplay inside that was more focused on the walking playstyle compared to the path leading up to the temple. All of these changes made the temple feel like a satisfying landmark for the player.

Because I was more focused on the temple, the other level designer iterated the path towards it and changed it to a more interconnected section. Our communication on this level made sure both playstyles were still fully explored in this level.

Planning and Sketching

Planning the level was one of our most important steps in pre-production. As seen in the images below, we made a node map with an according difficulty graph to show the progression of the game. We designed the levels so that they followed the 4-step Level Design. An introduction to teach the player the basics, a development where we are combining the basics with more level ingredients, a twist where the level ingredients are used against the player, and finally a conclusion where everything comes to together in a satisfying way.

Testing

The quality of our levels was highly dependent on playtesting, that's why we made sure to do internal and external playtesting as much as we could. Knowing we only had around 2 or 3 weeks to make the levels, some levels were tested more than others. In the images below you can see how we used heatmaps to show where players walked or rolled, and where they struggled the most. For internal playtesting we had this nice document that went over all aspects that were important to test. When tested, the person who tested the level could then fill in if it was presentable, playable, functional, or still in prototype. We organized these internal playtests with the whole team to make sure everyone is aligned with knowing what the game is and to get best testing results.

UI

UI is known to cause issues in projects, our game was not an exception. Since I've worked with UMG before I decided to take up some UI fixing in our project.

This was all at the end of production so it didn't hinder Level Design much.

I had to make sure that coins that are picked up after a checkpoint get reset in the level. With this, I also had to make sure that the amount of coins the player has also had to go back to what it was when they got the checkpoint.
To fix this issue I communicated to the person that made the checkpoints and the logic for the HUD. It didn't take me too much time to fix this, but it was definitely necessary for the game.

While fixing this I also found out that the special coins don't get saved correctly, I ended up fixing this as well.

With the time left I also made a controller layout to make sure it's clear to the player what the controls for the game are.