SHROOM & DOOM
my first multidisciplinary game project
Team Size: 6
Role: UI/UX Designer
Duration: 6 monthS
Software:
Unity / c#
FIGMA
CUSTOM ENGINE
SHROOM & DOOM is a 2D top-down game where players defend themselves against waves of enemies, using biomass to grow defensive towers for assistance. It focuses on replayability, challenging players to improve their high scores.
I initially prototyped the core gameplay in Unity, working with the other designer. During development, I created mindmaps, wireframes, and design documentation to guide the design process and ensure asset usability. I also conducted weekly playtesting to observe player behavior and refine the game's design. In the final stages, I transitioned to working in a custom engine, enhancing the UI by modifying JSON files.
This one-minute gameplay video provides a quick look at the game, showing the main menu, tutorial, final wave, and game over screen for those who want a brief overview of the game.
playtest 1.1
my contributions
1 // unity prototypes
2 // playtesting & Iteration
Throughout the development of Shroom & Doom, I conducted weekly playtesting sessions to gather feedback and improve the game. These playtests were essential in refining gameplay mechanics, UI design, and player interaction.
Below are key playtest report summaries that highlight how player feedback shaped the final game.
sept/2022
Early playtesting focused on evaluating basic mechanics like player movement, shooting, and enemy behavior. Players pointed out confusion about the defense point and noted the lack of clear instructions, which led to improvements in tutorials and gameplay clarity.
playtest 1.5
This session highlighted UI feedback, particularly confusion around the spaceship’s health bar. Players suggested clearer visual cues and more engaging enemy interactions, resulting in updates to the UI and enemy designs.
3 // wireframes
playtest 2.4
oct/2022
feb/2023
During this playtest, new features like the tower menu and different enemy types were tested. Playtesters found the tower system confusing and requested more clarity on enemy health, leading to improvements in tower and health visuals.
playtest 2.7
To shape the game’s main menu, settings, and tower selection screens, I created wireframes for the game using Figma.
I iterated on the designs based on player feedback to make the interfaces more intuitive.
apr/2023
In the final stages, playtesters struggled with visual clarity during combat and the game’s difficulty curve. Their feedback led to improvements in player visibility, enemy feedback, and overall difficulty balance.
This video shows early Unity prototypes of the game, highlighting the game's initial development stages.
4 // asf list
The ASF list (Affordance, Signifier, Feedback) was created to track and define what each game element should do, how it signals interaction, and how it responds to the player’s actions. The list also includes details such as collider types, art assets, animations, audio cues, and data fields. We developed this list not only to ensure consistency across the game’s design, but also to help us smoothly transition from Unity to the Custom Engine, keeping track of important features as we made the switch.
The ASF list was organized into A, B, and C buckets. The A bucket contained critical features that were essential to the game, while the B bucket held secondary features that could enhance the experience. Due to time constraints, we ultimately cut C bucket features to maintain focus on what mattered most.
This list helped us prioritize and decide which features to keep or cut, stay organized, and ensure that every element reacted appropriately to player actions during the transition to the custom engine.
Surprises that shaped Design Direction
1 // player as defense point
key learnings
A major surprise came from the shift in player engagement after changing the design from defending a stationary point to making the player the defense point. Early playtests showed that the original concept didn’t resonate with players, but after the switch, engagement and excitement increased significantly.
2 // Simplifying Tower Mechanics
Another surprise was the feedback on towers. We initially planned for more complex tower mechanics, but players found them confusing and less useful. This led us to simplify the tower systems, making the gameplay more accessible and enjoyable, which ultimately shaped the final direction of the game.
obstacles faced
1 // communication gaps
At first, communication across disciplines was challenging, especially since the programmers were focused on building the custom engine. To solve this, we organized into strike teams, where smaller groups worked on specific aspects of the game, like enemies or UI. This approach helped bridge the gap between the designers and the programmers, allowing us to collaborate more effectively and tackle specific features with clearer communication and focus.
2 // managing scope creep
One of the biggest obstacles we faced was managing scope creep, especially early on when our team had a larger vision for the game. As development progressed, new ideas kept expanding the scope, but unforeseen circumstances led to our artists leaving the team, forcing us to refocus. To stay on track, we used ABC buckets to prioritize tasks and I helped create an ASF (Affordance, Signifier, and Feedback) list to ensure essential features were addressed. This process allowed us to balance creativity with practicality and adapt to the reduced team size while delivering a cohesive final product
Reflections
Although Shroom & Doom isn’t the most ambitious project, I’m proud of the time and effort I put into it. This project wasn’t just about creating a game; it was about learning how to communicate effectively within a team and navigating the challenges of game development. It helped me, and the rest of the team, grow both as developers and as collaborators. It wasn’t an easy journey, but the experience holds a special place in my heart because of how much we learned and how it prepared us for future projects in the field.