DECO2300 WEEK 9

In this weeks lecture we conducted an exercise where we deconstructed the restaurant dining experience. The first matter of business was dissecting the internal and external factors that impact on the dining experience.

External:

• Temperature
• Parking
• Travel distance

Internal:

• Service Time
• Do staff enjoy their job
• Quality of food
• What kind of equipment does the restaurant have

With these factors taken into consideration, we were tasked with determining what experiences could be supported/augmented with technology and explaining how the technology would change the experience.

Some chefs are embarrassed to be seen pouring oil

Air-conditioning - alleviate extreme temperature

Automated parking - robots that park for you

Digital order system - Each chef in the restaurant possesses their own pda, in which they personally take over order without the need for running around paper

These robots are the future

Robotic waiters - Replace those low income bus-boys with robots! These robots won't complain about long work hours or harsh conditions and with an oil change a week you will never have any employee down time.

MSG dispenser - A machine that injects a quantity to balance the flavour of any poor dishes.

An ideal experience scenario for some of these solutions would be on the set of Gordon Ramsey's Hells Kitchen reality TV show.

DECO1800 WEEK 9 Demonstration Reflection

This week every team in our class was tasked with holding a demonstration as part B of their major assessment. Similar to our last presentation Clancy and I presented our work in progress. We began the presentation with a couple of flow charts showing the evolution of our idea over the past few weeks.

So far our we have a working version of a block breaker game, though the article implementation has been altered to a pre-defined newspaper article. I would have preferred to use journal text, though that proved impossible due to the nature of the data stored in Trove. During our presentation we were given valuable feedback on making our game more educational and more integrated with Trove's api's. A student suggest we include quizzes whenever a player loses their life, with questions relating to the article text and another student suggested we implement an image search in place of the missing article search.

DECO1800 WEEK 8

This Week I ran into a serious problem. After using PHP to follow a link to the page where there would supposedly be free online article text I found I was unable to access any text. The reason for this was surprisingly simple. Most sites used a PDF window to display their journal articles, whilst copy pasting text from the page in person was possible, accessing the text through JavaScript or PHP was impossible (particularly to someone with my experience).

Hey Tutors! Leave us kids alone

What I need to do is determine a different source of text that I can use to populate my teams game. I must attempt to salvage the use of newspaper articles or perhaps access article text from books.

This issue has caused a considerable degree of stress to myself, but I intend to work out a solution with my group members next week and work around this problem.

DECO2300 WEEK 8

This week we learnt about functionality and interactivity in regards to prototypes. We touched on experience prototyping and increasing the complexity of interactions. After watching a series of videos, where design teams done exactly this, we were tasked with creating 5 different physical interactions with the following applications. Email Twitter and Super Mario Brothers.

It was suggested that we focus on the elements of control for each application and explain how we would map the interactions into physical objects. My ideas for each are listed below

Mario

1. walk pad - users make contact with forwards and backwards pads for movement, if they jump/stop making contact with the pads, Mario jumps
2. play-dough pad - generic keys made out of play dough
3. action pictures - user touches pictures of various actions to have Mario reciprocate
4. scream tactics - users must scream actions such as 'forward' and 'jump' for Mario to do so
5. line movement - users must draw actions on a screen for Mario to do them

Twitter

1. Users must create the letter physically as a sports mascot would for every tweet
2. users must run to the nearest post office in order to send their tweet
3. users tweets are jumbled and they must re-write their tweet or their account is deleted
4. users are required to scream their tweets out aloud in the open before they're submitted
5. users must complete a level of scream tactics Mario in order to send their tweet

E-mail

1. users must write out their e-mails as if their very arms were giant pens, if they bend their elbows the entire e-mail is deleted
2. A crossword containing every word in the English language must be completed in the order of your desired e-mail to send it
3. letters are dragged and dropped onto the screen and can be moved around like physical objects
4. a sand blaster is used to draw the letters on the e-mail, we are not liable for damages
5. the user must pour lava on the screen to create certain levels, warning! death may ensue

DECO2300 Interactive prototype #1 reflection

This week I conducted my workshop demonstration for my game, Minestructor. My testing sessions involved gathering a pair of students and having them play against one another in a few rounds of Minestructor. I sat myself beside the students in question whilst the testing session was in progress and enforced certain rules that had not been encoded into the prototype. After each testing session I found there to be consistency among the feedback that I received.

Every pair of testers began their testing sessions, relatively unsure of the rules and the way they were meant to play. Many testers had to be reminded that it was 'their turn' throughout the testing session. Multiple users suggested enforcing turn restraints and or declaring with more clarity and audacity as to who's turn it is at any time. This wasn't exactly one of my feedback questions, but was nonetheless valuable feedback, users consistently agreed that setting out 3 turns per player was absolutely more desirable than enforcing 1 turn per player.

Users consistently declared that the mine count was appropriate, whilst many ended up activating a mine before reaching the finish line, they done so knowing full well their moves were a blind risk. Because so many players ended up taking many risks in order to race to the finish, it was no surprise that many players preferred to play with three lives as opposed to only one. The use of obstructers reinforced this response, as some users forced their opponents to traverse narrow strips of the field through exploiting the extreme size of the obstructers.

