Interactive Prototype III - Play Mines Between the Lines v1.5 + Money Cash Version!

As in Prototype II, you can use mouse input to select dots, or use keyboard input. Move the cursor which focuses on a box using the WASD keys. Select a side of a box using the arrow keys. Press F to reset, or click on the reset button.
Here is also a 'dark horse' prototype - a money cash version that I started on during the Interactive Prototype III stage!

Interactive Prototype III - Statement of Delivery

Interactive Prototype III – Statement of Delivery

Concept Prototype

This prototype will explore the concept of a mashup between two classic games, Minesweeper and Dots. Two players take turns connecting two adjacent dots with horizontal or vertical lines to form boxes with lines on 4 sides. When a player claims a box, the corresponding square in the mine grid is revealed, which can be numbers (that give points, and correspondingly reveal the number of mines in adjacent squares), or mines, which they lose points upon revealing. Players click dots using a mouse to create the lines, or can alternatively use the WASD to select a particular boxed area, and then the arrow keys to select a particular side of the box (top, left, bottom, right) to draw a line.

Visit my blog for more details on game rules, prototype testing, and play an early prototype of the game yourself at http://jasonh-deco2300.blogspot.com.au.

Form of Prototype

From Prototype II, the prototype is a combination of a digital game with physical inputs. The digital part of the game, which is mostly the game board, and score board, is coded in Actionscript 3 (Flash) and played on PC. Additions to the digital part of the game in Prototype III included the functionality of the reset button, and also an indication when the game had ended and telling which player had won the game.

The physical inputs are controlled using aluminium foil on a square piece of cardboard (held together with Blu-tack), with 4 central inputs for box selection, and 4 outer inputs for edge selection. MakeyMakey allows interfacing between the controller and the game by use of wires and alligator clips, and connecting to the PC via USB. MakeyMakey is special in that it allows almost anything that conducts even slightly to be turned into a physical input.

The MakeyMakey interfacing chip and connecting wires are neatly stored in the box below the square piece of cardboard.

Changes that were made between Prototype II, testing of Prototype II and Prototype III to the physical MakeyMakey controller include replacing the central Blu-tack inputs with short aluminium strips, two earth ‘ring’s for players to wear to connect the MakeyMakey to earth via alligator cable, and metal strips that could be placed to give the impression a player was ‘placing’ a line onto the game board.

There were also attempts to make a ‘dark horse’ prototype, by adding the element of cash, and being able to ‘buy squares in the game, functionality was added to the digital part of the prototype.

Figure 1: Screenshot of Mines Between the Lines (MBTL) v1.5 with full keyboard interaction and box selection pointer.

Figure 2: Screenshot of Mines Between the Lines (MBTL) v1.5a, Dark Horse Prototype, with sprites for cash, representing money added into the game.

Figures 3-4: Photos of the updated physical input controller, with ‘edge selecting tool’

For Prototype III, instead of using a bulky metal ruler or fingers to select the edges, I custom made aluminium foil strips that roughly match the size of the square on the face of the controller, to give the players a sense of placing an edge onto the game board.

Purpose of Prototype

The purpose of this prototype is to further explore additional features, and playing multiple games of MBTL with the addition of the reset button and end of game notification. The dark horse prototype is an experiment to add a new dimension to the game, in the form of cash as a form of currency used to buy squares.

Testing and Feedback

For testing, users will play through a game on a 5x5 dotted grid using physical inputs to control the selection of dots. They will additionally will able to play the game using mouse input and/or keyboard.

For feedback, it will be provided through a combination of verbal and written feedback. Participants will be asked to write down answers to the following questions (which have been improved from Prototype II):

1. How much do you feel like you are “placing” a line on screen by placing a metal bar onto the edges of the physical input “box”?

2. Are 8 buttons, 4 for selecting a box, 4 for selecting a side of a box (a line) too many/too complex?

3. I have considered adding in additional score popups (+1 points, +3 points, “You uncovered a mine!”), as a player takes a turn, to make things clearer. What do you think of this?

4. What other game controls would you like in the game? (Eg: select grid size, number of mines etc)

5. [Dark Horse Prototype Only] Earning cash to buy squares is an important addition to the Dark Horse prototype. Comment on how this affects the gameplay (eg: another layer of strategy, makes the game unbalanced, makes the game feel like Monopoly etc.)

