Sprint 3 saw significantly progress in development of core features for the game. There was additions to the combat of the game as well as the first electronic prototype being built. While there is still much to be completed, I was satisfied with the work I provided to the team this sprint. 

The first phase of work I did for the sprint were the additions to the game’s combat system. The cards I was assigned to make these changes were creating the crowbar and brick special attacks as well as their cooldowns, adding a ranged enemy, allowing some enemies to block attacks and adding enemy spawners. For the crowbar attack I wanted something that could hit all the enemies in a small area so that the player can fight back if they are surrounded. To do this I added a model that will be toggled on/off during attacks and added a rotate function to the player object. When the player is able to use the crowbar they will spin it in a circle hitting every enemy around them. The brick attack was harder to create however. While adding a projectile attack is easy, it wouldn’t make sense for the player to have an endless stream of bricks so I made the decision that players would have to pick up the brick after every use. This way the brick feels more like a special and powerful attack for the player and more fun to use as it could bounce off walls to potentially hit more enemies. The biggest issue with this feature though was working with Unity’s physics system as often the brick would fall through the ground or be thrown in the wrong direction. Most of these errors were easy to fix since the setup for the attack was the problem, but it was still tedious trying to go throw multiple scrips and components to get it to work. The ranged enemy was easy to set up, but I wanted to try something extra with it by giving it a line of sight. This also took sometime, but now if there is a wall between the ranged enemy and player the enemy will not attempt to shoot them.

The other chunk of work I did for the sprint was adding things that were necessary for the prototype. To accomplish this the cards I was assigned were creating win/loss states, adding  a health bar for players, rounding all prices to the nearest 10, putting the prototype together and building it out, and finally making a playtest feedback form for our testers. The win and lose states were not hard to create as it only required one other script to ask if the player had the necessary resources to win and the loss only tracked if the player had health left. While the price rounding works, the code feels somewhat redudnant as it divides prices by 10 then multiplies them again. Since the prices are all integer values they will automatically be rounded to a whole number. When building out the tutorial level with the new shop and house prtefabs, I noticed that the scale of the shops and the streets was not what I envisioned. I did not have the luxury of time so I built the prototype out, but the scale and the camera will need to be changed later in order to give the player a better experience traversing the map. 

While I have not gotten many playtesters yet, the ones that have tested the game had plenty of good feedback. Although some of the issues player’s had with the build were already planned to be fixed later, some other issues warranted design changes. The biggest issue players had was that they could not block against enemy attacks nor could they feasibily fend off large swaths of enemies. To fix this I will add a player block mechanic as well as give their attacks some knockback; additionally, the enemy density in the game will be lowered. 

Overall, the 3rd sprint was quite productive for me. Although the prototype did not meet my expectations I am confident that the next one will be significantly better.