It was on the topic of my obstructers that I received the lions share of my feedback. Many varying points of view were presented to myself. Suggestions were given to adjust the impossible advantage that obstructers could give that ranged from limited their size and quantity, to allowing players to use their own obstructers to destroy those of their opponents.

Out of the numerous suggestions and valuable feedback I received during this testing session, it is apparent that I need to re-work my implementation of obstructers.

DECO2300 Minestructer Prototype 1

This week I committed myself to completing my first Action Script prototype of my game mashup in Adobe Flash. This is the same concept that I made a video over, mere weeks ago: Minestructor. In this prototype I wanted to focus on the core playability of my game, mainly if people could regularly win by reaching the finish line first.

My video prototype had tested the clarity of my idea to audiences, therefore I would assume that my users new exactly what they needed to do when using this prototype. Through this assumption I was able to focus on building a prototype of the core gameplay and avoid enforcing certain rules.

I began my prototype with the creation of a minefield, interactive tiles carrying certain properties that determined the tile-state once triggered. Once each mine was created, a randomiser function would determine if a tile was a mine or not. Once every tile was created and drawn onto the canvas, another function would set the tile state's of all the non-mine tiles to show a numeral, indicating the count of nearby mines. Initially I was confronted with mines treating each other as neighbours despite not looking adjacent on the canvas, this was caused by their positioning in the vector that I stored them in. With a clever use of modulo functions I was able to code in exceptions that would avoid doing this at the edges of the game board and the player barrier.

My next major challenge was coding in obstructors. I worked tirelessly to create draggable obstructors that would render the tiles under them unusable. Thankfully, I was able to find a simple tutorial on drag and dropping (d&d) AS3 objects online from ...
http://www.virtualmv.com/wiki/index.php?title=ActionScript3:Drag_and_Drop_with_Targets

I feel it necessary to state that my d&d code emulated the code from this site, though my lock-in method for dropping followed a completely different method, one based of mathematical loops as opposed to object recognition. Once I was able to d&d my obstructers, I included exceptions to re-adjust the objects hanging off the edges of the canvas, or blocking the starting line.

Now that my vital operators were in place my game was playable, from the starting line you could begin traversing up the minefield in order to approach the finish line, indicators would suggest which players turn it was after each move was made.

DECO1800 WEEK7 Paper prototypes

This week we conducted a peculiar exercise in our contact session. We were required to create an interactive paper prototype of what our project would end up 'being'. 2 of my team members ran our paper prototype workshop whilst I and another member visited each neighboring group and tested their paper prototypes.

Our paper prototype gave us unique insight into the mechanisms behind user interfacing, primarily as class mates attempted to function our setup with little to no instructions. While our paper prototype was relatively rushed, we were quite proud of its similarity to our actual vision of what our game would look and feel like.

DECO2300 Week 7

This week in our lecture we learnt of the volatile and violent nature of feedback. We learnt different methods of collecting feedback and were introduced to the qualitative quantitative dichotomy in asking questions. Quantitative questions are based primarily around gathering statistics e.g. whats your income, are you employed and how old are you. Qualitative questions are used to evaluate exactly how an individual feels about particular aspects of what the questionnaire addresses e.g did you think the ball speed was too slow, did you like the overall color scheme etc.

Our task for the lecture was to re-visit our evaluation session for our video prototype and determine which of our questions were qualitative, quantitative and why.

1. Do you understand the objective of the game2. Do you understand the rules of the game3. What games do you think this is similar to4. How interested are you in playing this game My first two questions may appear quantitative it first, but users are encouraged to elaborate on their answer if it is not an outright yes. Elaboration on their perception of the games rules and objective are very much qualitative as they focus on the users opinion and can not be 'measured' indefinitely. My third question is a relatively open ended question, intended to make sure that my game mashup fulfills the criteria given to us, being a mashup of 2 classical games. My final question, gauging interest in the game, is a clear qualitative question. I ask users to rate their interest in playing the game suggested and they can return an answer ranging from not interested at all too very interested.

Deco 1800 Week 6

This week was to be my first week of coding, I was to create a function that would take a search term as an input and output an array of paragraphs. The aim of this function is to cycle through the available journal articles on trove, select a random article and return its full-text. My first step was to emulate an article search similiar to that of the Trove ultra basic search API provided to us on our UQ-cloud site.

I have wrangled with Trove for a while and determined the easiest way to strip article text will be to slice out the href link to the free article and use PHP to access the page and retrieve the text.

DECO2300 WEEK 6

This week we delved deeper into the mysterious and dangerous world of coding in Actionscript 3. We began with learning about commenting and referencing code, where to do it, how often to do it and where we should avoid it.

We eventually dove head first into an exercise where we began creating CRC(Class Responsibility Cooperation) cards, these cards are a tool used in Object Orientated Software that represent the interactions between objects and their outcomes. We were delegated with a task to create our own CRC card.

My CRC card referred to the interactions a player would have with the tiles in a minesweeper type game. There would be multiple players with lives that would each take turn traversing the minefield. Depending on which player would activate a mine, the tile class would behave differently.