Posted in Studio GDS210

Fighting with a Dragon.

I will discuss same parts of this game so please put a couple of hours aside and play this game before you read on.

I sat down to play this game with an open mind and didn’t take any of the good and bad press surrounding the game when it was released to judge it for myself.

Continue reading “Fighting with a Dragon.”

Posted in Studio GDS210

Giveth Taketh Board Game Pitch


This week on Monday, in a new team we pitch our new game idea, Giveth Taketh. Giveth Taketh is a player trading game that will have players swap and draw token from each other and a bag to complete a code of colours. The game has several was that player play compatibly against each other. Winning won’t be hard be if players pay attention they will be able to achieve this in a quicker fashion.

Giveth Taketh

Room for Change

That this stage of the game design all the members of our group have good knowledge of the concept and what we wanted to achieve. During the pitch I could have done a better job of articulating the idea and not have it mushed up and the nerves of the moment. Throwing your idea to the winds of change is a great way to find new points of view but always come with a reluctant   sense of hesitation. Also the effective use of a 5 minute pitch can be tough to get the important information across. This internal pitch was a step to help us better improve our skills for an external pitch to collaborator and peer audience.


As part of every pitch there are 4 areas of feedback that are giving for an audience. These consist of:

Feedback with Colourful Comments Symbol

Clarifying Questions

After our pitch there where a few question that people asked to help understand:

  • Some about the where about help understand the player interaction as this was a rushed part of the slides.
  • There where question in regards to the bag of random that we are using and how the player will know what is happening if this will be fun for players.

Warm Feedback/ Cool Feedback

We were giving a lot of warm and cool feedback for our idea, this was a great boost in moving forward as it meant that we could see have worked what didn’t quite come around or be understood as we had hoped. This help us question element of our own design in ways that we hadn’t thought of. For instance it had us asking the question do we need this, is this something that could be explained better or if x and y didn’t work why is this the case.

Warm feedback on the premise of real world scientists, and this feel of a steampunk like theme where well received and the game board idea of an atom with three cross over path was an idea that was like and felt like it had great parental.


Board concept

Cool feedback help cement the importance of areas that we were unsure of and felt that we could work into out game better and the probing question also help drive home these question and elements

Probing Questions

These question came up in the cool feedback as things players didn’t but also that they felt that this could be done differently

Q. Have considered complexity?

This was in regards to what the player was able to do on a turn and how the players were able to interact with each other in an interesting way. As it felt like players at this point where just alone for the ride and where not about to change the course of play much at their own accord.


We decided to make this accessible to players viva the interdiction of card that the players are able to play on their turn in was to help them self’s or disadvantage others.

Q. For what reasons would a player chose to hold on to the “bad” colour?

This question was ask as player had to complete a code of coloured tokens and because player need these colours having colours that didn’t help you to this goal just seem to be a waste and with no way for you the owner of the tokens to pass them to another player.

The only way these would leave you pile was of a player randomly took one from you but the receiving player had no way of knowing, was this a good thing I did? Was this a bad thing? With this it had us asking why they are doing this. So we started to think of was players could find out info about what players wanted or didn’t want by way of their action and how to make this apparent to players.


On the back side of this first pitch the team has a lot on our minds to help make the game a much better version of itself and  with a external pitch on Wednesday we hope to have these charge we are to make be well received. Onward and upwards.

Posted in Studio GDS210

Studio 1: “Grandpa’s Beard” Post Mortem

This game is a physics based game made in unity with the combined help of a programmer and a two man team.

Check out the prototype here

Programmer : Marivan Ebrahimi –

Grandpa’s Beard. All though this was a small game with not much scope, but this doesn’t mean that the complexity was any less complicated in its completion. The concept for this game come from a range of game looked into around stacking objects. This ranged from casual iPad games and work I did on a fellow student’s game in my studio classes.Untitled

To take this idea from concept to prototype there where several reiterations I need to go through to get there. A High Concept Document was based around an idea of stacking block to form towers, the team on this project, compromised of myself as the designer and a fellow colleague a programmer, I believe that we have managed a satisfactory job, in creating is prototype of this game idea, within three week development.

What went right? But also wrong.


With the documentation on this project believe that we managed a satisfactory job but there where area that could have been involved upon, keeping all elements of documentation up-to-date, and make the necessary changes were needed was done well but the groups could have referred to this on a more frequent bases to stay informed of changes. Documentation on project included, Game Design Document (GDD), High Concept Document (HCD), and Technical Design Document (TDD).

The good that came from these document was that have other peer look over and interpret them gave me a good scene of how I could word or explain what I’m wanting the game to portray or convey to other working on the game. Having people with different skillsets are able to see different elements that might not work together or areas that are not cover in enough depth. This help as I was able change my way of thing when structuring these documents in the future.

Source Control

This has been an area that in my past hasn’t gone as easily as it so simply should. With say this it is a simple are area that when it work it work wonderfully but can be so easy turn into the hellish part of a project.


The Up side to this project is the my colleague was able to set this up and I was then able to learn very helpful lessons form this working system and not have headache on it not working. Working from a master and everyone copying a version of this instead of everyone using straight from this master and branching from this to get things working and merging it but to this work. Looking at all this in after the fact seems common-sense but if glad that this is all a lot clearer after the duration of this project.

Colleague Understanding and Workflow

This was an area that worked will when all parties were at the same table be it task or element of the game we were constructing. We were able to play off each other’s strengths and help or instructed with weakness. Workflow and communication over the course was the area that needed improvement and knowing when each other was able to work on or was working on the project wasn’t enforces. Share schedules and working into this times that group members are able to work together would help and elevate unnecessary back and forth communications

Play Testing

Play testing is a so useful. This is a pessary thing and when a group contemplates that it’s not that useful until the game is finished. A game is never finished and only through play testing is going to become apparent.


The round of play test on this prototype went right in so many ways but show things o so wrong in the process. With a large amount of play testers we were able to find consistent reference to elements that we needed to consider the next time. All of these elements and outcomes stemmed from being over looking the planning and the structuring of documentation.


I believe that this group had a good understanding of element and issues that arose on this project. Knowing how to implement elements and overcome setbacks. However these are could have flowed much more effective if they had been address sooner. This resulted in element that needed work getting neglected for fixes and poor planning.

Apart from this a lot good has come from this project as a hole. Outlining key things that are paramount to the design and development of a game. Being able to reflect on and see where these areas are and improve on them will bolster future projects and their success.