Project Bread
Project Overview
Project Bread is a rogue-like game where players are dropped into an arena, battling enemies to collect artifacts to power up your character. Once you feel sufficiently strong enough, you can challenge the boss of the arena, Lord Rubik! If you are able to defeat Lord Rubik you can pass through the portal and claim victory.
Team Size: 2 Members
Roles: Game Designer, Programmer, Level Designer, 3D Artist and QA
Timeline: 5 Months
Tools Used: Unity, Jira, Maya, Substance Painter, Miro, Google Docs and Excel
Design Process
Project Goals
The goal for this project was to create a vertical slice of a rogue-like game
Rewarded players for constantly moving, bobbing and weaving through enemy projectiles and being light on your feet
Create memorable enemies and boss fights that would challenge the player
Creating the Boss
When creating the boss for Project Bread, I wanted it be the end goal of our game. The boss had to be challenging enough to where you couldn't easily defeat it without progressing through our other mechanics. I also wanted to give the boss certain stages that could be hit throughout the fight. The boss's attack had to influence the player by creating an environment where it rewards the player for constantly moving.
Boss Attack: Range Attack
The first primary attack is a standard ranged attack where the boss fires a volley of 3 projectiles at the player's current location. Once the boss is below 50% HP, this attack is powered up. The projectiles are now faster and the volleys are increased from 3 to 7.
Above 50% Hp
Below 50% Hp
Boss Attack: Range Attack
The boss's secondary attack is a shockwave, where the boss jumps into the air and lands on the ground, creating a shockwave. The boss creates a total of 3 shockwaves that the player is forced to jump over if they want to evade it. When the boss is under 50% HP, this attack is also powered up. In its powered up state, the boss's jumps are accelerated to be faster and now the attack creates a total of 5 shockwaves.
Above 50% Hp
Below 50% Hp
Boss Attack: Rain
When the boss hits 50% HP, it shields itself from damage and begins to summon its rain attack. The boss spawns large projectiles that begin falling down towards the player. Players will have to move out of the way if they want to avoid taking damage. As the rain attack progresses, the number of projectiles exponentially grows.
Designing Player Movement
When I was creating the character movement system, I knew I wanted to create a character controller that felt responsive and fast.​​​​​​​ I knew the base character controller would not be enough to dodge certain attacks, so I decided to implement a dash. The dash was set to a short cooldown and would propel the player in any direction.
Creating the Player's Weapon
When I was designing the player's weapon, I wanted to make sure that it felt weak and underwhelming at the beginning. This made it more impactful when the player starts picking up artifacts and upgrading their weapon. I also created the 3D model and textures that are seen in the final game.
I experimented with a few different ways of making the gun feel impactful to use. The first way I did this was through the gun's recoil. The first iteration utilized an animation based recoil system: when the player would fire their gun, an animation would play that would simulate recoil. However, there were some issues with this animation-based system, as the fire rate would increase, it would desync with the animation. The second system I came up with was a procedural based recoil system. Instead of using animations, I wrote a script that every time the gun was fired it would get pushed back and then return to its original place.
Animation Recoil
Procedural Recoil
Artifact System
The artifact system represented the progression element that players would go through. After an enemy was defeated, they would drop a random artifact, which would then upgrade a specific stat. The stats that artifacts could improve are the following: increased ammo capacity, attack speed, defense, damage, HP, jump height, and movement speed.
Designing the Enemies
Ranged Enemy
When designing the first enemy, I wanted the enemy to utilize a ranged attack to threaten players over distance. The projectiles needed to be fast enough to put the player in danger, but slow enough that they could reasonably dodge the attack. This enemy could detect the player at far distances and use its range attacks to keep the player away from it. I made the damage output on the range enemies to be 40 so players could take a few hits, since multiple range enemies could engage the player at once. ​
Melee Enemy
The melee enemy needed to be a stark contrast from the ranged enemy. Since the ranged enemy could attack from afar, this melee enemy had to be a danger up close. When the melee enemy gets in range of the player, it creates a shockwave that damages the player​​​​​​​. I designed the enemies to influence the way the player should move, if a player got too close to a melee enemy, they could utilize their dash to escape the shockwave.
Designing the Level
The designing process of Project Bread's level was severely cut down due to time constraints. Our team ultimately faced the decision of producing a level or polishing up our other mechanics. We decided it would be better to choose the latter, so I created this simple test arena to allow players to experiment with all of our other mechanics.
Initially, I wanted to create an elaborate boss arena that was raised off the ground and had players activate a device that would summon the boss and lock them in the arena. However, our first play test session was scheduled to be soon and we didn't have enough time to develop this type of arena. We needed a space that could communicate to the player that it was a one-way trip. I realized that there was a very simple and cheap solution to this issue. If we created a pit for the boss to reside in, this would be the perfect signifier for players to understand that once they challenge the boss there is no getting out.
Changes Made From Playtesting
Artifacts
Artifacts were changed to give players more feedback when they would pick them up and allow them to see how many artifacts they picked up in total. Implementing these changes had a positive effect on the artifact system. When conducting the next playtest we found that no players had any confusion about what artifacts did. Artifacts were also increased in power so that players could feel their benefits immediately after picking them up.
Old Artifacts
New Artifacts
Old vs New Artifact Pickup Indicator
UI Changes
A lot of players were confused by the blue bar above the health bar. A lot of players thought it was a mana bar and were wondering how they could cast abilities. The blue bar was in fact an armor bar and the amount of confusion that this caused was surprising and we knew we needed to change it.
Old Vs New Health and Armour UI elements
Boss Changes
In the original playtest, the boss was a scaled up version of the melee enemy. When viewing playtester gameplay it was apparent that the boss was an insufficient challenge for players. For the next playtest, I changed the boss to have multiple stages, making it significantly more powerful.
These boss changes were extremely successful as the boss went from something that players felt indifferent about to the highlight of the experience. This also reinforced our game loop as players went out and collected more artifacts to boost their character up to challenge the boss. We also saw a higher concentration of player deaths within the boss arena, which was significant, since in previous playtests, more deaths were occurring outside of it.
Heat Map Showcasing Artifacts Collected and Player Deaths
We also saw through our data that there was an exploit with the boss's rain attack. In our movement heat map we could see that there were large concentrations of player movement within each corner of the boss arena. When the rain attack occurred players would hide in a corner, which significantly reduced their chances of getting hit by one.
To correct this issue (in addition to having the rain attack spawn randomly around the arena), I implemented a change where every few seconds a rain attack would spawn at the player's location, forcing them to move out of the way. Overall, playtesting was fundamentally beneficial to our design process, as it allowed us to view our design through the lens of players and understand where the cracks in our systems were.