PLAGUE
TEAM PROJECT (6 People)
-The Tale of Nicholas Ratel
Genera: Side Scroller, Stealth, Platform
Game Length: 5~10 mins
Level Runthrough (5 mins)
Group Size: 6
Leah Breyer: 2D Artist
Emma Eastland: Programmer
Zimo Liu (ME): Designer
Alex Groo: Envirement Artist
Bradley Bartlet: Programmer
Kyler Finely: Narrative Designer
MY Role: Gameplay Designer, Level Designer, Game Tester
SOFTWARE: Unity(C#), Photoshop
MY WORK:
+ Design gameplay and features
+ Building the gymnasium and setting matrices
+ Building prototype features in C#
+ Building level whitebox
+ Debug and playtest
+ Iterate Level design based on playtest feedback
+ Communicate between artists and programmers
The Plague is a side-scrolling platform stealth game, a group project demo created in Unity. I worked as the gameplay and level designer on the team, also including writing code prototypes and improving the game based on player feedback. It involves a team-based collaboration throughout the entire pipeline, from concepting and prototyping to testing, adjusting, and decorating a complete game level.
ITERATION
Brain Storm Stage
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 Gymanism 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.
-
Verticle 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.
This made me realize how important it is to playtest for level design. As a level designer, I played the game so many times that it was easy for me, and I could hardly notice the real difficulty for the player unless in a real playtest.
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.
Project Post-Mortem
After the project, I realized how important it is for a team to have a producer in a role to coordinate and push everyone. The introduction of narrative and environmental art into the project was too late for further game testing, which was a pity for us. Our project is primarily managed through self-discipline. As a small team, we thought that would work, which it did during the first couple of weeks. However, it soon gave trouble after people ran out of passion, and it was hard at this stage to become a "bad" person.
As a level designer, the value of playtests was more critical than I expected. After playing the level too many times, the curse of knowledge made it hard for me to evaluate how the level actually feels. In the pipeline, I know how to take a game from draft gameplay to a fully decorated level, and communicate my thoughts to programmers and artists to implement and adjust them for a better experience.