Monthly Archives: June 2016

Renegade – Teaming up with Graphic Designers

Renegade is going to have some Graphic Designers to create some Graphicy Designy stuff! But what graphicy designy stuff you ask? That’s actually a really good question.

The game is called Renegade…

Originally the team and I had the idea to theme ‘Renegade’ around either a Prison break or a fantasy dungeon escape.

But we thought maybe before cementing in a theme, we would wait to be paired up with some graphic designers to see what ideas they had. Part of the decision to wait was what if our group came up with a theme that the graphic designers hated and was completely different to their skill set? Or something that they wouldn’t be able to accurately represent as well as we needed or wanted it to be?

They ended up liking the fantasy dungeon theme, but proposed adapting it to half of the board would be dungeon, the other half enchanted forest and the characters could be part shape shifter. It enabled making all of the games context fit in, link to each other and interpret easier. Easier reasons to understand why there are chests in a dungeon instead of a prison. Why would someone want to be a renegade when it’s a prison break? Wouldn’t all three people want to get out rather than it be a 2 v 1? It would also make it easier to fabricate some back story to the game and the context of the actions performed on the cards.

Bank Error

Not just draw a green card and have it say “move forward 2 spaces”. Instead, “A Wolf howls in the background, you panic and sprint forward 2 tiles”.

We are still deciding on visually how the game will look, but at this point we have come to the conclusion on the cards. I’m going to be careful when I say “The same principles as a Hearthstone card”. But what I mean is, there will be a strong centre point to focus on that will have some form of image representing the effect that the card would have, A border around the outside of the card, and colours that match what colour card it is.


I’m sure there will be many more visuals to discuss and update as Renegade continues to be made. But that’s all for now.

Until next time –






Posted by on June 27, 2016 in Uncategorized


Renegade – Play Testing Session

The objective of the game is to reach the end of the board through the use of dice and cards.

If you are the Renegade:

  • Reach the end before both of the Non-Renegades.

If you are a Non-Renegade:

  • Reach the end before the Renegade.
  • Help your Non-Renegade counterpart to reach the end.


This is what Renegade looked like in its first play sessions:

Renegade Updates 1

A quick overview of what game pieces Renegade consists of and what does what:

Renegade has:

  • 3 Player figurines – To move around the board.
  • 3 Allegiance cards – These decide whether you are the Renegade or not.
  • 7 dice:  1 Black die for movement, 6 coloured die – 2 Red, 2 Green, 2 Blue.
  • 15 cards of each Red, Green, Blue, Yellow.
  • A board.
  • Blank tiles, Tile tiles & Burn card tiles.

Chest Tile


The Chest tile: When a player lands on these they roll 1 of each of the coloured dice. The highest value is the winning suit and the player picks up two of the same coloured cards as the winning suit of die.






Burn Card Tile


The Burn Card tile: When a player lands on these they draw and play immediately 1 yellow card.





Pink Square



Pink tile: If a player is on or after this tile – they look at their own allegiance card and do not show or tell to any other player. This is always earlier in the game and before the Pink and Yellow tile.




Pink Square + Yellow



Pink and Yellow tile: If a player is on or after this tile – they reveal their own allegiance card to every other player. This is always later in the game and after the single Pink tile.




The red, green and blue cards can be held in the players hand’s ready for use when they are drawn or at the start of that players turn. Red cards allow a player to move other players back ‘x’ amount of tiles, and some other similar ‘hindrance some other players’ cards. Green cards allow a player to move other players forward ‘x’ amount of tiles, and some other similar ‘benefit other players’ cards. Blue cards allows a player to switch places with another player, some of the blue cards allow the player to switch another players cards in their hand with cards in the ‘card player’s hand’. Yellow cards were always played immediately on pickup – these cards made people discard cards or move backward spaces.

What went well:

The escalation of intensity as the game went on & the anonymity.

