Quality Assurance

As part of my project I got feedback from people who played my game. I got people to tell me one thing they would improve to the game to make it better.

One person said that they thought I could have put more effort into my background design. I agree with this feedback. I think if I had spent more time researching into medieval architecture, I would have had a better understanding on how the game should look like.


In order to track the bugs effectively I made a quality assurance form. It got hold of all the bugs in my game and when they occurred. QA forms help users keep track of their bugs and maintain them for fixing at a later stage. [David, Unknown]

I made my QA form into a grid displaying what the bug was, how it was found and how it was fixed. I also kept track of the date it was found on.


A full link to the QA form can be found here: QA form


David Wilson. (Unknown). Quality Quality Assurance: A Methodology for Wide-Spectrum Game Testing. Available: http://www.gamasutra.com/view/feature/4007/quality_quality_assurance_a_.php?print=1. Last accessed 14/01/15.

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: http://www.develop-online.net/opinions/how-to-write-a-useful-game-design-document/0196644. Last accessed 14/01/2015.


Learning new skills is never an easy task. Games require a lot of work for them to work properly. The slightest mechanic error can brake the game entirely and throughout the development of my 2D game I had to do a lot of bug fixing and polishing to make sure my game was in good shape. I feel throughout the process of making my 2D game I have learned a wide range of new skills that will benefit me a lot. Managing the project was one of the biggest skills I have learned. The ability to effectively plan out dates in which certain elements of the game need to be complete is a vital skill when it comes to developing games. I have learned just how much work needs to be put into development and how I can effectively manage the project to make it as good and polished as I can.

At first going into this project I wanted to make the biggest and best 2D game I could think of. So I began developing a 2D platformer that would have many level the player can play through. I later realised during the project that I had over scoped. The amount of levels and assets that would need to be made along side my game mechanics just wasn’t doable to a high standard. I was faced to either change the project slightly or make everything at minimal effort. I decided to change my project slightly due to the fact I wanted to keep my assets at a suitable standard. Instead of having multiple levels the player would play through, I just had one where enemies would endlessly come towards the player. I had essentially replicated a tower defence game. So I decided to build my game around that idea further developing bow and arrow mechanics to defend the player and barricades that the enemies had to destroy in order to kill the player.

One of the biggest tasks I had in hand was learning the game maker language (GML). At first it seemed an impossible task as I had not much programming skills or experience. however after a while of practicing and reading research sites such as the game maker docs website which is built into the program, I discovered it wasn’t such a difficult task. Making game mechanics became a lot easier o me when I learned simple actions like collision. It is done by checking if there was space in front of the character first using the action ‘place_meeting’ [yoyo,Unknown]. Once I learned actions like this I could manipulate them and reproduce them throughout my project.

During my project there were things that I thought went well as there were things that I thought didn’t do as well as I’d hoped. the bow and arrow mechanics within my game was a mechanic that really stood out for me and I am very pleased with the result. I feel it went well when I was playing the game and having a feel for the mechanics. It kept me playing the game as it was a fun and entertaining game mechanic.

I feel that parts of my level layout were not such a great success. The player is barricaded between two walls however there isn’t an awful lot of assets within the barricade to dress up the level. It seems slightly dull and boring. I would have made some sort of platform where player walks on instead of just the ground. This would really give the player a sense of safety and not like they are just in a ditch somewhere within the level.

During the creative process of my project I was able to let people come and play my game and give quality assurance to me to effectively critique the game and improve it. Some key critical advice I received is to give the barriers an onscreen health number. Before you just had to guess how much health the barriers had from 1 to 10. now the barriers have a number on top of them indicating how much health they currently have. This gives the player full indication on the health and what barricade they should give priority and manage over the other. I think it is important to receive critical feedback and to implement that feedback to the project in order to strengthen and improve it.

During my project I was to design the character and animate it. I began by drawing thumbnail sketches and then scanning them into the computer to further develop them. I then began to work on the in Photoshop where I gave it colour and shading to bring it to life. I am very happy with the result of my character and I am surprised that I didn’t have any issues or problems during the development of it.

Another sprite that I was successful with and pleased with was the enemy. Although very simple it brought a smile to my face seeing the slimy green blob slither across my level. It was very easy to animate. All I did was change the layer in Photoshop with tools like the warp transform tool and the liquify tool.

Like many things, my project had things I though didn’t go so well. Once of the biggest things that went wrong was the bow pullback mechanic. Playing the game for the first time was alright as you wouldn’t normally do things you would playing the game for a long period of time. I realized after a long time playing the player could click the bow and drag the arrow anywhere on screen. This included dragging the arrow over enemies anywhere on the screen killing them. I solved this bug by making the arrow fall out of the bow at a certain range using if statements [yoyo,Unknown].

After fixing that I then realised that the player could still drag the arrows over the enemies if they were really close to the bow. This meant that there was still something wrong with the bow mechanic. I fixed this by making a global variable called arrow lethal and only set it to true when the arrow was released from the bow. After that I realised the arrow was still set to lethal when It was in the ground set still. To fix this problem I set the global variable arrow lethal to false when it collides with the floor.

I thought the level design on my project did not go as well as i’d hoped it too have. The level was very simple. I think if I was to re design my level I would make it a lot more visually pleasing. I would design the background with higher detail such as treed and mountains that looked nice.

To evaluate I am happy overall with the outcome of my project. I can happily say that I have learned very good skills when it some to the development of 2D games and I can now use them during future development processes. I can understand now how important it is to receive critical feedback and implement it into your projects to improve.



YoYo Games. (Unknown). Game Maker: Studio. Available: http://docs.yoyogames.com/. Last accessed 14/01/2015.