Week 8 - Physical Interactions!

Contact Week 8 Notes:

Tangible Interaction:

Using physical game controllers: Wii Controller, steering wheel, Guitar Hero controllers

Answering Machine, marbles, to represent people/messages

ReacTable – drag elements, building blocks of electronic music http://www.reactable.com/

Central white dot pulsater

Generators, Effects and filters, controllers, global controllers

Super Angry Birds – physical slingshot, controller for angry birds, physical objects. Software programming.

Cylinder shaped, flows in water, creating digital pulsating colour waves, water pollution data.

Big-Mac-Index, digital screen how long to exercise to burn the calories of a big mac,/buy a big mac.

Human Diagram – create information graphics with your own body – pressing on icons with your foot on the ground? Showed silhouette (colour) on another board?

Sound Memories – Store memories in sound form, for blind person. Put a weird physical circular thing into a machine.

Other Tangible Interfaces

Plugg, SKAL, Daily Stack

Exercise:

Email, Twitter, Super Mario Bros (the platformer game)

Come up with 5 different physical interactions for each

What are the elements/controls of each application?

Eg: What are the basic controls in Pong, how could you map them to physical action/input?

Bike cycle forwards and backwards, seesaw, air controlled pong, ladder, pulley

Email:

Sending and receiving - moving a ball/marble between two different plates (similar to the answering machine example)

Open a 'mailbox' to check your inbox

Throw a physical envelope into the bin to delete a message/send to junk

Draw a coloured box around several emails to put all emails in the same category

