PLAGUE
Apr 2025-TEAM PROJECT (6 People)
-The Tale of Nicholas Ratel
Genre: Side-Scrolling Stealth Platformer
Game Length: 5~10 mins
The video may take a moment to load. Please wait.
视频可能需要片刻加载，请稍候。
Project Highlight (00:44)
The video may take a moment to load. Please wait.
视频可能需要片刻加载，请稍候。
Level Runthrough (5 mins)
TEAM MEMBER
Leah Breyer: 2D Artist
Emma Eastland: Programmer
Zimo Liu (ME): Designer
Alex Groo: Environment Artist
Bradley Bartlet: Programmer
Kyler Finely: Narrative Designer
MY Role: Gameplay Designer/Level Designer
SOFTWARE: Unity(C#), Photoshop
MY WORK:
+ Design gameplay and features
+ Building the gymnasium and setting metrics
+ Building prototype features in C#
+ Building level whitebox
+ Debug and playtest
+ Iterate Level design based on playtest feedback
+ Communicate between artists and programmers
Plague is a side-scrolling stealth platformer developed in Unity by a six-person team. I worked as the gameplay and level designer, while also contributing C# gameplay prototypes and iterating on the level based on playtest feedback. I was involved throughout the pipeline, from early concepting and prototyping to blockout, testing, iteration, and final environment implementation.
DESIGN & ITERATION
Brainstorming & Core Concept
In the brainstorming stage, each of our teammates posted a game genre. The winning tag for the gameplay is a combination of stealth and platform. The game's theme was initially Raccoon, but later changed to a medieval-era story about rats and the plague.
At that spot, I conceived the main feature of our game: unlike regular platform games, it had two layers that the player could shift between for pathing and hiding from enemies. The programmer decided to use a movement system similar to that of Celeste. He loves the game a lot, especially the dash ability.
Early Gameplay Design
-
Layering Feature Draft
The layering feature was planned for the following usages
1. Connect two parts of the level as gates or valves
2. Use as checkpoints between level segments
3. Use layers to distinguish the area of reward, shelter, and danger
4. Placed narrative elements like NPCs in layers as a reward or save area
In reality, some of these functions changed, like there were no NPCs in the final game.
-
Enemy Design Draft
Since this is a stealth game with a fast pace, I designed the mechanism so that the player must use the dash to sneak past enemies who are facing away from the player. There will be a safe area behind enemies where the player can dash through them, and the enemies will turn around when the player dashes through them to allow the player to pass.
Players should avoid enemy detection ranges. In placement, there are stationary and moving enemies that require the player to get through them at the right time.
Level Design
This project was planned to contain four levels: the gymnasium and three actual levels. The final game contains only a gymnasium with two actual levels. The adjustment of the first level in the playtest and environment art took longer than we expected. Still, the second level is in a whitebox stage because our environmental and narrative artists didn't have enough time left for it. The third level was still in the planning stage.
White Box of Gymnasium Level
The gym was built early to test the movement system, character scale, camera, controls, and basic enemy system.
White Box of Level 1
The First level serves as a tutorial, teaching basic movements, dash jumps, climbing, the layer system, and enemy mechanics. The narrative of the player from entering a town to descending into the castle.
White Box Of Level2
The second level takes place in the castle's dungeon sewer, and the player navigates it by boat. The sewer water level will kill the player. The player must open valves along the way to reach the next area. There are several rooms in the dungeon that the player should enter, stealthily kill the enemies, and find the switch to the valves. In this area, there are more moving platforms and new trap mechanisms that are hazardous to both the player and the enemies.
Draft Of Level3
The third level is still in the design phase. The idea was that the back layer contains a giant wheel that is constantly turning. The player needs to find the switch for the gates at the front layers to open the trigger and doors, thereby opening the segregation between the wheels. There are three layers inside the wheel. The goal of the level is to reach the center circle of the wheel, which will take you to the room and connect you to the exit path.
Between the front and back layers, some subpaths connect to rewards or give out information on other rooms before the player can go in there.
Playtests & Iteration
Our game underwent two playtests: the prototype playtest and the vertical slice playtest. We created questionnaires and conducted observations as players progressed through the levels, and adjusted the game content based on player feedback and observations.
-
Prototype version
-
Prototype feedbacks
Prototype Playthrough 1mins 30s
The first playtest confirms that my idea of the gameplay is enjoyable, and players appreciate the concept of shifting layers and dash jumping. I added more collectible rewards at the enemies' locations and added question marks on the enemies' heads to better illustrate the mechanism of dashing through them.
I also performed some coding work in this playtest, including debugging the enemies and creating blockout assets with basic functions such as collectables, checkpoints, layer shifting, and more.
-
Vertical Slice version
Alpha Playthrough 1mins 43s
In this version, the art team began implementing the game, and I focused on prototyping level 2, from implementing basic features to blocking out the design. The original playtest feedback on this version is no longer available due to expiration. I recall that many players complained that the game was too difficult. After the sprite asset replaced the original sprite, the collision box of the player became larger, making it harder to avoid danger and jump through gaps.
Repeated self-testing created a clear curse of knowledge: I already knew every jump distance, enemy timing, and route, which made it difficult to judge the experience from a new player’s perspective. External playtesting helped recalibrate my understanding of the level’s actual difficulty.
I adjusted many parts of the level to reduce the difficulty. I removed many of those pixel-perfect areas that players dislike, and adjusted the enemy return frequency. I added one extra area for the player to learn how to do a desh jump.
-
Observation Playtest
There was one small playtest before the final version, which we conducted as an observational study only. After implementing the art assets, several areas in the level became unclear for the player to distinguish, so I created slides for those areas to facilitate improvements.
RETROSPECTIVE
PLAYTESTING IS PART OF LEVEL DESIGN
Repeated self-testing creates a strong curse of knowledge. External players revealed difficulty, readability, and teaching problems that were hard to spot in my own playthroughs.
LEVEL METRICS AFFORDANCE CHANGE THROUGH PRODUCTION
Character sprites, collision, and environment art can all change how a space plays. Level design needs continuous validation from whitebox to final implementation to maintain level affordance.
INTEGRATE DISCIPLINES EARLIER
Narrative and environment art were integrated relatively late, reducing the time available for final testing. In future team projects, I would establish earlier cross-discipline checkpoints and protect dedicated time for final playtesting and iteration.