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.
Testing
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
Next blog post - I've made a game - some of the challenges