For the third sprint, our team worked fairly well together, and accomplished most of our goals post-haste.. After our second sprint, we realized we needed to plan our entire process around refining our game and making sure it seems like a completed package, rather than a kinesthetics prototype. We assigned cards, but partway through the sprint, we realized our priorities had changed and we needed a few card movements to reflect that. We were much more prepared this time, however, and were working diligently throughout the sprint.
We began the sprint with Usume geared towards working on the item functionality, since we had received feedback that more items would improve the game. However during the second week, after discussions with him and Patrick, we realized that we needed to shift our focus away from additional content towards refinement and necessities. We didn't have a game over screen, for example. Thus, our work began. We spent time improving our previous prototype while planning for future prototypes.
For myself, I assigned myself the task of creating and integrating our end screen, seen above. This includes basic scene management and assigning the correct components to the correct objects in the scene to make sure it runs smoothly. I also implemented the player's score being displayed, an image of which can be seen below. I apologize for how small the text is.
Our workflow was much healthier this sprint, and we were able to work and communicate effectively as a team throughout the sprint. With each discussion, we determined more and more details we wanted to see or accomplish in our next prototype. We were also much better at communicating outside of class, with many times where we came together, had a long discussion, then separated with our individual goals in mind. It was also great to see Usume willing to help Patrick with some of the more tricky Unity bits, either clarifying terminology or helping find methods to accomplish our goals.
I also gave myself the job of figuring out our fail condition, which took me very little time. Initially, we intended for the goal of the game to be more of a "beat the timer" type of game. However, as we moved forward with the development of the game, we realized that our timer design was geared much more closely towards a time-trial type of playstyle. During this sprint, however, we have combined the two. To explain, if the player attempts level 2 (updated version shown below, courtesy of Usume) and makes it to the finish line before 60 seconds have passed, they are taken to the game over screen with their time displayed in the top right hand corner of the screen frozen in yellow.
However, if the player does not reach the goal by one minute, the game automatically switches to the game over screen, and the time is shown in white. The only conversation left to have with my teammates is how the game over screen will work, and if we want a separate screen for if the player wins. We hadn't considered it when creating the trello board, but we may add it in to make the game less confusing to players.
With this prototype, I hope we can display our original vision more accurately to our players. Now that we have both a fail and win condition, our players will have a sense of urgency when completing the level. Now that we have implemented the limits for where the player can spawn blocks and how many blocks they can spawn, we can test our level design more clearly, and add possibly more levels going forward.
Comments
Post a Comment