Space in Stereo iPhone Game Jam Postmortem

A week ago, I sent out a quick tweet asking if anyone would be interested in doing an iPhone Game Jam at the 360iDev conference. The response was immediate and hugely positive, so, with the help of the organizers of 360iDev, we put together an informal iPhone Game Jam.

The idea was to get together Tuesday evening, starting at around 7PM, and to code all night and have an iPhone game (or at least a prototype) done by morning. About 25 showed up, working on about a dozen projects. Participants were welcome to group into teams or work solo. There were no restrictions as far as themes or technology. The only rules were that you had to finish something by morning (no leaving something that was 5% of a game) and you had to start the game from scratch (no finishing a game you had started a while ago).

The reason behind doing a game jam is to be able to quickly create game prototypes and decide if they’re worth pursuing further or not. Much better to spend a few hours one night and then throwing it away, than spending several months with multiple people involved. Also, the heavy time constraints often help participants by focusing them in the ultimate goal and forcing them to adopt creative solutions. Being all together in one large room added a lot of energy and made it possible to work really focused for many hours without a huge amount of caffeine (although the large amounts of coffee provided by Jay really helped!). In the end, we even ended up getting a late-night fiddle serenade by Phil Hassey. Try that at home by yourself! Owen Goss liked the idea so much, he decided to jam with use remotely through video conferencing!

One specific thing that I wanted to avoid with the game jam was the idea of giving any sort of prices at the end. I really wanted to keep the jam as an environment where people would be free to experiment and fail. If people were thinking of potential prices at the end, they would be a lot less willing to go out on a limb and try different things.

My goal going into the jam was to experiment with game mechanics that relied heavily on multi touch. I felt that very few games made good use of multi touch (aside from pinching) and that it had the potential to create something very different from the single-touch based game that we’re used to from mice for the last 20 years. The flip side of it is that a multi-touch game was much riskier and unknown. Could something that multiple simultaneous touches be fun, or would it be frustrating? Would your fingers get in the way and clutter the screen, or would it be a new experience? In the back of my mind, I was definitely drawing inspiration from the fantastic game Bug Bugs, by Igloo Games.

I did all the coding myself, but I teamed up with Evan McMahon from Veiled Games and he did all the awesome art in the prototype.

Owen Goss joining the iPhone Game Jam remotely

What Went Right

Started with an idea

I went into the jam with the idea of experimenting with multi-touch game mechanics. I also had in mind a setting that would be a good backdrop to those mechanics: You control a large, round spaceship in interstellar travel. As you travel between the stars, you need to collect different resources to power your ship and provide all necessary materials. Each type of resource goes in a different bay (which are located along the outer rim), so with two fingers you rotate the ship to move the collecting bay forward, and with the other hand you drag the different resources you encounter. Some resources aren’t useful, so you need to flick them away so they don’t hit the ship. Finally, other resources need to be combined before they can be processed, so you first need to bring them together, and then drag them to the ship.

You only have 10-12 hours to build a game, so if I didn’t have an idea going into the jam, I would have wasted precious time trying to figure out what to do while I could have been working on the game.

At the same time, I didn’t have the idea fully fleshed out and set in stone. I definitely let things change based on what I saw as I was implementing it. So it’s good to strike a flexible medium between having an idea and letting it evolve during the jam.

Used familiar tools

Just the day before, David Whatley raved about how great Cocos2d was for prototyping, and that same day, my friend Serban gave a presentation on using Cocos2d. I’m on record saying that I can’t stand to work with Cocos2d because it imposes a particular (totally backwards) architecture on you, and I can’t ever see myself shipping a game with it, but I can see the value in using it for prototyping.

The point of this jam (for me anyway) wasn’t to learn some new tech, but to experiment with gameplay. So I really considered it, but in the end, I decided to work with something I was familiar with, and used my (very small) codebase using straight OpenGL. I’m very glad that I did because I never felt that working at that level got in the way (other than one frustrating moment related to the first point in “what went wrong”),

Didn’t worry about performance

This is a hard one for me! The last two talks I’ve given are all about performance on the iPhone, but even thinking about performance here would have been a waste of time and resources. Sure, the game had to be fast enough to run on the actual device because playing a game on the phone is a very different experience than playing it on the simulator. Besides, a game like this requiring lots of multi-touch was impossible to play on the simulator.

But at the same time, I didn’t have to submit it to the App Store come morning, so I decided that as long as it ran on my 3GS, I didn’t care about anything else. That meant it could be very suboptimal and be a total memory hog. I didn’t care! I wasn’t even releasing resources!

