2/5 - 2/19
Time Summary: 13.5 hours
Studio Meetings: 4.5 hours
Debugging: 4 hours
Crushing Trap: 2.5 hours
Scene Transition: 1 hour
Cutscene Manager: 1.5 hours
Debugging
Encounter System Soft Block
For developers, week 4 was spent debugging. First, I handled a soft block bug that was occuring with my encounter system. Players could shoot, or at this time use their giant sword (another bug I fixed later), to kill enemies before they triggered the encounter, and thus causing the player to get stuck in the encounter barriers. I actually had already checked whether all the enemies were still alive, but had forgot to remove them from the list of active enemies like I do once the encounter begins, and so fixing this bug took less than 10 minutes of coding, and 10 minutes of testing.
Dashing Soft Block
The next bug I tackled was much trickier. We had a bug where the player could lodge themselves off the playable/walkable surface by dashing, and get themselves stuck. I had not worked on the dashing system and fall manager in previous weeks, so about an two hours of my time was spent diagnosing why the problem was happening in the first place. After understandign the code, I assumed the bug had to do with our fall manager's last ground position variable being set wrong, or the ground character controller attached to the player not knowing when it was or was not on the ground. By using breakpoints and my debugger, I found that it was both, especially since when the player swong their giant sword the player's ground controller would think it left the ground due to the sword overlapping with the player's box collider, and issue arose here. I was able to significantly minimize the issue by fixing the player's sword, which I explain what was the issue there below, and by changing the Update statement that calculated where the player's last ground position was, to a FixedUpdate which makes it run more often.
Giant Sword
Probably one of the first bugs that everyone noticed while play testing was that the sword was huge. At first I assumed an artist may have just dragged and dropped the sword sprite into the sword prefab without adjusting the sprites size, but interestingly enough, the swords box collider matched the size of the huge sword sprite. I was quick to realize that the player prefab in our tutorial was scaled down 10x the size of the actual prefab, and preassumingly the normal sized player prefab was what the developer working on weapons had tested the sword with in another scene. Although more issues may arise from the player in our main scenes being scaled down to a tenth of the size it is intended to be, I simply implemented precautionary measures that spawns the sword and other weapons in while considering it's lossyscale. I also let other developers know where the issue had arose so as they continue to write more code, they will make sure the objects they spawn in are relative to the size of the player when they need to be.
Dashing Without Stamina Bug
Stamina was already implemented and so fixing this bug was pretty quick. I just needed to check that the player had enough stamina to perform a dash or chain dash before allowing them to do so. The logic was simple and the bug was fixed with 2 if statements.
Crushing Trap
The level designers this week had asked the other level developer and I to implemented a few traps into the game, namingly an arrow trap, fire trap, and a crushing trap. I was assigned to complete the crushing trap while the other developer took on the others. First I set up a Basic Trap base class, so that the Trap Trigger I started to implement could be used not only to activate the crushing trap I was implementing, but also the traps my fellow developer was going to create. Then, as a derived class I created the Crushing trap. The logic behind the crushing trap is quite simple, but at first, figuring out the correct ray casting in order to avoid touching the player scripts was a little tricky. What I went with was, once the trap is activated, the trap's crushing animation begins. When the player first collides with the trap, the crushing trap script determines, where is the player and which side of the player should we check is going to make contact with something, and thus be crushed. Then, as long as the player is still colliding with the trap, I used raycasting to check is the player's box collider touching something other than this, the crushing trap, on the other side of where the crushing trap is touching it. If so, the player has been crushed, and let's access its health script and deal the maximum amount of damage, thus killing the player.
Cutscenes and Scene Transitions
Creating the cutscene and scene transitions was probably my biggest challenge of the week. The scene transitions was fairly simple, as it is just a trigger that queues the scene manager I created to start a coroutine to fade in a transition panel, and then once the fade in is complete, load a new scene which, if a scene manager has been set up, fades a transition screen out. The tricky part was mainly the cutscenes. Luckily, Unity has playable directors, which by using animations set to players, switching between vcams, etc. can create some pretty awesome cutscenes. The main problem I ran into was that once the cutscene started and then ended, the player still could not move. Additionally, sometimes when the player would walk through a cutscene trigger, they would be shifted over to the exact position the animation's transform started at. To fix both of these, I changed the player's animator culling mode to Cull Update Transforms. Here's an example of how these cutscenes can look with the scene transitions.