6. List any queries you may have about the game rules, or strategy.

7. Any other questions or comments?

Decisions Made

For Prototype III, there were several directions I could take my prototype in, and limitations and time constraints meant that I was not able to fully explore every option. I could continue my game along the standard route, adding in the option to flag squares, and other features from Minesweeper and Dots game, or I could take the Dark Horse prototype route, where I formulated an idea to replace/complement points in the game with cash that could be used to buy squares, place mines, steal points and other actions.

Standard game continuation:

I removed the ability to take another turn after a player captures a box. During Prototype II testing it was found to be too confusing, as Player 1 would accidentally take Player 2’s turn and vice versa.

I decided to add in the reset and end of game functionality first, as it was relatively simple to code.

When deciding on how to code the flagging option, I ran into problems with the opposing player able to see where the flag was placed and avoiding the square, when the opposing player could have been about to uncover that square anyway. I later decided that you could only flag a square if you were going to immediately claim that box for yourself.

Dark Horse Prototype:

This prototype involved being able to earn cash, simply by uncovering lines. Players would earn $10-$40 for drawing a single line (determined randomly), and could buy an uncovered square for $100. This means that when that square was uncovered, they would be able to receive double the usual points for that square (if 3 points, they now receive 6 points), if they had bought that square. For squares that had already been bought and uncovered, they had a chance to steal points from a square by playing $150, which would result in an opponents claimed square losing its value (a 4 point worth square could be worth 0 points to the opponent afterwards). This had a chance of failing however.

I was unable to implement all these specific rules in my coding, however it would have been very fun to test out this planned prototype in full.

Week 12 - Review of What is a Prototype? (Week 1)

How has your understanding of prototyping changed since week 1?

What would you change about your initial description?

How is that related to your experiences.

In Week 1 I wrote a blog post defining what Prototypes were. I have modified it for this post:

Prototypes are in-progress models used to demonstrate basic concepts of a final product. They are not usually in a finished state; rather several important functions are highlighted for testing in the prototype.

Prototypes can take many forms, from flat, to 3D, to digital; the main purpose is to convey the overall concept of the idea to people. For projects such as car parts, physical moving parts may constitute part of a prototype, where as a prototype for a website could a series of hand-drawn wireframes.

The most basic prototypes can be simply drawn with pen and paper. Depending on the detail and complexity required, prototypes could be made out of clay or wood, or digitally created using software, or uses a combination of both physical and digital components, such as a MakeyMakey (as a custom controller), and a Flash application on a computer.

Prototypes are an important part in determining if the final product will work. Prototypes simplify a product down to the core concepts so that if something isn’t suitable, it can be spotted easily and fixed. They help determine strengths and weaknesses in the product design. The interface of a prototype may not be fully polished, but clear enough for users to test features of the product.

Without prototypes the designer could lose a bit of focus on the practicality of the core concepts of their idea. They might create something that is almost useless in real-life, even though it may stem from a solid idea.

Now, at the end of the DECO2300 course, I have gained hands on experience into digital prototyping and what prototypes really are. Although my Mines Between the Lines prototype progressed significantly from its design stage to functionality, it wasn't complete, but was quite a functioning prototype. From the Week 4 contact I am able to further define my prototype as a sort of diagonal prototype, containing most features, with enough detail to discern between them, but simple graphics. The graphics I used in my Video Prototype to illustrate my game mashup (created in Adobe Illustrator), were very similar if not the same to the ones I used in my prototype in Flash, so there is a familiar point of reference, and gradual refinement of the same idea methodology to those who view my Video prototype and then progress to experimenting with my interactive prototype. Overall my definition of a prototype remains mostly the same, it's just that now I have extra experience in creating prototypes for myself, along with many techniques (CRC Cards, Set-based Design etc).

Week 11 - Set-Based Design and the Pugh Matrix

Today's contact was about Set-Based Design. There was an interesting Pugh Matrix that applies to web pages and web sites using criteria on a 7 point scale.

For Set-Based Design there are several principles to follow:

1. Map the design space (define feasible regions and possibilities, and explore trade offs)

2. Integrate by Intersection (look for intersections, conceptual robustness)

