Post Mortem from play testing of WWW

From the play testing of WWW, I have notice several important events that significantly affected the outcome of our project.

The first being that out lack of feedback to the player seriously diminished the play value of our game, to the point that it seemed that random chance was affecting the outcome of the player’s decisions.  I saw on the videos of the play testing, that several times, the player had done what he needed to do to get out of the level, but the lack of feedback meant that they didn’t know they had done that thing, and continued to move around the level, trying to work out what to do.

Secondly, the tutorial level was designed in such a way that all of the implementations/restrictions of the player were in full force.  That is that the player needed line of sight to the minions before he could take them over.  This could not be implemented and a simple switching between the characters had to be implemented, which meant that puzzle components didn’t need to be used for the tutorial level in the order that it had been designed for.  A lack of communication between the programmers meant that the switch and the jumping box had almost the same shade of green and that led the player to believe that these two elements had to be worked in together to solve the puzzle.  This, along with the lack of feedback, led to a great deal of frustration and saw many players exit the game without even finishing the tutorial level.

Thirdly, the game was essentially designed to be played with a controller and not a keyboard and mouse.  As we had only one controller on the day, the 3rd person controller, which can be a pain in the best of circumstances, had to be used with the keyboard and mouse.  This was not optimal and made for rather sketchy movement.  Although this could have been forgiven if both the earlier issues had been better resolved, but in this case, it only added to the frustration that the player felt with our game.

I think a lot of these things could have been handled better with more communications between the programmers and designers and a work flow that allowed for the inclusion of audio clips to be included at the time of writing the code.  The first things written in the code should be the variables and the audio clips that will be used and neither programmer thought of including this.  I know for my part, the audio has been one of the last things I think of when doing assignments and now realise that it should be one of the first.  I personally think that another cause of these issues is that we currently have no team manager to keep the focus on the final outcome.  Everyone seems to be tied up in their own problems and no one is looking at the bigger picture.

I know that I have learned the feedback is vital to any game.  Without feedback, the player could easily think that random chance is affecting their actions.  It is doubly important for our project so that the puzzles seem to be solvable and not at the whims of a “dice roll”

I think to overcome this in the future, I will make sure that the first thing I make provision for, in my code, will be the allowance of audio clips.  By thinking about what the player is doing, I will create sound effects that will indicate what they have done, and also keep in mind things like with a switch, changing the texture of it when it has been activated or a simple animation.

While there was nothing in this level to really get my teeth into with regard of AI, I did learn some aspects for creating code for a prototype.  I also gained an understanding in a couple of areas.  That in an Indie environment, a programmer must be way more that just the tech support for the project.  I need to be more involved in the design aspects of the project and not leave all those decisions to the people who I may think the job belongs to.  I have also gained an understanding of how I need to approach my own coding, even for prototypes, whereby I can put audio and visual feedback into the game.

For my part in this project, I created the TDD and added the 3rd person controller and investigated ways to try and establish line of sight with the other characters.  The methods I tried to implement did not pan out and although I have since established them, they did not appear in the build for play testing.  I also bought in the 3rd person Camera and a smooth follow script.  I created the code for the jumping box to propel the player into the air(although it would only do that if the player rushed the box.  Try as I might, I couldn’t get it to work when the player jumped in top of it.), The prefab for the bridge and the code that activates the bridge by rotating around the pivot points, resets a times and raises the bridge after a period of time.  I also created three place holder models for all the characters, although at the last minute, we did recieve a model for the wizard at the last moment on the day before the build was needed.

The biggest way that my choices affected the quality of the finished prototype, was the fact that I had dismissed feedback as a “nice to have”, rather than a “need to have”.  By not putting myself into the players eyes, or head, I failed to see the obvious when the player could walk off a platform and fall into an area that he can not solve the puzzle from.

When we started the project, I volunteered to set up the repo, which I did following the directions of my teacher.  Unfortunately, the first time I tried to push my changes onto BitBucket with SourceTree, I encountered a catch 22 error.  I could not push because I had to pull first and I could not pull, because I had changes to push.  This was resolved by changing the repo to GitHub, being controlled by the  other programmer.  Only the two of us currently have access to this repo and any other items are uploaded to the groups Google Drive.  While Unity is the preferred application for this project, there is a problem in that one of the team has only passed Scripting 1 and has no real idea of what can be done with the application.  While he should become more used to the package as time goes by, it will be a while before he realises how versatile it can be.

The biggest things I learned from this session have been:

“Feedback Dammit!!”, in the words of our teacher.  My first thought should not be how to make this bridge work, but what sounds will this bridge make, and what visual feedback will the trigger have.  For every action the player can make, there needs to be visual and audio feedback to help him with any future decisions.

Tutorials should be designed by the team as soon as the mechanics have been decided and not left up to one person.

Communication to all team members about every decision you have made, why you have made it and even explaining why you can’t complete something, inviting discussion about things that you didn’t consider at the time of a meeting and making sure that every person contributes to the discussions.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s