Zonghao Wu
Gameplay & Level Designer
Puzzle-solving
Music-based abilities
Linear Progression
About the game
Galdr: Forgotten Song is a third-person puzzle-driven game where the protagonist needs to rely on his abilities of controlling vines and monsters to solve puzzles and overcome obstacles.
Contributions
Gameplay & Puzzle Design
I designed most of the puzzles in the game based on the gameplay mechanics the team agreed on, and I turned the puzzles I designed into a coherent level with a reasonable difficulty curve through iterating and polishing based on playtest feedback.
During the first week of brainstorming and ideation, our team decided to go with the rough idea of making a puzzle game with a relatively linear level structure where the protagonist explores a forest with ancient ruins and plays a flute to generate “melodies” (which are essentially special abilities) to interact with the world and solve puzzles. Then we started to discuss what specific gameplay mechanics we wanted to put in the game to make the puzzles fun and challenging.
(my early sketch prototyping of the puzzles)
Since I didn’t have much previous experience with developing puzzle games back then, in my early stage of designing puzzles, I turned to big-title puzzle games like Inside, Cocoon, and Portal for reference and inspiration. I decided to borrow the “pressure plate” mechanic from Portal (which is also commonly seen in other puzzle games) and the “mind-control” mechanic from Inside and iterated on them to make them become the fundamental core mechanics for the puzzles. I chose these two mechanics because I believed they are relatively easy to implement, easy for players to learn, don’t contradict the theme of our game, and have good potential for extendability (for example, we can add more enemies with different abilities for players to “mind-control”). My teammates also came up with more mechanics for the protagonist, such as altering the environment, pushing enemies away, lighting up certain items, etc.
(I listed down what I needed for implementing the puzzles I designed)
After I presented and explained my early sketch prototypes to my team and iterated a bit based on their feedback, we were almost settled on what mechanics we would have in the game. Then I started to design puzzles with a bit more depth and complexity while waiting for the programmers to finish the basic mechanics.
I wrote down a specific list for programmers to understand what exact functionalities I would need for implementing puzzles, and the product owner turned it into tasks on Jira. I tried to be specific to avoid ambiguities but also not too specific on how to implement them so programmers could decide the best solutions themselves with their expertise.
(sketch prototyping of more advanced puzzles)
(early puzzle prototype in Unity)
Level Design
The level I made for this project is a linear level made of 4 puzzles. The player needs to solve the puzzle at their current section to proceed to the next section. The first 2 puzzles are smaller onboarding puzzles that teach players the pressure plate mechanic and how to use their special ability of controlling vines and monsters effectively, and the last 2 puzzles are large puzzles that put players' knowledge of the game to the test, and require a deep understanding of every mechanic in the game to solve.
(Top-down overview of the level)
When I was done with sketch prototyping of the puzzles and the programmers had already worked out some of the mechanics, I started to do level blockout in Unity and implement the puzzle I designed.
I was following two main principles when making the puzzles:
1. The end goal of the puzzle should be clearly communicated to players from the start.
2. When the player has already figured out how to solve the puzzle, there shouldn't be too much busy work required for the player to implement the solution.
(Different colors were used to color-code different mechanics in the level blockout)
(midway puzzle level prototype, including the draft versions of Puzzle 2, 3, and 4)
(Puzzle 1 breakdown. Players learn the pressure plate mechanic and the rule that monsters can hold down the pressure plate)
(Puzzle 2 breakdown. Players learn the rule that a "Thornshell" can grab and throw another Thornshell to solve puzzles)
(Puzzle 3 breakdown. Players need to combine and utilize what they learn from the Puzzle 1 and 2 to solve it.)
(Puzzle 4 top-down breakdown. Final test for the player and require them to use everything they learn in the game)
After I had my level blockout ready and playtested, I started to discuss with the artists to see what kind of environment vibe we wanted for the level and what kinds of art assets we needed. Based on the narrative the team previously agreed on, the player is exploring a dark forest crawling with corrupted creatures and the theme of the game is a bit fantasy-wise, so we decided to have a dark, gloomy environment with glowing vines and vapors for my level. The artists and I worked together to implement the environmental art.
(midway art implementtation)
(full art implementation)
(art asset briefs)
Challenges, iterations and learnings
During the early ideation and prototyping phase, the main problem I encountered was the discrepancies I had with other designers on how we wanted to implement the gameplay mechanics, such as how we wanted the player’s “mind control” ability to work in the game. Although we all agreed that puzzle-solving would be the main focus of the gameplay, people have different visions and opinions on what makes a good puzzle game. My solution to this was usually to take a step back, explain why I want to do this, listen to others’ reasons why they are against this, and discuss how we can make it better together. For example, for the “mind control” mechanic, we managed to come up with a better idea to do it by both taking a step back and combining the best parts of our ideas together.
Another problem I encountered during the prototyping stage was the communication efficiency with some of the programmers. We had young, talented, and capable programmers on the team, but sometimes they got carried away with their own visions of the project, which distracted them from prioritizing the most essential work. For example, when we were approaching the end of the second week and close to the first playtest, the puzzles I made were still missing some core functionalities, which were tasks that I assigned to the programmers several days ago, while the programmers were still experimenting with other new ideas. My solution to this was to talk with the product owner, explain the urgency and importance of those functionalities, and let him talk with the programmers again to make sure they prioritize the important work first. After several playtests, the problems I encountered were mainly about the level itself, including soft-locking in some parts of the level, insufficient onboarding, and the lack of guidance.
In the alpha playtest, our game is still at a very unpolished stage, and we haven’t reached a clear decision on a lot of details of the gameplay mechanics, all of which made our first playtest pretty chaotic. We had a lot of redundant, obscure mechanics back then, which hindered the judge from getting to the puzzles I designed at all. After this playtest, the team finally made up our minds to streamline the game and only focus on the essential mechanics. For instance, we cut the player’s special abilities from 4 to 2: altering environments and controlling enemies. In the beta playtest, when our game was much more polished, the main problems I found with my level and puzzles were: soft-locking in some parts of the level, insufficient onboarding, and the lack of guidance. We collected playtest feedback by both asking players questions and observing them during the game.
The thing in the red circle in the image above is called a “devourer”. Players can mind control the devouer and use it to carry them to reach areas they can’t reach. But during the playtest, it was quite often that players placed the devourer too far away or trapped themselves somewhere, making them unable to control the devourer again and resulting in soft-locking themselves. My solution is to confine the moving distance of the devourer to a certain area so that the devourer is always within the player’s control range, which also mitigates players’ overthinking because the devourer has fewer places to go, making it easier for players to see the answer to the puzzle. I decided to visualize the devourer moving area with mycelium texture to fit into the environment.
The feedback from the external playtest also helped me to justify the difficulty curve in my level. In the earlier internal playtest, some designers in the team thought the difficulty curve in my level was too steep, especially the last puzzle, while I believed it wasn’t as basically every mechanic required for solving puzzles has been onboarded to players throughout the level before they reached the last puzzle, and puzzle-solving will be less fun if there is no meaningful challenges for players to overcome. We can’t persuade each other and decided to see how it goes with other players. In the external playtest later, I noticed that 80% of the players managed to solve all the puzzles by themselves without getting stuck for too long, and many claimed that the difficulty curve is smooth, the puzzle is a bit challenging but not too hard. So the rest of the team all agreed with not over-simplifying the puzzles.
As a level designer, the first thing I learned from this project was that prototyping with blockouts in the engine is much more reliable than sketch and paper prototyping, especially for a 3D puzzle game. Almost 80% of the puzzles I designed on paper didn’t make it into the final build, as I found many of them weren’t that fun or didn’t work as I expected in the editor. Of course, it doesn’t mean sketch and paper prototyping are useless, as they are efficient to make and easy to present, but I believe I should compress the time of paper prototyping and start blockout prototyping in the engine earlier in the project. Another thing I learned about puzzle design was to expect the unexpected, as players won’t always see things the way you see. And the best way to find all unexpected things in the level is to have more and earlier playtests. Another important guideline I learned was that when designing puzzles, players should know “what to do”, but not “how to do it”, which means the player should know the goal of the puzzle from the start and let them focus on how to get that goal, instead of letting players wondering what is the goal of the puzzle themselves. I am happy with the level and puzzles I designed, and I gained valuable experience with puzzle design in general from this project, including how to explain and present my design ideas to others in a more well-structured and well-founded way.