Week 5: IP1

What is the key function or interaction for your concept?
Pressing given keys to control the forward movement of a frog crossing the road, and timing it to avoid moving objects.

How does it work?
Presses on randomly assigned keys will move the frog one step across the road.

What do you want to know about your prototype?
For users to understand that they can use different key presses to do the same action, i.e. move forward one space at a time. However each nominated key can only be pressed once only, once it's pressed it no longer performs any action.

How do you want IP1 to work?
The player will be placed in front of the computer, a quick tutorial will be shown to explain the rules. On screen the frog will be placed at the bottom with the goal placed at the top. In between will be moving objects which will need to be avoided. On screen, the key values that control the frog's forward movement will be displayed one at a time. The player must press these exact keys (in any order) to cross the road. However they can only press a key one time only, once that key is pressed it can no longer move the frog forward. The player must press the allocated keys to eventually get to the goal, and avoid the moving objects.

Video Prototype: Testing and Evaluation Results

In this weeks B Prac we ran our video prototype testing sessions. This blog post details my evaluation of this testing session.

Outcomes:

1. What you asked users to do:Watch the video (advised users they can stop, rewatch, replay video as they like), answer a few questions about the video, ask/answer if they had additional questions, complete a survey containing questions about the concept and the testing session.
2. What the users actually did:7 out of 8 users didn't replay the video, just watched it once through. Some resized the video to watch full screen. All answered my questions. Some had additional questions and feedback to add. All completed the survey correctly.
3. The measures you used:No qualitative measures were used in the testing session. Only observations and notes taken.
4. The feedback you sought:Feedback related to user's understanding of the game concept as communicated in the video prototype (gained from observation, Q & A session post-viewing). Feedback about video production quality, the game concept itself and testing session (from the survey).

Reflection:

Overall the video prototype was a great tool for communicating the concept for the game and it's rules without having to actually build anything yet. All users responded positively to the prototype, understanding the core concept of the game, and most understood the game's rules, interactions and mechanics. It was also good to get some feedback on how to improve the game at this early stage in design, which will make it a lot easier to implement when starting to build, rather than later down the track. 

Testing wise, I found my protocol adequate for what I wanted to achieve in the amount of time allocated. Towards the end of the session I wasn't as strict with asking the same scripted questions, I just asked the last 3 users if they had any questions or didn't understand anything. I felt this was good enough to get the same level of feedback in a shorter time. The lower scored responses to survey question 5 may have been due to the last minute testing towards the end of the session, where I didn't put as much effort in explaining the instructions, although all the participants I observed managed the watch the video, answer questions and completely the survey without any trouble.

Effectiveness:

I thought the video prototype was very effective in explaining the game concept. Overall users typically had a good grasp of the game's concept and rules after watching the video. 2 students who were not familiar with the Guess Who game had some trouble understanding those elements used in the game. The responses to questions 3 and 7 identify that more explanation about the guessing element of the game was necessary to help those understand how this translated into the mashup. Also explicitly showing or stating how the clues are to be delivered would make it clearer to viewers how this part of the game works.

Constraints:

Time constraints meant that I wasn't as thorough towards the end of the session in giving all the same instructions and asking the same questions as in the beginning. This may have resulted in collected less verbal feedback, but I think the result of this was pretty minimal, if any.


Implications:

The confusion of the guessing element and also crossing the road element at the same time has made me more aware that there may need to be more support in the game to train players how to play - maybe using a tutorial, or start playing at a really easy level, where the difficulty increases as time goes on. The next testing session will be quite different and more interactive, so I'll be more observant about their behaviour when interacting with the prototype than I was in this session.


RESULTS:

I had a total of 8 users watch my video and complete the survey. Overall the feedback was positive. After watching I asked a few informal questions directly:

1. What was your first impression of the video?
Comments included: "relaxing", "interesting", "good production", "clear", "good impression", "personal language used", "enjoyed the funny moments".

2/3. Did you understand the concept? Did you understand the rules?
6 out of 8 users responded positively, with no problem understanding. The remainder had some problems understanding the rules, especially concerning the Guess Who elements of the game. In these cases 2 of the users had very little background knowledge of this game, so therefore didn't understand how this translated into the game mashup.

4. What parts didn't you understand?
A user didn't quite understand how the clues were to be delivered in the game. Also here I had to explain the rules of Guess Who for the users who had never played this game, and describe how the Guess Who elements worked in Hop to Who.

