DECO2300 Dark Horse Evaluation feedback analysis

During my feedback session for my Dark Horse prototype I conducted 3 surveys on 6 individuals in total. I asked a few questions regarding the multiple features in my game, these questions are listed below.

1. Did the loss of movement make you choose your moves more carefully
2. How could I better have implemented the obstructer cannon
3. Do you prefer horizontal only movement, or would you prefer there to be diagonal movement as well

Which each pair of testers, I ensured they played at least one game where the movement loss on life loss was disabled and one game when it was active. Unfortunately I noticed that many users experienced severe difficulty in utilizing their respective item cannons. Due to the nature of my code, because the power bars are controlled by key-down and hold event listeners, when a player would begin powering up their cannon by holding down a key, it would cease powering up the moment another player pressed down any other key.

5/6 users stated that the loss of movement resulted in them playing the game more carefully. This was apparent as users began taking more care with their turns on their second game with the rule being enforced. The one user that did not take care in the game appeared to show little interest in it from the beginning, though I do hope this was not due to my game being inherently boring.

A wide variety of answers were supplied regarding the implementation of my obstructer cannon and how it could better be used. A few users pointed out the need for an aiming reticle of some kind and greater freedom to aim in a variety of angles. One user suggested giving the items more impact and power as to encourage users to utilize them more, one even suggested sound prompts to indicate players had collected an item. 2 users suggested changing my game into a turn based game, these users had not tested previous prototypes, but their feedback was relevant, giving players a chance to carefully aim their obstructer at the end of their turn would encourage their use greatly.

Lastly, users were overwhelmingly in favour of horizontal only movement, it allowed them to traverse the minefield quicker as they would have less 'variables' to take into account as they weighed up which tile to move onto.

I believe this prototype to be a success in respect to players delivering their moves with more care and consideration. Though I do feel that my failure to implement the obstructer cannons in an interactive and functional manner make this a very minor success indeed. I do feel in a future iteration of this prototype, I should firstly go back to a turn based system, but retain the keyboard movement setup and secondly flesh out the obstructer cannon with full 360 degree rotational aiming, a reticle and perhaps more powerups such as bonus lives.

DECO2300 Dark Horse Prototype

I have recently created the 'Dark Horse' prototype for Minestructor. This third iteration of my design idea completely reworked the ideas that It had originally been based off.

Whilst not a point of criticism, one crying result of players competing against one another whilst playing my game was a phenomenon I would like to call 'rushing'. A player 'rushes' when they indiscriminately race to the end of the mine field, disregarding the mine proximity prompts and gambling on there being less than three mines in the line directly in front of them. The use of obstructers had previously mitigated this phenomenon, however, if players ran out or forgot to use them, the winner of the match would almost always be the player that rushed to the finish. For this prototype I wanted to make players more aware of the mines and traverse the field more carefully.

I had initially intended to include a physical representation of each mine runner, who would have their limbs blown off as each life was lost. This gave me the idea of limiting player turns after each consecutive life was lost. By allowing careful players a greater quantity of moves, I would hope to encourage strategic game play over risky rushing.

On top of this re-working of the life and movement system, I decided to completely scrap the turn based mouse model of my previous prototypes in favor of a modern keyboard input model.This would allow players to simultaneously move together as they traversed the map.

Players will be allowed a combination of vertical and horizontal moves every 2 seconds(players can conduct twice as many horizontal moves than vertical ones) and operating the obstructer cannon can be done independently of moving. Players will collect obstructers and nades as they discover '?' tiles, which they may fire at their opponents via a cannon connected to their sprites.

DECO1800 Week 13 presentation Reflection

This week we presented our final product to our class for part C of our Major Assessment. I had spent the hours prior to this presentation frantically preparing for the short pitch we would be assessed on, printing out leaflets and bug testing our game.

Unfortunately I had not gotten our image implementation working in time for our presentation, it had become apparent that the canvas was redrawing itself over our image every frame, hiding it from view. Luckily our product was due in the afternoon and for the sake of the presentation I was allowed to ignore the bug.

