The jellokaraboosqaud assignment3_0715

RunAmok

Usability Test Plan

Game created byTeam Charlie

Week 2 version

Brought to you byTheJelloKarabooSqaud

Aaron ChristianAnthony Stewart

Austin SteyerBrandon Pounds

Justin Lelos Friday July 24,2015

Table Of Contents

Table Of ContentsExecutive SummaryMethodologyTesting

Impression Questions:Exploratory Questions:

Data TableImpression Results:Exploratory Results : Q&A Results:Player’s Questions:Table Ex.Testing ExperienceFlowchartReferences

Executive SummaryOur goal during this play test is to determine barriers that the player may come across,

how they respond to these barriers, and what strategies the player derives in order to complete

the game. After speaking with the development team we have developed a test plan that will fit the development teams requirements to create a fantastic game. In our Test plan we will be showing you our Methodology sequence and how we will perform our test. The test subjects will follow the “Think Aloud” methodology, and we will be conducting a few question in between each level. This methodology will be supported by a flow chart that is easy to understand. Our test plan will also cover what the team has found in our own testing and some ideas on how we can improve them. These trouble areas that we have found will be photographed to better help the development team to better address these items. We have developed questions that will support the players impression when they first start and what they experienced when they have finished. The Test plan will also show you how much data will be capturing and how it will be organized.

Methodology

We will start our play test as setting up the game for the player. We will select the best settings for the game to see the player and receive the best performance. When the splash screen appears we will then give the game to player to view. At this time we will ask the player to not touch or start the game and to please view and listen to the splash screen. We will then ask the player our impression question and allow us to document their answer. The player will be informed to please do not view the controls in the control menu and that they will be taught the controls in the tutorial.

From here the player will then begin their play test, during this time we will ask for feedback and try to understand what the player is thinking or feeling. As the testers we will also be recording how many lives and how long it took the player to finish the level. If the player asks a question during or after a level, we will also ingest this as data due to the request for Team Charlie. When the player has beaten a level we will ask the player to stop and answer some Q&A question that we have based on their experience with the level. This procedure of playing, recording, and then Q&A will continue until the player has finished the hole game.

When the player has finished all levels we will then begin asking our Exploratory questions. Its vital to the success of the project that we gain an understanding of the player’s complete impression of the game. This feedback is one of the key feedbacks to our methodology that will help Team charlie develop their game.

Testing

Impression Questions:

Based on the menu screen what tone or atmosphere is the game trying to portray?

How would you compare the menu screen on this game to other games you’ve played?

From looking at the menu screen is this a game that you are interested to play, and why?

Tell me what genre you think this game will be and what it could be about?

From your first impression what do you think could be added to the menu screen, if anything at all; that would increase your interests in playing the game?

Exploratory Questions:

Wall jumping is presented at the very start of the game, how does this increase or decrease the level of difficulty throughout the game?

What is the purpose of the platforms changing colors?

How would you describe the feel of the charge jump mechanic in this game?

How do the hazards in the game affect your experience with the overall gameplay?

What was your reaction to the Air brake mechanic?

How would you describe the tutorial?

How was your experience with the controls throughout the game?

Did you feel that the length of the level was appropriate?

What is your opinion on the crouching mechanic throughout the game, would you change anything?

How would you rate the overall re-playability of each level, and why

Data TableOur data table was designed to best fit what Team Charlie is wanting to see in our play test. We will be showing what level the player is on and how many lives it took finish the level. If the player has to continue the game this will be expressed in the number of lives used. Since each level has Three lives, Five lives used would mean that the game has been continued one time. We will also be keeping track of how long the player has played the game. Team Charlie has

also requested to be aware of any questions that the player has or troubling areas that they are experiencing. Below our table there is example of the data that we will be collecting.

Player Level Number of lives used

Time spent on level

Player enjoyed the level

Player Progression

Impression Results:______________________________________________________________________________________________________________________________________________________________

Exploratory Results:______________________________________________________________________________________________________________________________________________________________

Q&A Results:____________________________________________________________________________________________________________________________________________________________________

Player’s Questions:_______________________________________________________________________________________________________________________________________________________________

Table Ex.

Player Level Number of lives used

Time spent on level

Player enjoyed the level

Player Progression

1 1 7 5:36 Yes/with Frustrations

Had a harder time with jump ladder

From this example you can see that play tester had to continue twice due to the number of lives used. We have the time stamp of the player playtesting the game. The player enjoyment comes after the player finished the game. Having a simple yes or no in this data can be used easily in a pie chart, however we will take note of what the player did or did not enjoy in the lower section for the data. This will be use to allow a grading system to better inform team which players enjoyed most and if the level should be pushed back to a latter level due to difficulty.

Testing Experience

