Game Design Document Version History

When developing my game I noticed that certain elements the game needed to be changed through my game design document. This is a common procedure when it comes to game development. The further along the development process you go, the more detailed the information will be. You can begin to expand the document without losing it’s readability [Ella, 2014].

One of the changes I needed to make was the rocks. at first I was going to make rocks as simple sprites and import them in game maker. It seemed simple enough as all I thought it would be is a simple sprite job. Later down the line of development however I realised how much work I would have had to have put into coding the enemies to crawl over the rocks. Not only would I have to code them I would also have had to animate them stretching over the rocks in a realistic enough method.


In the end I ended up removing the rocks from the game. This is due down to not prioritizing them in the first place. When working on projects you cannot always know fore sure how hard every element will be unless you have had practice before. For future projects I can now see how much effort needs to go into game play elements as small as rocks and will think twice before sending them to the back of the prioritized list.


Another change I made was to the enemy. Through play testing the game I felt that only having 1 enemy was really boring. I received feedback from people who play tested my game and they thought the same way. I decided to add a bigger enemy to give it more of a challenge.


For the bigger enemy I made him a red colour instead of green. I also made him inflict 2 points of damage to the barriers so the game would be more challenging.


A link to my previous GDD can be found here: GDDversion1

A link to my updated GDD can be found here: GDD


Ella Romanos. (2014). How to write a useful game design document.Available: Last accessed 14/01/2015.


Digital Prototype


I further developed my paper prototype in game maker. I made a menu screen containing the play button, which takes you to the game level. A controls button, which takes you to the controls level. The exit button that exits you out of the game. For now all the sprites and titles are placeholder sprites. These will all be replaced once I have gotten the main focus of the game mechanics sorted first. It is important to prioritize certain part of the game such as the mechanics over other things such as sprites. You don’t want to be spending ages creating a good looking sprite then realise you don’t have enough time to add core game mechanics to the game.


The prototype as of now consists of a player, two barriers with their corresponding health set up and two bows that the player can pull back and fire. The enemies are also setup as red cubes that move towards the player inflicting damage on contact of the barriers.

prototype2 prototype3


Now I have setup my digital prototype I can further develop it with good looking sprites and fancy game mechanics that I don’t need in my game.

Paper Protoype

My Project prototype consists of:

barrier                 bow

The barrier                           The bow


char                    enemy

The player                                                The enemy


2 dice, one 20 sided and another 6 sided.


– Every turn an enemy spawns 30 cms from the player.

– You can shoot once per turn and move left or right once per turn

– every turn the enemies move 15 cms closer to you.

– You can shoot once per turn.

– When you shoot. depending how far away the enemy is you roll the dice to see if you hit.

If the enemy is less than 15 cms away from you you roll a 6 sided dice, if he is more than 15 cms away from you, roll the 20 sided dice. for the 6 sided dice, 3 or more and you hit, killing the enemy. With the 20 sided dice, roll 10 ore more to kill the enemy.

– If the enemy hit the barrier, a health is taken from the barrier. The barrier starts with 10 health and every turn the enemy is in contact with the barrier a health is taken from it.

– If the barrier gets destroyed it’s game over.


I played the paper prototype for a good amount of time with other people to test my game. After playing the paper prototype I realised only having one enemy was a bit boring and I needed a bit of a challenge. Playing the prototype was really beneficial to me for play testing my game before I make it.

I got some feedback from players who were play testing the prototype. One bit of critical feedback that I received was to make the enemy continue to move towards the player after the barrier gets destroyed. It felt batter knowing you die once the enemy hits you rather than the barrier.

IMG_0438 IMG_0437 IMG_0436


Images of the paper prototype in action.