Dissertation Summary

All in all thanks to this dissertation I achieved my long awaited goal. As Square Drop, Square Wobble and Square Follow prove - I can now comfortably create simple twitch based mobile games in C#.

Just to show how eventful this dissertation was, here's a breakdown of what happened each month:

September 2014: Coming up with the best dissertation for me
As this post shows, long before my dissertation started, I knew exactly what I wanted to achieve with it. I wanted to learn C# through creating a number of simple prototypes for mobile devices. Initially my plan was to replicate already existing mechanics from a selection games. As pointed out by Dave however, a dissertation which revolves around re-doing games would not have enough depth to be considered a good dissertation.

What makes a dissertation stand out is when a student researches and learns about the topic of their choice, and then proves they have gained that knowledge by producing their own piece of work that follows the theory they've learned about. Depth is what really matters, not the amount of prototypes I can replicate in 8 months.

Hence I changed my plan:

It still focuses on me learning C# as I'll still be creating artefacts for mobile phones, however instead of reproducing prototypes of games that have already been created, I will design and make my own games, following the philosophy of Bushnell's law, one that states - 'All the best games are easy to learn and difficult to master.'

October 2014: Theory work
Having sorted out the structure of my dissertation, I spent the entire month researching Bushnell's philosophy. I found out the tools that'd help me make a game easy to learn and tools that'd help me make a game difficult to master. I then decided that I want to make twitch based games, as there's a high market for them (especially for mobile devices). By making twitch games I'd also learn more code due to having to code in physics such as movement or object collision.

I then looked at job adverts to find out what coding qualities companies are looking for, and then I created three timelines - one that was structured around me creating one prototype by the end of the year, one with two prototypes, and one with three. Not knowing what's ahead of me, I had to create three differently scoped timelines, to later adjust to one that suits my abilities and time management best.

November 2014: Learning C# for the first time and designing my first prototype
In November I took my first steps with C# by going through a Pong tutorial. It helped me a lot in getting the hang of syntax and the way in which physics work in Unity. I then designed my first prototype for what turned out to be Square Drop.

December 2014: Developing my first game in C#
At the beginning of December I went through a detailed market research, to make sure that I know who I'm aiming at with my prototypes (which then helped me gather the right demographic of playtesters). Then it was all about developing Square Drop - my first ever game in Unity. Although I sacrificed most of Christmas holidays just to get the game working before 2015, it was totally worth it as I've learnt a lot of C# syntax at that time.

January 2015: Playtesting Square Drop and designing prototype #2
In January I got hold of 20 people to playtest Square Drop. Having received positive feedback about the game being is easy to learn and difficult to master, I decided to not iterate it and instead design a new prototype. That decision was reinforced by the fact that by iterating Square Drop, I wouldn't learn any new code anyway.

To get out of my comfort zone and avoid creating a similar prototype to Square Drop, I decided to design one which involves a different input than tapping, and a different twitch mechanic than timing (which is what Square Drop involved). That's when I designed Square Wobble - a precision game that is controlled by swiping.

February 2015: Developing, playtesting and iterating Square Wobble
February was all about focusing on Square Wobble. Having gained some programming experience from Square Drop, it took me a lot quicker to create my second prototype. As it turned out, players did not like the swipe mechanic, so I replaced it with the reliable tap one.

During that month I've also done some research on playtesting, and iterating, to improve in these areas, since Dave told me he was scepical about the way I dealt with them.

March 2015: Designing, developing and playtesting prototype #3 
March was a rush month, because I had to make sure I get my third and last prototype ready for playtesting before everybody leaves for Easter holidays (if I let playtesting happen after Easter I'd just have 2 weeks left for iterations). I designed a game called Square Follow which is controlled using a drag input and is based on a pure speed twitch mechanic. Once again, to learn more C#, I made sure that I created a prototype which differs from the other ones.

The game proved to be too easy to some and too difficult to others. That's when I made use of the knowledge gained from October and added tuning to the game.

April 2015: Iterating Square Follow and doing first polish work
In april I iterated Square Follow and, since I had completed more prototypes than I had even planned at the beginning, I could start concentrating on polish work. I added a high score, and a restart button, I named the files, prefabs and classes correctly, added comments to code, organised the folders and so on.

May 2015: Polishing all prototypes
At the beginning of May I improved the performance of all three prototypes. I tidied up their code, I got rid of the bugs and I made them work smoother than ever. Since, thanks to player feedback and iterations they are fun to play on top of that, there's nothing stopping me now from handing them in for marking, and celebrating for what has been a fulfilling year!