After asking these questions, I then asked users to fill out an online survey which asked questions about the video production quality, the game concept itself and the testing process. The questions and results are as follows:

1. How interested are you in playing this game? (Scale 1-5, 1:not at all, 5: Let me try it now!)
4, 5, 4, 5, 5, 5, 4, 4 (Average 4.5)

2. How unique do you think the game's physical interactions are? (Scale 1-5, 1:not unique at all, 5: very unique)
5, 4, 5, 4, 5, 3, 5, 5 (Average 4.5)

3. Do you have any suggestions to improve the game?
"Might be difficult playing both games at the same time coz the frog game is all about timing, but I think it's gonna be pretty fun"

"personal quibble with games that involve love stories. is there another reason the frog would meet someone? other people probably wouldn't care about this."

"through the video, I thought one of results of this game is to find the heart of Mr. Frog. So, maybe for someone, they don't need finish the whole one round of game. I think it can set a condition that anytime picking up the heart from the puzzle, gamer can win in advance"

4. How would you rate the video and audio production quality? (Scale 1-5, 1: poor, 5: excellent)
5, 5, 5, 4, 4, 4, 5, 5 (Average 4.6)

5. In the testing stage, were my instructions clear? (Scale 1-5, 1: I didn't understand at all, 5: I understood the instructions clearly)
5, 5, 3, 5, 5, 5, 4, 3 (Average 4.4)

6. Did you have enough time to ask questions or add comments after watching? (Multiple choice)
No I didn't have enough time: 8
I was given some time, but would have liked more: 0
There was plenty of time to ask questions: 0

7. Do you have any other comments?
"Was a good video! Great idea and well explained"
"Might need to consider for those who have no common sense on either games you mashup including me. Tutorial may work well to me anyway."
"great video and interesting concept. was definitely emotionally invested to save the frog from a car tire - very visual but not alarming :)"

View a summary of the responses here: 
https://docs.google.com/forms/d/13DCUIHV2wHqeu_8hDvAC27Seg8d_jv9Kc-tp_w0o2-0/viewanalytics#start=publishanalytics

Week 4: Contact Session Exercises

In today's contact session we were presented with more about different types of prototypes:

• Low fidelity / High fidelity
• Exploratory / Experimental / Operational
• Horizontal / Vertical / Diagonal
• Global / Local

These all are different ways to clarify the various goals and scope a prototype has.

After the explanations of each of these types of prototypes, the class was tasked with 2 exercises:

Exercise #1 Car Concept 

What are the functional components?

Our group listed, in no particular order:

• Dashboard controls, speedometer, tachometer, indicator/wiper controls
• Keys, Seats, Steering Wheel, Pedals, Hand brake, gearstick, mirrors, seat belt
• Radio, AC controls, window controls, seat adjustment control
• Displays, controls for the the display, GPS

Replacing a functional component

Our group discussed a few ideas, such as replacing steering with a trackball, or even using brain waves. The concept we chose involved replacing a car's accelerator pedal with a control based on eye-tracking and monitoring driver concentration. When a driver is looking to the road, this enables the car to accelerate. When the driver takes their eyes off the road, for example if they become distracted by their phone or fall asleep, this prompts the car to slow down and even stop.

Uses facial recognition to analyse the driver's level of emotion/concentration, and this could controls the speed. 

Low-fidelity prototyping
Our group decided the purpose of the prototype would be to test the driver's tolerances of concentration and their current behaviours. For example how long would a driver look away from the road to check blind spots, or check for other traffic. A lo-fi prototype could be a video shown on a monitor place in front of the driver, when the driver looks away, the tester would take note of what they were doing and for how long. Another idea was a driving simulation game, where the user was in control of the steering, but the tester was in control of the speed. The tester would watch the user, and whenever their eyes went away from the screen, the tester would slow down the acceleration.
Another idea I had, which is not entirely lo-fi, but it could use a special car with brake/accelerator pedals on the passenger's side (like those used by driving instructors). The driver would only steer, and the tester would only be watching the driver's responses to inform the acceleration/braking. This would have to be done in a controlled environment though. This way it could be easier to test in other scenarios, such as different weather conditions or time of day.

Exercise #2 Smart phone alarm clock app

The last task for this session was to the design a horizontal, vertical and diagonal prototype each for an alarm app which:

• Can set, edit & delete multiple alarms
• Can daisy-chain alarms -if one is allowed to ring out, another is activated automatically
• Can set different tones for different alarms
• Shake phone to snooze

Horizontal prototype:
A horizontal prototype basically shows the wide range of features, but without any of the functional deep interactions. This prototype could be the home screen of the app, it would show the button for creating a new alarm and would list any existing alarms and their details below, with a link to edit and delete these. Of course there would be no functionality, it would only be used for showing the front end "dashboard" a user would see when they first open the app on their phone and the possible points for which they can possibly interact with.

Vertical prototype:
A vertical prototype is essentially the opposite of the horizontal version, where it only really concentrates on showing one feature, but delves deeper into it's interaction and functionality.
The alarm app vertical prototype will focus only on the functionality of daisy chaining alarms. The prototype will start the user at the home screen, the user will create a new alarm, then choose the "daisy chain" option. They then can create the first alarm, choosing it's settings. The user can then add another alarm choose it's settings again and again until they are satisfied. Once this is done, the daisy chain of alarms will be added. The user can then see this from the home screen and edit or delete it if they choose. All the other app functions would not be available to the user.

Diagonal Prototype:
This type of prototype is a mix of both horizontal and vertical, but doesn't have the complete functionality of the final app. It can be used to follow a particular task flow.
The prototype could expand on the home screen functionality, with the ability to explore different sections of the app, showing the user interactions with the various interactive buttons and other elements. The user will be given a task to complete, for example choosing a tone for the alarm. They can navigate through the different features of the app to find where they can complete this task, but the functionality would not work for all of these, only the settings to change the alarm tone.

Final Video Prototype: Hop to Who?!

I managed to finish my video over the weekend, hooray! I shot most of it Saturday and spent that night editing. I had one last shot to film which I didn't originally plan on, so I had to shoot it and insert into the final video on Sunday morning.

Overall the whole process went really well. Planning out the script and storyboard, shot by shot, helped greatly. Combining different location shots also helped streamline the whole shooting schedule.

I decided to use a Frog toy to represent the Frog character (suggested by Peter). And illustrated the game's story and objectives using real world environments and objects rather than rely on animations. I filmed on a busy main road and also on the street outside my house for the outside locations. Everything else happened in my living room. For the shots of me explaining the game, I was able to use the chalkboard wall in my living room and illustrate some (fake) concept drawings to make an interesting backdrop.

I fortunately had the help of my partner and dog in some shots, as both actors and camera person.

Professional cameraman and teleprompter. Using a makeshift tripod.

Instead of Photoshop, I wanted to try out Premiere since I could download it for free with my Adobe CC subscription. Photoshop was fine for basic editing, but I found the timeline part a bit strange when I was trying to move and trim clips and audio. Premiere gave me a lot more controls over this. While there was a few things I needed to lookup on Google, basic video editing controls were pretty easy to learn since I've done a little editing previously, so I managed to get through this stage in a couple of hours. I also overlaid some basic illustrations made in Illustrator to help visually explain the story. Initially I wanted these to be animated, but for efficiency's sake I decided against this seeing as I'm not at all familiar with creating animations.

All in all, I'm pretty happy how it all turned out. I think I explained the concept of the game fairly clearly. Production-wise is also pretty good. The video was OK and the audio was clear enough. Some of the shots I probably should have used some kind of stabiliser so the video wasn't so wobbly. But since I was using my iPhone it was a little awkward to frame the shot without having the phone hand-held. The audio went well, there was a bit of a disparity between the audio from where I was on screen and the voice over audio I recorded separately, but luckily the music masked the difference in background noise.


Sources for Music and Video:

Music:

Ice Cream Sandwich, by Podington Bear
https://freemusicarchive.org/music/Podington_Bear/

Game Footage:

Frogger Video from Steverd99
Frogger developed by Konami, 1981
https://www.youtube.com/watch?v=l9fO-YuWPSk

Guess Who Video from Project Ad Hand
Commercial from 1992 for the game Guess Who? from Milton Bradley
https://www.youtube.com/watch?v=7XjW43YUgUA

Week 3: Video Planning and Storyboarding

With my script written, storyboard and shots planned. The last thing I need to do is get a couple of props made, and I'm ready to shoot this weekend. 

Since I added a storyline to my game, it's made planning the video prototype a lot easier and a lot fun too. I'm excited to film and edit and may even add some animations in if I have time). I'm hoping to shoot it all tomorrow morning, and *hopefully* do most of the editing tomorrow, maybe even get it done in a day. 