Open up an envelope (representing someone's email) to reply to them

Twitter:

Using movement of a bird model to send a tweet

Drop a rectangle object (representing a 'physical' tweet) into a box to retweet it on your profile

Actually place stars on 'physical' tweets to favourite them

Place a 'physical' tweet into the "hashtag box" (specially hash shaped) to find other tweets with same hashtags

To follow a person place your "profile box" onto someone else's "profile box"

Super Mario Bros:

Physical coins (objects) dropping, to represent dropping of coins

Use a 'Dance Dance Revolution' style control pad to control Mario with feet on the floor

Punch the air to throw a fireball (if available)

Clap your hands for Mario to jump

Run on a treadmill for Mario to move forward

Interactive Prototype I/II - FEEDBACK!

Below are the questions I asked users for Prototype I and the feedback I received when they tested my Interactive Prototype I: (EDIT: This also contains feedback for Prototype II).

Week 7 Prac Notes

Here are the notes Peter put on the Whiteboard for Week 7's Prac:

Wed 4pm (tomorrow)

1.       Statement of delivery + code (fla + as) to BB

2.       Thursday Testing

Prototype

1.       Appropriate for what you are doing

2.       Functionality complete for your testing

3.       Demonstrate understanding of OOP

4.       Comment

5.       Reference

SoD

1.       Brief description of concept and link to blog post with more detail

2.       Purpose of prototype – what aspects of proto are you testing and what do you want to find out

3.       Describe form of proto

4.       Testing approach

a.       What users have to do

b.      What feedback do you want

c.       How do they give you feedback

5.       Decisions in making proto

Week 7 - Designing Questions

Looking back at my Prototype I user questions, I realise that several of them lack clarity. Here are the questions I asked users when testing my Prototype I:

1. Comment on the suitability of mouse input to play the game (also, Alternative ways, keyboard input?)

2. How suitable are the positioning of the game elements?
3. How suitable is the size of the board? (eg: 5 x 5 suitable for short games, 10 x 10 for longer/fuller games)

4. The points for squares and mines, is it too much or too little?

5. How big is it of an achievement do you feel when gaining or losing points?
6. Are there too many things to keep track of? (Eg: confusing, or able to formulate a game strategy?)
7. Anything else to add here.

If you noticed, these are slightly different to the ones that were in my Statement of Delivery. I decided to define them more clearly, shortly before testing in the Week 7 B Prac.

From the Week 7 contact, I find I have a few tendencies when creating my questions. My questions seem to be compound, in that they ask for more than one thing in a single question. Additionally, I tend to provide supplementary questions in brackets for some of my questions in the hope of clarifying things.

So, to list them out, questions 1, 6, 7 are qualitative, and questions 2, 3, 4, 5 are quantitative, though not the best examples of quantitative. This is because most of my questions turned out to be closed questions, which can be answered in one word. If I could redo my questions, they would be something like this:

1. What do you think about using mouse input to play the game?
2. Comment on the positioning of the game elements.
3. Which size of board is most suitable? 5x5? 10x10?

4. How big do you think the penalty for uncovering mines should be? -1 points? -2 points? -3 points? -4 points? -5 points? More than 5 point penalty?

5. Comment on your own sense of achievement when you gain or lose points.
6. Is this game too complex?

7. How satisfied were you with your own game strategy? Very Satisfied, Satisfied, Neither Satisfied nor Satisfied, Dissatisfied, Very Dissatisfied.

8. Add any other comments here.

These questions may be harder for users to answer, but I feel that they could give clearer feedback for use in my future prototypes.

View my other blog posts to see my questions and the feedback I received for Prototype I.

Play Mines Between the Lines! (v1.1)

Interactive Prototype I - Extra content for Statement of Delivery

The content in the previous blog post consisted of the Statement of Delivery I wrote for Interactive Prototype I. The content below is EXTRA content that was not included in the Statement of Delivery, detailing about my process in adding features of my prototype.

Addition of Dots Features

The code I obtained for connecting two dots was a good starting point. However there were some things that needed to be added manually as I modified and integrated the code:

1.       Creating the Grid of Dots: From the Connecting Two Dots sample.

2.       Adjacent Dots: I added in detecting whether two dots clicked were adjacent horizontally or vertically, and prevent the drawing of a line if not. (would originally connect any two dots clicked)

3.       Tracking Lines: Keeping track of which horizontal and vertical lines had been drawn, done using arrays.

4.       Detecting Boxes: Detecting when the lines formed a box, and recognising that a box had been claimed accordingly.

5.       Player Turns: Detecting player turns and changing player turns after a player had made a move.

6.       Visual Indication: Indication on the board for creation of coloured lines, boxes.

These steps required quite a bit of experimentation to get right.

Addition of Minesweeper Features

Up to this point, the prototype was functionally complete from a Dots game perspective. Implementing the Minesweeper functions was the next step. These steps included:

1.       Generating Random Mines: This function was in the Minesweeper Game I used as a reference and I modified it to integrate it into my prototype.

2.       Number of Neighbours: Calculating the number of neighbours for each square was a lengthy function that I modified from the Minesweeper game. Eg: corners have 3 neighbours, wdges 5 neighbours, and centre squares have 8 neighbours

3.       Generating Random Numbers: Using the getNeighbours() function, the number of mines in neighbouring squares was calculated and therefore the numbers could be generated indicating the number of mines in neighbouring squares.

4.       Displaying the numbers: This step I had to experiment with my own code, and create an array to hold the numbers to be drawn.

5.       Fine tuning of display: Added coloured numbers, a different graphic for mines, added score and player turn indicator.

Features Excluded

I made some decisions to exclude extra functions that would have been completed after the above features were working.

1.       Dots on hover or click: Adding in a hoveron and hoveroff states was something that I attempted to partially implement, however would have required rewriting several parts of my code.

2.       Flagging option: Adding in the option for players to flag their mines was secondary to ensuring the mine grid was actually working first.

3.       Reset option: For the purposes of this prototype, the .swf can simply be closed and reopened again. I however did add a dummy reset option to test positioning of the button on the screen.

Problems Faced

1.       Layering of objects: I had a problem with the text of the numbers covering/on top of the dots, resulting in being unable to click on these dots. This was because the TextField area that contained the text had significant padding added to all sides of the text. To combat this, I could either make the TextField smaller so that it wasn’t on top of any interactive elements, or send the Textfield to the back, below the dots.

a.       Previous Order (from top to bottom): Numbers, Squares, Dots, Lines.

b.      New Order: Dots, Lines, Numbers (send to back first), Squares (send to back second).

Interactive Prototype I - Mines Between the Lines in Actionscript (SoD)

Interactive Prototype 1 – Statement of Delivery

The concept is a mashup between two classic games, Dots (aka Dots and Boxes) and Minesweeper. This interactive prototype was created in Actionscript 3 using Adobe Flash Professional CS6.

This prototype will be testing the basic concepts that mirror features in the Dots and Minesweeper games. A detailed breakdown of my prototype can be found on my blog at: http://jasonh-deco2300.blogspot.com.au/2014/09/the-content-in-previous-blog-post.html

The prototype involves 2 players taking turns moving the mouse and selecting dots in a square grid using the mouse. When two adjacent dots are selected, a horizontal or vertical line will be drawn between the two dots. If a player manages to create 4 lines in the shape of a box, they claim that box and any points which are in that box. Points in the boxes are determined by a hidden minesweeper grid and are revealed automatically as boxes are claimed. The interaction between the mouse controlled by the player and game screen (input and output) will be focused on in the testing of this prototype.

Figure 1: Mines Between The Lines Prototype Sample

Figure 2: Mines Between the Lines Game Sample (with Reset Button)

The main game board is centred in the middle of the window. To the left and right are score counters for the two players. Below is text indicating the current player’s turn. In the bottom right are just samples of what the numbers and mines look like (non-functional).

For testing, users will play through a game on a 5x5 dotted grid.

For feedback, I will be looking for things such as:

                How suitable is using mouse input to play the game? Can you suggest any alternative ways to play the game? Would using keyboard keys (arrow keys or WASD) be easier to understand? Easier to control?

How suitable is the positioning of each of the game elements? (relative to the window, relative to each other)

Eg: Main game in the centre

Player turn at bottom

Scores to the left and right

Title at top

How suitable are the colours of the elements?

Is the size of the board suitable for the game?

                Is 5 x 5 suitable for short games / testing?

                How about 9 x 9 or 10 x 10 dots for a fuller game?

The points awarded for squares and mines, is it too much or too little? Is it balanced?

How big of an achievement is it (do you feel) when you gain or lose points?

Are there too many things to keep track of? Or are you able to keep a clear strategy in your head?

What parts of the game do you find the most confusing?

Feedback will be given through a written survey and additional verbal feedback.

During the making of the prototype, I decided to find some samples of Dots and Minesweeper games that had already been made in Actionscript and use those concepts in my prototype. These included drawing the lines between dots in a grid, and generating the mines and numbers randomly. These functions were incorporated into my prototype as to provide functionality that had already been written by other people.

Connecting Two Dots: http://www.actionscript.org/forums/showthread.php3?t=277270

Build a Minesweeper Game Within 200 Lines of Code: http://code.tutsplus.com/tutorials/build-a-minesweeper-game-within-200-lines-of-code--active-8578

More details can be found on my blog post: http://jasonh-deco2300.blogspot.com.au/2014/09/the-content-in-previous-blog-post.html

The first step was to take the code from Connecting Two Dots and make it into a functional Dots-only game. The code I started with allowed drawing a line when any two dots were clicked. I built on this and added, line detection and tracking, box filled tracking with the use of arrays.

Implementing the Minesweeper functions was the next step. As Minesweeper itself is a complicated game, there were a few features that I did not include in the prototype. These included the option to flag square where players think mines might be located, and other small features such as the reset button, and for the dots to change appearance when hovered on with the mouse.

The final big problem before I had a functional working prototype was with the text of the numbers covering/on top of the dots, resulting in being unable to click on these dots once a square with text appeared. This was because the TextField area that contained the text had significant padding added to all sides of the text. To combat this, I could either make the TextField smaller so that it wasn’t on top of any interactive elements, or send the Textfield to the back, below the dots. However I also needed the square background below the numbers. I combated this by calling the numbers function first and sending to back, and then the squares function and sending to back.

Previous Order (from top to bottom): Numbers, Squares, Dots, Lines.

New Order: Dots, Lines, Numbers (send to back first), Squares (send to back second).

Week 6 Prac - Pong in Actionscript 3!

In the pracs this week, I continued the Pong tutorial on Blackboard. It introduced me to classes in Actionscript and went through step by step, adding in game elements such as the paddles and ball.

Week 6 Contact - Actionscript 3 and CRC Cards!

Today's contact delved into the framework for our Prototypes: programming in Actionscript (Flash). The contact talked about the basics of Actionscript 3.0 being an OOP language (Object-Oriented Programming), which we had begun exploring last week after finishing our Video Prototype. Personally I had already had some programming experience in several languages and knew about commenting, indenting, and print values for debugging in writing and testing code, as was mentioned in the contact. The specifics of classes however I had a rough idea about but today's contact gave us examples in the form of a Car class, creating car objects with different attributes from the class 'blueprint'. Actionscript, as I had started to figure out last week inherited classes into sub classes, such as "extends MovieClip", used to display an image when defining it in one of our classes.

To help us further understand the class - object hierarchy and how it helps us to manage creation of objects in Actionscript, we were invited to break down our own prototype into concepts and then list them as CRC cards (Class-responsibility-collaboration). Then we could use this knowledge to actually shape how our Actionscript code might look like when it came to coding our prototype.

Knowing the nature of my prototype was quite complicated, it being a mashup of Dots and Minesweeper, I created my own sort of headings in breaking down the concepts of my prototype as I crafted them into CRC Cards:

Week 3, 4, 5 Prac Notes

I wasn't quite sure where to put this in terms of the blog, but I decided to put it anyway. Here is a collection of notes from the Pracs in Week 3, 4, 5. Some of the notes I wrote for myself personally about things we explored in the Pracs, some are copied directly from the Prac summary Peter put on the Whiteboard in the Tuesday Pracs.

Week 3 Prac Notes
Week 4 Prac Notes
Week 5 Prac Notes