Dissertation plan, part 3 - Dave's feedback

Yesterday I had an enlightening meeting with my lecturer Dave. I told him about my idea for dissertation - that I want to make a number of simple prototypes of different kind, which would show that I can universally code a variety of game mechanics. He told me that whereas it is good that I want to focus on coding, there are other ways to learn C# than just copying code off the internet - anyone can do that.

What makes a dissertation stand out is when a student researches and learns about the topic of their choice, and then prove 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 - how many prototypes can I pull off in 8 months.

This is why, I have changed the way my dissertation is structured. 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, which I have always been inspired by, and have mentioned in the - 'Why make games for mobile platforms?' post.

It states:
'All the best games are easy to learn and difficult to master.'

As to how many and when I'll be aiming to create my artefacts - it's too early to decide just yet, because first of all I need to fully dedicate my time by performing a thorough research about Bushnell's law, and break down what makes a game easy to learn, what makes a game hard to master, see some good examples, see some bad examples, and only then use that gained knowledge to start thinking about producing my own games.

Game mechanics used for touch screen devices

There are four possible inputs that can be done with a fingertip on a touch pad - it can either be tapped, swiped, held, or dragged across. I will have a look at the mechanics of some of the most successful mobile games of today, and see how they correspond with these four input possibilities, to later help me decide on the prototypes I'll be making:

Tapping:

Tippy Tap

In Tippy Tap the aim is to keep tapping the incoming black squares, without letting them go off screen and making sure no white tile is touched in progress. The tiles scroll down continuously, increasing the speed as the game goes on. I really like this game actually, I pulled off a pretty impressive (at least for my friends) score of 292.

oO

In oO, players control the white dot which continuously travels around the outline of a circle it is currently touching. Tapping, controls whether the white dot is inside or outside of the outline. Dot transition from one circle to another is possible, but only at the point where they are touching, so tapping in the right moment is really important. The aim is to finish the level without touching any appearing spikes.

Flappy Bird

Players have to tap the screen to keep the bird up in the air and fly in between and through the Mario pipe obstacles. For every performed tap the wings flap moving the bird up by a considerable amount. If tapping is withheld, the bird starts falling until it hits the ground.

Holding:

Duet

In Duet, players control a circle with two dots attached to it which are positioned on the opposite ends to each other, and rotate continuously just like in the mentioned game oO. Holding the touch screen makes the circle move upwards along with the rotating dots. The aim is to beat the level, without letting any of the incoming obstacles touch any of the dots.

Hill Climb Racing

In this game, the aim is to travel as many meters across the map with a chosen vehicle as possible. The gas button accelerates the vehicle, the other - brake button does what it says. Interestingly, there's no need for extra buttons to control the car in the air, since adding gas pushes the car engine towards the sky, whereas brake does the opposite, rotating the car clockwise, towards the ground.

Angry Gran

In Angry Gran the point is to smack as many people that the granny walks by as possible. A simple tap will slap the pedestrian, but if the screen is held, the granny will start charging a special slap, which will knock the poor victim out, giving more points if done with a correct timing.

Swiping:

Paper toss

Flick the paper ball into the bin. The aim is as simple as that, yet the game has proven addictive and successful. The variable wind power and direction, is what makes the flicks unique every turn.

Cut the rope

A candy is hanging on a rope. The aim is to cut it so it falls in the mouth of what appears to be a frog like animal. Collecting stars gives bonus points.

Fruit Ninja

The point of the game is to slice open all the fruits that get thrown up on the screen before they fall off screen. If a fruit isn't sliced on time, or a bomb is accidentally sliced, a life is lost.

Dragging:

Angry Birds

Players use a slingshot to drag a bird, to then release it and destroy all the enemies in a level. Power and the right angle are key when using the dragging mechanic.

Flow Free

The aim is to connect two dots of the same colour together. Players can drag out a line from each dot, and have to make sure to 1. not cross one line with another and 2. fill the level out completely with lines, so no square remains empty. Dragging is the main and only input the player can perform.

Sky force

By dragging, players control the position of a spaceship, which flies through the level, and destroys enemies.

Optical Inquisitor

In this game, players drag a cross hair in order to aim and shoot the target which meets the given earlier criteria.

Some games also make use of the motion sensor that comes in-build with smart phones, which means tilting the phone left and right, or flicking it forward, can activate a mechanic in a game. This means that I can use more than just the touch screen to trigger events when making my prototypes.

