Feedback: Interactive Prototype #3

The addition to my Tic-Pac-Toe game (which you can read about here) was tested late last week by a bunch of DECO2300 students. The following is the results from those tests.

As per my Statement of Delivery, I tested the participants according to the following procedure:

1. I will get players to face off against each other using the computer keyboard. The players will play the previous iteration of Tic-Pac-Toe
2. While they are playing I will use a simple decibel meter to determine the amount of fun they are having while playing the game. This seems like a good measure of fun.
3. After 3 games of the previous prototype, I will then repeat the process with the new prototype. This will allow a  direct comparison and more accurately show how the players respond to the new feature.
4. Upon completion of all 6 games, I will conduct a short survey to provide more details
1. Which version of the game did you prefer?
2. Why that version?
3. Do you think the new feature could be improved upon?
4. Did you find the new feature easy to understand?

The overall results were less than positive but were helpful which was of course the ultimate goal.

Decibel: There was no significant difference of decibel level between the two varieties of the game. 

1. 100% of all participants said they preferred the version without the new feature.

2. When asked why they preferred the old version, they said that the new version was too difficult to play. Especially when the game pauses at a turn. You have to hit the correct key sequence but then the player won't turn at the moment when you want them to turn.

3. 50% of participants said that it could potentially be improved if the player was able to turn correctly at the correct spot. The other half were adamant it should simply be removed.

4. Yes, all participants understood what they had to do.

As you can see the results were not flattering for the new feature, but after all that was the point of this prototype. Based on feedback, if I had to continue this project I would likely remove the feature from the game. I cannot think of a good way to get around the players not turning at the correct spot.

Interactive Prototype #3

For this final prototype I wanted to try to make the game a little bit more dynamic. I felt I needed to add something that would make the game more interesting. Also due to the multiplayer aspect of the game, I wanted to make it more enjoyable (more competitive) and really get the users engaged with the game. So for this I tried a feature I wasn't entirely sure was going to work, but one that I felt was worth a shot.

The new feature builds upon the existing Tic-Pac-Toe game and essentially means that after a player captures a square on the board, the player's pacman stops moving forward until the player completes a minigame. All this takes place while the other player can continue to move around the board (until they capture a square). The mini game works as a sequence of key hits. So everytime a player captures a square, a sequence of 5 random keys are chosen from the player's movement keys (A,S,D;J,K,L). So this new feature works like the following:
1. Player captures a square.
2. Player's pacman stops moving
3. The player's first key hit appears on the right hand side of the screen.
4. The player must hit the correct key to move forward through the sequence of 5.
5. If a player mishits a key in the sequence, the sequence restarts.
6. Only when a player completes the sequence without a mishit will their Pacman's movement unlock.

I feel this system of gameplay might improve the multiplayer interactions and make the game more likely to go either way. Skill becomes so much more a part of it and I think that's really important.

I've tried to keep the other dynamics of the game the same, based on the feedback from previous prototypes. It'll be interesting the see the feedback for this idea especially compared to the old system.

Interactive Prototype 2 Testing

As I was unable to go to the testing practical, I filmed the setup and testing of my prototype. These videos show the setup with 4 hand pads.

Interactive Prototype #2

This prototype has been designed as an extension of my original Interactive Prototype. This new prototype builds on the original game and adds a new method of controlling the Pacmen. When designing the controller I tried to think of something fun but also functional. I also knew I wanted it to be simple, as anything too complex would simply be too difficult to use. My original design was supposed to include pads for your feet. These would be used to propel the player forward. After building an early prototype of this though, I quickly realised that this was not going to work well. I found that when running on the spot really fast it was not unusual to have at least one foot on the ground at all times. Since the game was predicated on the necessity of alternating steps, this simply couldn't work.

After the failure of this setup, I thought about changing the foot setup to something like bicycle pedals, but couldn't think of a sturdy way to try this out. In the end I opted to remove the foot propulsion system entirely and I think it's made the game a lot more playable. Now the players are propelled forward by a fast timer and they merely have to control the turns. I was at first worried that it would make the game too easy to play. After several minutes of playing though it became clear that would not be the case. Because the players are moving quickly and there is only a very narrow window to turn left or right, timing is everything and it's very easy to get wrong, thus slowing you down.