Storyboard:

Listing out my shots, props and locations

Concept to Prototype: Frogger X Guess Who

The concept I'm running with for now is a mashup of the classic games Frogger and Guess Who. While these games don't really have anything in common, I've taken some key components from each game to mix together into one awesome and challenging game, working title "Hop to Who?!"


Frogger elements:

• The game objective of getting the frog safely across the road.
• Timing the moves to avoid getting hit by moving objects such as traffic.
• The frog character and the level design.

Guess Who elements:

• Eliminating all the characters displayed so only 1 remains, by the help of descriptive clues.
• Physical interaction of flipping down tiles.

The Story of "Hop to Who?!":

The Frog is a lonely amphibian looking for love. He'll go to any length to find "The One" so he's risking it all by traversing across the dangerous highway all for a blind date. It's your mission to get him to his correct date safely. Make an ill-timed move and it's all over for him. Choose the wrong character and he'll leave broken hearted. 

How to play:

• The on-screen interface will display a frogger like level, there also will be a physical Guess Who style board with 16 character tiles shown face up.
• There are 2 objectives, both equally important. Get the frog across the road to safety and eliminate all but one of the characters correctly.
• To move forward the player has to flip down a character's tile
• The computer will show clues about what the mystery character looks like, so the player can flip down irrelevant tiles.
• The challenge is to flip the tiles down in sync with moving the frog to avoid collisions. This requires 2 mental processes to happen at once, strategic elimination and quick response.
• If the player gets the frog to safety, then there is the added reveal to check if they have selected the right character. Hopefully Frog can live happily ever after!

