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.