Friday, 29 August 2014

I've made a game - some of the challenges

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.
  1. I've made a game
  2. Why?
  3. How?
  4. Some of the challenges
  5. What did I learn?

Learning Unity3D

Unity provides a very high level environment for making games, however that doesn't make it simple. Unity is a huge package with a steep learning curve for someone with no experience of making games. In addition to this it's not just Unity I was learning. Each plugin must be learned and I used several including 2D ToolkitNGUIGame Analytics and iTween. All but iTween required a significant time investment to get up to speed with.

Fortunately there are many great resources for learning Unity.

Different aspect ratios

There are a bunch of different aspect ratios being used by various phones on the market. Usually this isn't a problem. For example a 16:9 iPhone 5 will simply show a bit more on the left and right when compared with a smaller 3:2 iPhone 4 screen. Unfortunately the core gameplay mechanic of Rebounder is angles so that extra bit of screen means that sometimes a solution that will work in one aspect ratio won't work using another. The problem gets worse as the number of aspect ratios increases. This is one of the reasons I decided to stick with iPhones and avoid Android devices.



In my head this problem could be solved by using some clever maths to calculate the angles required and adjust elements of the level accordingly. One small problem, I'm not that clever. Another solution I came up with involved attaching a script to each target that stored positions per aspect ratio. So the co-ordinates could be (-10, 10) for a 16:9 screen and (-8, 10) for a 3:2 phone. I binned this solution because most of the levels worked fine in various aspects so I was duplicating lots of co-ordinates. 

My final solution was the simplest. If a level worked in all aspect ratios it would be loaded as normal. If a level was different for each aspect ratio the level name would include the aspect ratio. E.g. Level2-16by9 and Level2-3by2. The aspect ratio would be calculated when the game started up and appended to the level name where appropriate. 

2D graphics

Unity3D is primarily a 3D graphics engine. No really, it's in the name. When I started development Unity did not have:

  • A Sprite GameObject
  • Collections of sprites
  • A sprite animation editor
  • Support for different resolution textures on different devices

Fortunately a great plugin exists called 2D Toolkit which has all of these features. Probably the most useful feature I found was the Sprite Collections.

You simply drag all your sprites into the editor and 2D Toolkit automatically squishes them together to form a large texture atlas containing all your sprites.

Even better, for each sprite in the collection you can specify things like anchor position, the which point it rotates around; and the collider type, such as sphere, box or you can draw your own. If that wasn't enough 2D Toolkit also supports different resolutions so you can display sprites of an appropriate size for the device. For example x1 on iPhone 3, x2 on iPhone 4 and iPad 1/2 and x4 on iPad Retina.

The only feature I wasn't impressed with was the GUI system. For that I used NGUI. It's not cheap but worth it if you need a complex GUI or can pick it up in a sale.

I've only scratched the surface of what 2D Toolkit can do in this blog. Without it I'd probably have given up way before Rebounder was finished. 

Massive self doubt

I've never made a game before, I've never been involved in any game development and making games is really, really difficult. Because of this I went through periods of time when I thought creating a game was incredibly exciting and periods of time when I thought what the hell am I doing, this is a complete waste of time. 

What kept me going was taking breaks when I got very frustrated/bored/despondent and taking encouragement from positive feedback I received from friends having played Rebounder.


Making a game takes time. I, like every other software developer who ever lived, massively underestimated the time it would take to complete all the tasks and massively overestimated what I thought I could achieve. At some point I stopped and thought, this is getting ridiculous, I'm never going to finish, I need to cut down my work. So I did.

I used Trello to organise my tasks.

I divided my remaining tasks into two lists, one contained nice to haves and the other required tasks without which I wouldn't have a game. I ended up sacrificing:
  • Sound
  • Music
  • More levels
  • Game Centre integration
  • Push notifications
  • Minor improvements suggested by testers
  • Android and iPad support
If I hadn't done this I'd still be working on Rebounder now, with no end in sight.

Next blog post - I've made a game - what did I learn?

Wednesday, 27 August 2014