To Do Next:

Start planning the video prototype, writing the script, storyboard so I can shoot and edit this weekend. I also need to write the Statement of Delivery and a Testing/Evaluation plan. The next blog will be about the video prototyping process.

Week 3: Video Critiques

During this week's lecture we watched a few more examples of video prototypes, all with varying degrees of good and not so good points. Watching and discussing these videos definitely helped to break down what works and what is less successful in a video, and hopefully I can take away the good examples and apply this to my own video.


Brisbane Park Finder

First impression
Definitely not a compelling video, the communication of the concept wasn't clear, and the production quality fairly poor.

Can you understand the concept?
By the end of the video I did understand the concept, however I don't think it was completely clear from the beginning.

What questions does it raise?
They never really addressed what the problem was, and how their product solved anything and if there is a need for this product. They didn't show the product in use much at all, so I was left wondering if they successfully built the features they described.

What could they do better?
Show the product more and scenarios of it being used. There was a super quick shot of it being used, but the rest of the video only showed the guy describing how it worked, not showing it in use. Improving the audio, there was a bit of background noise.

What do they do well?
What they showed of the Park Finder looked good.

Is there a better way to show certain things?
Showing the demonstration of the Park Finder would have been better if the audio description matched the voice over. He mentioned an example of searching in Greenslopes, however the demo showed a different suburb, which I found distracting, and therefore detracted from what he was trying to communicate.

Quality of the video/audio
The video quality seemed fine. The audio had a lot of obvious background noise.



Google Docs in Plain English

First impression
Overall I found this quite easy to follow and rated it as an example of a good video.

Can you understand the concept?
Yes it was communicated very clearly. It uses appropriate language, and uses metaphors to help the audience understand more abstract concepts, e.g Docs is a "home" for our documents. The visuals supplement the description well and further illustrate their message.

What questions does it raise?
I think it's pretty well explained.

What could they do better?
Some of the production quality was quite lo-fi, but this may have been their intention. The voiceover and pacing was a little too fast and possibly could have been slowed down a bit to help viewers take the information in.

What do they do well?
They defined a problem at the beginning the of video and told the story of a user scenario which illustrated their solution.

Is there a better way to show certain things?
They didn't show the use of an actual Google document directly, with only explaining the features of Google Docs.

Quality of the video/audioIt was well produced, and the audio was clear.


Pegasus Game

First impressionConfusion about what this game is actually about

Can you understand the concept? No at all - only that it is some kind of board game - possibly?

What questions does it raise? 

What is this game about? What are the rules? Why should I play this?

What could they do better? 

Give some explanation about what the game is about, why it should be played, how is it played. The soundtrack wasn't really appropriate, especially considering it was the only audio track it felt unnecessary and distracting.

