370 Postmortem (Sprint 5)

This week I worked on putting the finishing touches on our game. This included finalizing the torches, the UI, obstacles, and generally polishing the game.

Trello Board

Finalizing the torches was probably the trickiest part I had to tackle for this assignment. For this, I looked into various timers and timing methods to use for the torches. Ultimately, I landed on the WaitForSeconds coroutine which was a bit tricky to implement but I was able to figure it out eventually. I made the torch timer a public integer so that it could be edited as we playtested our prototype and figured out the timing of the torches.

TorchPickup code

For the obstacles, I specifically focused on the foliage. The foliage was a fairly simple piece of code - a collider, tagged with "foliage", would decrease the players speed significantly whenever the player touches it. Jumping to escape this boundary reverted the speed back to normal. The method I used may not have been the most efficient but it worked for our needs. In the future, had I given myself more time, I would have utilized a more efficient and effective method for this mechanic. I would have loved to consult the programmer for Group 1's game, Sea and Snow, since their core mechanic revolves around a very similar premise.

For the UI, I simply added a Lives counter to be displayed, and a game over screen for when the lives hit zero. Additionally, I had to fix the code that linked the health bar and lives counter. I worked with Matthew to figure out his code, then began to work the two pieces together. It was a fairly simple process, but working out the bugs that came with it was probably the most complex part. The idea is that when the player's HP hits 0, they lose a life and they must respawn at the last checkpoint. It went back and forth between working with the health bar, to working with the checkpoint, to working with the lives, but never all at once. Eventually, after a late night call, I figured out the solution after explaining my problem out loud to another classmate who was more experienced and realizing my error. In the end it was a fairly simple fix (resetting the health bar when you respawn) and the basis for our game was 100% complete.

During our last-minute scramble to get everything completely finished for the final, we just went over all of our code to make sure that any functioning code still functioned, and anything that was incomplete was commented out or removed from our game entirely. Our sprites had already been added on at this point, however we just did a few last minute checks to make sure the sizing was right and that the sprites all still worked with their new colliders and such.

Looking back on this project, I think we did a pretty good job with our game. We got all of our basic mechanics completed for the final prototype, we had some art done, and it functioned well. Our group was in constant good communication, and we each worked on our equal share of the work, assisting each other in the tasks (especially the programming tasks), and critiquing and helping each other when we got stuck. 

I think our biggest weakness was time management. We definitely put things off and it affected our prototype, as it always ended up coming up short of where we wanted it to be. For example, for this last sprint, I think we could have fit in the powerup that I wanted to implement since the beginning had we started a little earlier. As we went on, however, we began using the point system which was very helpful in managing our expectations and getting things done on time.

Final Game - Level 1

Moving forward, I think spreading out the work more evenly earlier on would have been massively beneficial for us. Most of the heavy lifting landed on the programmer, and I (the modeler) and Amir (the level designer) got off with some easy work the first couple of sprints. This resulted in lots of tasks being delegated to Matthew (our programmer), so we decided to start taking on some of the programming work, and also share some of the tasks with him. Ultimately, this is definitely the method to use in the future for new group projects and working in a group in general.