What Makes a Good Mobile Game?

A presentation by Nick Watt suggests a good app “plays to the strengths of mobile”. In his eyes, this consists of five things: Communications, Spontaneous, Geo-sensitive, Short periods of use and Focused activity (Watt, 2010).

In my game I look to follow these five things:

  • The game needs to constantly communicate what is going on, so descriptions of how to play each level should be shown. Where a timer is used, this should be shown counting down.
  • The game should surprise the user, there should always be new things to be discovered. To meet this I will make characters only available after a certain high score has been reached.
  • Geo-sensitive, although this means using the geo-location of the phone, I will understand it as using different features of the phone. I want to use the microphone, accelerometer, and all the different finger gestures to create variation in the game.
  • I want the game to be able to be played little and often, it needs to be addictive in the way that the user will keep wanting to come back to it. To do this I’ll add in the high score system, which will make the user constantly want to try and compete against themselves.
  • As short periods the time played needs to be focused. This would be done my creating simple games, but grow harder in difficulty the more points that are gained. This will make the user need to focus deeper into the game, as the harder it gets the more you focus.

Using these methods I should be able to create a mobile game that is addictive and enjoyable.


Game Theory

It was important to look at Game Theory before creating my game. Game theory can be based on any kind of game, whether that be virtual or reality, as all games follow the same ideas. Cailloi’s book (1958) “Man, Play and games” describes 4 basic categories of game:

  • Agon – competitive games where skills rely on skill/expertise (competition).
  • Alea – Games of chance, which hinge on luck/fortune/destiny (chance).
  • Mimicry – play in the sense of performance/acting/pretense/playing apart (simulation).
  • linx -vertiginous risk, playful activities which involve risk/thrill seeking/extremes (vertigo).

My game will use the Agon category, the game will be repetitively played because of competition with oneself. There should always be an urge to want to beat your own high score, and also beat your friends high score. The more the user plays the better they will become at the game, making them more skilled.


As iPhone’s have a small screen it was important to learn how to design for this, and what factors need to be thought about when creating and designing for them. As Matt Brian (2011) says in his post:

“The user interface needs to be as unobtrusive as it can be, leaving out any design elements that don’t add a use or function to the app. Bundling in too many design elements can leave it feeling bulky and will feel un-intuitive.”

I need to think about the basic functionality of the game, what are the most important things to include and what could be left out. I decided that the game should have limited buttons, it’s very distracting having buttons on the game play screens as the screen in so small they would take up valuable space. Not only this, but some of the games will have tapping as the way to win the game, so I don’t want any unnecessary buttons around that could be clicked on by accident. There will be no pause button, as this game is about completing levels in a short amount of time, so there would be no real point in a pause button for a game that last 4 seconds. In other words, there will be no buttons on the separate game screens, keeping the space open for all the game objects. What will be included though, is a timer bar, which will move down as the timer runs out. This will not be clickable.


Often when playing a game for the first time the sounds that are used aren’t always the first thing you notice. But as you continue to play the game you may become more aware of these sounds, even without realising memorising these sounds. One of the most well known game sounds of all time is Mario’s ‘bwoop‘ as he jumps in Super Mario. As a game designer it is always important to not put the game sounds last, they are one of the most important aspects of a game. As Collin’s (2013) hypothesis’ in his book “Playing with Sound: A Theory of Interacting with Sound and Music in Video Games” that:

“Interacting with sound is fundamentally different in terms of our experience from listening without interacting; that there is a distinction between listening to sound, evoking sounds already made (by pressing a button, for instance), and creating sound (making new sounds). ”

What Collin’s says here is that we have become accustomed to listening to sound, it comes naturally to us to just listen to sound. But in game play you can evoke sounds, you can do this that make sounds play, creating an interactivity with them. In this way the sounds in the game become more important, they become more personal as they are the sounds that the user is making themselves. They have gained complete control over something within the game.

With that in mind, I feel that it is important to collect the right sounds for my game, I want them to be something that the user feels a connection to. Like the Mario ‘bwoop‘, I want the user to want to play the sound over and over. Not only these but I feel the theme tune of the song must be something catchy, something that will stay in your mind. Like any good TV show, you will always remember the theme song – take “The Fresh Prince of Belair”.




When I first started my project I created a Gnatt Chart to control my time. I knew that there was a lot to do with my project, and creating a time plan would be so beneficial for me to keep on track. I also included on the time plan the time in which I wanted my collaborators to complete their work by too, so they could look at it and understand my schedule. (See Appendix 3).

Unfortunately, I didn’t manage to stick to my time plan. With a month to go I was roughly about two weeks behind with my work. It had taken me longer than I had imagined to code the individual games. As I didn’t know how to code ActionScript before I started, I was having to learn as I went along, this meant when I came to more complicated parts of code it ended up taking me longer to work out how to code and fix them.

With these delays  pervious delays and the last three weeks of the project approaching, I used the MoSCoW Method to decide on which parts of the projects were the most important for me to complete. The MoSCoW method is where by you determine which aspects of a project you Must complete before the deadline, which high priority items you Should complete, what you could complete if extra time is created, and what you think you Won’t complete before the end. (Wikipedia, 2014)


  • Get GameOver and StartGame functions working correctly.
  • Get scoring system working.
  • Add win/loose scenes.
  • Add sound/theme song.
  • Add the rest of the graphics.


  • Play around with the graphics.
  • Play around with the animations.
  • Play with difficulty of levels.


  • Add two more levels.


  • Have randomly shuffling characters, those of which are only loaded after a certain high score is reached.
  • Have as many games as originally desired.

With three weeks to go I tried to stick to these plans, but again, I hit problems with the difficulty of the code. I managed to make the gameOver and startGame functions work and a week and a half. I also gave each level a score system that worked for the individual level, but I did not manage to make the highscore system work.