Coding the Final Prototype

Because there wasn't much difference in the code between the last two physical prototypes I spent a lot of practical time improving the code and making it more versatile.

I set the number of dots per column (dpc) and the number of dots per row (dpr) as variables.

This meant I could have the system work out how many mines there should be ( INT(dpc * dpr / 0.15)).  So the more dots the more mines.

The system also then had to be able to cope with working out which dots were on the edge of the mat for itself, so I put in a new variable in the twisterDot class and had the main class work out the location on the mat before it created the dot.

I also made it so that if the board had less than 4 columns the system would only use the number of colours are there were the number of columns.  So, if there are only 3 columns  only three colours are used.  There are only four colours total though, so if there are more than 4 columns, it still sticks to four colours.

I felt that these changes, while not changing anything in the tests allowed for more versatility in the long term and meant that the game variables could more easily be changed, if I so chose.

Audio Cues

In my second iteration of the concept I worked on creating a system to differentiate between mines square and mines diagonally to the dot pressed.

This idea works really well in the visual interface.  It was easy to see which dots were being referred to.  I really like this system too because it added a level of strategy and thought to the game, allowing for more thoughtful play.

But when using an audio interface as I did in the final iteration, I couldn't come up with a nice simple audio cue that wouldn't take a while to learn.  I wanted people to be able to start playing right away with minimal instructions - this game is meant to be a party game and if people have to keep stopping to explain the rules or argue over what a sound meant, then it's going to detract from the game.

I considered putting in a single word audio output like "square" or "diagonal" but it just didn't feel right.  I liked the beeps and the words would still need explanation and I think people would just end up saying "What?" a lot if I followed that path.  Because of this I elected not to use the diagonal and square mine detection in the final version of the game.

P.S.  I also didn't use it in the makey-makey version, but that's because I had such a small mat.

Prototype III Construction

I thought that the easiest way to show how I made the final prototype would be to do a video.  There are a few gaps where I got caught up in building the prototype and forgot to film my working, but it generally shows what I got up to.

There's no sound, so please play your favourite song in the background. 

Maximising the Makey Makey

For the makey-makey prototype I wanted to have a large-ish grid of dots.  But the makey-makey only has a set number of inputs.  This limited me to only 3x3.

I had the idea - and I discussed it with Callum during the tutorials - of having two inputs linked to a button.  This would mean you could have a grid of pairs which would be quite large compared to just one input linked to a button.

I quickly got the code for this working, but then I reasoned if you are playing twister you're holding the button down.  There would be no way for the computer to work out which button you press if you are still holding down the first button.

Example to illustrate:

Button 1:  A, B
Button 2:  A, C
Button 3:  B, C

If you are holding down button 1, the computer is receiving ABABABABABABAB as input.  When you press another button, the system has no way of telling if you are pressing BC or AC as the input is just a garbled mess of ABCBABCBBACBABCBBCBABCABCB.

This is a bother, because I was really happy with the code I'd written.

Interactive Prototype 3

The Prototype

I created a 6x6 grid of buttons on the floor with coloured dots over the buttons.  The interface now has audio embedded into it, so that theoretically you don't have to look at the screen at all. 

The Questions

1.      On a scale of 1 to 5 rate the following game features:

a.       The visual interface.

b.      The audio interface.

c.       The positioning of the dots on the mat.

d.      The usability of the physical interface.

e.       The timing of the audio instructions.

2.      What do you think is the best feature of this interface?

3.      What do you think is the worst feature of this interface?

4.      What would you change?

The Feedback

People liked the audio, the guys who tested the game especially liked the sound of the explosion.  

People generally thought that the seeming randomness of the dots was interesting, some liking it and some not - it was felt that people spent a lot of time searching for the next colour.

There was a bug in the code, where if you pressed the next button too quickly the computer would get stuck in a loop and just keep calling out colours.  People felt that this was part of the game and that they enjoyed the rush to keep up - they felt it was a fun challenge.  There was a fair bit of laughter from players as they tried to keep up with the computer.  

My Reflection

I found people do not rate from 1 to 5 when asked.  People answered those questions with sentences and explanations - which I found so much better than the number system would have been.  I'd used the numbers because I wanted to try a different style of question to previous times, but I think I like this kind of feedback better. 

I was interested to see how people took the bug to be part of the game and remember back to previous testing when people talked about different game modes.  This is something I would explore if I continued with this project. 

Interactive Prototype 2

The Prototype

This prototype was a version of the game which had a 3x3 grid interface of "buttons" hooked upt he the Makey-Makey.  The interface has a colour picker and a mine alert system.  The grid being so small I wasn't able to include the directional mine detection from the last prototype.

The Questions

• Was having the monitor create a visual display useful?
• Is there another method you’d prefer?
• If an auditory element was added should it be as will as or instead of the visual interface?
• If you could add one feature to this game, what would it be?
• Do you think the physical interface works? Why/why not?
• How would you, using audio output or a single visual object, differentiate between a mine directly next to and a mine diagonally next to an activated dot?

The Feedback

People found that the buttons worked well but the use of the buttons with the interface didn't work as well as expected.  People found the interface small and hard to see.  Additionally they found that the colours were flashing up on the mine alert far too quickly for them to look up and see them.  

I found that people were ignoring the colour instructions and just pressing whichever button they liked and just searching for the mines. 

