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/