The reveal points on the game board served exactly as intended. At the start no-one knows who they are, the first reveal tile/area – players understand what their role is in the current game and can start to tailor a strategy and understand what they need focus on in order to get to the finish first. The reveal to all tile/area – If the person revealing was the renegade, regardless if the other two people knew what their role was, it became blatantly obvious what was the role the other two players had to fulfill was. If the player revealing to all was not the renegade, the players who didn’t know what their role was, it became a priority to find out. The first reveal point was important to make players understand their role in that game. The second reveal point was important because it forced players to understand who they were with, and against.

The understanding of what needed to be done other than rolling a single dice for movement.

There was a clear understanding of the interactions and results that happened within the game – when landing on a chest the players knew to roll 1 of each of the coloured dice and to pick up two cards of the same colour as the winning dice colour. Player’s knew when they were able to play cards.

The amount of cards players received when landing on a chest tile.

Two cards were a good amount because with what the actions were of the cards, players were never overpowered or under powered.

What didn’t go so well:

No card stockpiling.

There was no limit on amount of cards players could play each turn. Because of no limit – every turn, if players had or received red or green cards, they were used immediately. There was no strategy to stockpile cards for later use.

Blue and Yellow cards.

Some of the actions on Blue and yellow cards were completely useless. Blue cards allowed players to switch hands of cards with another player. Yellow cards made players discard cards. If players had or received red or green cards, they were used immediately. There was no point throughout the game where players had any red or green cards in their hand – making most yellow and blue cards useless.

Switch Card is OP (Over Powered).

The blue switch card is practically a cheat card if you have one at the right time.

This slideshow requires JavaScript.

The flow of player action to interesting result.

Because most of the blue and yellow cards were rendered useless – it made the game play linear. It literally became a race with no strategy involved.

If a player landed on a burn card tile – nothing happened because of no-one having useful cards to discard = not interesting. Players could make other players discard blue cards (that switch hands of cards), but because no-one had cards, what’s the big deal about discarding a useless card?

If players landed on a chest tile – they rolled the dice and because of the highest value of a dice (which is random), if the winning suit was blue – it was a disappointment rather than a victory. If the winning suit was red or green it was still just an ‘eh’ situation which resulted in moving 1 or two players backwards or forwards because of all cards being played immediately. And as another result of everyone always playing all of their cards, if a player was to move another player onto a burn card tile, it was again, pointless.

Board Layout.

Because we are paper prototyping and the board in it’s current state is a bunch of pieces of paper that can be moved around to change the board layout on desire. This is bad because of:

A) Any player could breathe or laugh and half of the board flies away.

B) There would be varying play test results because there isn’t a single board layout being tested repeatedly, it changed once per play test.

C) Because of the board being easily changeable, there was a particular game that had too many burn tiles placed either too close to each other or immediately after or before each other. C – was extremely bad for a number of reasons.

  1. Each time a player lands on a burn tile the player performs the action of a burn card. When the burn tiles are so close together it results in a mass chain of players moving onto and off of burn tiles. For example: a player lands on a burn tile – the card is a – Switch place with the player that is in last place. And then the person who is in last place is on a burn tile (but has already taken action). The two people who are switching are on burn tiles which means they both need to take action on a new burn card each. If each of those burn cards have an action or result that moves a player onto another burn space – well you get the point. It causes a snowball effect.
  2. In the event of multiple actions being taken as the result of a burn card there was no instruction or rule as to how or which action was to be resolved first. It was a mess. Players were taking random votes on what order the card actions should be resolved or if they should be resolved at all because a new burn card had changed the situation.
  3. This made the game length much longer than the required play time and slightly more agonizing/frustrating for some players, but for other so much more chaotic and fun.

The Game is too long.

The brief states that this game must be between 20-30 minutes of game play the first time they play. Everything after that must be faster than that. The majority of the play tests have run longer than 30 minutes even for players not playing for the first time.

Suggested Fixes:

Create a single fixed board layout and tweak from there. Use some form of board layout rather than movable pieces of paper. This will fix the Board Layout going wrong to the degree that it did in this play testing session. It will cement a board layout that will allow for tweaking and progression. Although imagine a board game where you get to set up your own layout each and every time. Don’t put burn tiles so close together and so consecutively – This will fix Board Layout C) 1. All of this combined will start to help fix The Game is too long.

Create a rule to only make a certain amount of cards playable per turn. – This will help resolve No card stockpilingBlue and Yellow cardsThe flow of player action to interesting result.

Change some of the functionality of the red, green, blue and yellow cards to more interesting interactions which results in a higher risk vs reward and give people a reason to want to wait to play certain cards. This will help resolve No card stockpilingBlue and Yellow cards, Switch Card OP The flow of player action to interesting result.

Create some form of rule or instruction or stack overflow for actions if multiple burn cards occur. This will fix Board Layout C) 2.

Find a reason to perform revealing to ‘self’ and ‘others’ to fit into the context of the game. This wasn’t a bad thing at this point, people were just making observations and suggestions that they might like a reason as to why this is apparent all of a sudden.

Utilize the coloured dice rolling upon landing on a chest tile to make risk vs reward ‘random’, rather than just ‘random’.

Until next time –



1 Comment

Posted by on June 27, 2016 in Uncategorized


Renegade – Board Game – Paper Prototype

I’m currently in the process of creating a 3 player board game “Renegade” with two other team members. Renegade is a Free For All / 2v1 Cooperation card using strategy/race board game. Each player randomly gets dealt an allegiance card on game start, two are non renegades, the other is a renegade. The renegade must beat the two non-renegade’s to the end of the board and vice versa.

Documentation is still going on behind closed doors and we are flushing out specific details and mechanics to Renegade. Upon pitching this to two groups, one small and one large, we received copious amounts of suggestions. We have sifted through all of said suggestions and picked apart what we are or are not going to use or adapt into Renegade’s game play. Some suggestions we are taking on board deviate completely from the original idea. Some, we have adapted in more complicated ways to increase interesting game play dynamics whilst also being easier and faster to perform these actions, more API (Actions Per Minute).

This slideshow requires JavaScript.

While some of the systems and numbers are still being tweaked I’ve gone ahead and made some placeholder prototypes. 3 Cards that we have already defined – The 2 Non-renegade and the 1 Renegade card have been created and detailed as such. However, while there is a board and it has spaces that the players move around on, the design is not finalized. The board remains blank at the current moment. Instead of drawing on the board to replicate what & how many squares will be on the board, small white squares that aren’t attached to the board will be made to freely change the layout at any given state. Allowing much more freedom and ease of iteration with changes made much faster. There are also 15 of each Red, Blue and Green cards. These will engage the players in performing specific actions. These are still also having specific design details iterated over. For now, each of the 15 cards have no instructions, but have a visual representation of what suit colour they belong to.

This slideshow requires JavaScript.

There’s plenty more to create and discuss, but that’s all for now.

Until next time –



1 Comment

Posted by on June 24, 2016 in Uncategorized



When I Grow Up

When I grow up. I want to be a World of Warcraft Level Designer for Blizzard Entertainment. Shoot for the skies right?

But why a level designer? Well, it gives context to game play, is visually engaging, it creates a navigable areas, it can guide player’s attention, amaze people, the list goes on and on. But, most importantly, it’s an area that allows all of the game play elements to come together.

It has one limitation. Creativity. A level can’t be what isn’t imagined. Besides, look at the possibilities.

But one more reason why I want to be a level designer?

I love it.

I’ve had a taste of level design from time to time. Previously, and a long time ago now, using the Warcraft III: The Frozen Throne map editor

Portal 2: Test Chambers Creator

Unity’s Terrain editor

This slideshow requires JavaScript.

This slideshow requires JavaScript.

I crave it. It’s the one thing that I constantly want to do. I’ve come to appreciate and highly respect level design. It’s beautiful, it’s art. From the floating ashes of flame to perfectly flowing hills, my is focus is dedicated to creating that jaw-dropping wave disbelief.

