Postmortem – blog 6

You won!

We made it! During a 10-weeks course, group Kraken built a shoot ‘em up game that works! The game has a tutorial scene, two different scenes of gameplay and a final scene when the player meets the boss in a final epic fight. We have a power up that finally works (!) and two different enemies with attacks and movement patterns that makes them very different from each other. Our boss enemy has three different attacks. I am proud of us!

Group Kraken started this project as a quite immature group, as could be expected. At the same time, we felt focused and exited to start working. There were some delays in the beginning since we were told we could not start working before we had a kick of meeting together with our Scrum Master, but as soon as that was done we were ready to go.

My first goal was to get the Scrum meetings going as soon as possible, to help us not waste time on not knowing what to do and when to do things. It took about a week and some collaboration with the project manager and after that the meetings in our group has run smoothly speaking about scheduling. However, during the first weeks more than one group member did not attend to all meetings and did not tell the group why they were absent or when they would be back. That raised some irritation in the group, but at the same time I am proud of how my group handled this. The ones in the group that were present did not waste too much energy because of this or lose their spirit but instead increased their work speed from week to week and continued doing so until the end of the project. Since the opposite also could have occurred, that the feeling in the group could have been “why should I work when he/she doesn´t”, this was a great way of handling the situation.

Once the meetings were on the role and managed by the project manager, my next concern was to take lead of the design process as the lead designer of the team. I decided right away that I was going to do this by using user stories, as I have spoken about in previous blogs, and I am very happy that I did. Already for the first sprint planning meeting I presented the first user story to the group and overall that went well. What I did not realize at that time, but have learned during this project, is that we as a group did not have the same picture of how the game or features of the game should end up. This led to misunderstandings and some energy waste in the first couple of weeks. I spend a lot of time thinking about this and how I could improve my communication skills when talking about the design of the game to the team. The solution I came up with was:

  •  Prepare both sprint planning meetings and design meetings even more. For example, at the end of every week I rewrote the user stories I had from the beginning of the project, so that it would fit the team and the game for the sprint planning the upcoming Monday)
  • Draw sketches of the features on the whiteboard when a suggestion came up, so everybody could see and react at once. When I started to do that, group members became much more active during the meetings and said “What, no, that is not how I want it to be!” and asked, “Can I come up and draw how I see it?”. Of course you can! And when we started to do that, we really improved our communication in the group.
  • Talk and ask and explain repeatedly when talking about the features in the game – what does it do, how does it look, what is the behaviours of the feature? Every time I felt that we had come to a decision, I summarized the details out loud one last time, asking the team “Do we now see this in the same way?”. This helped the work in the sprint run much smoother.

Did I learn something from this experience, during this game development project? I did indeed! As a game designer, I now know from experience what I had read about in the literature, that communicating a vision to a team is a difficult task. I have tested different ways of doing this and I have improved my skills in the subject. I know that I should start earlier with learning how the team wants and needs me to communicate and that will save us time and energy in whatever group I will be a part of in the future. 

If I could wish for one thing to be different before the course started, it would be that all students should have been prepared better for working in Scrum. That would have made a huge difference at the start of this project, especially since we did not receive a lot of information as the course started either. In my group, the solution to this became that I as designer (who had been taught about this in the previous course) as fast as we possible could helped the project manager of the group understand the basics of this agile framework and after that we have kept on improving.

The biggest weakness of this team I would say was quality assurance and the definition of “done”. Yes, we talked about it in the beginning of the project and tried to set our standards. Still, week after week, when it was time to implement and test features in Unity, assets did not work and had to be adjusted or redone. We improved some during the project but the problem with this was still present in the end when we built the final level – things did not work as they should and we spent a lot of time fixing that on our last workday together. Because of that, we did not have enough time to build the final level. We managed to put things together and the game running, but there was not enough time left for balancing and tuning. This is an important lesson that I will take with me into the next project. Regarding that final level, already before the final playtesting session I was aware that it is too difficult for an audience outside our own class, and that was confirmed by the playtesters. With a better planning for the end of the project, this could have been avoided. Still, as I know why it happened and what we could have done to fix it, I feel that the lesson is learned.

The core strengths of this team were the focus of getting things done no matter of group members were missing or other obstacles that came in our way. We also had a good way of responding to the feedback we recieved from the playtesting sessions, as we took the answers seriously and every time we tried to make changes that would improve the experience for the players. The final playtest session we also recieved valuable infromation, but since we will no work more on this game I will take that feedback with me into my total learning experience from this project. When I look back, I cannot see that we had even one break down as a group during all this time. That is also something to take with me. 

The final question I am asking myself is – “Am I satisfied with my learning outcome from this project?”. Yes, I am. I have learned tons of things that I will take with me into my next project – things I will do sooner than I did this time, things I can do better than I did in this project and things I will not do again because I now know better ways of doing things. I feel super exited to get into the next project in the education and keep evolving as a game designer.

  

you ded

 

No more restart for “Atherial”, it is time to hit exit and move on. Thank your for reading!

 

About Anna Malkan Nelson

2017 Game Design