Making a Game in 10 Days

[James posts his thoughts on Game Development at The Blocky Pixel]

A few weeks ago, while talking to a couple of friends online, I decided to issue myself a challenge. I wanted to see if I could use unity to build and submit a game in a week using Unity. I hadn’t had much prior experience with Unity, and largely it would be a learning exercise in exactly what it would take to get everything done.

I managed to pull it off, too. Not exactly in 7 days, but pretty close. Not the finest or most polished game ever created, but certainly not the worst either. I made Grey Out – a pattern matching game where you find shapes using like colour shades of grey. I was inspired by my bathroom floor. Seriously. How many times have you sit down doing your… umm… business… and tried to find shapes on the tiled floor? I do it a lot – others I spoke to did it too – so I thought there must be some meat there, and Grey Out was born.

I’ll start with a small caveat – I had some prep work done before I started. While on a long flight back from Brazil to Australia, I had plenty of time to work on some design. I also had a prototype I’d thrown together in about 6 hours, months earlier. Buggy as hell, I threw most of it away. I also had help from my business partner and girlfriend with content creation. Roping in others really saved my arse.

This describes the basic process I went through to go from start to end in a very small time frame.

1. Snap game design

No time for lots of prototyping concepts and seeing what works best. I used my best judgement to quickly decide on what had the highest likelihood of creating a fun experience. My earlier prototype and design was a time attack style game. Decided it would be safer to go with a more traditional level based game with unlocks, which would also give me an opportunity to teach the game transparently.

2. Pick a theme and run with it

I wanted to be careful with my theme – I needed to be able to do the art myself, and I most certainly am not an artist. I very quickly chose a black and white film theme. The assets would be easy for my to create and fit with the black, grey, and white mechanics. I know it wasn’t too closely tied to the action, but damn it, close enough. Once I picked it, I stuck with it. I also decided iPad only. Not enough time to design two interfaces and level sets.

3. Mock up with near-final art

I don’t have one of those fancy expensive artists. I have me and my wussy photo-shop skills. I wanted to get the look and feel of the game nailed down now. No point spending time mocking stuff up and fixing it up later. It also firmly solidified my concept for the game. Using a combination of original art, and using existing art as a reference point, I managed to very quickly put everything together. Slice it up and export it, and that’s most of the art work done.

4. Create the core mechanics

Now I had my art, I needed to put it to use. Using Unity, SpriteManager2 and EZGui, I spent a good few days getting the input working nicely, solution scanning, the matching working and the scoring. Being a puzzle game, this wasn’t too difficult. There aren’t too many systems interacting with each other here. Unity was great because I could quickly and easily throw it in a web browser and get some immediate feedback from my friends.

5. Write the content framework

Once I had my board all set up and running, I needed a way to get levels into it. I could have taken the time to create them all by hand in Unity, but really, too much work – also not flexible enough. It’s much easier if I can configure everything in XML. XML is very easy to create and parse. I created a library to read in and display level content using external files.

6. Hack together some tools

Tools. These were what really got the whole game done and dusted so quickly. Because my levels are defined using XML, I very quickly hacked together a level builder using C# and WPF. The level builder allowed me to very quickly create and tweak content without fighting an editor, or having to manually hand craft the level files.

7. Create the menus and supporting game mechanics.

So now I have a few test levels? Okay, I need a way for the player to move through them. Next I spent time on all the boring, but very necessary, menus, splash screens and title screen. I created scenes in unity for the high level groups of levels (called Reels) and the levels themselves (called Scenes). The first Reel and Scene would always be unlocked, and be unlocked through successful play.

8. Tutorial, Levels and Feedback

I’m now reaching the point where it’s starting to feel like a game. With my level builder and supporting game mechanics, I can start creating content. I spend the first two Reels starting slow and teaching mechanics, then create a third Reel of some simple puzzles. Now I have something people can play! At this point I started getting people to play it, get feedback, then tweak and add important features.

I highly recommend using TestFlight for this – it’s a great service for managing your test builds on iOS devices. Also, you can just share the web version! Unity is awesome, and not everyone has an iDevice.

9. Sound

This is a tricky one, because this is something I have the least experience with. Sound is something very important to a game, it’s also hard and expensive to do well. With this in mind, I decided to not bother with music. Music done well is awesome, music done poorly is annoying. Better to just not bother. Sound effects were dug out of an old sound pack Last Level Games had purchased for another title. Nothing perfect, but close enough. Unlike music, average sound is better than no sound.

10. Content Sweatshop

Content creation is exhausting. If I hadn’t enlisted the help of girlfriend and business partner, I couldn’t have created all the 130+ levels to go into the final game. This is where the tools really paid off. It was something that required no detailed knowledge of the game to use, and even my non-techy-girlfriend could use it. This was easily the most stressful and tiring part of process.

11. Test and tweak

Content done! Game done! Before finally submitting I spent some time (not as much as I would have liked) testing and tweaking levels. The core game seemed pretty stable at this point, and we had all play tested our levels, this was just spending a little time making sure it all hung together.

12. Submit to Apple – and wait.

Finally, time to submit to Apple. A mildly painful process, but could be worse. Could be better too. Once you submit you start waiting for apple to get around to looking at it. Couple of things to be careful of – there is a bug where some Unity games can crash on an iPad 2. Try building with xcode 3.2.5 with the 4.2 SDK. Also make sure you’re icons all match up, and you have a support page on your game’s website. We were rejected on our first submit for those reasons.

13. Relax!

And that’s it! It was an altogether exhausting process, but I learned an awful lot about what it takes to get something to market from (mostly) scratch. The game isn’t perfect by any means – the difficulty is a bit over the place, there is no iPhone version, the sound isn’t so great and the art looks like a programmer did it, but it’s there, and still fun! We’re selling it for 99c, and if we get enough people actually playing it we’ll look at an iPhone version and regularly creating new content as free updates.

If you want to, you can check it out. I’m curious to know what people think about it. Do you think it was worth the effort?

[Grey Out was just approved for sale in the AppStore and you can check it out here - iPad]