Some of the designers I’ll be keeping a close eye to are: Chris Robinson, Ely Cannon, Victor Chong, Ian Gerdes, Edward (Ed) Hanes, Kevin Lee, Damarcus Holbrook, Michael McInerney and Paul Cazarez.

Until next time –



Leave a comment

Posted by on June 24, 2016 in Uncategorized


Play Testing & Questionnaire

Jordon and I were lucky enough to have some wonderful people play test Ball Ball on two separate occasions and provide some interesting feedback about their thoughts on the game.

Some of the feedback from the first session provided us with specific details that needed attention before the second play test began. Such as the line renderer from the balls position to the mouse’s position when launching to give a better visual representation of which way the ball will be launched. We were able to iterate over and improve on the existing design before the second play test. It was important to help players understand what was already in the game rather than add more content.

The questionnaire looked like this:

Ball Ball Questionnaire

Some of the answers  were predictable but very understandable. And by that I mean that as a developer, I always try to think as if I was playing this as a ‘Player’ and not a developer, what is the game missing? Or what doesn’t feel right? Some answers highlighted details to what have should have been in the game but unfortunately didn’t make it into the prototype, or certain aspects that could have made the play experience less frustrating.

Specifically like interacting with the ball – Sometimes it was particularly hard to launch. Some of the answer’s for “What did you feel could be improved?”:

  • Prediction for where my ball is going
  • The feedback of where the ball was going to launch?
  • The visual feed back in terms of how you are going to be launching the ball
  • The pull back before firing is sometimes unresponsive
  • the pull back mechanic is a little buggy, doesn’t always activate when you click or when you let go, and has a limited range it can register how far it is pulled back.

Looking at these answer’s from both a developers perspective and a players perspective, I completely agree. It would have made all of the difference for players to see where the ball would have been launched.


But like I mentioned previously in the “What went wrong”, unfortunately not everything we had planned made it in. While we were also thinking that this was something that needed to be added, the responses concreted this.

What elements did you find hard to understand? Why?

  • the level design was quite effective at teaching me about the different pickups.
  • very few. the most issues I had with the game revolved the lack of feedback for where my shots are going, and the lack of accuracy that resulted.
  • none.
  • Trying to understand how the much force is required before releasing the ball. Each pull is different when using the status effects.
  • none. all good
  • I didn’t read the wall of text in your instructions screen. There was too many words.
  • Nothing really. was mostly well communicated what the objectives of each level were.
  • It was all pretty straight forward. The generic green blocks were a bit unclear though.
  • None. Game was simple and fun to play.
  • Not sure what the green blobs do. Not sure why TNT sometimes knocks me off screen and sometimes doesn’t.
  • In the begging it was if I actually finished the level.
  • Everything seemed pretty strait forward

The responses that are in orange bold letters make me warm and fuzzy as a designer. Their responses clarify that my intent as a designer for this game has been accurately applied. The intent that the player shouldn’t feel lost and that the level teaches the player with what they need to do. The response in red bold letters is how I felt about the instructions too. If we had more time on this prototype I would have loved to make imagery instructions. People are able to interpret, understand and relate to images much faster than they ever will to a block of text. A little instructions pamphlet full of gifs of how to launch the ball or how the ball interacts with objects would make understanding the game so much easier.

While I could go on to mention every response people had to every question, I’m only going to mention two more specific things that I’ve learnt/found very useful.

  1. One of the answers to the ‘Any other feedback?’ was – Consistent HCI
  2. Facial expressions and body language watching people play games.

HCI? I don’t know what HCI is. What is HCI?

So my interpretation from the response is: “This game has a consistent human brain activity and interactions between the visual representations and systems in place of Ball Ball”. I hope that’s right. Thank you kind play tester.

Facial Expressions and body language – Play testers were being audio and video recorded. I watched every play test video (in this case because there’s less than 15) and payed close attention to how they interacted with the game, their facial expression.