People did indicate that this board was too small but they could see why it was so. 

My Reflection

I was really disappointed with how small the prototype was - but I was limited by the makey-makey.  I want to find a way to make the game much bigger for the next round of testing. 

I had expected that the questions were biased to make people suggest that having an auditory output would be a good idea, but mostly people just said that the screen was too small.  I guess you can't expect testers to be creative.  

Interactive Prototype 1 - Refleciton and Review

The Prototype

The prototype I created for this test was a simple keyboard version of the game.  I wanted to test the mine detection system which the first lot of testing had revealed to be a concern.  I created two versions.  

Version 1 detected when a mine was in the eight squares surrounding the one pressed.  

Version 2 differentiated between mines in the straight out dots and those in the diagonally adjacent dots.  

The Questions

1. How easy did you find avoiding the mines in version 1?
1. Very easy, easy, meh, hard, very hard.
2. How easy did you find avoiding the mines in version 2?
1. Very easy, easy, meh, hard, very hard.
3. If you were playing the full game how useful do you think having the mine detection system from version 1 would be?
1. Very useful                Useful             Meh                 Unhelpful       Completely useless
4. If you were playing the full game how useful do you think having the mine detection system from version 2 would be?
1. Very useful                Useful             Meh                 Unhelpful       Completely useless
5. What features of version 1 did you like?
6. What features of version 2 did you like?
7. What features of version 1 didn't you like?
8. What features of version 2 didn't you like?
9. Which version did you prefer?
10. What one thing would you change about version 1 to make it better?
11. What one thing would you change about version 2 to make it better?
12. Any other comments?

For this testing session I switched back and forth between start with version 1 and then 2 to try and remove that bias from the testing.  

The Feedback

People had far more mixed responses than I'd thought.  I'd expected people to prefer version 2, but while there was a preference for version 2 a couple of people actually liked version 1 better. 

I think overall the second version wins, the best feedback I got to articulate why was:  Liked version 2 because of the higher level of logic, felt that had better change of finding the mines so was more willing to explore to find the mines.  In the first one felt much more chance/random luck and thus was unwilling to explore and move about. 

My Thoughts About the Questions and Stuff

I felt that the first 9 questions were helpful, the last three not so much.  I found the comment questions more helpful as they gave me whys, while the first 4 where kind of a mixed bag.  Some people also put down that they found one version harder than they other but then said they would find it more useful, so I'm not sure that the questions were as clear as the could have been. 

Video Prototype Feedback

People liked the video and felt that it explained the concept well, they did ask how the colours were determined and what system there was for letting the players know - which I'd forgotten to put in the video.  I explained this after the viewing when asked and people seemed satisfied with the response.

People indicated that they thought the social aspects of the game would be a lot of fun and they thought that people would have fun playing it at parties.

People did raise the question of different play modes - having a team game for example or maybe a challenge mode where you have to stay on the board without repeating dots - and wondered if there was a winner or if it was just a social game.  In response to this, I think that there is a winner - the last person standing.  I like that the winning isn't a big deal because you get to replay so easily and quickly.  You can take turns with friends if you have a big party and it's all just very causal and social.

Some people felt that having the mines blow up felt very random, and even though there is a slight mine detection system in that if you are next to the mine it alerts you, the game might benefit with more strategy.  I have to agree with this point as when I was playing the version of the game in the video (finger MineTwister) I found the mine alert system next to useless (and I don't think it was just because my bother would take about 10 seconds to work out if I was on a mine or not).

This strategy component will definitely be something I look at going forward.

Revisiting the Definition of a Prototype

A prototype is something which is used to test an idea, a way to get feedback.  It's a really broad and inclusive thing, that basically can be anything from a conversation with a friend where you explain your idea and ask them what you think, to a fully-size fully-functional mock up of what you want.

At it's best I think a prototype is easily changeable.  Something you can create quickly, and change quickly and can leave behind if it doesn't work.

The Theremin

Playing the Theremin is not an easy thing, it takes a lot of trial and error to work out where the hands need to go to produce the right sound.  This exercise is looking for a way to help people learn the Theremin, to help them know where to put their hands to produce the right notes and tell them when they are right.

Option 1: Visible lasers.
Using visible lasers which will help guide the player to where to put their hands.  Downside is that you could end up with a lot of lasers beaming about the device.

Option 2: A distance measuring device.
A distance measuring device which displays the results on a screen.  It would tell you what numbers you need to get from the X, Y, and Z axis and what you actually have.

Option 3:  A brace over the arm/shoulder.
A brace over the arm or shoulder which detects the hand and/or arm positions and provides physical feedback on where the player needs to move to be correct.  Downside could be if the device provides too much resistance and people get hurt - but I'm sure those bugs could be worked out in testing.

Option 4:  Air Cannon
An air cannon that blows air where you need to put your hand.  A similar idea to the visible lasers but perhaps harder for the hand to detect, the stream would likely have to be very small and once you are trying to detect the air from three directions, it might become hard to be accurate.

Option 5:  Colour
A similar set up to option 2, but the screen displays a colour, the closer you are the greener it gets, when you are far away it's red.

Option 6: Bubbles
Have a video camera in front and to the side with a screen to watch.  On the screen is a bubble where you need to move your hand to.  Get your hand to the virtual bubble and it pops, the next one appearing.

CRC Cards