While playing the game, the team encountered a multitude of situations that blocked a player's progress through a level. One of the most frustrating situations was in the first level when the player is presented with a wall jump. If the player fails the very first jump attempt at the wall, momentum will be lost causing the player avatar to slide down the side of the wall and fall through the gap that sits right under the wall. It caused many deaths and was very frustrating, something like that should be introduced later in the game so the player may learn to wall jump more efficiently as that would be something that increased with the difficulty of the game later on. This falls under error prevention because you want your player to be able to recover from the error itself and not be punished by the game for something that the player does not have control over. We understand that Team Charlie has fixed this problem by extending the platform so the player does not fall to their death. However the latter mechanic that is in level one is far too difficult for introducing the game’s key features. As a suggestion we would like to see the ladder mechanic be in level four due to the difficulty that is involved with it. As a replacement in level one have a simple wall jump so the player can learn the mechanic before applying all the mechanics in the game.

The next situation is not something that's detrimental to the gameplay. When a player rapidly presses the spacebar while moving up a wall jump section their avatar will accelerate gaining momentum, it causes the player to fly upwards this could potentially end with the player losing a life. This is something that would fall under match between system and the real world because if someone thinks about jumping from wall to wall gravity would prevent them from gaining momentum in the real world so they would expect the same thing from wall jumping in a gameFor the team jumping in the game does not feel as responsive as it should. When a player jumps and hits the ground they should be able to jump again immediately however there is a slight delay when the player touches the ground. That being said this is the only feature of the game that the team feels is sluggish, everything else is quick and responsive, so this is more of a consistency and standards issue, were all features and mechanics respond immediately except for jumping. After our meeting with Team Charlie we learned that they want the jumps to be more of a rhythmic pattern. Our team has a few suggestions that could help with timing the jumps in the game. The game could have synchronized music, so that the player can follow along with the music and time their jumps. Our other idea is for the jump to have its own sound, that way the player can recognize when they jump. Our last proposal is to have a springboard mechanic built into the walls themselves, this would propel the player in the direction that is desired.

The game does not feature checkpoints, when you die in a level you will have to start from the very beginning. While the levels are short some frustrating areas of the game will have to be played over and over. This is a user control and freedom issue because a player won't lose any progress with checkpoints set in place. We know that the levels are short and they are intended to be that way from Team Charlie, however implementing a checkpoint system still would not take away from the difficulty of the game and could relive some of the frustration of starting over the level.

When we played through level three we noticed that when the death blocks fall from the top they won’t respawn if the player dies same for the trophies in the levels. This event happens in the entire game when the falling blocks or trophies are involved. This deals with a consistency and standards issue, the blocks and trophies should always respawn when the player restarts the level as it is an obstacle that they face during the game. If this was intentional there should be a checkpoint after the falling blocks that way the player does not see this error.

After playing the tutorial, the instructions on how to play the game and use the features go by too fast, making it so the player has little time to read the instructions or even notice them. This is a visibility of system status issue, because the player can not receive the appropriate

feedback when it is necessary for them to be receiving it. When we had our meeting with Team Charlie they had explained to us that they have already recognized this as an issue, both taking the player's eye off of the character or missing the information completely. A solution for this is to prompt the player well beforehand what feature they are about to encounter and also display a picture of the key they will need to press. Our suggestions are to prevent the player from continuing forward until they press the desired key, or make the tutorial not have the consequences of actual gameplay. Make it more of an open testing ground for features and let the player play it for as long as they need to understand all the features.

During our playthroughs on level 1 we encountered a bug that causes the player to have the ability to use the airbrake mechanic while on the ground. The player would tap the jump key and rapidly press the airbrake and hold it to continue moving backwards on the ground. This is a glitch that was stumbled upon while attempting to complete level 1 but it can be duplicated on

any level. Possible causes would be that the program is confused on player avatar position, or the condition that makes the ability enabled.

If this feature was not intentional to the game we found that this feature be quite useful for the jump in level 1. Potential having this feature as a real mechanic could be useful to the players. There could be a couple of things that could prevent players from either air braking through the game or having this brake and kneeling glitch from happening. One thing that could be added is having the brake feature utilizing a different a key such Shift or Z. This could potentially stop the confusion between the crouch and break mechanic. Now if this feature was to be added to the game a break bar (aka:Stamina Bar/fuel) could be added to the game that allows the player to only break back so far. This would stop the player from moving too far back in the level and could help players solve jump puzzle’s with a little extra room to charge a super jump.

Flowchart

ReferencesBarrientos, JD., Brown, J., Schwanz, C., Simanek, J., “2015”. Run amok “ver. week 2” [unity, video game]. Team Charlie.

Nielsen Norman Group. (n.d.). Retrieved July 23, 2015, from http://www.nngroup.com/articles/ten-usability-heuristics/

Usability Test Plan Template. (n.d.). Retrieved July 23, 2015, from http://www.usability.gov/how-to-and-tools/resources/templates/usability-test-plan-template.html