Numerous students tested our game throughout the session, many finding it rather tiresome to play through every level. It became apparent very soon that we should have conducted more play-testing to adjust the games pace.

Overall I believe our presentation was successful, we demonstrated our API to our tutors when they visited our stall and even taught a few students fun facts about the Vietnamese war. After our presentation was over and our class dismissed, I rushed off to one of the computer labs to fix our game and write up our report. I had the finished product submitted by 2:00 Pm.

DECO1800 Week 12

Our final week approaches and with it, the race to polish our project. This week we've fleshed out our levels and questions and tweaked the difficulty of each level. The extra two articles added to our project were a new report on separatist tensions and unrest arising in East Timor in 1994 and a critical piece released in 1971 aimed at Australia's continued involvement in Vietnam. For each of these articles, I created 10 multiple choice queries that will be given to the user at random, each time they lose a life.

At the moment we have discovered a slight bug in our code. Somehow the ball speed will increase each time a user loses all their lives and attempts to retry the level. This is the same incremental difficulty increase seen in progressive levels. So far we are un-able to determine to cause of this bug, but are considering working it into our final product to dis-courage successive losses.

I will begin integrating the image search into our program this week, integrating our API with Trove ever more slightly. Currently our game is starting to look complete.

DECO1800 Week 10

This week we continued working on our group project. Currently we have not progressed on our project since the start of the mid-semester break, we have however, constructed the core Trove implementation for our API. So far we can pull a random related image through a search term and access news articles through a similar method. We have set up multiple levels for each newspaper article input with an increasing degree of difficulty.

Our aims in the near future will be to layer an image over all of our blocks, allowing users to dissolve the blocks one by one and reveal the text underneath. Additionally, we will be implementing a quiz system at the end of each level, ensuring users read the text in order to proceed to the next level.

Towards the end of this weeks workshop we were able to lay the groundwork for a quiz system. We implemented a prompt that triggered when the user attempted to play the next level. Currently the quiz mechanic has not completely been fleshed out, but we intend to lay the ground work down with placeholders soon.

DECO2300 Prototype 2 Feedback

During my Prototype 2 testing session, I conducted 4 surveys, obtaining feedback from 8 different participants regarding several features in my game. The three primary points of feedback that pursued through this survey were...

1. Fun Factor
2. Immersion/Interactivity of physical input
3. How does artillery mechanic affect gameplay

I encouraged each pair of testers to present any suggestions that they may have during each survey and in turn received valuable feedback. One consistent suggestion was to include a cone of fire, as this would assist users in determining the general area they would be firing. I noted this suggestion immediately as I had to clarify the shot spread explicitly to each user throughout my testing session, particularly when users attempted high or low powered shots.

6/8 users strongly stated that they found my prototype fun to play, whilst 2 users found themselves rather dis-interested in the game, I would partly attribute this to the two participants not knowing each other at all(I believe competitiveness is key to appreciating this game). 

After a shaky initial introduction to the rules, most pairs would quickly begin showing excitement as they traversed risky tiles in the minefield and attempted game winning shots with the obstructor cannon, I have linked footage of one of these play throughs below.

https://www.youtube.com/watch?v=aIMJnuMzzGA&ab_channel=TonyPrusac

Across the board, all users responded positively to the interactive physical input. One user pointed out that the use of the palm scanner and fire button grounded them into the theme of the game, others praised the use of the aiming dial. Overall, participants felt that the physical input was significantly immersive.

My third question focused on the delivery of obstructors and prompted users to suggest alternative mechanisms to improve upon my idea. As well as the cone of fire suggestion, another user suggested allowing the cannons to destroy deployed obstructors where possible. Generally users were pleased with my implementation of the obstructer cannon, stating that it made it harder to cheat and more interesting.

For my next prototype I will begin developing  a completely re-vamped, stylistic approach to the match, I do not plan on further implementing the Makeymakey, but I will be instead implementing sound effects and greater visual effects. Additionally I plan on completely re-thinking my approach to the basic rules of Minestructor.

