Postmortem
|
At the start of this project, our group had some issues when it came to deciding on how we wanted the game to look and whether or not we wanted to stick to the original concept document. After some short discussions, we decided that we would try and stick to the original concept as much as possible. Since some many other groups had also chosen Umibozu and we figured that they would be moving away from the original concept in order to have their version stand out, we thought it would be a good idea to do the opposite of that. Our first playtesting session helped us realized that our game was favoring the player too much. In order to remedy this problem, we added more spawn points and gave the enemies different movement patterns. We also did not get to implement the fog for the first playtesting session. I was absent from the second playtesting session, but from what I was told we did not have the greatest time. The instructors were a bit bothered by the fact that players could not die in the game and were required to play the entire level. Last week we had our final playtesting session. Overall I think that it went well, our group got some good feedback. Since this was our first time developing a game we were not entirely sure how to go about it but after the Alpha presentation we were able to reevaluate our work methods and focus on what was important/needed for the project. At the final playtesting session our group was able to showcase our complete game. We also managed to get some very helpful feedback from this session too. Before the playtesting, our group got together and discussed whether we thought the game was to easy. It turns out that our game was too hard and not that enjoyable. The instructors informed us this was a common mistake that all first-year groups make. In the end, we managed to make a game that not all of us may have been happy with but it was a game that managed to meet all of the requirements and passed! I believe that the final version of our game captured the aesthetic goal, which was mysterious game. With our black and white art style and suspenseful music, the feeling of mystery was prevalent throughout the game. Players were able to feel the tension and the suspense growing with every hit they took thanks to the avatar showing damage until it eventually disappeared. The death of the player would bring up the end screen where the player would have the option to try again or go back to the main menu. However, should the player make it to the end of the level, where they rescue a person in distress, they would then encounter the mythical Umibozu. A shadowy sea monster that will attack the player as they make their way back to the port from which they started. Our games version of Umibozu took the form of a shadowy octopus that would chase the player from beneath the waves stabbing at the player with dark tentacles. While our game may have passed not all of us in the group was happy with the way it turned out. Some were unhappy with the creative direction of the game, while others were dissatisfied with the level layout. Our coding was good, our art style looked good and the music was good. Had we had more time to work on this project maybe we could have worked through our group issues and made the game that we all wanted. I personally like the game and I look forward to showing it to my family. Overall I have learned many things from this course, academic and personal. During the course of this project, I realized that I did not have a lot to contribute to the making of the game. I do not know how to code or draw, and all I really did was try and schedule meetings and work on the sprints. My lack of contribution to this project has made me more determined to learn how to code and possibly learn how to draw, this way I will be of more help to future teams. This project also helped me see that if I want to be a good manager I am going to need to be more direct and determined. I see now that I was too laid back when it came to managing the team. Examples of this include members not showing up for meetings and me not doing much to track them down, besides sending them a message on slack. I should have done more to make sure that the team stuck more to the group contract. Some of these problems could have been avoided if I had provided more structure and been less afraid to confront team members about issues in the group. Overall I have learned that I need to be more direct when it comes to managing the group. I also need to learn more about how to code and draw in my free time that way I can be more involved in the production of the game. Some of the academic lessons I learned from this project are that I do not really understand how to actually manage a group. I feel that the management courses did not well prepare me for this role and were taught in the wrong order. Since we were expected to use scrum for managing the groups, it would have been helpful to learn that in the first project and management course instead of the traditional management styles that we were not going to use. Having a better understanding of Scrum and what the responsibilities of a scrum master are would have been helpful. In the end, I asked for help from some of the second year project managers and got a better understanding of what my role is. At the end of this project, I have learned that I need to reach out for help more when I am unclear of what I should be doing and when problems arise. Instead of just sitting back and hoping for the problems to blow over or be solved on their own. Now that I have a better understanding of what went well and what with wrong during this project and where these problems came from, I hope that I will be able to take these lessons and be a better manager in the next group. M. Causey  |