3. Establish feasibility before Commitment (gradual convergence, stay within agreed sets)

As compared to point-based design, which is defined up front, and designed before developed, and can require repeating of iterations.

This contact taught us a different way of thinking design which hadn't been talked about in previous contacts.

Exercise:

The exercise is about the Theremin, a remarkable electronic musical instrument that can detect movement of the users hands/arms in 3D space and reproduce sounds based on that positioning. The user does not need to actually touch the instrument itself.

The Pugh matrix is useful for comparing different input methods in playing a Theremin duet/orchestra. The input methods I have chosen are:

Xbox Kinect: it can capture movement in 3D space, such as hand movement, which is very suitable for the function of the Theremin.

Joystick: A joystick maybe able to control in different directions through different controls, in order to allow the Theremin to be controlled.

GPS: The GPS positional data can be transferred to a computer in order to control the Theremin in 3 dimensions.

Several lasers in a grid can pinpoint positioning of objects that are in the lasers' firing lines.

Criteria for each of the input methods are:

Accuracy - Playing the correct note on the Theremin

Responsiveness - the time it take for the signal from the input method to reach the Theremin

Affordability - the cost to set up the input method. Higher score mean less cost

Ease of use - Whether a user is able to pick up and use the input method immediately or, requires learning beforehand

Portability - the size of the input method

Ease of implementation - the ease of setting up the input method

The Xbox method seems to be an effective method to control the Theremin that models the movement in 3D space, but the Joystick also seems to be an effective method.

Week 9, 10, 11 Prac Notes

Here are the prac notes on the whiteboard from Week 9, Week 10  and Week 11 pracs:


Week 9

DECO2300

Peter is sick so you’re stuck with me

Today

MakeyMakey Challenges

Coe help with assignments

Challenges

Create an interface that

Involves blowing air

Requires objects to be thrown

Involves tilting

Involves hand gestures

Week 10

(Tutor Eval today)

Please complete a form

DECO2300

Tomorrow 4pm Code + SoD due (blackboard)

1.       Outline your game/application concept

2.       Link to blog post with detailed description

3.       Describe this prototype

a.       Purpose (hint text physical interation choice/method

b.      Specify what aspect you are testing

c.       What do you hope to find out

4.       Describe form of prototype

5.       Testing approach

a.       What will you ask people to do

b.      What feedback will you be looking for

c.       How will you get that feedback

6.       Decisions you made

a.       Include/exclude

b.      Why

The game application concept that is being tested is a mashup of two classic games, Minesweeper and Dots. 2 Players take turns connecting two adjacent dots with horizontal or vertical lines to form boxes with lines on 4 sides. When a player claims a box, the corresponding square in the mine grid

Week 11

Week 10 - Experience Prototyping

Today's contact was about experience prototyping.

Exercise

Restaurant Dining Experience

What is the existing experience? From different

stakeholder P.O.V.?

What external/internal factors impact on the experience?

What aspects of the existing experience could be

enhanced/augmented/supported with technology?

How would introducing technology in to this context

change the experience?

What experience scenarios might you test with the

technology?

The existing restaurant dining experience is composed of customers entering a restaurant, sitting down at a table, and ordering their meal with the help of a waiter who will be taking their order. The customers then wait for their food and when it arrives they start eating. After they have finished eating, they indicate they want to pay the bill for the meal and leave. The waiter in a restaurant dining experience has to run around taking orders from many different customers, and then passing them onto the restaurant's kitchen. When the food is ready, the waiter also delivers the food to the customers on plates and trays and the like. For the cooks in the kitchen, their job is to ensure fast production of food, according to the waiter's collected orders, with the additional preference that the food for everyone on a particular table is ready within minutes of each other. Sometimes a restaurant inspector might be an external factor, coming in to inspect the various systems of the kitchen. The restaurant's reputation could also affect the experience, as well as the design of the restaurant itself (tables, chairs, wall painting etc). Also the smell of food, the quality, the ambient noise level are environmental factors than can affect the desirability of a restaurant experience. The experience could be augmented with online/fast ordering, possibly able to order with the customers smartphone via an app, and be able to receive the food when they arrive. This would change the way waiters receive orders

Interactive Prototype II - Video: Users testing my prototype!

I took several videos of users interacting with my prototype II. Here is just one: