Feedback & Reflection for Interactive Prototype 3

Our final prototype testing session was this week. Once again, I had tested my yoke and my game by setting up my game on screen, assembling my yoke and connecting it to the MakeyMakey.

Likewise to previous testing sessions, I had sat down with testers and interviewed them while they were playing the game. My questions were:

• Does the new yoke feel better to hold?
• Is the amount of tilt required to move the player too steep?
• Should this be adjusted?
• Overall, is it fun to play the game with the yoke?
• Is the addition of the ammo count a good idea?
• Does it make the game too difficult?
• Does it add a nice challenge to the game?
• The secret word is now randomly selected, what do you think of that?
• Are the words too hard to guess?
• Does the random word selection make the game more fun?

Summary of feedback

The yoke

Overall, users were happy that the yoke handle didn't fall apart. However, they found it annoying when the handle kept coming off the base.

I had received mixed opinions about how the yoke felt when people held it. Some liked the new, compact design because it felt sturdy when holding it, whereas, others liked the old design because it was much bigger and it had a much more novelty feel to it.

In regards to the amount of tilt required to move the player, everyone said that it was perfect. Last time players had to rotate the yoke to a steep angle in order to move the player. This became tedious for them. This time, people were happy with the amount of tilt because it required less effort to rotate the yoke handle.

Ammo count

I had received a general consensus regarding the addition of the ammo count. Everyone said they loved the feature because it added a slight challenge to the game - this was my reason for adding it. One user also remarked that it adds a layer of strategy, because now the player has to conserve their ammo and therefore they must be careful of shooting the right things.

A funny observation I had made was that some users actually shot the ammo boxes and they were surprised that their ammo didn't refill. Some had realised this and so they didn't make that mistake again, but I had to tell one person explicitly.

Random words

When asked about the random word selection, users agreed that it was a much-needed feature. For them, it was a pleasant surprise when they realised the word this time is different. They commented that the random word selection makes the game much more fun as opposed to each play-through being mundane with the same hard-coded word.

Reflection

Overall, I was happy with the testing session for the final prototype.  It went much smoother than before, but it wasn't completely flawless.

I did have some issues with the yoke again, but this time they weren't as severe as before. When users were playing, sometimes the yoke handle would come off the base. This wasn't too much of a big deal because it was easily fixed by reattaching the handle back onto the joint.

An annoying issue was sometimes the player pressing the button to shoot would not register. I had tracked down what the problem was and it ended up being the connection between the button's wire and the MakeyMakey's ground. Although it was connected (using the alligator) clip, the connection wasn't reliable. This was very difficult to fix because I had no idea why the current wouldn't travel along the connection. A workaround (which only worked occasionally) was to hold and squeeze the alligator clip hoping that the current would travel through.

Apart from the above technical difficulties, the testing session was great since I had received quality feedback. Also, the yoke handle didn't fall apart like last time, so my efforts in rebuilding the yoke paid off mostly well.

Week 12 Exercise - Revisted Definition of Prototype

For this exercise we were required to revisit our definition of a prototype from week 1.

My understanding of prototyping has changed since week 1. I know now that there can be different types of prototypes which range from ones that test an overall design concept to one that tests in-depth functionality, or even a combination of both.

Prototypes can be used to test specific elements of a concept as opposed to the entire concept as a whole.

From my experiences this semester, I've learnt that prototypes can be built upon for subsequent iterations. They don't always have to be rebuilt from the ground-up, unless you're trying a completely different approach.

The key to prototyping is good user feedback. Without it, you will never figure out the strengths and weaknesses of your concept.

Week 11 Exercise - Theremin Concepts and Pugh Matrix

Concepts

1. Use the Kinect to track the motions of the user. A screen displays a grid infront of the user. The Kinect will track the positions of the hand for each note. Then, the notes will be reproduced by showing a marker on the grid.
2. Use air jets which shoot air vertically and horizontallly to help the user find the right positions. This allows to feel where they must position their hand to produce the right notes.
3. Program the the notes/positions onto an animatronic exo-skeleton  which will moves the users arms in to the position required to play the composition.

