The game, the good, the bad, the cool, the nice, the lessons learned, the post mortem

 

All I needed was the last thing I wanted

To sit alone in a room and say it all out loud 

 

During this Shoot ‘Em up project we, team Kraken, have accomplished a lot more than I had anticipated in the beginning. I had, for example, no idea how skilled the artists or the programmers were. In the end, I am happy that I ended up with the people I did. Even though our project has had its ups and downs. Especially after hearing how tough other teams had it with some of their own team members.

The game

The result of the project, our game, includes a player avatar with two different shooting mechanics, two enemies, a unique power up, whale boss appearances with some armor tearing off going on and the final boss fight (which is less polished than the other features).

I am very pleased and content with the game as a whole. The group has worked really hard throughout most of the project, and rarely complained about things, or stand-ups. Which is good! I as the manager didn’t have to twist my head around, figuring out how to make everyone’s wishes come true (since we were working in an agile way, every individual’s opinion matters).

 

Main game features

What I have learned

This being the first project, and me being a manager for the first time, made me learn an abundance of new things. I feel like I gained experience points which will help me in the upcoming projects.

Few things I learned:

o   More QA

I didn’t realize how important it is to assign a QA responsible person until it was few weeks left of the project. This goes especially for art assets. No QA resulted in disappointment in a few cases because there were things lacking in those assets and could’ve been avoided if another person would give feedback. (For example – this color doesn’t fit our background, it should be blue. Then the asset’s owner can change it quickly and the problem is solved)

o   More Testing

Our game has a few difficult mechanics that are easy for us developers to understand, but not to the outsiders who play the game for the first time. This was especially apparent during the final playtesting session. It made me realize that we should have made more room for playtesting the game and let others playtest it to use the feedback and improve the gameplay. It was mostly the coders who did all the playtesting. Lesson learned.

During the last playtesting session, considering the feedback, it was visible what the majority of testers had issues with – the power up bugs and the final boss battle. For the final boss battle, you were supposed to shoot the harpoon at the whale’s mouth/tongue, which was not clear at all. We taught them in the beginning to tear armor plates off, and that is what they aimed for during the boss battle. This could’ve been avoided if we’d let someone from outside playtest the boss battle. Regarding the power up – when used during a checkpoint scene – it would bug the entire game – the background would be grey, the obstacles (islands) would be invisible and such things. In my opinion, we should not have aimed for this unique power up – which spawns a storm cloud and makes the enemies loose track of you. It is what it is. 

 

A student enjoying our game

o   EXP gained in management and use of scrum/agile

With no previous experience or Minor lectures in Scrum, I tried my best to use this framework. It wasn’t too complicated to comprehend, especially incorporating the agile mindset by having the Agile manifesto in mind, at all times.

And like mentioned earlier, I was a manager for the first time, which in itself resulted in a lot of new knowledge about group dynamic, leadership etc.

o   For next time – establish structure, rules (group contract, PID) in the beginning

I’ve already begun gathering information and lessons learned that I will use for the upcoming projects. A group contract and a PID (Project initiation document) will be the starting points. Since these documents are created by the whole team, the team members will have the power to decide and come up with rules that everyone will have to follow (more like a guideline than something set in stone – have to continue with agile mindset). I believe this will help with motivation and excitement to start working but will also serve us a helping hand in times of conflict.

Some positive things

The team itself is a positive thing. Most of the members took initiative and worked harder than necessary, which I am proud of, of course.

There were rarely any issues with code etc. to an extent that it had to be consulted with the teachers.

Meetings and stand-ups, I am especially happy about since all of the meetings had a positive effect on the group and the project and is something I will continue doing in the same pace. My team appreciated them a lot, and that I created weekly schedules that included time and place for: sprint reviews and plannings, daily stand-ups, a design meeting or two, in addition some other information related to game design course (like lectures, playtesting session…)

Some negative things

However, no team is perfect. I had issues with one team member in terms of communication throughout the whole project, which made the team irritated and confused. There were tasks done by Kim (pretend name) that were never discussed by the team and that weren’t supposed to be included in the game. The communication was biggest issue. I could rarely reach out to Kim, let alone get a response. In the end, it didn’t feel like Kim was fully a part of the team. I’m not saying that Kim was a total roadblock, Kim did do a lot of work and contributed to the team, nonetheless.

Another negative thing (related to communication once again), was that not everyone was active on our Slack channel. For most of the time it felt like a monolog, or dialog. This made me frustrated as a manager because I never knew who took part of the information posted there and who didn’t.

This was partially solved during a sprint retrospective which we started having after our scrum master, Raoul, introduced us to it. During the retrospective, the manager asks the team three questions: “What should we start doing?” “What should we stop doing?” and “What should we continue doing?”.

When the team was asked “What should we start doing”, a question regarding lack of activity on slack was raised. And a suggestion from the second-year scrum master came that we could incorporate a reaction system. As soon as you see a post, you react with an emote of your will.

This idea was awesome and helped tremendously. It didn’t feel like a monolog/dialog anymore.

 

Let the fire consume and cleanse what’s before me