Friday, 30 October 2015

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.

Thursday, 22 October 2015

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.

Tuesday, 13 October 2015

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.




Thursday, 8 October 2015

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.