DECO2300 Week10 Minestructor prototype 2

I have recently completed the second iteration of my Minestructor prototype. Most peculiar about this iteration is the physical input system that I created for the game. But I will first talk about the changes I made to the game since my first prototype testing session.

The most poignant criticism I received from my first interactive prototype concerned the use of my 'obstructors', which would give players the ability to make the game nigh un-winnable for their opponents if exploited correctly. I decided to make the implementation of this mechanic the primary focus for my second prototype. But I also needed to make the interaction physical, so merely nerfing the advantage these blocks granted to the player would not have satisfied my goals.

Inspiration came to me in a peculiar form whilst I was playing a flash game in class, what if I utilised RNG. I began considering different forms of implementation of an RNG mechanic through physical means. I quickly thought of an aim and power module, primarily due to the influence of Angry Birds in the flash community, and began focusing on a simple, yet innovative design.

I had to create a clever physical prototype that was not merely an external directional pad, I thought of an aiming mechanism similiar in design to an egg timer and a crank to adjust power. My design for the aiming mechanism was consistent throughout the creation of my prototype, as it formed the crux of my physical prototype. My initial idea for a power crank had to be scrapped in favour of a simplistic up down power control mechanic. This was in part due to the limited inputs of the Makey makey, though this design decision allowed me to implement another innovative feature in my physical prototype. Instead of only having a button to fire the obstructor, I included a 'hand scanner' on the play pad, merely a space in the circuit that would need a flat palm to connect it, which I believe added an extra layer of immersion in the product.

My finished product became a dark game pad that would take the player out of the fast paced minesweeper click-athon and force them to carefully execute their next move. A simple loop of randomiser algorithms allowed me to encode a shot spread that would have the obstructors influencing gameplay in un-expected forms.

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.

DECO1800 Week 5

"Holy Bagoly", these are the words that escaped my mouth when I learned that we were to give a presentation in our next contact session. Certainly a terrifying affair for any student, giving a presentation in front of a judgmental class of students. I spent the previous night to our presentation, memorizing lines and ques for our group and fortifying my self esteem with many motivational memes. I flicked through meme after meme, growing in confidence and recalling my lines with greater clarity determination.

The first thing to strike me as rather odd was the manner in which the tutors propelled 'feedback' towards the groups presenting prior to my group. Hateful and threatening comments were made by the tutor such as "I would have liked to see you refer to your poster a bit more". My team member Clancy squeaked in fear when we were called up next, he was to present with me. Our other 2 members Cornel and Jordan wore sickly expressions on their faces, teeth chattering and lips quivering. We marched to the front of the class like a group of death-row inmates, I turned to stare at the class and began my presentation.

What happened next was similar to one of Ashton Kutchers blackouts in his classic film The Butterfly Effect. Suddenly, I was declaring that the presentation was over, I noticed that the timer next to us had passed 3 minutes, a perfect length. I turned to look at our audience, every persons' hair was spiked and pointing back, revealing the shocked expression on their faces. I turned and looked at my team members, each sporting a cool, satisfied look, "ehh ehh excellent performance guys, you can return to your seats", our tutors croaked, obviously blown away by the killer presentation. We walked back to our seats, sporting smiles too big to fit on our faces, we had won.

DECO2300 WEEK 5

This week we were introduced into the wonderful world of Action-script 3. Our lecturer spent our lecture introducing our class to the concept of action script and its applications in past projects created in DECO2300. We were told that the idea behind using flash/actionscript for our prototype was to communicate our idea and facilitate feedback from users.

Many examples of code and tutorials were uploaded to our BlackBoard site to assist us in our programming tasks. Fortunately for myself, I've already delved into Javascript and dealt extensively with Object Orientated Programming when I completed my CSSE1001 course last semester.

DECO1800 week 4

Our activity for our contact session this week was to imagine and bring in 3 Trove based API's to share with our team.Our ideas would have to interact with Trove in some way and serve any purpose of our choosing, my ideas were:

