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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s