Sunday, February 28, 2010

As I said earlier, day 1 consisted of me cheating because instead of spending the promised one day, I actually spent a weekend getting a running prototype together. I ended up borrowing code heavily from Pop Fizz. I didn’t have to re-implement asynchronous data load, animated particle systems, and persistent state storage. What I did end up writing was the basic structure of the game, a class to abstract out the tank guns, and a class to abstract out projectiles.

The big question I wanted to answer was whether to use a full-blown physics simulation or whether it would be sufficient to just fake it. All I really needed was a position, velocity, and acceleration vectors for every item on the screen and a full physics engine seemed like an overkill, not to mention a computational overhead. I also needed to solve collision detection. Simplified collision detention can be easy to implement, but I needed it to be fast. So, I sat down and started to write a spatial hash mechanism that would help me speed up the process. Half way through that effort I realized that I’m not being very smart because a physics engine would give me all of these things for free. I hence gave up and embraced Chipmunk all the way.

In the end, that ended up being a great decision. The final game uses Chipmunk not only to move things around the screen and detect collisions, but also to simulate bumps on the ground, stack guns on top of each other, and model the final explosion of the tank when the player dies. As far as overhead goes, it turns out that Chipmunk is pretty efficient at what it does. More importantly, version 5.0 came up with some really useful enhancements that allow you disregard unnecessary computations early on. In addition to breaking objects up into layers and groups, you can specify custom collision handlers that can have up to 4 callbacks through out each collision event:

Begin: Two shapes just started touching for the first time this step. Chipmunk has not yet calculated collision forces for this collision, and the preSolve() and postSolve() callbacks have not yet been called.

Pre Solve: Two shapes are touching. Some collision force computation has already taken place.

Post Solve: Two shapes are touching and their collision response has been processed.

Separate: Two shapes have just stopped touching for the first time this frame.

For the most part, all I care about is the Begin event. It signifies that a bullet has hit an enemy or a player. I don’t actually care about the collision forces, so the calculation is pretty cheap and can stop right there.

The physics decision out of the way, I wrapped some sprites around Chipmunk bodies and this was the final result:

You will notice that I added a simple tutorial place-holder right from the start. My tendency is always to leave the tutorial until the very end at which point it’s a pain in the butt to stitch it into the game. So, with this project, I wanted to make sure that tutorial was built into the game from the get-go. The final tutorial ended up being pretty much identical to this one and having it there from the start saved me some head scratching later on.

You will also notice that the guns themselves are animated. That was a big part of the visual appeal for me, so I wanted to test that behavior right away. The initial gun logic was pretty straightforward – aim, shoot, and cool. As I will talk about in a later post, this implementation was too simplistic and I had to create a whole state machine to model each gun. But more on that later.

For now, this was as far as the two days have gotten me, but the results looked promising enough to keep going.

Shortly after I released Pop Fizz, I ended up being sick in bed with some flu. As I was lying there, I was thinking that it would be really fun to produce something else. However, at that point I wasn’t ready to invest two more months into something that would just disappear into the app void again. That just seemed like too long of a time to waste. A week, on the other hand, didn’t seem that long. So, the thought occurred to me – what can I crank out in seven days?

I chatted with my brother and we remembered our Sybila Soft days and the game with a tank and an ever-growing stack of guns. Then, just to prove his point, he sent me the following sketch:

I was sold. More importantly, I wanted to play that tank because it looked like fun. So, I was presented with a challenge: how can I turn that picture into a game in seven days or less?

The first thing I did was I cheated. I turned the first day into a weekend to create a simple prototype and test the feasibility of the idea. And that’s where we begin our daily count-down...

Skip forward to last year, when I discovered that iPhone is actually a cool platform to code against and started playing with it. I ran across Cocos2D and Chipmunk as two independent, community-supported frameworks that made the job considerably easier. Cocos2D is a well-polished set of libraries that abstracts all the OpenGLES goo away from you and gives you a clean interface to manipulate 2D sprites (along with a whole bunch of other goodness). I worked with several other frameworks in the past and I must say I was very impressed and thankful for all the good work that went into it. Similarly, Chipmunk is a simple, but powerful physics engine that takes care of all the physics goo for you so, in the end, all you have to worry about is the game dynamic itself. Here is a big shout out to the Cocos2D and Chipmunk creators and contributors – thank you!

Back to the story, though. I was on a bus from Syracuse to Boston last November. For those of you who aren’t familiar with the route, let’s just say that the trip is a full-day joyride on sketchy inter-urban buses. Fortunately for me, Greyhound just upgraded their buses to have power plugs and WiFi onboard. The WiFi was nonexistent, but the power plugs worked (at least the one at my seat), which gave me whooping 8 hours of uninterrupted computer play during which I was trying to come up with a simple game for the iPhone. This is what I came up with:

A bunch of duplicate symbols on the screen – you match two identical symbols, they pop and disappear from the screen. Simple, but fun (or at least fun enough to make an 8-hour bus ride bearable). Following that trip, I spent two months turning that idea into a game, which eventually became Pop Fizz:

I managed to squeeze in quite a few features into the original idea – three different worlds with their own set of rules each, three different game types within each world giving you nine total game permutations, close to thirty achievements, InApp purchase integration, Twitter support, global leader boards, animated menus, ... you name it. In the end, I was very excited about the result. However, the game didn’t do particularly well. A lot of people downloaded the free version, but only a handful upgraded to the paid one, and eventually Pop Fizz got lost in the sea of other arcade games out there.

The good news was that I solved a lot of common problems (like writing a silly dialog box that allows the user to enter their name – I thought that would be an iPhone freebie, but no…) and I got quite comfortable with the platform and its tools (although there are days when I still curse Xcode’s auto-completion logic or the compiler’s ability to generate warnings but then hiding them from you and claiming success).

Saturday, February 27, 2010

The idea for Doodle Blast! has been hatching around for at least two decades. In the 80s, I was growing up in Europe and, back then, Sinclair ZX Spectrum was the pinnacle of home computing as we knew it. It was a pretty cool black box. It came with 48k of RAM (which is less than the size of most icons these days), a built-in BASIC editor and interpreter, whooping 16 colors (only two of which could occupy any 8x8 pixel area), and a jack for a tape recorder that allowed you to store programs on audiotapes as 5mins of screechy noise. In short, it was daBomb! The best parts about it were that coding it was rather simple and that an independent person could sit down and create something that maxed out the capabilities of the machine. In short, it wasn’t very different from the iPhone today.

Back then, my brother and two of our friends decided to form a “company” (and I use that term very loosely) called Sybila Soft to write games for the Spectrum and distribute it to our friends. Friend-to-friend distribution was the modus operandi of the time and we were often surprised ourselves at how far our games travelled. The best part is that those games are still alive and floating around the Internet today, ready to be downloaded and replayed in some java-based Sinclair emulator running as a widget on your desktop.

Anyway, that was the first time we came up with the idea of a tank with an ever-growing tower of more and more obscure guns. However, we grew up out of our teens, moved on with our lives, and the idea never came to fruition.

It’s two days after I published Doodle Blast! on iTunes. Originally, I thought about writing a day-to-day blog as I was writing the app, chronicling the process and some of the decisions that went into making it. However, what ended up happening is that I spent most of my time cranking out code, having little time for anything else. So, now that I have some time on my hands, I’m going to write a little post-mortem blog instead. I have saved daily snapshots of the code base, so I can re-create the progress and share it here with you.

Now, I’m not much of a blogger, so if I’m going too slow, too fast, or too dull, lemme know. I’m open to suggestions.