• Strovy Mode: An interactive story that pulls in random elements from Trove based on a users preferences, that alter the main characters and images in a preset story.
• Trove Funk: This API will access Trove's gargantuan music collection and allow users to manipulate the sound quality with a funk meter.
• Trove till you drop: A Russian roulette style quiz game that forces users to face off in a Trove article questionnaire, correct answers are measured by relevance and the loser is banished from Trove forever!

At the contact session, we were all forced against our will to participate in a 6 hats of critique activity. This activity had every member in the group critiquing each idea based on 1 of 5 different categories e.g. objective criticism, optimistic improvements, things that you don't like.

During this activity, our team was able synthesize a new idea that incorporated elements from each of our members best API concept. Through synthesis we were able to create, Trove Breaker (the idea only). We decided that Trove Breaker will be a take on the classic block breaker game, incorporating article paragraphs from Trove to create words to insert into individual blocks. By breaking these blocks, users are able to reveal the entire paragraph and read it.

DECO2300 Video Prototype User Evaluation

After showing my Minestructor kickstarter video to a class of roughly 20 design students, I approached 8 of them and asked them a series of questions regarding it. The questions are listed below.

1. Do you understand the objective of the game
2. Do you understand the rules of the game
3. What games do you think this is similar to
4. How interested would you be in playing this game

Interestingly enough, I assumed that almost every participant in my survey would immediately notice the similarity between my idea and minesweeper. I was shocked to find out that a significant proportion of students in the class had never played minesweeper. This was an important factor to consider as every student who had admitted playing minesweeper in the past understood the objectives and rules with crystal clarity and were able to parrot them back to me. The students who had not played minesweeper however only had a vague understanding of the rules. There is the obvious case of a language barrier in determining how much misunderstanding was due to my lack of communication and of the cases and sentence structure variance between English and Mandarin. 

In regards to this design ideas similarity to minesweeper, students that had never played minesweeper before had difficulty relating the two together, though some noticed the similarities since they had investigated the game for the purpose of our assignment. However, I found that every user that had played minesweeper in the past immediately outlined similarities between the 2 games, a couple even mentioned obstruction.

Many users telegraphed some degree of interest in playing the game, particularly due to the simple concept, small learning curve and somewhat ambitious nature of the game. I believe I will have to take further steps to clarify the rules of the game to participants in the future, though as it appears now, my design concept satisfies most of my expectations.

DECO2300 Creating my Kickstarter Video

My task for this week was to dedicate myself to a final idea for my game mashup video prototype.

Interestingly enough, my decision occurred on an unusually cold winter night. I was mashing potatoes in the kitchen until I was alerted by a skype call, a tune audible at even the lowest of decibel levels. I began to walk towards my computer when I suddenly noticed a landmine in my path. I altered my path to avoid the mine, but one of my housemates appeared walking in the opposite direction, I was obstructed. I walked around my friend, consequentially stepping on the mine and causing a blinding explosion. I awoke at my desk to the loud skype tune buzzing at me, blinking furiously as I tried to digest the events of my dream. I rejected the call and began working, I had chosen my idea!

This is the sound of failure

My game idea involved combining elements from the hit Windows classic Minesweeper and everyone's favourite paper based game, 'Obstruction'. I wanted to turn Minesweeper into a competitive affair, but a mere time challenge would not suffice, so I spliced elements of Obstruction into a top down Minesweeper race-track to create Minestructor. Players would begin at the bottom row of a grid-like minefield and attempt to traverse the deadly mines and reach the end of the minefield. Players will take turns moving over a space in the minefield and will each possess the ability to place an obstructing shape in their opponents path. A player can only place an obstructing shape before they complete their turn and will own a limited selection of shapes.

You better watch your step!

