Our Last Hope (Is Some Kid) - Blog Post Postmortem

 Postmortem

Now that the last sprint is completed, I feel quite satisfied with what was achieved given the time frame we had. There were a lot of successful things about the prototype and a lot of things that could have become successful if there was more time to do so. It was a huge learning experience to act as a lead, even if it was just in a small team of three, and I’m very happy with having the opportunity to do so. I very much felt like my team worked well together, and that is possibly the most important and successful part of making any game or prototype.

 Although the stress of turning in a working prototype caused everything to feel like it was crashing down, we managed to pull it together and turn in a successful prototype. Our main movement mechanic, grappling, turned out to be flawless. We noticed far too late that there was a rare occurrence where grappling would cause Kevin to freeze, and the only way to fix it was starting over. My teammate was able to find the problem and fix it, making the most important feature work perfectly. 

 We also had an issue with having Kevin take damage while the player was in hand mode, and having the old Kevin despawn if the player died from it. It was essentially a duplication bug, but it was really important to fix because the old Kevin would keep getting hit if it was in the line of a zombie’s movement. This caused the player to die shortly after respawning. I was eventually able to fix it by making a list of all the duplicated Kevin’s, and destroying them every time the player would die and go to a checkpoint.

With all the successes that can be considered for a five sprint prototype, there were some things that could have been grea
tly improved if more time was given. Luckily, none of the bugs are game breaking. There was one bug that existed for a while, and no matter how much we tried to fix it, we simply couldn’t figure out how. There are times when going back to Kevin mode when in hand mode would cause Kevin to disappear, causing the player to remain in hand mode with no Kevin to go back to. Kevin would come back if the player pressed E a couple of times, or if the player restarted from the last checkpoint. We tried to figure out what caused it, but we could never find any true way to make it occur. This made testing whether it's gone or not really difficult. We ended up adding UI that said “Kevin gone? Push E” as a last resort for the final playtest day.

Since a lot of the focus had to be on making sure the movement mechanics worked, some features that were worked on didn’t make it into the final prototype, and secondary features, such as weapons and combat, weren’t as polished. One thing that would have been nice to be able to fix was having only certain weapons be wielded by the hand, instead of all of them. I originally didn’t want the hand to be able to use the bat or ball, but making the distinction would have taken two more cards worth of work. There would have been a lot of factors to take into account, like going into hand mode when a weapon the hand can’t wield is already wielded by Kevin or picking up a weapon as the hand and switching back to Kevin with it. Unfortunately, there was not enough time to prioritize that feature.

 As far as using Agile development goes, I did a decent job of working on one card at a time up until the last sprint. Since we were using GitHub, we would never have more than one person using it at once. We all had our own personal projects that were copies of our shared one that we would work on and then push the packages onto GitHub. This wasn’t normally a problem, but since there were so many things to take into account with every new card completed, everyone took a bit more time on the GitHub when pushing their work to make sure it all worked properly and didn’t break anything. I ended up completing cards, but not being able to push the work immediately after because someone else was on the GitHub project. This caused me to move on to the next card before pushing and fully completing the current one. I was greatly feeling the pressure of time running out. Considering the yet to be assigned work I had to look forward to for other classes, I didn’t want to waste whatever precious time I had at the moment doing nothing. I do really like using Agile development but in the last sprint when it’s crunch time it was very hard to do it properly, and I have a lot to learn about how to skillfully do that.

Most of what I would change if I were to do this project again would be relating to Trello and Agile development. This was a very big learning experience for me, not only with using Trello, but also with leading a group in the development of a prototype. While I have been a group leader in other settings, being the lead of a prototype is vastly different. While I knew what needed to be done for the prototype, prioritizing each thing was much more difficult. I always felt like I had two or three cards off when prioritizing the backlog, even though we never missed a deadline for each playtest and the features we needed to have present. I truly believe that if I had prioritized the backlog better, some of the bugs that we still have or felt rushed to fix would have been dealt with much earlier or wouldn’t have occurred at all. The nature of making a game is hard, and things go wrong especially when learning a new system at the same time. I know that there's a lot more room for me to grow, more than likely more than I have mentioned, but the final product that my team and I completed is one that I can say I’m proud of.