Pugh Matrix

Pugh Matrix

Progress for Interactive Prototype 3

Over the past few days I have been working on Interactive Prototype 3. I have been working on improving the game and redesigning the yoke.

New Yoke Design

After some troubles with the yoke during the testing session for Interactive Prototype 2, I have decided to redesign the yoke all together. I started by taking apart the original yoke handle and rebuilding from scratch. The first thing I did was figure out a way to securely place the shooting button inside the left column of the handle. From there I had built the right column of the handle symmetrically. Finally, I had to incorporate the new game button. The final result is below.

New yoke design

As you can see the new handle is much more smaller and compact. This design makes the handle very strong and durable.

The base has only slightly changed. The rotational joint is now much stronger. Detection rotation still uses the same method, but it has now been relocated closer to the joint. Additionally, the base also allows for cleaner wire redirection.

Modified base

Rotation detectors are moved closer to the joint

I believe this new design is much better than the old one. It should withstand the handling during the next testing session very well.

Game Improvements

For game improvements, I have changed a few things. Firstly, the secret word is now randomly chosen from an array of 24 words. Another major addition is that now the player has an ammo count. The player starts with 10 bullets and ammo boxes are dropped at random intervals by the aliens. These ammo boxes can be shot while they are falling. To refill their ammo, the player must allow the ammo boxes to fall down and they must collect them by colliding with it.

Game improvements include random words and an ammo count

A very useful improvement is the way that random letters are dropped. Now there is bias towards the correct letters which was a much-needed tweak. I have implemented this by adding a second timer which triggers the drop of a random CORRECT letter. A correct letter is one which is still left to guess to form part of the word. The frequency of the original timer has also been tweaked slightly so too many letters don't spawn in a short period.

Reflection for Interactive Prototype 2

This week's testing session for Interactive Prototype 2 was mostly successful. I say mostly successful because not everything went smoothly.

I had received sufficient feedback which I am very happy for, though there were a few issues with the yoke. The problem was, since the yoke is made out of LEGO, it didn't hold up too well throughout the entire testing session. But, during the first playthrough it was fine since the user handled it very well. After a few playthroughs, the handle would sometimes become detached from the base or small pieces would come off. In one event, the left side of the handle which supports the shooting button broke. Additionally, for one person, the left rotation couldn't be detected. This was fixed by re-taping the foil on the underside of the yoke handle. Luckily, these problems were easy to fix and testing could resume again.

Even with the yoke problems, I was still able to fully test it. For the next prototype, I will be redesigning my yoke slightly so its much stronger, durable and addresses the issues discovered in the testing session.

Despite the problems with the yoke, everything else went smoothly. I had received a lot of great feedback which I will definitely consider for the next prototype.

Feedback from Interactive Prototype 2

This week we had conducted testing of our second interactive prototype. The procedure for testing was very similar to the previous testing session for the first interactive prototype. I had set up and displayed my game on the screen. I had also assembled my yoke and connected it to the MakeyMakey.

A video of a test subject using the yoke to play the game is below.

I believe the testing session was a success and I had received some very good feedback. I sat down with the users as they were playing the game with the yoke and I asked them several questions:

• Do you think it is easy to move the player with the yoke?
• If not, please say why and offer any suggestions.
• Now that we have the yoke, do you think the player speed and acceleration or deceleration should be adjusted?
• How difficult is it to shoot with the yoke?
• Do you have any suggestions to improve on this?
• Is the placement of the new-game button on the yoke suitable?
• Do you think adding the bubbles around the letters are a good idea?
• If so, does it make it easier to shoot the letters?
• If not, why is it a bad idea?
• Do you have any other alternatives?
• Should I remove it completely? 

Summary of feedback

Player movement

Now that the yoke is involved, all of my testers were very happy with the movement system. According to the testers, the player is very easy to control with the yoke. I had asked them about adjusting the speed and acceleration/deceleration, and they responded by saying that it were no issues at all. In fact, the smoothing of the movement feels even better now with the yoke.

The yoke

