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.