In the end, I'm actually really glad the foot propulsion system didn't work out because the final design works really well and makes the game a lot more fun. Strategy becomes more important and because it's a multiplayer game, the game gets pretty intense. It's a good thing the setup can take a beating because it certainly cops some abuse when players miss a turn haha!

Interactive Controllers

I borrowed the Makey Makey a few days ago and since then I've had a lot of fun playing around with it. The first thing I did was hook up a bunch of bananas to my computer and played super mario. I got some of my friends playing it and they were hooked. The thing that most startled me was the responsiveness of the system. I thought that touching bananas would cause some sort of lag but it's practically instantaneous. It certainly opens up a whole new world of possibilities in terms of the kinds of high speed games that could be controlled with the makey makey.

I'm currently building some game pads to be used with my game and am looking forward to putting them in action. The idea is to have players run on the game pad to run forward. This should be interesting and I'm hoping it will be exciting. I'll make sure I film the prototyping of the game so that you can see how people will play the game. When I get something workable I will test with a bunch of alpha testers to see how they respond to the game controller as a way of controlling the game.

Week 7 - Questioning Feedback

Since developing the interactive prototype and getting the feedback, we have had our week 7 contact in which we discussed how to ask the right questions when getting feedback. Two important factors we looked at was considering which questions were the right questions and what is the proper way to ask them.

Asking the right questions
When it comes to asking the right questions, the thing that was really hit home was to make it measurable. What do I mean by that? I mean that you should ask questions that allow the responder to answer in a way that creates a measurable response. This allows for a quantitative summary rather than a subjective qualitative response. For e.g. 70% of students prefer option A over option B. That's not saying that getting qualitative feedback isn't helpful, because it is. It just helps to be able to say that a certain percentage of users preferred certain options over others. Once it's established which is better, it's then ideal to go back and see why that conclusion was met.

We went on to talk about different approaches to asking the questions, involving things like removing bias (or adjusting for it rather), and measuring the difference of opinions quantitatively. The example given is just presenting a simple scale from 1 to 5 and allowing the users to mark their opinions on this scale rather than just a boolean yes/no.

How to ask the questions
It's important when asking the questions to ensure that the responses are as accurate as possible. In order to achieve this we should make sure that we don't ask leading questions. This just makes sense but it's an easy thing to do if you are not being careful in question design. Additionally it's important to allow the user to make their own statement. If interviewing them it's always best not to interrupt when they are speaking or even when they're not as it might prompt them to further explain. This is a very important part of asking questions.

Attitude is also very important. It's crucial to avoid condescending or rough language which might put off the interviewee. Being polite but assertive is a good method to ensuring the optimal amount of cooperation from the user.

Interactive Prototype 1 Feedback

Unfortunately I was unable to attend the B practical of week 7 so I organised some students to help me out in a bit of free time. I gathered a group of 5 students with a variety of backgrounds and degrees so as to get as diverse a feedback I possibly could. What follows is a summary of their responses to my follow-up interview questions.

Which version of the game did you like best and why?
All those interviewed said that they preferred the game variant which required a pacman to capture a minimum of 2 sides in order to capture the square. It was unanimous in that they all said it was due to the fact that the games went on a bit longer. Only requiring 1 side was essentially too quick and didn't leave enough game time. I found this unsurprising as I had come to the same conclusion by myself but I wanted to make sure that it was a general consensus. It will however be interesting to see how everyone feels once the controller becomes more physical. We'll see if they want the games going longer then haha.

When it came to starting positions though they were a bit torn. None of them really liked position 1 due to the players starting too far apart. It made each player's run too easy (especially with 1-capture). When it came to the other 2 positions though they didn't really know which to choose from. 3/5 said they probably preferred the more central one but couldn't really describe why they thought it was better than the other one. The one thing they all did agree on though was the fact that players should definitely start very close to each other as it really opened up the game a lot more. They all agreed that this made the game more exciting. This surprised me. I thought that the players starting further apart would be better. It seems I was wrong.