An example of a game that uses the motion sensor is Fall down:

In fall down, players have to tilt their smart phone in a way so that the ball falls down the platform gaps. Platforms keep moving up, so the game ends soon as the ball disappears off the top side of the screen.

References:
Youtube: androidtechman videos [ONLINE] Available at: https://www.youtube.com/user/androidtechman/videos [Accessed 19th September 2014]

Why make games for mobile platforms?

I could have chosen many paths to my games design career - I could make games for consoles, pc's or go for board games instead. Why did I choose to develop games for mobile devices?

Well, first of all, anyone can make a mobile phone game. If you can code and you've got the right program then there's nothing but imagination stopping you, from pulling off a game, that'll be talked about for months, and played by millions of people. What's more, is that it really doesn't take long to make a decent mobile phone game. It only took three days for Dong Nguyen to create Flappy Bird. He didn't need an artist, a sound engineer, or a programmer. He's done the game all by himself. In three days.

So why not develop and publish a three day project on a bigger machine?

Because of target audience. Console games, are for gamers. They are for people who want to sit on a couch, and have a go at a certain genre of their likeability, which usually includes an interesting storyline, and tens if not hundreds of mechanics involved. It is very unlikely, a console gamer will pick up and play a game that is limited to one or two mechanics, and has been coded in 3 days by one person. I caught myself playing the Impossible Game on a PS3 before, but it just didn't feel right, like it did when I played the exact same version on my smart phone. I just thought - come on, you've got a Playstation in front of you. You can do better...

Computer games are the same, maybe excluding Flash games, which are pretty much like mobile games, with an exception they never become popular, simply because people don't play Flash games any more.

Mobile game target audience is much much wider, than its alternatives. Games like Flappy bird, Angry Birds, or Dots are for people who don't want to get involved with the game, but just want to have a go at something quickly, to kill time by giving themselves an easy challenge. There's no story, straightforward gameplay, and usually just one simple goal. Practically games like this are for everyone. And everyone have smart phones and access to games like this nowadays.

On top of that I love one game design principle, which fits to mobile phone games perfectly. It's the Bushnell's Law, which was frankly what brought Nguyen so much success.

It states:
'All the best games are easy to learn and difficult to master.'

If players know how to play the game the minute they try it, but they find it challenging getting 5 points, then 10 points, then 30 points, they'll keep on trying until they beat their new score (and be superior to their friends). This is when the game becomes addicting and difficult to get hands off, which is what every games designer wants to see.

So in a nutshell, the reasons why I'm going for making mobile games are:

• Simple to develop
• Enormous target audience
• It has one design principle which is the secret to success

Wikipedia: Flappy Bird [ONLINE] Available at: http://en.wikipedia.org/wiki/Flappy_Bird [Accessed 13th September 2014]

Wikipedia: Bushnells Law [ONLINE] Available at: http://en.wikipedia.org/wiki/Bushnell%27s_Law [Accessed 13th September 2014]

The Keys For A Successful Mobile Game [ONLINE] Available at: http://greatpreneurs.com/keys-successful-mobile-game/ [Accessed 13th September 2014]

Dissertation plan, part 2

What follows is an email I sent to my lecturers, explaining exactly why I have decided to make a range of prototypes for my dissertation:

For my dissertation I want to put a large focus on learning C# and Unity. This is for two reasons:

One is that I haven't coded in C# yet, and in order to make mobile phone games in Unity, I've got to have some knowledge of it;

Two, if I happen to look for a job, it'll have to be programming, so a coding focused dissertation is probably what my employer will be looking for.

This is why my idea purposely doesn't include any design, or art work. My plan is to create a number of short game prototypes that instead of art, use place holders. Each prototype would let the player explore a different mechanic:

one could be jumping: http://www.youtube.com/watch?v=STHQFMd2bfY

the other could be tapping: http://www.youtube.com/watch?v=qEN99W8zBj4

another would be slicing: http://www.youtube.com/watch?v=TFFQNjJ5C5Q

and so on.

If I could show a set of 7-10 of them to an employer, or use the code I created them with to make my own smart phone games I would be happy.

So to answer all questions:

What do you intend to learn over the year?
I want to create a number of short prototypes for Android devices, and learn using Unity and coding in C#

What do you imagine you would be marked on?
The amount of prototypes I've created

How will your improvement be measurable?
The bigger variety of prototypes I make, the more code I'll learn