The result, it played perfectly fine on my phone, and I spent zero time trying to optimize it or taking a longer route because of performance or memory reasons. On the other hand, just the tiny, single level I created is about 12MB, so it’s clearly very bloated.

Teaming up

As I mentioned earlier, I teamed up with Evan McMahon to create the art for the game. He wasn’t at the conference, so we organized everything through IM and Dropbox. The experience was great because not only did he create some awesome-looking art, but he really motivated me along the way. We played off each other’s energy and came up with new ideas because of the collaboration.

Going solo would have been OK because I was surrounded by a room full of like-minded developers hacking away at their games, so that would have helped keep up the energy levels, but it wouldn’t have had nearly as much of an effect as working directly with someone else. My only regret is that Evan wasn’t there with me.

What about the art itself? Was it a waste of time to add it to the game? After all, it didn’t help me make a better decision about the multi-touch game mechanics, did it? It wasn’t a waste of time at all for me. First of all, it took just as long adding some nice art than it took to add stand-in art because there wasn’t anything special about it. But most importantly, there is a feedback loop between the look of the game and the gameplay and feel of the game. So seeing the art in the game definitely changed how I felt about it and the decisions I made about it during the night.

What Went Wrong

Didn’t have a project ready

This just goes to show my lack of experience with super-rapid prototyping. I didn’t have a project ready to get started with the prototyping. I originally created a blank OpenGL project from XCode, and quickly realized I would be missing all the set up for sound, the view controller structure, and even some of the default touch-handling. So I grabbed one of my current projects in development, stripped it of everything game specific, and turned it into the project for the game jam. Not a big deal, except that it took me a good 20-30 minutes to go through this, and in the process I deleted a couple crucial lines that gave me lots of problems with OpenGL for the next 30 minutes. Doh!

Next time: Come prepared with a blank project, ready to go.

Running up against technical stuff

I went with OpenGL instead of Cocos2d on purpose to avoid having to deal with learning technical stuff sleep deprived in the middle of the jam. Unfortunately, it turns out my understanding of the multi touch event API wasn’t up to snuff to handle 5 simultaneous touches, starting, moving, and ending, each of them affecting a different object (or different parts of the same object). During the jam I wasn’t writing unit tests either, so that made for a pretty confusing time until I stepped back for a second, hit the documentation and Apple’s touch sample program, and tried to gain a better understanding of what was going on. Hint: Apparently looking at the touches in the UIEvent* parameter passed to touchesBegan is not a good idea, and you need to look at the ones passed in NSSet*.

Not enough time!

I certainly didn’t get as far in the prototype as I had hoped I would. There’s only one type of resource (ice chunks) and the control mechanics need to be improved quite a bit.

Is it possible that if I had used Cocos2d I would have gotten more done of the prototype? Yes, it’s possible, although I won’t know until I try it. Is it possible that half way through the prototype I would have encountered something that Cocos2d couldn’t do and I was left stranded? Yes, that’s also possible. And that’s a big reason why I don’t like framework-y type of APIs, and instead I would rather have a toolkit type of API so I can call into it and do the work myself whenever I want instead.

In any case, this is the flip side of “using familiar tools”. I will definitely experiment with Cocos2d in the future and consider it for another game jam if I’m familiar enough with it and I feel it speeds up development.

Everybody still going strong late at night (but not quite so perky anymore)

Conclusions

I think Space in Stereo has potential, but right now it’s too early to tell if it’s any good. The basic mechanic is there, but it’s not fun by any stretch of the imagination. I already learned a bunch about it though, including that some things weren’t nearly as much fun as I was hoping would be. For example, rotating the space station with two fingers… well, sucks. The better control scheme is to move the space station by dragging around the middle, and rotating it by dragging a finger around the edge in a circular motion. That was also what everybody was instinctively doing when they were trying out the game.

The game is just at the point that spending another 4-5 hours on it would answer a lot of questions about how fun it can be. I’m definitely planning on spending that time and then making a decision. If I decide not to go ahead with it, it’s not a big deal. Great games come out of making a lot of different prototypes and throwing away all the so-so ones along the way.

As far as the Game Jam itself, it can only be described in one word: Awesome. It was everything I was hoping for and more. I can’t stress enough how much it helped to have everybody else around you and being so focused for that period of time. I had heard much about game jams, but I had never actually participated in one. After this one I’m sold. I can’t wait until the next one!