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.