IP3 - Testing and Evaluation

Today was the very last testing session for this course. Overall I feel it went pretty well. For the 3rd prototype of Hop to Who, I didn't make any huge changes, mostly it was a refinement of the game based on last session's feedback.

I had a total of 6 participants play the game. Three of whom had already played in previous testing sessions so were pretty familiar already with the game and the remaining three testers playing for the very first time. I thought it was really beneficial to observe the difference in the participant's behaviours and responses due to this.

Overall the response was very positive and testers responded very positively to the questions about their general understanding of the game and their enjoyment levels. All said they understood the goal of the game, and all rated it a 4 or 5 on the 5 point scale of enjoyment of the game.




In this prototype I decided to rely less on myself giving verbal instructions, and added How to Play instructions to the splash screen to be read on start up. I think this decision resulted in less of an immediate understanding of the game rules, and more of a learning curve. I noticed most players didn't spend a lot of time reading the instructions and were keen to play the game as fast as possible. Perhaps for a future change a more interactive tutorial could be integrated so players do not have to read a long written explanation about how to play, rather learn by doing.
Despite this all participants still quickly grasped the game controls and game mechanics within 1 or 2 times in playing the game. So I feel confident that the majority of players could quite easily start playing the game of the first time without the need for in-person facilitation, and learn fairly quickly how the game works.




Including an easy level definitely helped ease players into the game before it got too challenging. From my observation, 5 out of 6 testers started at the easy level and worked their way up to the hard level. Every player actually got a chance to win the game at least once, which is a vast improvement from the last testing session. The outlier participant (who actually was a first time player) didn't attempt easy at all, he jumped straight into the medium level for 1 turn then tried the hard level 2 times - he managed to win a lot and picked up the game play very quickly. The survey results were a little mixed, most rated it an average of 3 (where 1 is too easy and 5 too difficult), 2 rated it a 4, and one person rated it a 1 (too easy - the outlier tester). It was interesting to note the varying skill levels of the participants, especially the one who was very skilled on the first time playing, compared to another player who had previously tried the game before in the last session, but still struggled a little on the easy level. Seeing these difference in levels, I feel supports my decision in including the different difficulty levels, so everyone regardless of skill, can still enjoy the game. In the future I could implement even more challenging levels to cater for those who find the game too easy.


As for the physical controls, they worked a lot better than in the last round of testing, although still could use a bit of reworking to ensure the tiles don't bounce as much. If I had more time I would move the position of the contacts so even if the tile did bounce, it wouldn't affect the Makey Makey from registering input.

Another feedback suggestion I'd implement is to remind the player to reset all the tiles before replaying. If this isn't done at the correct time before pressing the replay button, can disrupt the game as the program thinks those tiles have already been eliminated.

Survey link:
http://goo.gl/forms/mIRqJAnZBz

View the summary of responses here:
https://docs.google.com/forms/d/1XMu8zuWiq71SCMVKwqRIt1wVrZILvw3hIjOje1wk6QU/viewanalytics

IP3 Concept

Hop to Who?! combines the games Guess Who and Frogger. There are two main aims of the game, firstly to safely guide the frog across the road, and second to guess the identity of the frog’s mystery date waiting on the other side of the road. This game is aimed at those aged 5 years and up. It’s purpose is to mix elements from both games in order to create a game that is both challenging and fun.

A physical Guess Who tile board is the physical input for the game. Each “tile” shows a different and unique character. As the game progresses, clues about the chosen single mystery date will be shown on screen, allowing the player to eliminate incorrect characters by dropping a tile face down. Each time a tile is put down, this controls the forward movement of the main frog on screen.

The Story of "Hop to Who?!":

The Frog needs to cross the road to meet his blind date. As he crosses, the game will display clues about the characteristics of the blind date. The player needs to both get across the road and match the mystery date with the final remaining character tile.

Frogger elements:

• The game objective of getting the frog safely across the road.
• Timing the moves to avoid getting hit by moving traffic.
• The frog character and the level design.

Guess Who elements:

• Eliminating all the characters displayed so only 1 remains
• Giving descriptive clues to help the player eliminate the character tiles.
• Physical interaction of flipping down tiles.

How to play:

• The on-screen interface will display the game interface, there also will be a physical Guess Who style board with 10 character tiles shown face up.
• There are 2 objectives, both equally important. Get the frog across the road to safety and eliminate all but one of the characters correctly.
• The onscreen clues will give the player hints as to which frog tile to drop down.
• Each time a tile drops down, the frog on screen will move forward one space
• As the game progresses, further clues will be given to help eliminate frogs.
• The challenge is to flip the tiles down in sync with moving the frog to avoid collisions. This requires 2 mental processes to happen at once, strategic elimination and quick response.
• If the player gets the frog to safety, then there is the added reveal to check if the player has selected the right character.
• If the remaining tile matches the mystery date, the frog will live happily ever after. Otherwise sadly the frog goes home alone.
• There are 3 levels to choose from, Easy, Medium or Hard

Game Updates:

From the last prototype released, there have been a few iterations integrated in to the latest version:

• The game board itself has been updated. As the tiles bounced when dropped down, I used conductive foam, placed where the tile's contacts meet to help prevent this, and reduce noise. 
• A splash screen has been added, to give a short overview of the game (so I don't have to give a detailed explanation to participants every time they play). 
• Three difficulty levels have been implemented, based on the speed of the traffic.
• Updated some graphics, such as the trucks
• Removed the number text at the top (which previously indicated which tile numbers had already been eliminated, as past testers paid no or little attention to these).

Post-testing survey link: http://goo.gl/forms/rXBebqb2jx

IP2 - Testing and Evaluation

Today's testing session went pretty well. I had a total of 10 users play the game and complete a survey.

This latest prototype generally achieved it's purpose, and all of the users testing it had little problem grasping the concept of the game and how the physical controls operated. 100% of users responded that they understood the game's concept. 8 out of 10 understood it well from my instructions given, 2 users would've preferred some more explanation. Especially for those who had never played Guess Who, I could've explained the elimination concept more clearly in detail, as those who never played had trouble choosing the correct character tiles to eliminate at first.

The game board was successful and I received positive feedback on it's construction. There were a few technical issues, where 2 of the tiles weren't able to make an adequate contact with the earth points. As the tiles are pretty thick and heavy, the steel wool helped to cushion the impact when the tile drops, but for one tile (#6) it broke off, so when it was dropped, sometimes the metal to metal contact caused the tile to bounce and not register a move - usually causing the frog character to get hit by a truck. Another tile's hinge was a bit too tight (#4), so it didn't drop down easily, also causing problems with the game. At times this resulted in the user losing the game, when they otherwise would've won. 3 users noted in the survey to improve the tech breakdowns on the game board as an issue, so this is something I will definitely improve in the next iteration.

Most participants grasped the guessing/elimination concept quickly. 4 of the 10 users had a little trouble matching the clues to the eliminate the correct frogs - for example some users had trouble eliminating the right tiles after receiving a clue that used a negative style description, "I am not wearing a hat" - users would put down tiles of the frog's not wearing a hat, rather than eliminating the opposite frogs with hats. However, no one had trouble with the opposite clue, "I'm wearing a hat", users all correctly eliminated frogs not wearing hats.

I personally don't think I'd change this type of negative clue, as it does require a bit more mental challenge, and over playing multiple times, users tended to realise this mistake and self-correct to eliminate the right character tiles.

I received positive feedback regarding enjoyment and fun users had, and about the uniqueness of the controls. 7 users rated the game 5 out of a 5 point scale (5 being the best score), and the remaining 3 rated it a 4. As for uniqueness, 7 rated it 5 out of 5, 2 users rated it a 4, and 1 user rated it a 3 (5 being the best score).

As for the difficulty, there was a wider spread of replies, this may be due to the fact that the earlier sessions, the speed of the trucks was faster and the earlier users found it a bit too hard, so I compensated later by slowing the speed down. Half of the users found the difficulty suitable, rating it an average of 3 (challenging, but not impossible), and an the rest evenly spread on either side of this rating. Some user suggestions included creating levels to help ease players in and teach them how to play, gradually making the levels more difficult. Another was to be able to choose a difficulty level. This is a definite consideration for the next prototype.

  

   

Unfortunately I didn't capture any recording of wins - here's some recording of players almost winning, one user would've won if my game board didn't fail :(

Survey Link:
http://goo.gl/forms/ayAlSBwWgu

Summary of responses:
https://docs.google.com/forms/d/1JfgVLDcQDcQhkIdgUM1F2P1qE-_GWyKw7wCLIwAiEFk/viewanalytics

IP2 - Concept

Hop to Who?! combines the games Guess Who and Frogger. There are 2 main aims of the game, firstly to safely guide the frog across the road, and second to guess the identity of the frog’s mystery date waiting on the other side of the road. This game is aimed at those aged 5 years and up. It’s purpose is to mix elements from both games in order to create a game that is both challenging and fun.

A physical Guess Who tile board is the physical input for the game. Each “tile” shows a different and unique character. As the game progresses, clues about the chosen single mystery date will be shown on screen, allowing the player to eliminate incorrect characters by dropping a tile face down. Each time a tile is put down, this controls the forward movement of the main frog on screen.

The Story of "Hop to Who?!":

The Frog needs to cross the road to meet his blind date. As he crosses, the game will display clues about the characteristics of the blind date. The player needs to both get across the road and match the mystery date with the final remaining character tile.

Frogger elements:

• The game objective of getting the frog safely across the road.
• Timing the moves to avoid getting hit by moving traffic.
• The frog character and the level design.

Guess Who elements:

• Eliminating all the characters displayed so only 1 remains
• Giving descriptive clues to help the player eliminate the character tiles.
• Physical interaction of flipping down tiles.

How to play:

• The on-screen interface will display the game interface, there also will be a physical Guess Who style board with 10 character tiles shown face up.
• There are 2 objectives, both equally important. Get the frog across the road to safety and eliminate all but one of the characters correctly.
• The onscreen clues will give the player hints as to which frog tile to drop down.
• Each time a tile drops down, the frog on screen will move forward one space
• As the game progresses, further clues will be given to help eliminate frogs.
• The challenge is to flip the tiles down in sync with moving the frog to avoid collisions. This requires 2 mental processes to happen at once, strategic elimination and quick response.
• If the player gets the frog to safety, then there is the added reveal to check if the player has selected the right character.
• If the remaining tile matches the mystery date, the frog will live happily ever after. Otherwise sadly the frog goes home alone.

Making IP2

For the 2nd interactive prototype, not a lot changed concept wise, but I made a lot a changes to the game's interaction and code.

In this iteration, the Guess Who element and the physical controls were added. In order to account for the guessing/elimination features I had to add in new object (character.as) for the extra mystery frog date characters , which held attributes representing their characteristics:

• colour: red, blue, green
• wearing a hat: true/false
• wearing glasses: true/false

As well as adjusting the existing code to support the new feature, I also added a new function to show the clues that help describe the mystery frog (chosen randomly each time the game restarts)

One annoying problem was with one of the red trucks appear at the top of the screen, above the clue box, even though the stacking order seemed to be correct. I tried deleting the last truck added to the truck array, but this just forced the next last truck to do the same thing. I ended up working around this and cheating by adding an extra truck to the stage, but positioning it below the visible stage area, so it stayed hidden.

Working on the new code

The final interface, with the new clue box sidebar added to display the clues one at a time

The game board is made from a piece of 15mm thick MDF, and the 10 tiles are also cut from this material. Each tile has an illustration of a different frog character (each one has a unique description, and physical attributes are evenly spread out). The top of each tile has a metal screw at the top with a wire soldered through to the back connected to a Makey Makey input (the letters WASDFG and the 4 directional arrow keys). The tile is attached to the bottom board with a hinge, so when it is dropped down, it hits another metal screw which is wired to the earth.

The game board

The back of the board

Close up of the game board and Makey Makey

After initial testing the game, I found that the tiles sometimes bounced when dropped down. This caused the controls to malfunction, either not registering at all, or conversely too many times, meaning the movement of the frog character on screen didn't move at all or move too many times. To combat this, I added some aluminium foil to cover the bottom contact. This seemed to work at first, but didn't fix the issue completely. I then tried taping some pieces of steel wool on instead, this worked a lot better and also made it less noisier. I then decided to solder the steel wool in place so it stayed in place.

I also decided to add in a physical replay button to replace the spacebar key - it's just a wire attached to the space key, with a paper "button" taped on top which when pressed touches a screw connected to the ground.

Overall I'm pretty happy with how it all turned out. I was pretty lucky to have my partner help me construct the board in a way that kept it all nice and neatly organised and taught me how to solder the wires in place. If it were up to me there would've been a mass confusion of wires running all over the place. The steel wool and screw contacts are probably not the most ideal solution for ensuring the best contact between the tile and the board, as it does tend to move a bit. But for this stage it works the majority of the time and is easy to adjust and manoeuvre. The size and weight of the board also are a bit too much, but it was a cheap and easy material to use appropriate for a prototype at this early stage.

Testing the game

Adding the steel wool to the bottom metal contacts

Week 9: Experience Prototyping: The Restaurant experience

Restaurant Dining Experience 

In class we discussed experience prototypes. We were asked to consider how this form of prototyping could be incorporated into the process of designing new technology for restaurants. 3 different stakeholders were considered: the customer, the waiter, and the chef.

• What is the existing experience? 
• What external/internal factors impact on the experience?
• What aspects of the existing experience could be enhanced/augmented/supported with technology?
• How would introducing technology into this context change the experience?
• What experience scenarios might you test with the technology?

Customer:
What is the existing experience?
The service they receive from entering until leaving the restaurant: Waiting for a table; being seated; reading the menu; ordering; waiting to receive their order; eating; paying the bill. Pre and post experiences could also be considered: booking a table; checking out a restaurant's website, review or social media; reviewing the restaurant after visiting.

What external/internal factors impact on the experience?
Recommendations and reviews, quality of service, quality of food/drink, price, speed of service, interior decoration, atmosphere, number of diners, queues, noise, customer's expectations, who they are dining with, other patrons.

What aspects of the existing experience could be enhanced/augmented/supported with technology?
The ordering experience, the menu itself is an obvious one. Another could be when waiting in a queue for a table at a busy restaurant, a system to see when a table is free, or get feedback on how long your waiting time will be, you could even start ordering before being seated to speed up service time.

How would introducing technology in to this context change the experience?
It might allow for less frustration when waiting for a table to open - customers could leave and do something else if they know how long to wait and comeback later. They also would be able to eat earlier if they ordered food earlier, and wouldn't have to wait as long while hungry.

What experience scenarios might you test with the technology?
Get a small group of "diners"in a waiting area to simulate the experience. Give them allocated slots which are display on screen, give them the option to wait, order and/or come back later at the estimated time. 

IP1 - Testing and Evaluation

In this week's A Prac Class it was time to test my Interactive Prototype 1.

I firstly explained the goal of the game, to move the frog across the road while avoiding the moving trucks (red blocks). Most testers were already familiar with the Frogger game, so this was easily understood by the majority. After this, I explained how to control the frog character (using number keys and arrow keys).

As the game was quite quick to get through, I instructed testers to play as many times as they liked, until they won, or got sick of playing. The first few users all only got to move once, and died upon hitting the first truck. This was mostly because they didn't understand the number controls (each number could only be pressed one). After the first try they managed to progress further in the game.

The first 3 testers tried around 3-4 times, they all progressively improved however none made it to the end, so I adjusted the speed of the trucks to make the game easier. I also did a quick demo first, so show how the controls worked, rather than just give the instructions verbally. After doing this , all the testers managed to win at least once. It still seemed quite challenging (didn't win all the rounds) but could get through after 2 or 3 tries.

I measured by observation. I counted and noted the exact point where the tester's character died, so I had a quantitative measure of their progress over the span of their attempts. I also noted how they used the controls, and where their gaze was (either on screen or on the keyboard).

Many testers had some trouble using the number keys, especially in the beginning. However I am not so concern with this problem, as the next prototype's controls will be completely different. Plus the element of elimination of keys (or in he final prototype, character tiles) is an integral part of the gameplay, and is supposed to offer a challenging element - plus the game is quick, so it's fast and easy to restart the game if needed.

The testers didn't really notice the numbers on screen (showing which numbers were eliminated). Testers had their gaze on the frog character only, and occasionally looked at the keyboard. So I discerned from this, that visually showing what numbers/character tiles on screen probably wouldn't be necessary for the next round. The results from the survey as back up this - where 3 out of 8 finding the game a bit too difficult,  where most marked this as suitable.

As for the testing session itself, I probably didn't give enough explanation to the initial testers who had more difficulty grasping the controls, so giving a demo may have contributed to the improvement of the later testers.

For the next testing session, I'll still pay attention to the explanation of the controls and the difficulty levels, as these will be different again. The added concept the the guessing may also need to be paid attention to, as it adds another level of complexity to the Frogger elements and hasn't been able to be tested in this session.


Detail of results:

I had a total of 8 testers play my game and complete the survey.

Observation and process:

User 1: 

• Died straightway on 1st truck
• Died on 4th truck
• Died on 7th (last truck)
• Died on 7th (last truck)
• User didn't understand that keys could only be pressed once at first. Kept pressing random keys in no particular order, so found it difficult to keep track of which keys were already pressed. Gave up after 4 times trying and not winning

User 2:

• Died on 1st truck
• Died on 3rd truck
• Died on 6th
• Died on 7th (last truck)
• As the previous user, took a while to grasp the controls. Gave up after 4 times

At this point I made the game difficulty easier by reducing the speed of some of the trucks

User 3:

• Died on 1st truck
• Died on 6th
• Died on 7th (last)
• Died on 7th

At this point I made the game a bit more easier again. And I changed my method of explanation at the beginning, by demonstrating the game quickly first.

User 4:

• Died on 7th (last)
• Died on 5th
• Win!
• This user was the first one to make it across the road. The new difficulty level seemed to be improving the chance of winning

User 5:

• Died on 7th (last)
• Win!

User 6:

• Win!
• Died on 6th
• Win!

User 7

• Died on 7th (last)
• Died on 5th
• Win!
• Died on 4th
• Died on 4th
• Win!
• Win!
• Win!
• This user seemed to enjoy playing and kept playing the game after they already won.

User 8

• Died on 7th (last)
• Win

Survey:

View a summary of the responses here: 
https://docs.google.com/forms/d/1ydUyNWBemM7w0qzX1dCX0t2DamKjKIZwSK29fL5FMfM/viewanalytics#start=publishanalytics

Week 8: Non-traditional Physical Interactions

Some ideas (some good but mostly not so good) exploring some unique types of physical controls:

Email

• An email is represented by an object such as a block. By putting the block in different containers will correspond with moving emails to different folders. Putting a block in the "trash" can will delete the email.
• Each of your email contacts are represented by a character figurine. Speaking up close to a character will record and send an email to them.
• Email inbox number is represented by a level (like a thermometer), the higher it is the more new emails you have. The goal is encourage the users to lower the level to zero.
• Emails are printed on cards, when the card is crumpled the corresponding email is deleted.
• Pick up a pencil to start a new email. Anything you say when the pencil is held will be converted to the email's text.

Twitter

• Writing a tweet on a post it note (limited space means limited characters used) and pinning it to a board posts it.
• Printing a tweet (may have special identifier such as QR code) and display it on a special board will add it as a favourite tweet and then display your favourite tweets physically, offline
• Notifications received will be literally "tweeted" with sound. Tweet text is converted to audio and can be played back, like an answering machine.
• A scrabble like board with 140 empty spaces. Placing letter tiles on these spaces will form a tweet. Once done lift the board vertically and throw off all the times at once to send tweet.
• A small loudspeaker like device. When you want to speak, take out your loudspeaker and say your tweet into this. Everyone around you can hear it loudly, and it will also be captured and sent as a tweet.

Super Mario Bros

• The player has to physically move, jump, run to control the characters corresponding actions
• Related to the above idea, for multiplayer games, you have to verbally direct another player who cannot see their character on screen. They then must do the correct physical gesture. Afterwards they can see the game recording side by side with a recording of their movements.
• Toys/figurines are used as controllers. So by moving the toy through a space or over physical objects represents the character in the game's action.
• Collecting coins and other special items in the game also dispenses real world versions of these objects that you can collect as you play. You could even use these as currency, by inserting coins back into the game console to unlock levels, get more lives etc.
• Punching a soft toy representing an enemy or an obstacle to destroy. The harder you punch, the more effective your attack in the game!

IP1 Game Concept

The concept for my game hasn't changed too much from my initial idea.

Concept Recap:
It's a game mashup of the classic games Frogger and Guess Who. While these games don't really have anything in common, I've taken some key components from each game to mix together into one awesome and challenging game called "Hop to Who?!"

Frogger elements:

• The game objective of getting the frog safely across the road.
• Timing the moves to avoid getting hit by moving traffic.
• The frog character and the level design.

Guess Who elements:

• Eliminating all the characters displayed so only 1 remains, by the help of descriptive clues.
• Physical interaction of flipping down tiles.

The Story of "Hop to Who?!":

The Frog needs to cross the road to meet his blind date. As he crosses, the game will display clues about the characteristics of the blind date. The player needs to both get across the road and match the mystery date with the final remaining character tile.

How to play:

• The on-screen interface will display a frogger like level, there also will be a physical Guess Who style board with 10-16 character tiles shown face up.
• There are 2 objectives, both equally important. Get the frog across the road to safety and eliminate all but one of the characters correctly.
• To move forward the player has to flip down a character's tile. Additional controls will be provided to move left and right.
• The game will show clues about what the mystery character looks like, so the player can flip down non-matching tiles.
• The challenge is to flip the tiles down in sync with moving the frog to avoid collisions. This requires 2 mental processes to happen at once, strategic elimination and quick response.
• If the player gets the frog to safety, then there is the added reveal to check if they have selected the right character. Hopefully the Frog can live happily ever after!

For this prototype, I've focused mainly on the Frogger game elements - the interface, and the controls of the frog to cross. In place of the Guess Who tile board tiles, I'll be using the number keys on the keyboard and also the left and right arrow keys, for controlling the movement forward and sideways. The mystery character and clues element won't be added for this iteration.
The goals of this prototype will be to check if players understand the controls to move the frog forward, and understand that once a number key is pressed then it is disabled and cannot be used again to move the frog. I also want to check the difficulty of the game, whether the vehicles are too fast or too slow.

Week 7 contact: Reviewing the Video testing session

Revisit your user testing questions from the video prototype. Or consider the ones for your next testing round.

• Which are quantitative and which are qualitative?
• Do you fall into any of the traps outlined previously?
• How would you rephrase the questions?

Overall I was pretty happy with the wording of my questions and the nature of the feedback I received. I would only change some minor details and wording of some ratings values, to make it more descriptive and relatable for the tester. 

What was your first impression of the video?
This was a qualitative question. I felt it was useful in getting feedback on overall feelings and initial reactions to the video prototype.

Did you understand the concept? 
This was a quantitative question, but testers we're given the chance to add comments related to this question.

Did you understand the rules?
This was a quantitative question, but testers we're given the chance to add comments related to this question.

What parts didn't you understand?
This was a qualitative question and gave testers enough option to share their concerns.

How interested are you in playing this game? (Scale 1-5, 1: not at all, 5: Let me try it now!)
This was a quantitative question. This question was a little vague, but I think the values on the scale help give an indication of what the top and bottom ratings represent.

How unique do you think the game's physical interactions are? (Scale 1-5, 1:not unique at all, 5: very unique)
This was a quantitative question. I feel this question is probably not specific enough to what "unique" actually meant. The values on the scale could be more descriptive.

Do you have any suggestions to improve the game?
This was a qualitative question.

How would you rate the video and audio production quality? (Scale 1-5, 1: poor, 5: excellent)
This was a quantitative question. The values on the scale could have been a bit more descriptive.

In the testing stage, were my instructions clear? (Scale 1-5, 1: I didn't understand at all, 5: I understood the instructions clearly)
This was a quantitative question.

Did you have enough time to ask questions or add comments after watching? 
This was a quantitative question.

Do you have any other comments?
This was a qualitative question.

For the next testing session:

I need to really consider what I want to test and what kind of feedback I need from the next session.
My initial thoughts are to focus more on the understanding of controls of the game - will users understand that they the keys can only be pressed once, and only control forward and sideways movement. Also I'd like to check the difficulty level of the game. I may make the trucks move slower across the road for the first half of users, then speed them up a bit for the second part. I don't want to make the game too easy, but also want players to be able to win.

Week 6/7: CRC Cards and the making of IP1

In this week 6's session we created Class Responsibility and Collaboration (CRC) cards which really helped me to consider and plan out how to structure and build the code for the game.

For IP1 I'll probably only be focused on 2 main elements of the game: The frog and the vehicles.

Frog Class:

Attributes:

• X & Y Position
• Starting position
• Orientation
• Speed

Behaviours:

• Move forward, left & right

Collaborators:

• Vehicles (check for collisions)
• Safe zone (position when it's crossed the road)

Vehicle Class:

Attributes:

• Type of vehicle, ie truck, car, etc.
• X & Y position
• Speed
• Direction (left to right and vice versa)
• Colour

Behaviours:

• Moves in one continuous direction

Collaborators:

• The frog (check for collision)

For future prototypes, I've also considered:

• Character Class - each Guess Who character will need different attributes concerning their appearance, ie is it wearing a hat, what colour, glasses, facial hair etc. It will also need a status (ie is it the chosen one or not). The chosen characters attributes will also affect and inform the clues given on screen.
• Clues/Cluebox - this will display clues about the chosen character that players will have to guess. It needs to know which is the chosen character in order to give the appropriate clues to the player

CRC cards

In week 7, I have started working with the Actionscript 3 code. The Pong tutorial was really helpful in my game's code. Setting the location of the frog and truck objects and the movement and speed has been based on Peter's tutorials. I also followed this Adobe Masterclass webinar on making a Frogger game for some guidance (https://edex.adobe.com/resource/2c28f6fe2a/), although he built this using the Action panel and the timeline. Nevertheless it was useful in helping to consider the separate classes and objects I needed and how to structure some of the functions.

I decided to use the 0-9 number keys as the controls, since I'm not adding the Guess Who tile board interactions at this stage. These will control the forward movement of the frog, but can only be used once (as the tile flips can only happen once in Guess who).

Also instead of using the arrow keys for orientating the frog left and right, I decided these will just move it in a right or left direction which is I think is a lot easier to understand, and since there will only be a limited number of movement keys.

Other things to consider will be how to make the number controls only able to be used once and communicating this to the player visually. I'll also need a way to restart the game if the frog dies or if the player wins.

Starting the code the Frog class

Week 5: IP1

What is the key function or interaction for your concept?
Pressing given keys to control the forward movement of a frog crossing the road, and timing it to avoid moving objects.

How does it work?
Presses on randomly assigned keys will move the frog one step across the road.

What do you want to know about your prototype?
For users to understand that they can use different key presses to do the same action, i.e. move forward one space at a time. However each nominated key can only be pressed once only, once it's pressed it no longer performs any action.

How do you want IP1 to work?
The player will be placed in front of the computer, a quick tutorial will be shown to explain the rules. On screen the frog will be placed at the bottom with the goal placed at the top. In between will be moving objects which will need to be avoided. On screen, the key values that control the frog's forward movement will be displayed one at a time. The player must press these exact keys (in any order) to cross the road. However they can only press a key one time only, once that key is pressed it can no longer move the frog forward. The player must press the allocated keys to eventually get to the goal, and avoid the moving objects.

Video Prototype: Testing and Evaluation Results

In this weeks B Prac we ran our video prototype testing sessions. This blog post details my evaluation of this testing session.

Outcomes:

1. What you asked users to do:Watch the video (advised users they can stop, rewatch, replay video as they like), answer a few questions about the video, ask/answer if they had additional questions, complete a survey containing questions about the concept and the testing session.
2. What the users actually did:7 out of 8 users didn't replay the video, just watched it once through. Some resized the video to watch full screen. All answered my questions. Some had additional questions and feedback to add. All completed the survey correctly.
3. The measures you used:No qualitative measures were used in the testing session. Only observations and notes taken.
4. The feedback you sought:Feedback related to user's understanding of the game concept as communicated in the video prototype (gained from observation, Q & A session post-viewing). Feedback about video production quality, the game concept itself and testing session (from the survey).

Reflection:

Overall the video prototype was a great tool for communicating the concept for the game and it's rules without having to actually build anything yet. All users responded positively to the prototype, understanding the core concept of the game, and most understood the game's rules, interactions and mechanics. It was also good to get some feedback on how to improve the game at this early stage in design, which will make it a lot easier to implement when starting to build, rather than later down the track. 

Testing wise, I found my protocol adequate for what I wanted to achieve in the amount of time allocated. Towards the end of the session I wasn't as strict with asking the same scripted questions, I just asked the last 3 users if they had any questions or didn't understand anything. I felt this was good enough to get the same level of feedback in a shorter time. The lower scored responses to survey question 5 may have been due to the last minute testing towards the end of the session, where I didn't put as much effort in explaining the instructions, although all the participants I observed managed the watch the video, answer questions and completely the survey without any trouble.

Effectiveness:

I thought the video prototype was very effective in explaining the game concept. Overall users typically had a good grasp of the game's concept and rules after watching the video. 2 students who were not familiar with the Guess Who game had some trouble understanding those elements used in the game. The responses to questions 3 and 7 identify that more explanation about the guessing element of the game was necessary to help those understand how this translated into the mashup. Also explicitly showing or stating how the clues are to be delivered would make it clearer to viewers how this part of the game works.

Constraints:

Time constraints meant that I wasn't as thorough towards the end of the session in giving all the same instructions and asking the same questions as in the beginning. This may have resulted in collected less verbal feedback, but I think the result of this was pretty minimal, if any.


Implications:

The confusion of the guessing element and also crossing the road element at the same time has made me more aware that there may need to be more support in the game to train players how to play - maybe using a tutorial, or start playing at a really easy level, where the difficulty increases as time goes on. The next testing session will be quite different and more interactive, so I'll be more observant about their behaviour when interacting with the prototype than I was in this session.


RESULTS:

I had a total of 8 users watch my video and complete the survey. Overall the feedback was positive. After watching I asked a few informal questions directly:

1. What was your first impression of the video?
Comments included: "relaxing", "interesting", "good production", "clear", "good impression", "personal language used", "enjoyed the funny moments".

2/3. Did you understand the concept? Did you understand the rules?
6 out of 8 users responded positively, with no problem understanding. The remainder had some problems understanding the rules, especially concerning the Guess Who elements of the game. In these cases 2 of the users had very little background knowledge of this game, so therefore didn't understand how this translated into the game mashup.

4. What parts didn't you understand?
A user didn't quite understand how the clues were to be delivered in the game. Also here I had to explain the rules of Guess Who for the users who had never played this game, and describe how the Guess Who elements worked in Hop to Who.

After asking these questions, I then asked users to fill out an online survey which asked questions about the video production quality, the game concept itself and the testing process. The questions and results are as follows:

1. How interested are you in playing this game? (Scale 1-5, 1:not at all, 5: Let me try it now!)
4, 5, 4, 5, 5, 5, 4, 4 (Average 4.5)

2. How unique do you think the game's physical interactions are? (Scale 1-5, 1:not unique at all, 5: very unique)
5, 4, 5, 4, 5, 3, 5, 5 (Average 4.5)

3. Do you have any suggestions to improve the game?
"Might be difficult playing both games at the same time coz the frog game is all about timing, but I think it's gonna be pretty fun"

"personal quibble with games that involve love stories. is there another reason the frog would meet someone? other people probably wouldn't care about this."

"through the video, I thought one of results of this game is to find the heart of Mr. Frog. So, maybe for someone, they don't need finish the whole one round of game. I think it can set a condition that anytime picking up the heart from the puzzle, gamer can win in advance"

4. How would you rate the video and audio production quality? (Scale 1-5, 1: poor, 5: excellent)
5, 5, 5, 4, 4, 4, 5, 5 (Average 4.6)

5. In the testing stage, were my instructions clear? (Scale 1-5, 1: I didn't understand at all, 5: I understood the instructions clearly)
5, 5, 3, 5, 5, 5, 4, 3 (Average 4.4)

6. Did you have enough time to ask questions or add comments after watching? (Multiple choice)
No I didn't have enough time: 8
I was given some time, but would have liked more: 0
There was plenty of time to ask questions: 0

7. Do you have any other comments?
"Was a good video! Great idea and well explained"
"Might need to consider for those who have no common sense on either games you mashup including me. Tutorial may work well to me anyway."
"great video and interesting concept. was definitely emotionally invested to save the frog from a car tire - very visual but not alarming :)"

View a summary of the responses here: 
https://docs.google.com/forms/d/13DCUIHV2wHqeu_8hDvAC27Seg8d_jv9Kc-tp_w0o2-0/viewanalytics#start=publishanalytics

Week 4: Contact Session Exercises

In today's contact session we were presented with more about different types of prototypes:

• Low fidelity / High fidelity
• Exploratory / Experimental / Operational
• Horizontal / Vertical / Diagonal
• Global / Local

These all are different ways to clarify the various goals and scope a prototype has.

After the explanations of each of these types of prototypes, the class was tasked with 2 exercises:

Exercise #1 Car Concept 

What are the functional components?

Our group listed, in no particular order:

• Dashboard controls, speedometer, tachometer, indicator/wiper controls
• Keys, Seats, Steering Wheel, Pedals, Hand brake, gearstick, mirrors, seat belt
• Radio, AC controls, window controls, seat adjustment control
• Displays, controls for the the display, GPS

Replacing a functional component

Our group discussed a few ideas, such as replacing steering with a trackball, or even using brain waves. The concept we chose involved replacing a car's accelerator pedal with a control based on eye-tracking and monitoring driver concentration. When a driver is looking to the road, this enables the car to accelerate. When the driver takes their eyes off the road, for example if they become distracted by their phone or fall asleep, this prompts the car to slow down and even stop.

Uses facial recognition to analyse the driver's level of emotion/concentration, and this could controls the speed. 

Low-fidelity prototyping
Our group decided the purpose of the prototype would be to test the driver's tolerances of concentration and their current behaviours. For example how long would a driver look away from the road to check blind spots, or check for other traffic. A lo-fi prototype could be a video shown on a monitor place in front of the driver, when the driver looks away, the tester would take note of what they were doing and for how long. Another idea was a driving simulation game, where the user was in control of the steering, but the tester was in control of the speed. The tester would watch the user, and whenever their eyes went away from the screen, the tester would slow down the acceleration.
Another idea I had, which is not entirely lo-fi, but it could use a special car with brake/accelerator pedals on the passenger's side (like those used by driving instructors). The driver would only steer, and the tester would only be watching the driver's responses to inform the acceleration/braking. This would have to be done in a controlled environment though. This way it could be easier to test in other scenarios, such as different weather conditions or time of day.

Exercise #2 Smart phone alarm clock app

The last task for this session was to the design a horizontal, vertical and diagonal prototype each for an alarm app which:

• Can set, edit & delete multiple alarms
• Can daisy-chain alarms -if one is allowed to ring out, another is activated automatically
• Can set different tones for different alarms
• Shake phone to snooze

Horizontal prototype:
A horizontal prototype basically shows the wide range of features, but without any of the functional deep interactions. This prototype could be the home screen of the app, it would show the button for creating a new alarm and would list any existing alarms and their details below, with a link to edit and delete these. Of course there would be no functionality, it would only be used for showing the front end "dashboard" a user would see when they first open the app on their phone and the possible points for which they can possibly interact with.

Vertical prototype:
A vertical prototype is essentially the opposite of the horizontal version, where it only really concentrates on showing one feature, but delves deeper into it's interaction and functionality.
The alarm app vertical prototype will focus only on the functionality of daisy chaining alarms. The prototype will start the user at the home screen, the user will create a new alarm, then choose the "daisy chain" option. They then can create the first alarm, choosing it's settings. The user can then add another alarm choose it's settings again and again until they are satisfied. Once this is done, the daisy chain of alarms will be added. The user can then see this from the home screen and edit or delete it if they choose. All the other app functions would not be available to the user.

Diagonal Prototype:
This type of prototype is a mix of both horizontal and vertical, but doesn't have the complete functionality of the final app. It can be used to follow a particular task flow.
The prototype could expand on the home screen functionality, with the ability to explore different sections of the app, showing the user interactions with the various interactive buttons and other elements. The user will be given a task to complete, for example choosing a tone for the alarm. They can navigate through the different features of the app to find where they can complete this task, but the functionality would not work for all of these, only the settings to change the alarm tone.

Final Video Prototype: Hop to Who?!

I managed to finish my video over the weekend, hooray! I shot most of it Saturday and spent that night editing. I had one last shot to film which I didn't originally plan on, so I had to shoot it and insert into the final video on Sunday morning.

Overall the whole process went really well. Planning out the script and storyboard, shot by shot, helped greatly. Combining different location shots also helped streamline the whole shooting schedule.

I decided to use a Frog toy to represent the Frog character (suggested by Peter). And illustrated the game's story and objectives using real world environments and objects rather than rely on animations. I filmed on a busy main road and also on the street outside my house for the outside locations. Everything else happened in my living room. For the shots of me explaining the game, I was able to use the chalkboard wall in my living room and illustrate some (fake) concept drawings to make an interesting backdrop.

I fortunately had the help of my partner and dog in some shots, as both actors and camera person.

Professional cameraman and teleprompter. Using a makeshift tripod.

Instead of Photoshop, I wanted to try out Premiere since I could download it for free with my Adobe CC subscription. Photoshop was fine for basic editing, but I found the timeline part a bit strange when I was trying to move and trim clips and audio. Premiere gave me a lot more controls over this. While there was a few things I needed to lookup on Google, basic video editing controls were pretty easy to learn since I've done a little editing previously, so I managed to get through this stage in a couple of hours. I also overlaid some basic illustrations made in Illustrator to help visually explain the story. Initially I wanted these to be animated, but for efficiency's sake I decided against this seeing as I'm not at all familiar with creating animations.

All in all, I'm pretty happy how it all turned out. I think I explained the concept of the game fairly clearly. Production-wise is also pretty good. The video was OK and the audio was clear enough. Some of the shots I probably should have used some kind of stabiliser so the video wasn't so wobbly. But since I was using my iPhone it was a little awkward to frame the shot without having the phone hand-held. The audio went well, there was a bit of a disparity between the audio from where I was on screen and the voice over audio I recorded separately, but luckily the music masked the difference in background noise.


Sources for Music and Video:

Music:

Ice Cream Sandwich, by Podington Bear
https://freemusicarchive.org/music/Podington_Bear/

Game Footage:

Frogger Video from Steverd99
Frogger developed by Konami, 1981
https://www.youtube.com/watch?v=l9fO-YuWPSk

Guess Who Video from Project Ad Hand
Commercial from 1992 for the game Guess Who? from Milton Bradley
https://www.youtube.com/watch?v=7XjW43YUgUA

Week 3: Video Planning and Storyboarding

With my script written, storyboard and shots planned. The last thing I need to do is get a couple of props made, and I'm ready to shoot this weekend. 

Since I added a storyline to my game, it's made planning the video prototype a lot easier and a lot fun too. I'm excited to film and edit and may even add some animations in if I have time). I'm hoping to shoot it all tomorrow morning, and *hopefully* do most of the editing tomorrow, maybe even get it done in a day. 

Storyboard:

Listing out my shots, props and locations

Concept to Prototype: Frogger X Guess Who

The concept I'm running with for now is a mashup of the classic games Frogger and Guess Who. While these games don't really have anything in common, I've taken some key components from each game to mix together into one awesome and challenging game, working title "Hop to Who?!"


Frogger elements:

• The game objective of getting the frog safely across the road.
• Timing the moves to avoid getting hit by moving objects such as traffic.
• The frog character and the level design.

Guess Who elements:

• Eliminating all the characters displayed so only 1 remains, by the help of descriptive clues.
• Physical interaction of flipping down tiles.

The Story of "Hop to Who?!":

The Frog is a lonely amphibian looking for love. He'll go to any length to find "The One" so he's risking it all by traversing across the dangerous highway all for a blind date. It's your mission to get him to his correct date safely. Make an ill-timed move and it's all over for him. Choose the wrong character and he'll leave broken hearted. 

How to play:

• The on-screen interface will display a frogger like level, there also will be a physical Guess Who style board with 16 character tiles shown face up.
• There are 2 objectives, both equally important. Get the frog across the road to safety and eliminate all but one of the characters correctly.
• To move forward the player has to flip down a character's tile
• The computer will show clues about what the mystery character looks like, so the player can flip down irrelevant tiles.
• The challenge is to flip the tiles down in sync with moving the frog to avoid collisions. This requires 2 mental processes to happen at once, strategic elimination and quick response.
• If the player gets the frog to safety, then there is the added reveal to check if they have selected the right character. Hopefully Frog can live happily ever after!

To Do Next:

Start planning the video prototype, writing the script, storyboard so I can shoot and edit this weekend. I also need to write the Statement of Delivery and a Testing/Evaluation plan. The next blog will be about the video prototyping process.

Week 3: Video Critiques

During this week's lecture we watched a few more examples of video prototypes, all with varying degrees of good and not so good points. Watching and discussing these videos definitely helped to break down what works and what is less successful in a video, and hopefully I can take away the good examples and apply this to my own video.


Brisbane Park Finder

First impression
Definitely not a compelling video, the communication of the concept wasn't clear, and the production quality fairly poor.

Can you understand the concept?
By the end of the video I did understand the concept, however I don't think it was completely clear from the beginning.

What questions does it raise?
They never really addressed what the problem was, and how their product solved anything and if there is a need for this product. They didn't show the product in use much at all, so I was left wondering if they successfully built the features they described.

What could they do better?
Show the product more and scenarios of it being used. There was a super quick shot of it being used, but the rest of the video only showed the guy describing how it worked, not showing it in use. Improving the audio, there was a bit of background noise.

What do they do well?
What they showed of the Park Finder looked good.

Is there a better way to show certain things?
Showing the demonstration of the Park Finder would have been better if the audio description matched the voice over. He mentioned an example of searching in Greenslopes, however the demo showed a different suburb, which I found distracting, and therefore detracted from what he was trying to communicate.

Quality of the video/audio
The video quality seemed fine. The audio had a lot of obvious background noise.



Google Docs in Plain English

First impression
Overall I found this quite easy to follow and rated it as an example of a good video.

Can you understand the concept?
Yes it was communicated very clearly. It uses appropriate language, and uses metaphors to help the audience understand more abstract concepts, e.g Docs is a "home" for our documents. The visuals supplement the description well and further illustrate their message.

What questions does it raise?
I think it's pretty well explained.

What could they do better?
Some of the production quality was quite lo-fi, but this may have been their intention. The voiceover and pacing was a little too fast and possibly could have been slowed down a bit to help viewers take the information in.

What do they do well?
They defined a problem at the beginning the of video and told the story of a user scenario which illustrated their solution.

Is there a better way to show certain things?
They didn't show the use of an actual Google document directly, with only explaining the features of Google Docs.

Quality of the video/audioIt was well produced, and the audio was clear.


Pegasus Game

First impressionConfusion about what this game is actually about

Can you understand the concept? No at all - only that it is some kind of board game - possibly?

What questions does it raise? 

What is this game about? What are the rules? Why should I play this?

What could they do better? 

Give some explanation about what the game is about, why it should be played, how is it played. The soundtrack wasn't really appropriate, especially considering it was the only audio track it felt unnecessary and distracting.

What do they do well? The footage of the game play looks of a high quality.

Is there a better way to show certain things? The gameplay needed description, showing various moves made in the game means nothing to the audience if they don't know the objectives of the game. This could be a voiceover, or text descriptions throughout.

Quality of the video/audio 

Production wise the quality was fine.



Gauss Glasses

First impression

Pretty good overall, perhaps too long in describing the science behind it.

Can you understand the concept? 

Yes, it was explained well, the problem and solution was clearly defined.

What questions does it raise?

I wasn't sure how these glasses rate against regular glasses. Also I was wondering how accurate the dangers of the blue light is, and how these glasses rate in protecting against it (maybe that's my inner sceptic thinking). Although the way they explained the problem of blue light did make me feel concerned, albeit quite alarmed when they showed the light burning the back of the eyes.

What could they do better?

Some of the animation, such as the moving graph of the light radiation I didn't understand, it looked very scientific, but I didn't know what the significance of the data was, so this could have been illustrates better. Also including some feedback from professionals like optometrists to help give quality assurance and professional back up to their claims.

What do they do well?

They definitely sold their product and it's benefits well, and compelled me to consider buying the glasses. They showed great video of the people behind the manufacture, so that assured me that they were going to be made well.

Is there a better way to show certain things? 

Some of the animation could have been done in a more refined manner (for example the burning eye animation) and the graphs could have been shown in a more approachable way.

Quality of the video/audio 

It was really well done and professionally produced.

Overall takeaways:

• A good video should introduce the problem space at the start, and subsequently offer a solution to this problem. 

• Relate the solution back to the audience, tell them why this product benefits them. 

• Communicate clearly, so that the whole audience can understand (i.e. don't use technical jargon if your audience are laymen) 

• Use scenarios to show the context of use and explain how the product works 

• Visuals should support the audio descriptions. 

• Inferior production quality can detract from the video's message and professionalism.