Overall, players had liked the yoke. They loved using it to play the game and they mentioned that it was very fun controlling the player with the yoke. One person even said that the big orange button to shoot was very intriguing and addicting to use.

Some players mentioned that it is now actually much easier to shoot with the yoke.

The only issues some players had with the yoke were regarding its form factor. Some said that the yoke was too wide, so when holding it, it was difficult to reach the centre-button without moving their entire right hand. Additionally, there were complaints by two people who said that the tilt was too steep when rotating the handle to move the player. In other words, players didn't like the amount they had to rotate the yoke just to move the player. I will address this for the next prototype by redesigning the yoke handle to be smaller.

Gameplay

Overall, players were happy with the game itself. I had stated to them that a lot of the issues from the previous session are still present because the main goal of this session was to test the yoke.

Players liked the idea of having the bubbles around the falling letters because it gave them a visible, larger and uniformly sized hit-box when shooting letters.

Week 10 Exercise - Restaurant Dining Experience

What is the existing experience? From different stakeholder P.O.V.?

Experience from a customer's view

• Customers walk in, are greeted and are given a seat
• They are given a menu
• Customers read the menu and decide on what to order
• Waiter/waitress comes and asks the customers if they are ready to order
• Customers order what they want, then wait for some time until their food is served

Experience from a waiter/waitress view

• Greet customers, give menus to customers, find them a table that is not taken
• Take orders from customers
• Give orders to the chefs
• Serve food to customers
• Pick up dirty dishes/clean tables
• Fulfil the requests of customers at any time

 What external/internal factors impact on the experience?

• How many customers there are on a given day
• How many waiters/waitresses are working on a given day

What aspects of the existing experience could be enhanced/augmented/supported with technology?

An aspect that could be changed is the way that customers order their food. Instead of reading through the paper menu, customers can browse through a digital menu and then submit their order when they are ready. The order is sent to the chefs which they can see on a screen back in the kitchen.

How would introducing technology in to this context change the experience?

• Customers can take their time to browse the menu and submit their order when ready.
• It makes it easier for customers to customise their order. They can change the items and quantities, specify any special requirements, etc any time BEFORE they submit it.
• There's less hassle for waiters because it saves them going around everywhere to take customers' orders.
• Orders are sent immediately to the kitchen.
• Order can be tracked - e.g. how much time is remaining until food is served. This is a good thing for customers to know about.

What experience scenarios might you test with the technology?

On a busy day, get customers to try the digital menu. By using the interface, we will know how user-friendly it is. Additionally, we will see how efficient it is that waiters do not have to go around taking people's orders.

Yoke Completed

After two days of reliving my childhood moments with LEGO, my yoke assembly is finally complete. The handle buttons are fully functional and the handle can rotate smoothly.

Completed yoke handle attached to base

The thumb button on the left side of the handle is for shooting whereas the centre button is to start a new game. Each button is connected to two wires. In order to keep my design elegant, I have redirected the wires though the inside of the yoke handle and out of the back. A rear view of the handle is below.

Rear view of yoke handle - wires are fed through the inside

To detect rotation of the handle, so the player can move left and right, I have used a very simple method by just sticking on foil on the underside of the handle.

Underside of yoke handle

The two foil pieces are connected to wires which run alongside the rest of the wires inside of the handle. To complete the circuit, a foil piece will need to make contact with the base. The base has two contacts which "detect rotation".

The base component

The two contacts you can see on the base are simply LEGO pieces attached to the base and are wrapped in foil which will be connected to ground. The yoke handle attaches onto the base on the rotational joint at the top. The base is actually very sturdy and can hold the weight of the yoke handle.

The development of the yoke wasn't too difficult, but it was quite time consuming. I am happy with the result and I look forward to testing it next week.

Interactive Prototype 2 - Yoke Development

It's been quiet on the blog for the past two weeks because I've been preoccupied with other coursework. Nonetheless, I have commenced development of my physical input, the 'yoke', for my game.

To recap, the yoke resembles the controls of an aeroplane, shape-wise but not entirely functionality-wise. It will feature two buttons: one to shoot and the other to start a new game. The rotation will simply move the player on the screen.