What do they do well? The footage of the game play looks of a high quality.

Is there a better way to show certain things? The gameplay needed description, showing various moves made in the game means nothing to the audience if they don't know the objectives of the game. This could be a voiceover, or text descriptions throughout.

Quality of the video/audio 

Production wise the quality was fine.



Gauss Glasses

First impression

Pretty good overall, perhaps too long in describing the science behind it.

Can you understand the concept? 

Yes, it was explained well, the problem and solution was clearly defined.

What questions does it raise?

I wasn't sure how these glasses rate against regular glasses. Also I was wondering how accurate the dangers of the blue light is, and how these glasses rate in protecting against it (maybe that's my inner sceptic thinking). Although the way they explained the problem of blue light did make me feel concerned, albeit quite alarmed when they showed the light burning the back of the eyes.

What could they do better?

Some of the animation, such as the moving graph of the light radiation I didn't understand, it looked very scientific, but I didn't know what the significance of the data was, so this could have been illustrates better. Also including some feedback from professionals like optometrists to help give quality assurance and professional back up to their claims.

What do they do well?

They definitely sold their product and it's benefits well, and compelled me to consider buying the glasses. They showed great video of the people behind the manufacture, so that assured me that they were going to be made well.

Is there a better way to show certain things? 

Some of the animation could have been done in a more refined manner (for example the burning eye animation) and the graphs could have been shown in a more approachable way.

Quality of the video/audio 

It was really well done and professionally produced.

Overall takeaways:

• A good video should introduce the problem space at the start, and subsequently offer a solution to this problem. 

• Relate the solution back to the audience, tell them why this product benefits them. 

• Communicate clearly, so that the whole audience can understand (i.e. don't use technical jargon if your audience are laymen) 

• Use scenarios to show the context of use and explain how the product works 

• Visuals should support the audio descriptions. 

• Inferior production quality can detract from the video's message and professionalism.

Week 3: Ideas

So far I've come up with 2 potential ideas to prototype:

Wearable Idea

• Problem: Meeting new people can be daunting for the first time and can create social awkwardness/anxiety
  
  Solution: A small wearable display that either encourages or dissuades social interaction by showing compatibility with those around you. If you meet someone who shares no common interests it can be awkward or tedious to have to make conversation with that person. Using this, people will enter their interests in a companion app. When you get near to someone (who's also wearing one) the device will display a happy face if you have many things in common or a sad face if not. You can now avoid people based on this and find people who may be more compatible. Alternatively you could challenge yourself to talk to people with no common interests as you. Either way, people would have some conversation material to break the ice.
  
  I'm not sure how I'd use this concept for the interactive prototype 2 requirement. This requires a physical input component, using the MakeyMakey to create a novel physical interaction, and this concept so far doesn't really afford any creative physical interactions now, apart from wearing the device and looking at it's display.

Game Mashup Idea
The idea I've been thinking about so far is a mashup between Guess Who and Frogger:

• Combining the guessing/elimination element of Guess Who with the gameplay of Frogger (i.e. crossing the road while avoiding danger).
• The aim is to navigate the frog across the road to safety and also eliminate other characters to reveal 1 final character (this character could be revealed once all others are eliminated and the frog crosses the road)
• The computer chooses a character. The player has to make a guess based on the given options about the characteristics of the unknown character (e.g. is it/he/she wearing a hat?). Each correct elimination allows the frog to make a move across the road.
• Physical Interactions: using large tiles like in Guess who with different characters displayed, each time the player flips one down allows the frog to make a move. The player has to time each flip to avoid moving objects, which is shown on the screen.
• You lose if the frog dies (by getting hit) or if you guess the character incorrectly.
• The game could be 2 player, the fastest player to cross and guess correctly wins.

This week's plan is to choose one of these ideas (I'll get some feedback from other people) and elaborate on how it can be prototyped.

I need to start on planning a script and statement of delivery for the video prototype, so I can start filming on the weekend. I'm aiming to edit it and finalise statement of delivery by early next week, before the Wednesday deadline.

Week 2: Video Editing

In today's prac we were introduced to video prototypes and shown some good examples of explainer and Kickstarter style videos. Pete also explained some best practices when shooting video and the process of planning and creating a good video.

We then had a chance to practice our video editing skills using Photoshop. I'm quite experienced with Photoshop and I've used some video editing software in the past, so using the video timeline wasn't too challenging. Being able to use the other Photoshop tools such as adjustment layers in video was also handy.

Here's my final creation:

Week 2: Prototyping with Augmented Reality

Augmented Reality (AR) blends the digital and the real, allowing people to visualise 3D virtual forms in a physical setting in real time. 

Inition's "AR 3D printing"

Using AR when learning to weld with Soldamatic

Using AR as a prototyping tool allows users to experience a realistic simulation of the the prototype without very little or all functionality.

Using Microsoft's HoloLens as a protoyping tool

Exercise: Design a variation of an everyday object, using AR as a prototyping tool

The everyday household object that I have chosen is a floor lamp. The design variation on the stock standard lamp is a lampshade that can change design and be customised to suit the owner's aesthetic preferences. For example, the lamp shade's colour could be changed to suit the interior decoration of a living room, it could display a montage of the owner's Instagram photos, or it can project unique moving silhouettes over the room. 

Customisable lamp shades could look similar to this. Source: Random Good Stuff

It may be difficult to produce a working prototype to communicate how the final product may appear, especially in early stages where the technology may not be fully realised (possibly using something like projection mapping or coloured e-ink).  Using AR will allow designers and users to visualise the different design possibilities and get a good understanding of the final product. 

Colour-changing film, E-Ink's Prism

The AR device will digitally project the user's chosen lampshade preference onto the plain lampshade which acts as a green screen. The user can customise the lamp's settings using a paired smartphone app where they can choose from various colours or patterns or import their own images, and see them displayed on the lamp in real time. 

References:
http://www.dezeen.com/2013/01/04/inition-develops-augmented-3d-printing-for-architects/
http://www.cnet.com/news/the-next-big-thing-in-tech-augmented-reality/
http://www.pcworld.com/article/2873657/hands-on-with-microsofts-hololens-the-3d-augmented-reality-future-is-now.html
http://gizmodo.com/color-changing-e-ink-is-here-but-not-in-ebook-readers-1677767392

Week 2: Prac Review

In today's prac we got together in small groups and did some brainstorming for the 2 prototype challenges. 

First we came up with some examples of faux pas, awkward or embarrassing behaviours:

• Rude interruptions in conversation
• Asking (mistakenly) if someone is pregnant
• Eating habits - too noisy, with hands, mouth open
• Walking in public spaces - a large group of people taking up the whole path, standing on the right side of an escalator, stopping in the middle of a thoroughfare or the top of an escalator.
• Playing loud music on public transport
• Speaking too loudly on the phone
• Not controlling naughty children

We then had to take one of these social faux pas and generate an idea for a wearable that transformed this behaviour either in a subtle way or an obvious way.

Our idea was a small wearable device like a lapel mic, that while listening to the wearer's conversation, it can detect if something offensive is said to another person. If an embarrassing remark is spoken, the device sends an alert to the wearer's phone, prompting it to start calling in order for them to avoid any further embarrassment or confrontation. The wearer can then make a convenient escape. 

Then we chose 1 game from each column and discussed the main features of each game, and what was the most fun, challenging or interesting element from each. 

For Hangman some of the features we discussed included the challenge of choosing the best letters, process of elimination, limited "lives", the different rules players have for drawing the hangman, the fun in drawing each line one by one to form the complete picture.

For Guess Who, features included the process of eliminating characters, choosing the initial character that is hardest to guess (eg doesn't have any striking individual features that can eliminated quickly), the physical actions of flicking the tabs up and down and the noise they make.

For Lemmings we talked about the problem solving aspects of the levels, there are multiple paths/solutions, puzzle game, the cute characters, wanting to protect and guide the lemmings.

To create our Hangman/Lemmings mash up we took 1 aspect from each game to create a new game "Hanging  by a Thread". Our somewhat morbid game took the cheating death theme from Hangman (ie the relief you feel when your man doesn't get hanged), and from Lemmings, the cute characters that you form an emotional attachment with. 

Or game works like hangman where you guess the mystery word. However each wrong guess brings a guillotine blade closer to a cute kitty. Every time you guess right prolongs the kitty's time to doom, and if you get a correct answer you get some kind of time extension or the blade lifts further up. You can even get some rewards for your cat while it's waiting, like a bowl of milk or a toy :)

Today's prac exercises were really helpful in getting the ball rolling in generating concepts for the main project. Hopefully I can continue exploring some fun and creative ideas to prototype!