What are the benefits of reproducing existing games, and how many would you intend to reproduce?
Reproducing a number of prototypes that differ from each other gameplay wise, would show that I can universally code in many different mechanics. This would help me make my own simple games in the future, as well as prove that I can code to a potential employer. As to how many prototypes I'd be aiming to make - as I mentioned, probably between 7(one every month) to 10, but it is hard to calculate (might end up being much more if I get the hang of C# quickly).

Dissertation plan, part 1

What do I want my dissertation to be about?

Having just over a month left before starting my last academic year doing Computer Games Design at UCS, I've already been thinking about what I want to learn from my dissertation. Having been inspired by Dong Nguyen, the Flappy Bird creator, who was at one point making 50 000$ a day, I've decided that in the near future I'll be creating simple and addicting 2D computer games for mobile devices using Unity.

Before this can happen however, I need to break down all of my strengths and weaknesses, to see whether I'm prepared to develop a fully working game as of now.

Having taken part in the Dare to be Digital competition, where I was given a chance to see and experience what a professional gaming industry feels like, I've learned that when it comes to producing a game for a mobile device, there's a need for the following people:

• Designer - comes up with the game idea and pushes it in the right direction
• Manager - makes sure all deadlines are met
• Artist - provides all the art assets, and puts the game in the right mood
• Animator - brings the game to life by providing visual effects
• Sound engineer - reinforces aesthetics using audio elements
• Programmer - turns all the theory into practice by making things interactive with code

While game companies have a specialist in each of these areas, if I want to be an independent game developer, I've got to be good at all of them.

So how confident do I feel about each quality?

• Designer - my course has taught me a lot of design work, so I'm comfortable that I can design creative and fun games, and improve the right things to make it better
• Manager - I've successfully managed 2 full projects, and generally I'm a very organised person, so I think being a manager is my strength
• Artist - I can use Photoshop and Illustrator, I've never had any issues with my artwork, so I don't think I should improve upon being an artist as of yet
• Animator - during Dare to be Digital, all responsibilities regarding animation laid on my shoulders and quoting my team mates I've done a good job, so animating is not my current worry
• Sound engineer -  I can get sounds I need off the internet, without running the risk of copyright infringement, since most of them aren't under any copyright law, so I'm not interested in this area
• Programmer - I've coded in ActionScript before, however Unity only supports JavaScript, Boo and the more advanced C#. I cannot code in neither of them

As it turns out - coding is the aspect that I need to undertake in the coming academic year, in order to become an independent mobile game developer, and successfully make games in Unity. What comes with learning code, is also operating Unity itself. Certain functions and variables will provide different functionalities in the Unity engine, so I'll find myself learning new things about the software as well. Being ambitious and thoughtful, I decided that I want to code in a language which has the biggest potential in the gaming industry - C#.

How do I want to structure my dissertation?

Having spoken to a couple year above computer games design students who have gotten 1sts and 2.1s, I realised that apart from having an aim, I also need a structure. I can't just say - I'm going to learn C#; I've got to plan out how I'm going to execute that effectively.

So let's break things down:

• I want to mainly focus on learning C# and the Unity engine altogether, which means that I don't want to do any design, art, or audio work
• Since I'm a C# newbie I need to work my way up at the right pace, so taking things slowly without delusionally going for impossible tasks is a must
• I need deadlines taking place multiple times throughout each semester, to keep me going nonstop

So what sort of dissertation will provide all these points?

My idea is to replicate mechanics of a range of computer games that have already been done before. I'll pick games that are simple enough to do within a specified time scale and also that will teach me something new not only about C#, but also Unity.

As an example let's pick the Impossible Game. If I was to make a short prototype of it, while carefully replicating all its mechanics, I'd have learnt how to:

• put gravity
• allow a place holder to jump
• scroll place holders across the screen
• make one place holder destroy another
• make one place holder support another when its jumped on

Replicating the mechanics of this one simple game would already teach me a lot of things, that would prove useful in the future considering I want to be developing simple addicting games similar to that.

In conclusion, I know what my strengths and weaknesses are, and I've got a brief plan A for my dissertation. It doesn't mean, that this is the plan I'm going for - maybe the lecturers won't like it, maybe I'll change my mind. Either way, I know that whatever I'm going to do in the end, will involve learning C#, because this is the one quality I'm currently missing, in order to achieve my aspirations.