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:

Interactive Prototype II - Play Mines Between The Lines v1.3!

Prototype II introduces 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. Alternatively you can still use the mouse to select dots, same as Prototype I.

Interactive Prototype II - Statement of Delivery

Interactive Prototype II – Statement of Delivery

Concept Prototype

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 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

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. The physical inputs are controlled using aluminium foil and Blu-tack on a square piece of cardboard, 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.

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

Figures 2-3: Photo of physical input controller.

On the physical input controller, the central inputs correspond to the box selecting pointer, controlled by the WASD keys, the outer inputs correspond to the sides of the box that can be placed, controlled by the arrow keys. Another piece of aluminium foil (which can be worn as a ring) is used as the earth controller wire to allow MakeyMakey to create a circuit and send the input to the prototype on-screen.

Purpose of Prototype

The purpose of this prototype is to further explore different ways to interact with the game, other than the standard keyboard and mouse inputs. MakeyMakey was an ideal experimental ground for testing other physical inputs, as almost anything wired to the MakeyMakey can be used as a “button” controllable by the player.

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 (as in Prototype I), as the prototype supports both inputs concurrently.

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:

1. How does using keyboard keys via physical inputs feel compared to using mouse input?

2. What do you think of having separate controls for selecting a box, and selecting a side of a box (a line)?

3. How suitable are the positions of the controls relative to each other? (box selection in middle, edge selection on the edges)

4. How much do you feel like you are “placing” a line on screen by correspondingly placing a metal bar onto the physical inputs (on the edges)

5. Do you have any more suggestions to make box selection (central physical inputs) more prominent?

6. Do you have any queries about the game rules, or strategy? (more relevant to Prototype I)

7. Any other questions or comments?

Decisions Made

As in Prototype I, features had to be excluded due to limitations of what I could code in Actionscript in time to test as a prototype. These included the implementation of a flagging option, as the dilemma of capturing two boxes at the same time in a single turn, when one box awarded points and the other a mine (lost points), was to be remedied by the ability to flag a square beforehand, and not suffer the penalty for uncovering a box with a mine. Another feature included the ability to reset/restart the game. Extra physical inputs for these features would not have been reasonably difficult to implement, however the Actionscript programming for these features was not implemented in time.

I made a decision to focus on the basic moves of placing a line betweeny two adjacent dots and creating boxes with these lines. In Prototype I, I implemented controlling of the game using mouse input. MakeyMakey does allow for mouse inputs (it has the ability to track mouse movement in 4 directions as well as left and right clicks), however my Actionscript prototype would be fiddly to control with MakeyMakey, as mouse input requires precise clicking of dots on thescreen. For Prototype II, I fully implemented keyboard interaction. I decided that the best way was to split interactions between choosing a “box” in a 4 dot region and choosing two dots to place a line between. I received a helpful piece of feedback during Prototype I testing that instead of selecting two dots, I should select the line between two dots directly. These lines corresponded to the 4 sides of a box.

I originally had the box selection as the arrow keys, and the edge selection as WASD keys, however I swapped the controls, as wiring up the MakeyMakey was more convenient with the box selection as the arrow keys as they required alligator clips to work properly. The WASD keys used thin metal wires instead.

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).