21 Apr 2020
21 Apr 2020
After investigating the codebase I found three scripts which implement enemies causing damage to the player: DamageOnCollision, DamageOnTrigger, and Health, all of which were written by different people. I created a test scene with all the different enemies and projectiles. It was unclear if the player was taking damage at this point. All of the scripts seemed to be in place. I made a quick health counter UI to see if the player was taking damage, and they were not.
The player is hit by each enemy but does not take damage.
It took me longer than I’d like to admit to figure out the reason it wasn’t working: the DamageOnCollision component has a LayerMask property that has to be set to check collisions with the Player layer. I just assumed that it would have been already set properly. Once I changed that, the player was now taking damage. However, they took damage from the enemy’s aggro trigger.
The player takes a point of damage when they enter an enemy's aggro radius (visualized in yellow).
This has been a thorn in my side ever since I worked on the aggro component, and it keeps coming back to haunt me. From previous encounters, I knew the solution is to reorganize the prefabs. If I put the enemy’s collider and the DamageOnCollision onto a new childed GameObject, it would work properly. Halfway through doing this I realized that this shouldn’t be happening in the first place. Like I said earlier, there are two damage components. DamageOnCollision handles damage via OnCollisionEnter while DamageOnTrigger handles damage via OnTriggerEnter. The aggro range is a trigger, so why was it causing damage in the component that checks for collider collisions? The author of the DamageOnCollision script had mistakenly implemented the function OnTriggerEnter. I removed this and now the aggro no longer caused problems, and I didn’t have to reorganize all the enemy prefabs.
Also, in the video you can see that the player takes continuous damage when they’re in contact with the enemy. I added i-frames to the player so they would have some invincibility. The rest of the time was spent tuning damage values on enemies/projectiles and the number of i-frames on enemies/the player.
Io desperately tries to jump inside the test scene but can't get off the ground.
Finally, before I made a pull request I pulled from development to see if there would be merge conflicts. It ended up completely destroying my test scene, and now Io couldn’t jump and her animation was wonky. I tried for a while to fix it, but couldn’t figure it out. The problem was that my test scene had been carried over since the first week of the project. Every time I needed a new test scene I just copied the previous one. This meant it didn’t have every object/setting that the actual CrystalCaves level has. I decided to just copy over the Crystal Caves level and modify that to act as my new test level. This took a while since I had to redo some work and also delete a ton of tiles from the actual level.
Enemy damage now works properly in the updated test scene.
The player takes damage when they enter the Acrobat's aggro radius.
This issue is related to the previous ones. The Acrobat actually uses DamageOnTrigger so my previous solution couldn’t work here. I had to reorganize the prefab. I had to coordinate with another pod member who was working on the Acrobat’s behavior since I didn’t want to double up on work or create merge conflicts. I ended up moving the damage-box onto a child of the enemy along with the DamageOnTrigger script. This way, the aggro trigger wouldn’t “combine” with the enemy’s hitbox. The solution was fairly straightforward but testing it was time-consuming.
It was a very urgent update since the Acrobat damage pretty much prevented player progress and made playtesting pointless and somewhat impossible. Because of this, I wanted to make sure that my edits to the prefab structure didn’t break anything and tested the level extensively. The Acrobats are pretty far into the first level and playing in the Unity editor on my laptop is SUPER sluggish. Every time I made it to the Acrobat section and had to make a change, it took me forever to get back there. I thought of adding Acrobats to the beginning of the stage just to test it, but then how would I know they worked in their actual location? Also, I tried having the player start closer to the Acrobat section but moving the player and the camera just doesn’t work. Even leads in the Discord said the only way was to move the player and look in the scene view, because the game camera just can’t update when you move the player. Moving the game camera also doesn’t work, it just snaps back. Anyway, that was frustrating but I did get it working eventually. In the future, I think a way to have the player start at different points in the level should be a priority for easier debugging/testing.
Both of these tasks were extremely important to the game and were time-sensitive, moreso than anything else I’ve worked on with this project. That said, the final weeks were less stressful/”crunchy” than I was expecting. I suppose a lot of that is because we reduced the scope so much, but also the last weeks were reserved for minor tweaks, polish, and bugfixing. In my 494 project, the last few weeks were incredibly stressful and I put in an unhealthy amount of hours into it to get it finished. On Io, I actually had trouble meeting my time quota this sprint.