The entire yoke device will be comprised of two components: the handle and the base/stand. The handle will be attached to the base. The base is very important since it will detect the rotation. However, the detection won't actually be proper rotational detection. Instead, I intend to take a shortcut and just detect the contact of the underside of each end of the handle with the base.

My progress so far includes most of the yoke handle completed as well as the integration of the new game button which is situated in the centre.

Most of the yoke handle is completed including the centre-button to start a new game

Although it is made out of LEGO and may look flimsy in the photograph, it does in fact have very good structural integrity. The two wires you can see come from the centre button. They will be connected to ground and some key on the MakeyMakey.

The centre button is actually an old doorbell button. For shooting, I will use another push button I had found. The thickness of the black casing is just perfect to hold so I will have to somehow integrate this as a part of the yoke handle. Most likely, the whole unit will replace the left vertical block of the handle (see picture above).

These two buttons were found in the deepest reaches of my garage among the rest of the useful mess in there

I will try to keep my design elegant and not have a mess of wires everywhere. The two wires for the centre button will actually be run through the inside of the handle and out of the back. I will also do the same for the shooting button.

Week 8 - Progress (Minor Game Adjustments and Yoke Idea)

Just a small update

For Interactive Prototype 2, I have made a few minor adjustments to my game and have started looking into how I could build my physical yoke.

Some adjustments to the game include decreasing the frequency of letters spawning. A noticeable change is that now the letters have bubbles around them. This was a great suggestion from one of my testers. The coloured ellipse adds some extra surface area to the letters to make them easier to shoot since they have a visible hitbox now.

Letters are surrounded with an ellipse/bubble

For my yoke, I am thinking of building it out of LEGO. There'll be two components - the base and the actual handle. The handle will be attached to the base and will pivot left and right. The base will detect the handle rotations when the bottom of the handle makes contact with the base. The handle will have two buttons - one to shoot and one to start a new game.

Week 8 Exercise - Physical Interactions

For this week's exercise we were required to think of five physical inputs each for Email, Twitter and Super Mario Bros.

Email

1. Different trash bins represent different folders/contacts. To send an email to a specific contact, toss some paper into the right bin.
2. You hold an address book and slide contacts to your email on the screen to choose the recipients.
3. Use a guitar for typing your email.
4. Flush to clear your trash folder and junk mail - an external 'toilet flush handle' device connected via USB.
5. To mark an email as read, stare the screen for a certain amount of time. To mark an email as unread, look away from the screen.

Twitter

1. To hashtag something, perform the 'hashtag gesture' (Jimmy Fallon style) - this will require a wearable glove-like device
2. To tag other people, whistle then touch them.
3. To retweet something, open it then whistle twice.
4. To follow people, drag them onto your queue - each person is represented by their avatar.
5. To upload a picture, give it to the bird and pull the sling (similar to Super Angry Birds)

 Super Mario Bros

1. Use a treadmill, or better, an elliptical trainer to walk forwards and backwards.
2. Use a pressure plate to detect jumps.
3. Ride a skateboard to control Mario, roll back and forth to run in either direction and perform an ollie to jump.
4. Punch to shoot fireballs - use a speedbag or punching bag to detect the punch.
5. Physically squat 100kg to crouch in the game.

Reflection for Interactive Prototype 1

I believe the testing session for my first interactive prototype was very successful.

My implementation so far served me well to test my intended ideas and interactions. This is mainly because the prototype was essentially a near-complete game with only minor elements missing. This had allowed me to test all of my game mechanics and rules very early. I now have a solid idea of what is good and what needs to be tweaked for the next iteration.

My goal for the first interactive prototype was to implement all core game mechanics which would form the foundation of my game. The aim of the testing session was to test this foundation before I had progressed any further into development. Elements such as player movement, alien movement, falling letters, shooting, and guessing the secret word were essential for testing as these form the basis of the game. These elements need to be perfected before moving onto things like physical inputs and other additional features/ideas.

Due to the nature of my game, there weren't any constraints which hindered me to test my ideas. Flash and ActionScript 3 is the perfect platform to work with for testing my core functionality.