Each section of the field can host a limited quantity of obstructive shapes, for this prototype I have aimed at a minimalist set up. Each player will possess 4 particular shapes and be able to allocate 1/2/1 shapes accordingly to the game-boards sections. Each shape will function similarly as they would in Obstruction, blocking access to the adjacent tiles surrounding the source of the shape. This means that placing a 1x1 obstruction block in your opponents field will subsequently render 9 tiles in-accessible. A player will win if their opponent activates a mine, or reaches the end of their minefield. I believe this game concept to be simple enough to understand through a short 1 minute introduction, yet complex enough to require hours of game play to master. Further complexity can be achieved through increasing the quantity of deploy-able shapes, the size of the playing field and allowing shape customization.

DECO2300 Week 4

In this weeks lecture we learnt about different types of prototypes. We touched base on many different forms a prototype could hold, but most importantly, we focused on horizontal and vertical prototypes.

Horizontal prototypes will generally consist of multiple features, but they will each contain little detail. A horizontal prototype usually tests the interactive metaphor behind a design, testing of raw functionality is usually delegated to the vertical prototype. Vertical prototypes generally focus on a few features within a design, but deal with in depth functionality. These few features will be highly detailed, but the entire design will still be conceptual.

These kinds of prototypes are one of many prototypes that can be used to test many different features of your design. The prototype that we used to complete a task in the lecture was a diagonal prototype. Diagonal prototypes are a mixture of horizontal and vertical prototypes, that adheres to a specific scenario.

We applied these methods to an in class task, where we had to determine the functional components of the inside of a car, the components related to driving behavior, how the driver interacts with them and ways we could test that.

We determined some functional components were the seat belt, door steering wheel and indicators. Interaction could be tested through many means including using actual cars. We were delegated with a task, where we needed to think of a low-fidelity prototype to test these components, similar to that of body-storms of earlier design subjects. For my low fidelity prototype I considered allowing each member of the design team to represent a component of the car, a member would act as a door whilst another would use their arm as a seat-belt. Whilst impractical, low fidelity prototypes are an easy way to immediately test usability of a design.

DECO2300 WEEK3

In this weeks lecture, we were introduced to conducting video analyses and tasked to conduct one on team Lambda's Brisbane park finder. The video involved one of the projects team members standing in front of the camera, speaking about the app, with periodic cuts to interfacing examples.

Analysis:

My immediate opinion of this video is one of indifference. The presentation lacked flavour and left much to be desired. The concept itself was conveyed proficiently and with simplicity. This service will allow users to search through Brisbane's parks on an interactive map, even searching for specific attributes like barbecues and soccer fields. Only one question came to mind watching this particular video, and that was if I would ever need to utilize an app such as this. < br/>
The need for an app like this may have been delivered in a more creative and engaging manner. Such as showing a group of people arriving at a bare park with picnic supplies, or bringing pets to a no animal zoned park as the presenter narrates their dilemma for the benefit of the viewer. The representation of the actual app being used on a phone was delivered excellently. It conveyed the functions of the app with great clarity and speed.

I believe creating a need, must be handled more indirectly than merely asking the viewer if they've ever encountered a particular problem. As I demonstrated before, the need for the app could be conveyed in a subtle scenario or possibly through a stylised cartoon. The video quality in this clip was of a high standard, though the audio quality appeared rather un-professional. Numerous sounds worked against team lambda, such as passing cars and cawing crows. Even once the camera cut to the prototype of the app, the audio was still being conveyed in this manner.

DECO1800 WEEK 3

This week we finally decided upon our teams. The contact session began with the class dividing themselves into groups and brainstorming ideas for varying Trove apps. My initial group was the puzzle group. We spent 5 minutes in front of this white-board,  writing down ideas with fervour.

Many ideas were thrown down during our time in front of the puzzle board, but after 5 minutes we were forced to move over to the game board. To our disgust, many broad ideas were already displayed on the white-board, forcing us to innovate and create fresh new concepts to add to the board.

