370 Blog Post 4

Nathan Kriger

Blog Post 4

Blazing Marshmallow Development 

Introduction

This sprint was about cleaning up and connecting the dots. The main focus was the camera effect that had been started at the end of sprint 2 and making it function much better and smoother. At first my code was simply reading the players speed (a speed tracker created for this purpose) and using it to determine the camera fov nearly 1 to 1. This caused various problems because the player's speed did not smoothly go up and down. It often jaggedly jumped around from place to place along with some strange half second slowdowns that could occur while grappling and claw shooting. Furthermore, this FOV did not have a stable limit in how wide or narrow the camera could change resulting in a really messy experience all around. To rectify this, I instead used loops. Instead of the speed being copied to FOV. I had the camera read the speed and increase or decrease the fov 1 int value at a time up to a defined limit. This immensely fixed the jittery problems smoothing out the overall experience allowing the player to be clearly communicated when they were increasing in speed.

New design concepts

While talking to the lead this sprint there were a few concepts thrown around that my lead was talking about that seemed really cool and interesting however since they were not in the backlog the lead was worried about adding them in. I took initiative to break down certain design tools the lead had talked about that I knew I could make for them relatively quickly for use at the start of the sprint. To that end I coded a developer prefab tool for the lead so he could set objects to fall at certain points of the level. This was a huge success and was a lot of fun to see how the lead used these ideas in the level. A basic prefab with an empty game object with a box collider that when the player hits it would cause a specified object to be disabled. With falling objects in place came the idea of having objects that could damage the player as well. This was a simple script of allowing the lead to tag objects he wanted to do damage along with setting those damage values.

Connecting the game

Now that we had all these level concepts in place the level that was made out of these ideas was dynamic and engaging to play however it had 1 large issue. If the player took damage before or while on fire it is unlikely and, in some sections, impossible to survive the burn before hitting water. To help with this I recommended the lead we make are existing chocolate collectables and also give HP back on pickup. After he approved the idea to be tested i workshopped some quick code to allow the player to regain hp on choco pickups. After adding in some lines to make sure the player doesn't go past 100 hp while getting pickups I tested the new gameplay idea. This turned out to be a really nice change because our existing system now felt much more valued and rewarding to achieve for the player. I felt desperate to get the chocolates while burning and was always focusing on them as a secondary goal rather than a maybe pick up if i feel like it. Other small things I worked on this sprint were water slowing the player down on hit, a reverse effect of the fire speeding up the player. This had some tuning involved because we didn't want it to slow the player if they were already fairly slow as well, considering if they weren't on fire. To accomplish this creating a few lines that detected player speed and only slowing them down depending on how fast they were going made the slow down limited to not be unfair to the player.

Conclusion

Overall, by the end of this sprint we had a significantly more sensible game to play with all the core systems fully working. With solid gameplay loop with replay ability. I'm loving how our original game is coming together fully encompassing our original idea and so much more.