Overall, I believe my first interactive prototype was effective for testing my concept. I had executed everything well to ensure I had received the feedback that I wanted.

Feedback from Interactive Prototype 1

Today we had conducted testing of our first interactive prototype. I believe today's testing went really well because I had received a lot of constructive and actionable feedback. I think this is a result of me asking very specific questions. The questions I asked are below:

1. Is the objective of the game clear?
2. Should the player movement be adjusted?
3. Should the alien movement be adjusted?
4. How easy is it to shoot the letters?
5. Is it easy to infer what happens when a letter-bomb has landed on the ground?
6. Is the placement of the answer field effective?
7. Overall, is the game too hard or easy?

Summary of Feedback

Game's objective

For most people, the objective of the game was clear. The reason for this is that they were already familiar with games, particularly Space Invaders. They knew that they had to shoot the falling letters. However, some people struggled to figure out which letters to shoot or spare. But after multiple playthroughs, these users became familiar with the game rules. A few users suggested that a hint for the secret word should be displayed, because they were just shooting all of the letters because they were afraid to lose. I am not too sure yet how to address this because I believe it will make the game too easy.

Player movement

Interestingly, I had received mixed opinions regarding player movement. Half of the people loved the movement and thought it was perfect in terms of speed and smoothness. However, the other half did not like it at all because it wasn't accurate due to the deceleration. To address this, I will have to find a good balance of speed and deceleration. I am planning to reduce the amount of smoothing/deceleration and ensure that the player's speed is the same as the falling speed of the letters.

Alien movement

There were a few issues with the alien movement. The problem is that when multiple incorrect letters fall down at roughly the same time, the alien row will move down multiple times rapidly.This was  overwhelming for users to see. One of the users suggested that I should implement a delay timer to prevent the aliens from moving down rapidly in such a small amount of time.

Letters

Most users had no troubles shooting the actual letters themselves. They said that the letters were a big enough target and shouldn't be increased in size. One user suggested that the letters should be encapsulated in a circle. I think this is a good idea because it gives the letters, as targets, more surface area and a visible hit-box. This will aid in more accuracy for shooting the letters.

One major issue regarding the letters was that since they are randomly generated, sometimes the player has to wait for long periods of time for the correct letter to spawn. A great suggestion was that there should be some bias towards the correct letters for the generation and not to have it purely random. Another issue with the letters are that, sometimes, too many letters are spawned on the screen and it becomes very difficult to shoot them. This is due to the random timer interval which triggers a letter to spawn. Again, I will need to tweak this.

Overall difficulty

The overall difficulty of the game will need to be adjusted and balanced since I had received varying opinions regarding this.This was mainly due to the users' varying skill levels, but also because of some of the ways that the existing game mechanics that are implemented such as the player deceleration, alien movement and letter generation.

Over the next couple weeks I will tweak these mechanics and address the issues mentioned above.

Week 7 Exercise - Evaluating Previous Questions

For this week's exercise we were required to think about our questions from our Video Prototype (the questions can be found at http://tinyurl.com/alphabet-invaders).

I believe most of my questions were quantitative. I also used Semantic Differential scales for most of them, however one of them was a simple binary choice.

I think that my questions were very specific so the users could not give general answers. However, I did offer them the option to give general comments and suggestions at the end of the survey.

The question "Based on what you saw, does the interface look familar and easy to use?" is a compound question. I should have split this up into two questions:

1. Does the interface look familiar?
2. Does the interface look easy to use?

Also, instead of the binary choice, I could have used a scale like the other questions.

Interactive Prototype 1 - Progress

I had commenced development of the first Interactive Prototype in Flash a week ago. Back then, I was able to spawn the player and aliens and make them move. However, the player would move in a very primitive manner - i.e. the  movement was very choppy and linear.

The player and aliens can be spawned and they can also move.

The sprites in the game are exactly the ones used in my Video Prototype, they've just been imported from the Illustrator file. This not only saves my time, but it also makes everything consistent. What my Video Prototype showcased was intended to be exactly what the game should look like (as much as possible, of course), and therefore that is what I am aiming to accomplish.