The numerous denizens of the puzzle group were able to deliver, including myself off course. Trove enriched ideas flew thick and fast as we coated the whiteboard in a layer of ingenuity. Half way into our brainstorming session, we were all wearing grins as if they were Anonymous masks. We had thought of many unique ideas that would suit our major assignment perfectly. One being a choose your own adventure, incorporating characters and images pulled straight out of Trove in a random nature, offering a unique experience for each play-through.

The remainder of our activity consisted of looking at and analysing other peoples ideas. This activity brought many laughs to the group and allowed us all to familiarise ourselves with each others sense of humour. This ultimately made forming our project teams surprisingly easy. In no time at all, I met with three other lads and we formed our DECO1800 dream team.

DECO1800 Week 2

This week marked our first contact session/workshop.It progressed as I had expected it, a short introductory session between students, followed by a few ice-breaking brain-storms on sticky url. Though entertaining, this contact session was not without its frustrations!

Ten minutes into the session, the tutors looked around the room, puzzled to such an extent that their heads were metaphorically puzzle pieces. What was worse, the two puzzle pieces metaphorically resembling the skulls of my tutors did not complete one another, leaving this mystery unsolved. What were they puzzled by you ask? Well take a seat and I'll explain.

We were missing half the class! I wondered where all my pesky classmates were and how this lack of commitment would transcend into the group project. Images flashed before my eyes of lazy teammates dozing off during team meet-ups and submitting hand drawn deliverables moments before our due date. I stiffened my resolved and mentally noted each and every individual that had made it to the contact. Name, age, degree, nose-type, every important detail was internalized and memorized.

The students that did attend broke up into groups in 2 scenarios that divided us by preference in relation to a specific dichotomy. The first was Dogs/Cats and the second was Kanye-West/tayler-swift. This exercise allowed not only the tutors, but the students to identify who the winners and losers in the class were. Unsurprisingly, the pro-cat crowd was identical to the pro-teilor group and the denizens of the pro-"Yeezus" cliche, much like any respectable member of society, preferred the trusty hound over the mangy cat.

DECO2300 week 2 Workshop B

PhotoShop MotoShop...

I knew this day would come. Much like death, having to learn Photoshop is an un-avoidable event in virtually any humans life. Many will claim that this analogy is irrelevant due to the looming possibility of immortality through cryogenics and stem cells, but I have digressed.

Following what felt like a short lesson we tested editing short clips in Photoshop using footage recorded on our Iphones. Whilst the end product appeared trivial and minuscule, the familiarity we had gained with the program had significantly boosted our confidence with video and photo editing

DECO2300 Workshop A Week 2 Post

An exciting task was thrust upon my workshop class this week. We were to form tightly-knit groups and brainstorm ideas until we agreed upon a certain frank-en-game. Our task involved 3 peculiar games, with apparently nothing in common, left my group gasping for ideas like a beached salmon.

1. Galager (A bottom up space shooter/scroller)
2. Dots n Boxes(A competitive puzzle shape drawing game)
3. Operation (A board game surgeon simulator)

Whilst considering the difficulty of this task, an idea violently exploded from our minds in a manner very similar to the Alien movie. Our idea consisted of blending Operation and Galager, whilst juxtaposing a Dots n Boxes mini-game side by side with the main product. We call it...

Galager Surgeon:

You play a micro sized doctor flying a sterilized medical themed fighter jet through the open cavity of a surgery gone wrong! Blast away blood clots, tumors and infectious organisms whilst attempting to sew up a life endangering surgical wound. As points are accumulated, the player is allowed to begin "sewing" the wound in a separate screen in a mini-game that resembles "Dots n Boxes". But beware, fire upon a blood vessel or vital organ and risk tearing open the wound further and losing valuable time.

Additionally, each team in the classroom was entrusted with creating a wearable social device that would deal with annoying behaviors. This task proved to be considerably more gruesome than the former. We discussed all manners of deviant behavior such as sneezing, blowing noses and un-desirably vocal ticks many individuals emit.

This week was truly a test of our psychological fortitude.

DECO2300 My Digital Pantry

A real digital pantry should have better quality than this