Some people have no particular body language or facial expressions at all.  And while watching the people that have no expressions at all, I ask myself, “are they enjoying it? What do they like? What don’t they like? What’s running through their head?” They are giving no sign of how the game is making them feel. Even though this is unhelpful to know their player experience is, I can still watch how they interact with the game and see what processes they go through. Is this how it was intended to be interacted with? Have they found a more useful way to interact with an objects that could be utilized in our game to create more interesting dynamics or player experiences?

Gareth No ExpressionSteve no Expression


But then there’s people who do. Watching these people react and how drastically they react to different situations, helps understand what is going on through their head.

Caleb Win Woo

Such as a victory “Woo” because they understand that they have beaten the game.

Nic Excited

Concentrating excited face.

Nic Whaaa.

Eh? What happened? I’m bored.

Oh no 2

A happy realization that they’ve messed up.

Oh No

A sad realization that they’ve messed up and have to repeat again.

Tony Sad

Hanging head of disappointment.

Tony Stretch

I have no idea what’s going to happen but lets give it a try anyway?

Tony WTF

Determination. Definitely determination.

Pritish Happy

I’m enjoying playing Ball Ball.

Pritish Huh

Did I break the game?

Seychelle Surprised

Surprised. They didn’t expect that.

The people who play and have facial expressions and visual emotion provide a much greater opportunity to try and understand what’s going through their minds.

Such as:

  • Why they feel angry or frustrated.
  • What aspects are bringing a smile to their face.
  • What caused them to think they broke the game.
  • Why are they finding particular aspects hard to figure out.
  • They did or didn’t notice something that they should have.

The play testing recordings and questionnaire help to understand what is going right, what is going wrong and what the path to the next destination should include.

After all – What are games without players?

Until next time –



Leave a comment

Posted by on June 21, 2016 in Uncategorized



Ball Ball Post Mortem

Ball Ball is a prototype 2D fixed camera physics based ball interaction game. It was created using Unity 5.3.3f1 and in collaboration with another team member –

Programmer: Jordon Dodds.

It’s a free download on

What Went Right:

Communication & Effort

The amount of effort and communication between Jordon and myself was great. Throughout the entirety of working on Ball Ball we spoke on an extremely frequent basis on everything ball ball related. It made the creative process so much easier and more enjoyable. Both Jordan and I put in the amount of effort required to get Ball Ball to a prototype stage. While Ball Ball still might not be the originally sized planned game, it wouldn’t be what it is without the great communication and collaborative effort.

Game Elements

How accurately this game transformed from an idea, to a concept and then to a prototype. Ball Ball turned out to have the exact play style and game feel as originally intended and documented. Almost every game object and the way it interacted with each other was also exactly as intended, with the exception of sticky goo (see what went wrong).



Even though the GDD, TDD and HCD could have used many more iterations, what information, design principles, visual aids and game systems were in place greatly bolstered the design process of Ball Ball. In this case, partly figuring out the game before it’s even been started makes so much more time for actually creating the intended thing, rather than a bunch of head scratching and thinking “what now?”. The task schedule was even being created on the go. Before Ball Ball was underway I quickly went through the TDD and GDD and made a list of some of the things that needed to be done. Once some of the objects had been completed, I’d add a few more tasks that needed to be done. With major objects like the ‘Ball’ and TNT for example, those as headings don’t break down exactly what needed to be done. Breaking down a task into what actually needs to be done set a pathway to achieve small milestones.

Task Schedule & breakdown.JPG


What Went Wrong:

Aspect Ratio

When converting from playing in the unity inspector to a build or maximized screen, some game objects were not in the camera’s view. That’s because I’d been constructing the level in a free aspect. Free aspect makes the camera show the amount of space that’s been allowed in the unity editor.

Aspect Ratio 1

What the camera sees in 16:9 Aspect Ratio

Aspect Ratio 2

What the camera sees in Free Aspect