What did you like about the game concepts?
Everyone said that they liked the idea of 'capturing' squares. One person said "It's a fresh take on something that everyone knows" which is great, but that's just about the only real piece of useful feedback I was able to get from this question. They didn't mention the way players move or anything else which leads me directly to the next question.

What didn't you like about the game concepts?
Here I got some pretty brutal but pretty useful feedback. No-one really liked the way players were controlled on the keyboard. They didn't really mind having to tap the key to move forward (although they said they would prefer not having to do that), but the thing they really didn't like was having to change direction by 'turning left ' or 'turning right'. They found it confusing because if you're heading down and want to start going right across the screen, you have to turn left.

I originally designed the controls with a physical controller in mind. So that when you're running there would be fewer pads necessary. Even when I asked them to consider the practicalities of a more physical 'floor-pad' style controller they were still unsure if it would be ideal. The problem, as they said, would still be there. So I daresay I'll have to rework the next prototype for a simpler controller.

What would you add to make the game better?
This question made it far more interesting. I got many different suggestions. Mostly related to the original Pacman game, like having ghosts that could chase you around and force you to change your route. The four people who suggested that idea said it would make the game more interesting. One of the four went even further by suggesting making the game more like mario kart. Allowing players to fire missiles/special items around that have a negative effect on the other player. I thought that idea was pretty interesting and would really like to have a go at implementing that. I actually went back and asked the other 4 people what they thought of the Mario Kart style idea. They loved it. Basically said Mario Kart is such an exciting game because other players can affect you. So I think this is something I will definitely have to look at doing this.

Interactive Prototype #1

For my first interactive prototype I've decided to implement a bare-bones version of my game Tic-Pac-Toe that I initially prototyped with my video. The basics of the game are described below.

- The game is a cross between noughts and crosses and pacman.
- Each player controls a pacman
- Each pacman can only move over the lines of the game board.
- Once a pacman has traversed the enitre length of the side of one square, that player 'captures' that side of the squar.
- Depending on the prototype, a player will be required to capture either 1 or 2 sides of a square to capture the square.
- Once a player has captured a square, it gets marked with the 'X' or 'O' that is associated with that player.
- Squares can be taken from another player, if the other player takes a majority of the sides of that square.
- Victory is decided the same way as noughts and crosses with a line of 3 marking victory.

Here's a link to the original video:

Special Report - Video Feedback

My video prototype was released a little while a go and since then I've got a bit of feedback from the prototype that I am now comfortable to share. I was trying to gauge the general reception of the video and whether or not people thought it looked like fun.

Initial Thoughts
People commonly said straight away that it seemed like a good idea when pushed for why they thought that though, they were less than helpful. It was like they were having trouble describing their reasons for being interested in the game.

Does it look like fun?
Again people thought it did look fun and were actually quite keen to test it out. I have been asked a few times when I would have it ready. I followed up on these people and asked them what they thought looked like the funnest part of the game. They overwhelming mentioned the multiplayer aspect of the game so I think this is what I will focus on with the continuing development of the game.

What didn't you like?
People were confused with the running aspect of the game, specifically how you would turn left or right. This information was left out of the video. Some were also concerned the game might be exhausting. Personally, that's what I want something that requires a bit of effort.

Final thoughts?
I asked people about where they thought I should move the project forward. Most people said they liked the basis of the idea, but didn't really understand the specifics because the video didn't really mention them. This is true, but also the intention of the video prototype. I didn't want to lay features or specifics out from the outset only to have them change dramatically. I was looking for the intrigue factor and I'd say I've found it.

My Video Prototype

Week 4 - Types of Prototypes

This week's contact session was all about different types of prototypes. The very first slide summed up the talking points quite well by listing a variety of different types of prototypes. After going over them and discussing a little about what each of them means, we went to work to answer a couple of questions on the topic of a car. Namely how would we list, and sort the functional components of a car and how relevant they are to driving and driving behaviour.