I would like to ask for forgiveness from my cohorts of avid followers. This highly anticipated blog post comes to you after an unquantifiable length of meditation. Prepare yourselves...

My housemates wiggled their eyebrows and shot puzzled expressions in my direction as I paced around the kitchen and living room, testing every 'device' in sight. "He's gone crazy!", one of my more worrisome friends cried out. But they were wrong, dead wrong! I needed to consider every device that I regularly used, a seat, a desk, the kitchen sink. Suddenly I realised that in my steely determination to complete this task I had neglected to feed myself for an extended duration, my belly gurgled. How much time had passed since I had eaten anything, I asked myself this question numerous times, but to no avail. Perhaps 10 maybe 20 hours had passed since the last morsel of food passed my lips, however, the details were unimportant! I spun around and approached the pantry and experienced a shock that electrified my digestive organs, shattering any notion of hunger. 'The pantry!' I yelled, my voice laced with triumph.

The pantry door is a device that I as a food consuming human tend to use rather frequently, 4-6 times a day to be more precise. I will operate this device relentlessly in an attempt to evaluate what kind of side dishes, seasonings and sauces are available as I prepare my meals. Long minutes tend to be consumed as I crane my neck to and fro, inspecting each corner of the pantry. My idea is cryptically related to blog's title, a 'Digital Pantry'.

My digital pantry will include an interactive screen, where inventory can be checked without pointless operation of the door hinges taking place and pre-programmed dishes (vetted by the user) will appear in green if sufficient inventory exists, orange and red if only partial or no inventory is available. Inventory management will be assisted by a built in barcode scanner and a manual inventory entry (sugar, salt etc).

This device variation will bring civilisation one step closer to the digital age portrayed in many of our childhood sci-fi films. Look Below for a digital paper prototype.

DECO2300 First Week

A famous French philosopher, René Descartes once said, 'Except our own thoughts, there is nothing absolutely in our power', this quote has been a lens through which I have viewed life ever since I read it. The nuance of this quote rung true as our lecturer uttered the words, 'What do YOU think a prototype is?', a smile crept along my face as I considered this gauntlet.

For me, the concept of a prototype was simple, it is functioning model only within the scope of its intended role, regardless of any functional restraints that would effect it in the marketplace or tech industry. A prototype can be as overt as a camera attached to a robot, or as innocuous as a few toilet rolls taped together.

Whilst a prototype may look nothing like the final product, it serves a vital purpose in conveying the concept from withing the designers head to possible investors and team-members and providing a reference point for the designer to improve upon their model (and ensure its compatibility).

A prototypes purpose will vary from project to project, but all prototypes will ultimately convey the functionality/dis-functionality relating to the particular problem it will be addressing.

This man is able to make a wooden bike, but not a long enough shirt.

Once an idea has been conceived, a prototype should immediately be produced. Even if it is constructed out of paper, a prototype can provide priceless feedback towards a project that mere introspection never would.

My first week of DECO1800

An architect's work is not complete until the draft paper is correctly rolled.

After leaving the first lecture for DECO1800 last Friday, numerous questions buzzed around in my brain. 'What do I expect to be doing this semester?', I could hear a voice whisper as I approached the bus stop. I tried to focus on something else, but the questions persisted. 'I want to learn/experience/do...', the voices persisted, 'What are your expectations for this course?'. I mulled over these questions but was unsure how to answer them, so I studied my course description, 'I'm worried about...' it spoke. Minutes blended into hours, the questions persisted. Suddenly, an epiphany tore through my synapses. I rushed to my computer to document my thoughts and confront the questions that had plagued me all day.

I expect to be undertaking a group based development project throughout this semester, working extensively with HTML and JavaScript, whilst simultaneously updating a regular blog, compiling a portfolio and submitted reflective journal entries.

I hope to experience working on a project with a zealous team and complete a project that exceeds the sum of its parts.

I hope that my contributions to the group project will drive it towards a collective goal.

I expect this course to be:

1. Time Consuming
2. Challenging
3. Rewarding