And that is just because of the current unity window layout. Depending on how you have the layout in the Unity editor, the camera will adjust its view. I was making levels in free aspect on the computer at home and it worked fine because I had the same layout every time. But when opening a build of Ball Ball, or just playing in maximize screen, half of the level’s objects aren’t within the cameras view. I had to reconstruct all of the levels in a 16:9 aspect ratio. That way the levels will always be in the cameras view.

Scope / Time Frame

Without detailing an entire list of what didn’t go right, to sum it up – certain aspects that were planned, didn’t end up making it into the game. For example, the sticky goo made it into the game but had completely different functionality as intended. Particular aspects such as the ball launching mechanic and the finish zone could have been greatly improved. I also never got to create my own 2D assets, which I was genuinely looking forward to. This is partly because it was only a 3 week project, two of which were documenting the idea and making the game concept more solid. It was also partly because maybe we should have realized that it was only a 3 week project and toned down the scope. It was either have a completely perfect design concept with systems ready to be created and have no game. Or have a somewhat functional design with a working prototype.  Or alternatively, a perfect design and a perfect game, but no sleep.

Repository Pushing

I had issues with GitHub commits, pulling and pushing towards the end. This was because the git ignore was in the wrong location. If it’s not in the very base layer of the project, and by that I mean not in the very first folder that holds the contents to the project, the git ignore file doesn’t do its job. And because of this, it subsequently adds a whole bunch of stuff to the upload that stops it from uploading.


This is Right

Until next time –



1 Comment

Posted by on June 18, 2016 in Uncategorized


Ball Ball Scripting – Logical Design & Code Quality

In a previous blog post I mentioned that some of the code could have been structured better. Now that Ball Ball isn’t in its most basic form and has all of the core elements working, both the programmer and I changed some of the code inside of the ball. Rather than all of the other objects waiting to detect when a single object collides with them, and change properties inside of that single object, why not have the single object detect when it collides with things and change its own properties?


Although many more improvements could be made within the game to make it more efficient, and in the case that it would become more complex, more easy to adapt and change. Rather than having 50 pickups and having an individual script, minimize the amount of scripts by having the least amount of objects detect for the majority.

But lets start small with changes like having the ball detect for the pickups that enlarge it and shrink it. There’s multiple ways to do what is being described, but the way that we did it was adding an OnTriggerEnter2D(). And inside this trigger method, check for the colliding objects tag and perform the corresponding code.

Code upgrade

It also becomes easier when activating UI elements. So instead of having 4 scripts, 2 of which need a reference each to the UI controller and the ball, there are two scripts. The ball will only need a reference to the UI controller.

Start Ball Ball

This means that there is less room for errors. It also means that there is only one place that code would need to be changed in the event that both the shrunken and enlarge pickup needed changing.

Speaking of UI controllers. Because of the way that this game has been set up, each level is a Scene, and each object is a prefab, or a collection of prefabs.

So because every time a level is complete, a new level is loaded. Each time a level is loaded The GameController and the UIController need access to certain scripts or objects. While it’s appropriate to fill in the gaps through the inspector I can safely say that sometimes I’ve forgotten to fill in one of these gaps. And it causes quite a few issues and wastes time. I like to avoid times like these by making the GameController and UIController get the scripts or objects they need in Start(). I also do the same for some particular UI elements that do or don’t need to be activated on start.

Scene Kit Prefab



This way, every time a new scene is loaded instead of having to untick every box in the inspector in every scene, it’s already done. So when a Scene Kit prefab is dropped into a level, the only thing that needs placing are the objects that I’d need to construct a level. Other than that, the Spawn point, Ball and Finish zone would have to be moved to the desired location.






I’m sure that DontDestroyOnLoad would have been applicable too, especially to everything in the kit, with the exception of the ball, finish zone and spawn point. But in order to get the prototype working the Scene Kit did perfectly. The DDOL is definitely something worth looking into though, It might have been even more effective and efficient than using a Scene Kit prefab. I’ll have to test this theory later on.

Until next time –






Leave a comment

Posted by on June 17, 2016 in Uncategorized