I've made a game - how?

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.
  1. I've made a game
  2. Why?
  3. How?
  4. Some of the challenges
  5. What did I learn?

An idea

Before you can start making a game you need an idea. Ideas are easy, good ideas are difficult and being able to see an idea through is even more difficult. Anyone can come up with ideas on a very ad hoc basis but I wanted a more structured approach. So I did what comes naturally to me, I read a book on coming up with ideas.This helped me create a process. Essentially I would think of as many ideas as possible then iterative through them, giving promising ideas more thought then discarding them when I deemed them not good enough. Did it work? Difficult to say really. You could argue, quite rightly, that my idea is hardly genius, but hopefully it was one of my better ones.

Research frameworks

Once I had an idea I was reasonably happy with I needed to find a framework to help me build the game. There are a lot around. The frameworks I researched included Unity3D, Corona SDK, Marmalade, edgelib and ShiVa3d. Obviously there are pros and cons of each but Unity stood out because I could write in C#, you could deploy to mobile devices for free, it's Stack Overflow style answers site is great and the asset store is invaluable. The main con was that the pro version is very expensive and Unity say that the free version isn't designed to build professional games. Fortunately for me this wasn't the case and I didn't need any pro features.

Build a prototype

The next step was to build a prototype. I really wanted to throw together some code as quickly as possible to:
  • Prove that a simple game could be created quickly using Unity
  • Prove that the game idea worked by getting a people to play it
  • Prove that puzzles could be created of varying difficulty
  • Prove that the idea worked on mobile devices
  • Work out how to build the 2D graphics using a 3D game engine
  • Get some idea of how to structure a Unity project
  • Prove that enough levels could be created to make a game (as a side note I found an iPhone app called InkFlow which was great for sketching level ideas)

Build the game

Making the prototype didn't take a huge amount of time because I wasn't concerned with graphics, menus, quality code, project structure etc. Not so much when building the final game. Most of the prototype code couldn't be reused so I essentially rebuilt Rebounder again from scratch, and this time do things right, well, better than before.


Manual testing is boring. Unfortunately I ended up doing quite a lot because automated testing was one of the many things I cut from the game due to the decrease in my time/motivation and increase in my children. Other than myself I mostly relied on a few others to test for me. I used TestFlight to distribute development builds, it's great, I highly recommend it.

Next blog post - I've made a game - some of the challenges

Tuesday, 26 August 2014

I've made a game - why?

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.
  1. I've made a game
  2. Why?
  3. How?
  4. Some of the challenges
  5. What did I learn?


  1. First and foremost I wanted to make something. Software development is about creating stuff. Most developers, including myself, spend their lives creating software for other people, making other people's ideas. I wanted to come up with an idea of my own and then create it. In my opinion this one of the most rewarding and exciting things you can do as a software developer
  2. It's a challenge like nothing else I've done before. I wanted to prove to myself that I could do it
  3. I've been a gamer for a long time. I've spent a long time talking about what makes games good and what makes games bad. Part of me has always wanted to try and make a game
  4. Lastly I thought there was a small chance of making some money. I know, I know, pretty unlikely, but I would rather try and fail than not try at all

Next blog post - I've made a game - how?

Saturday, 23 August 2014

I've made a game

I've made a game. It's called Rebounder, it's a puzzle game for iPhone and it's available on the App Store right now unfortunately not on the app store right now because iOS8 broke the game and I've yet to fix it. The aim of the game is to get the balls to the target(s) by drawing lines on the screen. Each target must be hit five times to complete each level. In typical mobile puzzle game fashion each level is short and new mechanics are introduced as you progress.

This project has taken me a long time and has thrown up a lot of challenges for someone who has no experience making games. I'm going to write a series of blog posts about why I did it, how I did it, how solved some problems I faced and what I learned. Hopefully it'll be interesting.

Thanks to everyone who helped test and gave feedback. Thanks to my wife for giving me a lot of time to work on Rebounder. Massive thanks to Fin Costello for giving up his time to create the graphics.

Next blog post - I've made a game - why?