We were then asked to design and describe a horizontal, vertical and diagonal prototype for an alarm clock application. The horizontal prototype is fairly straightforward because it only has to be a general overview of the application. There doesn't have to be anything functional or anything designed in great detail. This is where a low-fidelity prototype or paper prototype would be ideal. It would allow for a great range of screens and layouts to be trialled with little waste.

The vertical prototype would require a little more work as it is supposed to be more detailed but with less range. So for a vertical prototype I would definitely create a more detailed mockup and then likely create a functioning prototype to test the effectiveness of a particular key feature. This is how we determine the success of certain aspects of the design and functionality.

Lastly a diagonal prototype would simply be a combination of the two. This would simply be a more refined, polished and functional version of the app that could be tested or really looked into as a viable option.

Week 3 - Video Prototypes

When we first told that we were going to have to create a game mashup, I immediately thought of a great game called Pacxon which was a really fun spinoff off Pacman. It took me very little time to see how I could incorporate some of the same ideas into Noughts and Crosses. I actually arrived at my idea of Tic-Pac-Toe very quickly but took a lot longer to more fully work out some of the details (many of which I still haven't decided on.) I set to work on putting together a rough design for Tic-Pac-Toe.

Once I had a general idea of what I was going to do, I sat down and tried to work out how I should interact with the game. I needed something special and unique. I sat down and discussed it with a few people and the idea that kept cropping was the idea of a floor pad that you ran on in order to control your pacman. This is my favourite idea so far and what I'm going to prototype I think. It'll be interesting to get feedback on my video, and see what people think.

Week 2 - Designing Prototypes

In the contact this week we discussed devices that we regularly use at home. One of the devices that was mentioned was monitor calibration devices. It got me thinking about the way that I have to interact with said monitor calibrator. Generally speaking the device is placed against the screen and then software on the computer activates the device. While this is happening you have to sit there and wait for the calibration to finish. I was thinking of someway to more closely replicate the way a human would look at the screen. We don't have our face pushed up against the screen. We sit back look at the screen from a distance. What makes calibration so annoying is that it is required regularly as the monitor's colours shift around.

My idea is to utilise a form of augmented reality glasses  that would remove the need for calibration entirely. The glasses would be wirelessly communicating with the computer so that it knows what colours are meant to be displayed and then utilises colour-shifting on a HUD on the inside of the glasses. This way the glasses could be constantly calibrating the monitor during normal operation. It would remove the need completely for a monitor calibrator.

In order to prototype whether a glasses solution would be possible, I would first calibrate a monitor to a very bad calibration and then utilise something simple like combinations of very lightly tinted cellophane. If that was considered to work well, I would move on to a google glasses application that could be run.

http://www.google.com/glass/start/how-it-looks/

Week 1 - Prototypes Discussion

We had our first contact for DECO2300 today. We just generally discussed the course overview and assessments. We then discussed as a group what prototypes are and what they are used for.

After a short discussion our group had concluded the following:
- Prototypes can take on any form. They can be electronic, interactive, made from paper or just an initial sketch. There is really no limitations to what form a prototype can take.
- Because there are no limitations to prototype form it follows that the tools and materials you need to make them are completely dependant on whatever type of prototype you have decided to produce.
- Prototypes are used to test both design and functionality of whatever it is you are making and find problems before it goes to market or indeed through a lengthy development process.
- Prototypes can be created at all stages of development. For instance testing ideas at first and then as development progresses, testing both design and functionality in relation to user interaction.

There are no practicals this week so there is nothing to talk about there i'm afraid.

I do however have an excellent example of prototypes in action.
SurfEars is a product that was originally funded by a kickstarter campaign. It is a type of ear plug specifically designed for surfers and other watersports designed to combat the very real problem of surfer's ears and ear infections. The designers utilised a 3D printer to rapidly prototype and test many different designs. The final product is a testament to good design as it comes fully adjustable to fit into each unique ear and for it's ability to stop water without restricting sound.

http://surfears.com/