Zonghao Wu
Gameplay & Level Designer
About the game
Third Person Action Shooter
Parry Ability
Bullet Hell
Azathoth, Mother of the Stars is a third-person action shooter Boss fight that combines the "parry" mechanic in action games with traditional shooter gameplay.
Contributions
Feature Owner
This project was made for a school assignment that we were tasked to design a Boss fight within 3 weeks. The team first discussed what kind of Boss is realistic to make and what kinds of combat mechanics we feel excited about. We all agreed that making a typical Sous-like action game Boss would be out of scope, as that would need a lot of animation assets and fine-tuning to make the boss patterns smooth enough to not look too weird. We all agreed that making a shooter game Boss was more realistic and could still provide compelling combat.
As the feature owner, I took the lead and suggested that we could use the combat loop in Resident Evil Boss fights for reference, which is about learning boss attack patterns to survive, resource and movement management, destroying boss weakpoints to stagger it, etc. Others agreed with this direction, then I tasked the team, including myself, to find some Boss references from other games with similar gameplay to break down and prototype the 3C and core gameplay. During the prototyping phase, we found that the "parry and deflect" ability can be an interesting and creative mechanic to put in our game.
(I broke down some Bosses from Resident Evil and Astro Bots for the team's reference)
After our Boss fight prototypes were taking shape at the end of the first week, I led another meeting within the team, making more specific decisions on how we want to handle players' parry ability, how we want the Boss patterns to be, and what kind of combat style we want to achieve.
(midway meeting summary)
Gameplay & Combat Design
During the first week, I prototyped a TPS character with basic functions within two days in order to better showcase my vision of the game to my teammates. I chose the third-person perspective mainly because I thought it was more visually attractive and could provide more information to the player during combat, which is essential to a Boss fight.
(3C prototype, with basic "dash" and "parry" ability)
(Blueprints of my character. I set up the basic functions for the "parry" mechanic, and my teammates came in later to continue working on it.)
During the prototyping phase, I found that everyone was fond of a parry/deflect system, and I thought adding a bit of timing precision elements of action games to a shooter does sound fun and creative, so I set up a parry input with animation and VFX in my third-person character too. My teammates agreed to do a TPS Boss fight with my third-person character, then we started to conceptualize the Boss mechanics. My teammates built the logic for the parry mechanic to work, and I integrated that logic into my character blueprint with their help.
(with the technical help of my teammates, I implemented a basic parry/deflect system at a quite early stage)
(I added UI and particle effects for successful parries to enhance the visual feedback)
For the Boss, I prototyped and implemented a "stun meter" system for the Boss, which usually goes hand in hand with parry/deflect in a lot of action games. How the stun meter system works is simple: the Boss's stun meter with 0, and player attacks will deal a certain amount of stun damage to the Boss and increase its stun meter. If the Boss's stun meter reaches 100%, it will be stunned for a few seconds and become vulnerable to the player's attack. After the stun phase is over, the Boss's stun meter will be reset to 0. If the Boss isn't attacked within a few seconds, its stun meter will also gradually decrease, forcing the players to continuously attack the Boss. In order to encourage players to use their parry ability now, the parry/deflect projectiles will deal significantly higher stun damage to the Boss than normal attacks, bringing high gains to the high risks.
(The yellow bar is the Boss's stun meter. When the stun meter is maxed out, the Boss will be immobilized and show weakpoints for a few seconds.)
(Blueprint for the stun meter system. I called it Poise system back then)
(Blueprint for Boss vulnerability after being stunned. It will fall from the sky and show three destroyable weakpoints, the destruction of which will deal significant damage to the Boss)
To add more strategic/resource management depth to the game instead of just letting the players spam the shooting button, I also prototyped and implemented a weapon overheating mechanic.
(Weapon overheating mechanic)
One of my teammates developed a modular system for designing Boss behavior where we can customizable different patterns and set different variables. I used that system to implement the Boss's phase 1 behavior.
(Boss Phase 1)
(Boss Phase 1 behavior data table)
Level Design
The level I made for this project mainly took inspiration from the Khan Maykr Boss arena from Doom Eternal.
The team decided to make a more static Boss who would mostly stay at the center of the level and throw projectiles at the player, as we believed a relatively static Boss was easier to make and polish.
The main principle I set for myself when designing this level includes:
1. Leave the middle area large and empty for the Boss.
2. Leave enough space for players to move around, but also provide enough cover.
3. Has two floors and all platforms are interconnected, easy to find jumpad or stairs to traverse through the level and move between vantage points.
4. Spread the pickupable evenly throughout the level to incentivize the player to move around.
UI Design
I implemented most of the UI and VFX, including the Boss HP bar & stun meter, crosshair & hit marker, player vitals, parry UI & VFX, dash UI & VFX, tutorial prompts, etc. Some of the player vitals were further polished by my teammates to strengthen readability.
(Player UI widget)
(Blueprint for player related UI)
Challenges, iterations and learnings
Throughout the 3-week development, I think we had two main blockers:
1. The difficulty of integrating everyone’s different systems and functions together.
2. The different expectations everyone had for the game.
For the first blocker, I think it was partially caused by the different prototyping habits people had and the lack of experience in co-op prototyping, which made it a bit hard for us to fully understand each other’s systems. For me, I was more used to doing solo prototyping or just letting the programmers build the fundamental systems needed for the gameplay, so my blueprints were usually not “scalable” enough to be seamlessly integrated into others’ systems. I knew this was my problem, so I tried my best to support others and explain things when they were trying to understand and integrate my blueprints into their system, or just do the integration work for them if needed.
For the second blocker, it mainly occurred in the third week when I realized people had different ideas on what should be the fun core gameplay loop and how hard our Boss fight should be, which resulted in vastly different opinions on how we should iterate our game. So on Tuesday of week 3, the team had a relatively long meeting together where we went through and settled all the different ideas we had one by one. We exchanged our ideas and managed to understand each other’s concerns, such as some in the team thought the parry window needed to be more lenient to make the game more accessible, and I was worried that if parry became too powerful, people would just button smash without actually thinking (especially since we already have a much longer parry window than most action games), which was not an engaging experience. We all took a step back and landed on solutions that we all thought reasonable.
During playtests, I observed where players get stuck or struggle during the Boss fight and noticed that the stun meter decay rate I initially set was a bit too punishing, and players fell down from the phase one platform a lot and usually spent a lot of time trying to get back, and players barely notice their HP and weapon heat bar at the bottom right corner when they are busy dealing with the Boss attack patterns. So I lowered the stun meter decay rate, made the phase one platform larger, and moved the player's vital UI to the center of the screen.
The first thing I learnt, or confirmed, was that prototypes are always more convincing than merely words for designers to demonstrate their ideas (words are still important, but need to be supported with solid prototypes). When we had the debate about whether we should do an FPS or a TPS in the first week, I chose to fast prototype a relatively polished third-person character with all basic controls and showed it to my teammates. When I explained my vision of the gameplay with the prototype to them, they found it pretty cool and solid, and thus decided to iterate upon my character blueprint. I also did the same for the other mechanics that I thought were good fits for our game, such as instead of using lots of words explaining why I thought a poise/stun meter system could make our Boss fight engaging and fun, I prototyped the whole system immediately to visualize my ideas for the team to comprehend. Early and fast prototyping of gameplay ideas makes the whole development process much more efficient. My prototyping skills also got honed during this course.
The second thing I learnt is that once the team has almost settled down the basic core gameplay, the product owner/ feature owner should align the team on questions like what exactly is our target audience and what would be the pros and cons of the gameplay we intend, otherwise there will be a lot of discrepancy in the later part of the development. When we all agreed to put a parry/deflect system in our Boss fight, I assumed our teammates would understand that our Boss fight would mainly focus on hardcore action game players rather than an accessible game for all players, and it is normal that people with zero action game experience probably won’t enjoy our gameplay, but I should have said that aloud from the start instead of just assuming. At the beginning of the third week, the team started to have vastly different opinions on how we should iterate on the game, and some even thought we should remove the whole parry mechanic because some playtesters couldn’t do it at all. At that moment, I realized that we as a team didn’t have a clear consensus on what our intended gameplay experience is and what our priority target audience should be. As the feature owner, I tried to let my team understand that if people who are clearly not our target audience don’t enjoy our game, it doesn’t mean our core mechanics need to be completely reworked. And if the playtesters haven’t played similar games before, we as the devs probably need to do more onboarding for them about things that we assume people would know, like the i-frames during dodging animation. I noticed that players having experience with similar mechanics in other games all found our parry feature to be fun and satisfying, which convinced others in my team that our game was definitely fun for the right audience. I also agreed with my teammates to make the game more lenient and include more in-game onboarding. Although we did solve everything in the end, it would still be better if the team could have a more aligned vision from the start.