Feedback for developers, feedback for player

Hey!

Today’s post will deal with playtesting and its’ effect on making Fear is in me.

2 playtesting sessions scheduled during the course were great opportunities to confront games that we are currently producing with real end users and to gather feedback on what needs to be improved. Unfortunately, the technical issues that occurred just before the first session were a bit too much for us to handle. After we built the project, aiming the weapon turned out to be faulty and causing multiple features act very weirdly. In the end, we didn’t manage to gather any meaningful feedback. Unlike the second session which was a big success for us! I consider it successful not because of positive opinions on our game, but rather the negative ones and the lacking things that testers noticed. Big part of them told us that we have good foundation and it can become very enjoyable game once we provide a player with better understanding what is actually happening. Right after the session, my team discussed the criticism we’ve got, so that we draw conclusions and set goals for the upcoming sprint (you can read my post about our Sprint Planning here). It was pretty straightforward – we were missing feedback given to a player.

Do I deal damage to enemies?

Do I take damage from them?

Why did I die?

These questions remained unanswered, leaving the testers very puzzled and making the whole game really unintelligible. That’s why my team focused on implementing sounds, animations and effects, all of which were meant to provide a player with needed information and to ensure that he or she understands clearly what’s going on.

First of all, we got short sighing sound that indicates that the character – Eri is hurt. We also needed to make a death sound, but killing a little girl didn’t seem like a perfect idea. Instead, we decided to go around and I believe it is really interesting design decision – Eri doesn’t die when she takes fatal damage. She wakes up from her nightmare, making a quick gasp, and that’s the noise we put into the game. It was followed by sounds related with power ups. To give more comprehension for different kinds of flashlights (namely, regular flashlight, dual flashlight and searchlight), which work as weapons we implemented sound of changing weapons as well as metallic noise that represents putting a new battery into the flashlight.

Next step was making enemy Hellbats fully audible. So, after some search and experimenting we got satisfactory result – turning lights on them causes hiss as it torches them. In addition, we wanted to imply that these bats are actually vampires, so their death animation makes them fade away, burning. Brutal shriek is the last noise they make.

We hope that all of these changes will have a positive effect on how the players perceive the game, making everything that is going on very clear. We’ll shortly know, the final presentation is coming very soon!

About Krzesimir Pszenny

2017 Project Management