New Game Collage Website

After many, many months of thinking about updating the Game Collage website, I finally got around to it. Read all about our adventures since Doodle Blast!, get in touch, tell your friends, ... all that good stuff!

www.GameCollage.com

It also houses the official Game Collage blog, so come check it out!

The Doodle Contest

Oh yeah. I know I mentioned this below, but in case you missed it, definitely check out the Doodle Contest. Just click on the image for more info:

As a bonus, here are a couple of pictures from the iPad launch crowds in front of the local Apple store this past Saturday. The first is just a mood shot. The second is my attempt at pretending to be sociable and hip as a local developer. Both of these masterpieces are courtesy of ReesPhoto.com.

(Here I'm the model, not the photographer - just to be clear)

iPad Impressions and Other Goodies

The weekend is over and I can start thinking more rationally about the iPad. Haha! Right... Anywho, here are some impressions.

It’s a sleek little device - thin, light, and just shiny enough to invite your fingers to rub it all over. However, the more I keep looking at it, the more it looks like an oversized iPhone. I have to laugh each time I see my iPod Touch right next to it. I can just imagine women pulling an iPad out of their purses to answer a telephone call or jocks with iPads strapped to their biceps as they jog on treadmills in the gym.

If you disregard the perf boost needed to deal with the quadruple-sized screen, the iPad doesn't seem to run that much faster than the iPhone. It doesn't run slower either, which is a good thing, but it's not the speedy bullet that Apple initially implied. If you use the same tricks you use on the iPhone, though, it runs just fast enough.

Initially, I was more than a little worried when I developed code against the iPad simulator. Using Cocos2D, whenever I plopped a large texture on the screen, say a background, the frame rate would immediately drop to 20-30 FPS, even with OpenGL blending completely disabled. If you write a game, you need at least one large background texture most of the time, so the potential frame rate limitation posed a serious problem. That said, I was very happy to find out that the actual iPad handles all OpenGL calls much more gracefully. Doodle Blast! ran on full 60 FPS with the screen mostly empty and barely dipped into the 40s with everything in motion. I must say that the game looks quite slick on the big screen, especially when the camera zooms in and out while everything is in motion. Best looking doodles five bucks can buy!

In the end, I don’t think the iPad will reach nearly the popularity levels of the iPhone (watch me be completely wrong!). It’s definitely a fun toy to play with, though.

So, what’s next? Not sure. Right now I’m taking a little bit of time to catch my breath. I can hardly believe that it has been only one month and two weeks since Doodle Blast! first hit the stores – now there is an update, and iPad version, a blog, a web site, two trailers, over 11,000 lines of code and a contest. Talk about busy!

On a different note, I was browsing through the Doodle Blast! code base and I ran into two Cocos2D utility classes that I keep using and re-using all over the place. So, I thought I would share them with you. The way I generally write code under pressure is to write and polish the code paths that I need, leaving all others to be flushed out when they are actually needed. What that means for you is that these snippets are not fully complete, but they work as a great starting point. Feel free to use them however you please. A mention of credit is always nice, but not required.

The first utility is an action, EyeBlink (EyeBlink.h, EyeBlink.m), that does just that – blinks "eyes" on sprites. Basically, it takes 1 or 2 sprite frames as input. You can either specify two frames – one with eyes open and one with eyes closed – or just a single frame of closed eyelids that will be superimposed over an image of your character. The action then switches between these frames (or hides them if only one frame is specified) with some randomness built in to simulate irregular eye blinks. Here is how you’d use it:

Option 1:

CCSpriteFrame* openFrame = [[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:@"eyesOpen.png"];

CCSpriteFrame* closedFrame = [[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:@"eyesClosed.png"];

CCSprite* myCharacter = [CCSprite spriteWithSpriteFrame:openFrame];

[myCharacter runAction:[EyeBlink actionWithOpenDuration:0.7 openVar:0.3 closedDuration:0.1 closedVar:0.05 openFrame:openFrame closedFrame:closedFrame repeatForever:true]];

[myLayer addChild:myCharacter];

In this case you create two frames and alternate between them. The duration of the open frame will last 0.7 +/- 0.3 seconds while the duration of the closed frame will last 0.1 +/- 0.05 seconds.

Option 2:

CCSpriteFrame* characterWithEyesOpenFrame = [[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:@"myCharacter.png"];

CCSpriteFrame* closedEyeLidsFrame = [[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:@"eyesClosed.png"];

CCSprite* myCharacter = [CCSprite spriteWithSpriteFrame: characterWithEyesOpenFrame];

CCSprite* eyeLids = [CCSprite spriteWithSpriteFrame:closedEyeLidsFrame];

[eyeLids runAction:[EyeBlink actionWithOpenDuration:0.7 openVar:0.3 closedDuration:0.1 closedVar:0.05 openFrame:nil closedFrame: closedEyeLidsFrame repeatForever:true]];

[myCharacter addChild:eyeLids];

[myLayer addChild:myCharacter];

The same frame duration parameters apply here as well, but instead of switching between two frames, the code shows and hides a single frame.

The second snippet is a Chipmunk / Cocos2D debug node (DebugDrawNode.h, DebugDrawNode.m) that automagically draws debug outlines of all collision shapes associated with a given cpSpace object. It’s a simple subclass of CCNode with a custom draw() method. To use it, instantiate it and add it to your layer at the proper Z-depth thusly:

cpSpace* space = … ;

[myLayer addChild:[DebugDrawNode nodeWithSpace:space] z:SOME_Z_VALUE];

Enjoy!

Doodle Blast! Update Released

I guess Apple was busy with the avalanche of iPad apps for the past several days so it took a while longer, but Doodle Blast! update has finally hit the stores on Saturday. It took about three weeks to put together and now the code line count is up to over 11,000 from the original 7693. Phew!

By popular request, I've added a health bar and the ability to post your scores online later. I've also added a news ticker (which I'm about to test later today) and a mini-game - The Attack of Evil Vampire Bunnies . They were originally intended to be Easter bunnies, but I had to put the project on hold for about a week to port Doodle Blast! onto the iPad, so Evil Easter Bunnies became Evil Vampire Bunnies. Shhhhh!!! No one will ever know...

I was up all night last night trying to come up with a trailer and here is the result:

I should really try to find someone to do these for me. Not that I mind expressing my artistic side, but, let's face it, I'm probably a better coder than animator. Nonetheless, I hope you enjoy it and download the update if you haven't yet!

Alive and Kicking!

Doodle Blast! HD has hit the streets today and so have I! I just came back from the Apple store in U Village in Seattle, where countless number of “early adopters” and geeks like myself spent the wee hours of the morning waiting for their shiny box. More on that tomorrow, because I'm exhausted after two weeks of very little sleep and the couch is calling my name. However, I was finally able to see Doodle Blast! HD on the device itself. All I can say is - smooth as butta'...

Ready to Go

After some confusion and near heart-attacks yesterday when I thought that Doodle Blast! HD was rejected from the AppStore, I came to find the following message this morning:

Boys and girls, it's official! I, of course, have no clue _how_ the game runs on the iPad, but it seems that it least runs. I'm guessing that I'll be updating the iPad version sometime this weekend once I actually see it running on the device. Until then, I'm biting my nails in anticipation.

And check out the updated Game Collage web site. Brand new as of yesterday! Here is the welcoming image for you:

Those Pesky Crashes

Unless you have a dedicated team of testers working with you, it’s pretty easy to publish an app with bugs in it. Hopefully, the majority of your scenarios work because you’ve tried them out (that is assuming, of course, that you are not publishing titles for a device you’ve never seen - hello, iPad!). However, there is always some weird combination of user input you haven’t thought of that, apparently, everyone else has.

We’ve all been there - you write an app and a friend of yours wants to take a look. You reluctantly give up possession of your precious little baby and cringe in the background as your friend taps on all the wrong places. Three seconds later, he returns the device to you with your app all locked up or, better yet, not running at all. You and your friend never talk again.

Okay, so maybe that’s just me. However, my point is that even in these scenarios, you are pretty safe. Apart from losing a friendship or two, you can go home, try to recreate some of the issues, and fix the bugs you find along the way.

When you ship, however, chasing crashes becomes much more difficult. Apart from getting the occasional “The app crashes and it sucks! Don’t buy it” review, you don’t get much information about how your app performs. You may not even know that it crashes at all; not unless you look at Apple’s iTunes Connect portal in a little more detail.

I’ve just submitted an update for Doodle Blast! today and discovered this handy little button hiding underneath the application details:

Clicking on it, you get a nice little summary of what, if any, crashed have been reported:

Besides being told about the crashes, you can download a .crash file, which magically opens up on your machine and shows you the full stack trace of your app at the time of the crash.

That’s pretty cool! I’ve worked on a variety of platforms where you might get some core dumps but, no matter how hard you try, you can never get your hands on the actual stack trace. Either your symbols are too old, or they are from the wrong build, or you just didn’t clap your hands three times before throwing some salt over your shoulder. Whatever the case, the bottom line is that getting some useful information out of a crash log is always a challenge.

This is not the case here. You just need to know that these crash logs are available. I didn’t… until now. And, sadly, it turns out that Doodle Blast! crashes every now and then. Curious, I looked at the downloaded .crash log and discovered that if you tap on the Doodle Blast! title text in the main menu, bad things happen. Don’t do it, kids. You’ve been warned. Fix coming up in the next update…