Week 11

This week I play tested the game and implimented changes from new research I had recently looked into. A Gamasutra Article …………. talks about Blizzards Diablo II and the resource management mechanics they’ve implimented. Their goals are similar to mine where they have the players balance mana, skill and health. The article states about those mechanics “Not only does managing these resources form a very natural pace to the combat, an attack-and-retreat flow that becomes more apparent the longer the game goes on, it also creates a constant feeling of “almost there”, such that players will always feel wanting for something, whether that’s more health, more mana to use a skill, or for a cooldown to end.  It’s an emotional state which is only ever resolved once battle is over and the enemies are dead, but resumes as soon as the player moves on.”

That comment had me thinking about how I can use the mechanic to achieve a similar effect.  To achieve this I manipulated the spwan times of the resources vs the regeneration of the players health. I wanted the player to experiance that ‘almost there’ feeling in play. So when the player is on one side of the area – they will be forced to move to the other side.  In doing so they have have to spend a certain amount of time being very vulnerable to death, and this is being designed to happen many times in one game. In doing this the player has to push and concentrate harder in the game every 5-10 seconds (roughly) and my goal in this is create less linear play.

To hopefully compliment these new ideas, this week I also worked on the visual feedback off the game. I added subtle colour changes, effects and animations to give the player a more satisfying attack and damage.

Hopefully over the next coulpe of weeks I can further develop these ideas further to help deliver my game with a strong feeling of sacrifice in the mechanics.




Week 10 – Converting to Final Concept


  • I started by doing 2D plat former tutorials on YouTube to learn the difference between 3D and 2D scripts. Brackeys was the most helpful Channel, I stuck to these tutorials and used the provided assets for placeholders while I converted my scene to 2D.

This slideshow requires JavaScript.

  • Then I created my own assets and built a simple game prototype (still using the character, enemy and pick-up Brackeys placeholders.

This slideshow requires JavaScript.

  • Next I continuously play-tested and re-designed the game until it was up to a good play-testing standard. I’m still using the placeholder character and enemy’s for now – but the mechanics and game itself.

This slideshow requires JavaScript.

Week 09

This week was a huge challenge. Somehow a computer corrupted my files and I kept opening my back up projects on that same computer (regrettably.) It affected my project settings and UI – and took hours to fix.

Now after creating millions of back-ups I have a completed working build (for real this time.) I plan to play-test next week, and kept updating the game so that it gets closer to answering my question about meaning and mechanics.

This week’s play-testing and build vid

Week 08

This week I developed a more detailed methodology on my Report, and made sure all the bugs were fixed in my mechanics. Now all these problems have been fixed and I can finally start testing

  • Health needs to regenerate 
  • Gun needs to stop firing when the player is out of resources 
  • Feedback and Art needs to be more presentable 
  • Spawn Points for enemy and resources


Week 07

Working 3D Prototype


[Done] [Yet to Do]

Power A: Spacebar

  • High Damage is being made to the Enemy, and low damage to self.
  • Medium Damage is being made to the Enemy, and resources are being used.

Power B:  Left Mouse Click

  • Medium Damage is being made to the Enemy, and resources are being used.
  • Enemy is being forced backwards.

Power C: Right Mouse Click

  • High Damage being made to the Enemy, and low damage to self.
  • Enemy is being forced backwards.

Current Bugs:

  • Health needs to regenerate 
  • Gun needs to stop firing when the player is out of resources 
  • Feedback and Art needs to be more presentable 
  • Spawn Points for enemy and resources


Things to consider when play-testing:

  • Amount of High Damage to the Enemy/Player
  • Player Health Increase over time
  • Amount of Player starting Health
  • Amount of Player starting Resources
  • Amount of Resources Available to the player
  • Environmental Factors
  • Amount of Medium Damage to Enemy/Player
  • Longer Fire Rate – Positives to game-play (stagger?)
  • Is there a cool down for the longer fire rate?

Balancing Rundown.JPG

^^ Prototype Video

Professional Practice

Quantum Break – The Facts and Fiction of Time Travel

Week 06

This week I opened Unity and started putting together a placeholder environment using tutorials  in order to test out the mechanic.

I completed Unity’s Survival Shooter tutorial in order to learn more about how multiple scripts work together in a project.


After completing I tried to alter the scripts in order to work my mechanic into the game. The idea was that instead of having the player just shoot with one input, I would make the player shoot in the three different ways, each damaging the enemies and the player in their own unique way. It took a while of messy note-taking and focus but I eventually worked out a plan of action.

(example of messy notes & trying to make sense of everything (there’s plenty more) )20160407_185757.jpg

At this stage, my primary focus was to add the ‘sacrifices’  to the shooting, which in hindsight seemed like an easy task that turned out to be at best a learning curve.

To briefly explain how it’s going to work:

Using your players Health will give you +20 attack damage

Using your players Resources will give you +10 attack damage

Using your players ‘Time’ will give you a longer attack time

Power A  will have:

  • +30 damage to enemies
  • -10 PlayerHealth
  • -20 PlayerResources
  • (no time bonus)

Power B will have:

  • +20 damage to enemies
  • + 10(ish) sec attack
  • – 10 PlayerHealth
  • (no resource bonus)

Power C will have:

  • +10 damage to enemies
  • + 10(ish) sec attack
  • – PlayerResources
  • (no strength bonus)

Starting with Power A I tried to implement a new line of code that when the player is shooting it will deduct a ‘SacrificeDamage’ to the players health.

It looks like this:

Public int SacrificeDamage = 10;

Void SacrificeDamage()

If  (playerHealth.currentHealth>0)


I’m confident that I can put the mechanic together for testing, I just came across a large amount of compile errors while learning everything. My main obstruction in just physically intergrading the scripts properly. (Hopefully, on Friday I can make it all work together – i’m getting close)

This week  I also started to put together my literature review with a couple of paragraphs done.

Professional Practice

This week I attended the NZGDA meetup. The GDC talk was inspiring, and set forth my goals of going to it next year.


Because of the talk, I went home and looked at the GDC vault watched three videos. Farah’s Diversity panel, A seminar about portfolio building and a woman in games seminar.






Week 5 Reflection

Discussing idea feedback:

User Interface:

Feedback on the mechanic was unanimous, from the three people I discussed the idea with – all said that User-Interface would be very important in  understanding the mechanic. One suggested that I try prototyping with and without User Interface and the effects on game play.


It was suggested that using combined and multi-gesture button pushing might make the mechanic easier to comprehend.

Comprehension and Communication:

Initially I thought of the mechanic working as each button being represented as”A+B-C,” instead, it was recommended that I communicate each button/action as just “-C.” So instead of telling the player they have three resources minus one, its being told as you are not able to use this one thing. If that makes sense.. I’ll come back to this.


It was suggested that the object that the mechanic is interacting with should compliment the meaning portrayed. Looking into semiotics and representation in everyday objects can achieve this.


Over-all the feedback suggested that the mechanic can work, but needs to be clearly and carefully communicated to the player. Through prototyping from now on, I can find the most effective and least intrusive way of presenting my mechanic and its meaning.