Reacting to Feedback

A continuation on my previous blog post.

First of all, we had issues with Unity Collaboration once again (whoever saw my Alpha-presentation knows what I am on about, also mentioned in my blog earlier). The project updated poorly and caused the game to crash on one of the computers. Of course, this brought negative feedback that we later on filtered out.

To conquer this issue once and for all I decided that the weekend before any presentation showcasing the game our programmer will create the final build. This way our lead coder has the opportunity to look things through without anyone messing it up. Once again, not learning from our previous mistakes we implemented some features the morning before the session. Mistake. Again.

We had a group meeting directly after the play-testing session to evaluate and reflect on the feedback. We got as many as 30 individuals answering the survey I had prepared. Diagrams depicting the results combined with written answers proved its worth when we collected the feedback. We also wrote down notes and comments by hand and combined them together. Some tweaks stood out but far more valuable was the suggestion for new features we had not thought of. This included an indication before the next enemy wave. Now the music of the game hints at what is coming and a sign indicating the spawn of the enemies is roughly implemented.

I exported the results and uploaded it to our shared folder of assets for the project. 

As pictured above, it is clear the fire rate and velocity of the standard bubble projectiles has to be increased. This is however a tweak instead of a feature so it was not a high priority of the following sprint. Instead we focused on the final features we wanted to have implemented. I used a basic Scrum pull backlog for this; tasks were delegated but not to a full extent. Instead, the team members could pull tasks once they’re done with their highest priority. This was a success, since every feature we decided to implement are featured in the current game build. Better yet, it’s a weekend before the next presentation of the game.

-Mikael Sukoinen

Preparing to Play

On Monday the 27th if February, 2017, we are provided a second chance for other game design students to try our game and give feedback. The last play-testing session was not prepared accordingly and this time I wish to improve. We did however gather a lot of valuable and constructive feedback which the group tried to remedy. I wish to gather data from the play-testing on how we succeeded in that and on possible new flaws.

The first thing that was lacking on our first session was an actual survey. We were unsure on specific to ask on a pre-alpha game so we simply took notes and provided testers with a sheet to write feedback on. Feedback was received for sure, but we did not have any tangible results to measure. It made reacting and correcting the flaws just a bit too difficult. Another obvious failed that occurred was the fact that we were missing a death screen; upon death after death the game had to be restarted. Luckily, that was fixed the day after.

As a format for the survey I chose Google Docs as that seemed to work as intended for most of the other groups. It would also be useful to have an online medium for it as then it can be accessed on any computer. The results would be easily accessed as well.

Our feedback surrounded the purpose of the game, common gameplay and player feedback. For example, we had no recoil when firing our main weapon. When creating the survey I wanted to ask those questions directly, i.e:

I make music for the game. Last time I relied on the volume output of my laptop’s speakers. Mistake. This time I will bring my own sound isolating headphones to make the testers experience the different elements of sound in the game. Also, we used a basic wired mouse for the testing. This time I will bring something more suitable and game oriented.

I watched some videos on collecting good feedback for the game. My main source was a sheet of link’s provided by our course director. The most direct was the one on top of the list by the Youtube channel “Extra Credits”. Emphasis was on providing testers with an experience to bring up discussion and feedback. I want to know how the player, not me, experiences the game in order to improve the experience for the player.

Tomorrow our game designer will do a quality check on our survey and it will then be put to use on Monday. I will update on how that goes.

P.S. I obviously had to add something “funny” to it: