Week 13: Planning the Next Prototype

Time to think through the logic of the last prototype for the course in detail, as I have several days to get it done.

So - I'll be testing Social Interactions and assume that 2 people will have fun playing the game and will find their way around as a group. 

Hypothesis 1: 

• 2 people (or kids) playing the game will find a way to self-organize to get the correct answers to the questions asked 

Pass/Fail: Most people got their questions right. When they didn't get their questions - they were just fooling around intentionally.

Hypothesis 2: 

• In pairs people will enjoy the game more than if they were to play alone. 

Pass/Fail: Will be tested through self-reporting in the form of close-ended question. If users report that they enjoyed the game more when playing together - this would mean that the hypothesis is right. Optionally - I could do 2 rounds of testing - 1. test as 2 people then 2. test with the same testers as 1 person - and then do self-reporting.

Fixes from the last prototype: 

- record voiceover under the coat :) 

- make numbers bigger in size 

Game logic changes: 

The main issue is to find an event that would indicate that the answer is correct, since 2 numbers have to be pushed. 

How I could do that: 

Assume the question is how much is 11 + 4 and the correct answer is 15.

- Wait for 1 person to stand on 1... 

- Wait for 2nd person to stand on 5... 

If a person stands on 1 - and then on 5 - the answer is correct or stands on 5 - then on 1 - the answer is correct.
If a person stands on a wrong answer - "Zero" it, say - wrong answer.

+ I need to change the questions I ask so that I end up with 2-digit responses. 

A problem that 2 people cannot stand on 2 numbers simultaneously. This is a limitation that I cannot find a way around. So, I guess I'll have to explain this to people in the form of instructions.

That's about it.

Thinking About The Next Prototype

Time to start thinking about the last prototype.
So, the instructions are as follows:

Final Prototype: 
1. Refer or redesign the original prototype
2. Dark horse - do something that seems impossible
3. Add new features: test something not tested yet

Prototyping Process: 
- go through evaluation/testing sessions
- take some ideas from it
- SoD (decisions made)

As I brainstormed the different options for the prototype - I decided to stick to Option 3 - adding new features and test something that is not tested yet.

So, what I am planning to do is - make my game MathsFun social, make it work for 2 players. How I think it should work: 2 people could step on different numbers for the solution (for number 10 - one would step on 0 and another one would step on 1).

I'd focus on "social" part of it for testing.

In order to make it work, I'd need: 
- change problems that result in solutions with at least 2 numbers (so, from 10 and above)
- the physical component of the game doesn't require much changes, it can stay pretty much the same (but rebuilt again).

Looks buildable and feasible to me :) And also fun when doing the testing :)) I'll need 2 testers at a time. 

Week 11: In-Class Exercise - 3D Movements for Theremin

This week we received quite challenging tasks. At least for music illiterate people, since I don't play any musical instruments :)

So, our first task is: 

1. Generate concepts for consistently reproducing and generating 3D movement in space that allows for the musical composition to be accurately played on Theremin.

So, the regular notes look like this:

Source: Wikimedia

Theremin operating principles according to Wikipedia are as follows:

The theremin is distinguished among musical instruments in that it is played without physical contact. 

1. The thereminist stands in front of the instrument and moves his or her hands in the proximity of two metal antennas. 
2. The distance from one antenna determines frequency (pitch), and the distance from the other controls amplitude (volume). 
3. Higher notes are played by moving the hand closer to the pitch antenna. Louder notes are played by moving the hand away from the volume antenna. 

So, in order to come up with instructions on how to play a certain composition on Theremin - we basically need to translate the regular notes to 3D signs/gestures people would use when playing a composition on Theremin. 

Here come the concept ideas: 

1. Translate each regular note into gesture language on Theremin and come up with a gesture for each note

2. Translate each regular note into gesture language on Theremin + play with one hand

3. Translate each regular note into gesture language on Theremin + play with 2 hands and a head :) 

The second part of a task is to come up with a Pugh Metrix to compare concepts against each other.

So, here are the criteria I believe are essential when it comes to playing musical compositions on Theremin. 

1. Learnability 

The shorter is the learning curve - the better 

2. Fun in the process 

The more people have fun when playing the instrument - the better it is. 

3. Complexity 

How complex the system is - whether a lot of things are required for initial use

4. Number of mistakes people make when playing

The fewer mistakes people make when playing an instrument - the better it is. 

5. Implementation cost

The cheaper the system is - the better. 

Interactive Prototype 3: Testing Session Results

We did a testing session this week - it was a lot of fun. I really enjoyed testing my prototype even though it wouldn't always work as intended and sometimes would go crazy :) Mainly because Makey-Makey inputs were sensitive - so when a user stood too long on one input - my ActionScript would count that as a wrong answer. 

Overall the feedback was great: 

1. It's pretty fun, I like the idea that I need to balance at the same time as completing each math problem. My only issue is that sometimes the problems and answers don't link up e.g. when the sum total is equal to 8, 9 would work.

2. It looks amazing that i cannot wait to play the final concept. only glitch i have so far is the incorrect answers(response?) and also the touch sensibility may need to adjust.

3. It is funny. I believe that it not only bring lots of fun for children, but also can help children do the basic math question. like addition, subtraction. If the circle can flashing, it will be more appealing.

4. It is fun to play for kids as the touch points are decorated in colored and shiny papers. You may want to add a background music behind the game:) overall the game is super great I think!

The prototype was tested by 5 people. 

User 1

User 2

User 3

User 4

User 5

Here is the fully completed survey:

Now back to the hypothesis I was intending to test: 

#1 Hypothesis to Test:

Kids play at least 3+ game sets (maths questions of 10).

How much time kids spend playing the game is a direct indicator of game quality. If users "stick" to the game and return to play it later - the game is successful and user experience is engaging. Since the prototype is close to the final version of the game - this is the crucial hypothesis to be tested that makes or breaks the game.

I'd say that the hypothesis is validated, user were willing to play longer and they did enjoy the game.

#2 Observations: 

This time I'll be observing users to test: size of numbers, size of circles, quality of voice over to notice any design issues that need fixing. Since the prototype is "high fidelity" - it's not the time to pay attention to design details. To collect this data - I'll be using Google Survey with open questions and just regular observations and making notes.

As a result of observing users test the game and their feedback, here is a list of changes that can be made to improve game experience:

• add music to the background
• make numbers bigger in size
• randomize numbers
• think and come up with a solution: how to make touchpoints less responsive (I mean so that if a user stands on the same button for a bit longer - ActionScript doesn't accept it as a wrong answer - and therefore the voiceover doesn't get confusing)

Other ideas to be considered: 

• make the game social - and test it on several users - so that people self-organize to get answers right 
• come up with a logic that adjusts fast to current user complexity level