As of today, the majority of the game is complete. The player is able to move smoothly with acceleration as well as shoot bullets. The aliens can drop letter-bombs which are able to land on the ground and turn red or green depending on whether they are a part of the secret word the player has to guess.

As you can see, much more has been implemented.

Currently, the aliens cannot be killed because the entire row is a single entity. Also, the player cannot be killed by the letter-bombs. I have done this purposely because I want to know people's opinions on whether or not the aliens should be killable and the player should be invincible. This will be done during the testing next week.

The game is over when the row of aliens get too close to the player, so it is actually possible to lose the game. However, right now it's impossible to win because I haven't implemented the player's answer which should be at the bottom of the screen to populate with the correctly fallen letters. In the Video Prototype, I had shown an array of boxes at the bottom of the screen which would contain the correctly fallen letters. For now, I will just implement a single text field which updates itself as the correct letters fall.

Some additional miscellaneous functionality I have implemented are the splash screen and game over screen. For now, they are just basic images created in Illustrator and imported into the Flash project.

Personally, coding in ActionScript 3 isn't very difficult as I have learnt Java previously and the syntax is almost exactly the same. I am also used to the concept of OOP. Using Flash overall hasn't been hard to grasp because I've worked with Flash a few years ago (back in the Macromedia days, but I've also used the CS3 version). It just took a little time to adjust to the interface changes because I haven't used Flash since then.

For next week's testing, I just need to implement the answer text field at the bottom of the screen and that will be sufficient for my testing purposes.

Week 6 Exercise - CRC Cards

For this week's exercise were required to create CRC cards to help us identify what classes we need for our game. So far, I could think of five classes. The cards are below.

Reflection for Video Prototype

Before working on the first Interactive Prototype, I thought I'll take some time and look back at my Video Prototype.

I believe my Video Prototype was extremely effective at communicating and illustrating my idea. Although simulating and animating the game myself was tedious and took a long time, I think it was worth the effort. By showing the game itself, viewers can see what the game looks like and plays without any verbal explanation. My aim was to accomplish everything visually, and I can say this has worked.

The explanation of the rules were well integrated as a part of the game's animations so viewers could easily understand them. Even the physical input, the yoke, was shown visually to explain how it works with the game. Again, this was integrated as part of the animation.

I also think that the theme of the video contributed to its success. The familiar arcade aesthetic accompanied with the music captured viewers' attention. Additionally, the game trailer style effects made the game concept seem more legitimate and solid according to external feedback.

Overall, I believe the Video Prototype was a success and I am happy with the outcomes and results.

Feedback From Video Prototyping

This week we had presented our Video Prototypes to the class. I had collected feedback using a survey I had created on Google Forms which can be found here: http://tinyurl.com/alphabet-invaders

The results of the feedback can be found here.

Overall, I had received positive feedback with a few great suggestions to improve certain aspects of the game. Some conclusions which I have drawn are:

• The concept of mashing up Hangman and Space Invaders is indeed creative.
• The rules of the game are very easy to understand.
• The interface is certainly familiar and easy to use.
• The yoke is fairly suitable to control the game.

Some good suggestions I had received included:

• The user could have an option to import their own custom list of words.
• The game should be faster paced.

In response to making the game faster paced, I am thinking about making the aliens and the player move faster. Additionally, the aliens will drop a lot more letters which will drop faster than shown in the video.

Week 4 Exercise 2 - Alarm Clock Prototypes

This exercise required us to design and describe a horizontal, vertical and a diagonal prototype for an alarm clock application for smartphones. The features of the application include:

• Setting, editing and deleting multiple alarms
• Daisy-chaining alarms
• Setting different tones for different alarms
• Shaking the phone to snooze the alarm

Horizontal Prototype

User interface for alarm application

My horizontal prototype simply tests the user interface of the alarm application. There are four main screens:

1. The first screen the user is presented with when they launch the application is the list of alarms. Here they can view all created alarms, enable/disable each one using switches, edit/delete each alarm. Most importantly, the 'Add Alarm' button is located on the top for easy access.
2. If the user presses 'Add Alarm' on the previous screen (or even edits one), they will be presented with the second screen where they will be able to customise the different options for the alarm. Options include repeating, tone, a descriptive label, daisy-chaining and of course the alarm's time. If the user wishes to daisy-chain alarms, they can select that option and they will be taken to the next screen (#3)
3. On this screen, the user is presented with a list of all existing alarms they wish to daisy-chain with. They can select multiple alarms or none at all. The layout of this screen is very similar to the screen where users can choose the alarm's tone - it is simply a list.
4. When the alarm rings, this screen will be displayed (taking up the entire display because it requires the user's attention). The alarm's time is shown topmost followed by the descriptive label. The two buttons are self-explanatory. On this screen, the user also has the option to shake the phone to snooze.

Vertical Prototype

The aim of my vertical prototype is to test the dismissing and snoozing of the alarm when it rings. Essentially, it will use screen #4 from above and test each aspect of it including overall layout, the readability of the alarm time and label, the effectiveness of the snooze button (and shake-to-snooze functionality).

Diagonal Prototype

The diagonal prototype aims to test a a scenario where the user undertakes the following tasks:

1. Launch the application and view you alarms
2. Add a new alarm for 5:00pm with the label "Tea time". The alarm should repeat on Mondays and Thursdays. It should have the tone 'Xylophone' and should trigger (i.e. daisy chain) Alarm 1.

The purpose of this prototype is to see where the user is having difficulty in completing tasks.

Week 4 Exercise 1 - Car Dashboard

What components are relevant to driving behaviour and what are the interactions of those components with the driver when driving?

• Steering wheel - driver rotates to steer the car
• Speedometer, tachometer, fuel gauge, etc. - driver should glimpse at it and get the desired information
• Gear stick - driver operates it by moving it into positions
• Handbrake - driver can pull or release (by pressing the button)
• Side-mirror adjustment controls - driver selects which mirror to adjust using a switch, and then adjusts the position using buttons
• The screen in the centre of the dashboard - driver can control it with a joystick

What would you test?

I would test the screen in the centre of the dashboard. I would like to know how effective it would be controlling it with a joystick as opposed to using touch.

How would you test it?

I would test the controls by giving the user a task to accomplish while driving. I will see if they have difficulty in navigating the interface and how long it takes to complete the task.

Video Prototype

My Video Prototype for Alphabet Invaders is now complete. You can view it below.

Development of the Video Prototype

I have commenced development of the Video Prototype. I am using Adobe After Effects to animate the entire video. The video will show a emulation of my game. What better way to explain my game than to show the game itself? My aim is to present something along the lines of an actual game trailer.

The bulk of the video will be showcasing the game. I have also included an explanation of the physical input which is now the yoke (instead of the toy gun mentioned in a previous blog post). I believe the yoke is more suitable for this type of game since it just consists of horizontal movement and clicking (triggering a shot). The gun would have felt unintuitive since you won't be able to aim it freely.

My explanation of the yoke is simply showing what it looks like (stylised and not as a photograph) and animating the yoke rotating concurrently with the player's ship on the bottom of the screen.

I have created the game's sprites in Adobe Illustrator and imported them into After Effects where I have animated my game.

Animation took quite a while to do mostly because I haven't touched After Effects in a couple years. But after brushing up on my skills, I was able to get into it pretty easily. Each shot fired and letter dropped was animated manually as well as the player's ship and aliens.

Below is a screenshot of my progress nearing completion.

Getting busy in After Effects and Sony Vegas. What will I do without dual monitors.

My purpose for Sony Vegas is for compiling the raw animated footage with the music as well as cleaning up/trimming the start and end of the video/audio.

Ideas for the Video Prototype

I have now begun to think about how I should create my video prototype. I am most likely going to animate most of the parts of the video in Adobe After Effects. These parts will be showcasing the game itself. The titling, editing and compiling will be done in Sony Vegas Pro. I will also need to show my physical interaction device which is the toy gun. I plan to either take a photograph or record a video of me holding it to show how it works with the game. The aim is to move the gun back and forth horizontally concurrently with the player in the video. This will make it appear like the gun is controlling the player.

I have drawn up a very rough storyboard to illustrate the parts of the video.

Rough storyboard for the video

Game Mashup Idea

After a long time of deciding which games to choose, I have finally selected to mashup Space Invaders with Hangman.

The gameplay will be very simple and almost similar to the original Space Invaders. The objective of the game is to guess the word (like in Hangman). However, the way you select letters is different. The attacking aliens will drop random letters. To select a letter you want to form part of the word, you must let the letter fall to the ground. You can shoot any unwanted letters before they land on the ground. If an incorrect letter lands, the aliens will move down closer to the player.

A sketch of the game is below.

Rough game sketch - the word to guess is 'Telephone'

Another idea I could add is that the letters fall in designated columns. This might add an extra challenge.

For the physical input/interaction, I am thinking about using an old Konami Justifier gun for the PlayStation 1. I cut it's wire a long time ago so I could use it as a pretend gun and run around with it back when I was a young lad.

Konami Justifier Gun for the PlayStation

Shooting will be easy since all that is required is to trigger a click/key press upon the squeezing of the gun's trigger. The only problem with this is how to control the movement of the player. The gun does have two extra buttons (one on the side and on the rear), but I don't think it will be intuitive or easy to use to control movement with them.

For the next few days I will be working on my Video Prototype. I'm thinking about either doing stagnant mockups or even an animated mockup of the game. I will also need to think about what other content I need to explain my idea.

Week 2 Exercise - Mixed/Augmented Reality Prototype

For this week's exercises we were required to think of a device we use regularly at home and design variations to the way that we interact with that device. To test the different types of input, we were supposed to design a mixed or augmented reality prototype.

One of the most common devices that everyone on our table uses is a television. A remote is the primary way to interact with a television. The most common commands we send to the TV is to change channels, adjust volume, change video inputs and such. However, most remotes are packed with various buttons which can become overwhelming. What if there was another method of performing these basic commands in a much quicker way that is familiar?

In today's world, most of us have smartphones with a touchscreen interface. The primary way we interact with them is with the use of gestures such as swiping, sliding, grabbing/pinching. For our TV operation, we will be bringing these gestures into the mix.

The input device instead of the remote will be a device very similar to a tablet and will be slightly larger than your hand. On the surface is where you will perform your gestures:

• Swiping left and right will change the channel
• Sliding your fingers vertically will adjust the volume
• Grabbing/pinching with all fingers will make the TV image zoom out and display all video inputs
• All other controls will be available in an icon layout menu which can be accessed on the device

The system will look very similar to the image below, except the tablet device has a very minimal interface. The majority of the screen will be used to the hand gestures and other occasional-use controls will be tucked away in a sliding menu.

Image reference: http://www.prweb.com/releases/2012/1/prweb9083508.htm

The prototype will mimic the results of the above commands using mixed/augmented reality in order to test the input device. The tablet remote will simply be a plain panel of glass or any smooth surface. The user (tester) will be equipped with the augmented reality (AR) gear while holding the fake input device. The AR equipment will display an image on the TV screen as well as on the device all on the user's visual feed. The user is able to perform gestures on the device which actually appears like they are giving the TV commands. For example, if the user swipes left or right to change channels, the AR's visual feed will show the channel being changed on the TV screen.

Week 1 Exercise - What Are Prototypes?

I believe prototypes are the early stages of a design. Prototypes can take many forms ranging from physical to digital such as a simple paper prototype or an interactive simulation.

Prototypes can be made out of anything, depending on the type of design/product. For example, for physical prototypes, paper or clay can be used. For digital prototypes, you will need the right software for wireframing or creating an interactive simulation.

Whether through physical or digital methods, prototyping is an essential process to ensure the final product does what is required without flaws. Prototyping exposes the strengths and weaknesses of a design. The more tests that are done, the better the final product will be.

Below is an example of a paper prototype and a digital prototype.

This paper prototype is for the design of a UI for a mobile application.

This digital prototype simulates the aerodynamics of a car.