There were even a couple of cases during Casey’s Contraptions that we wanted a particular effect, and couldn’t get it quite right, but it would have been trivial to whip up a shader if we had been using OpenGL ES 2.0. In the end, we had to resort to texture combiners (yuck), and it wasn’t exactly what we had in mind.

OpenGL ES 2.0 requires that you write shaders for any different kind of “thing” you render, whether it’s a simple 2D quad, or a fancy skinned character. I wanted to provide at least a basic 2D rendering shader in my graphics library, but the workflow was a bit awkward.

First of all, shaders on iOS are compiled at runtime [1], so we need to access the shader source and compile it. Initially I was thinking of having the shader source files as text in the graphics library, but for the game to access those files, it would have to explicitly add them to its resources so they can be copied during the build phase. That’s error prone (I would always forget to do that with every new project) and just plain ugly.

Another possibility would be to include the source text as a string in the library. That would simplify things, but it would mean that:

1. You would lose shader syntax highlighting.
2. You would need to have the annoying \ at the end of every line.

After asking on Twitter and getting some good suggestions, I decided the easiest way would be to use xxd. It’s a shell tool that comes preinstalled in all Macs (and Linux) that takes a file and converts it into a C array that can be included in a program directly.

I liked xxd even better than the old standby of bin2c because it already comes installed, and it generates the whole file, not just an array that then needs to be included from another file. Yes, it would be easy enough to modify, but why bother when you have a perfect tool for the job already?

Now, I can set up a custom rule in Xcode 4 like this:

Update: The array generated by xxd isn’t null-terminated, so we need to add a zero to the array. The easiest way is to use sed. Thanks to SixEcho Studios for the heads up. Also, I updated it to use the varaibles INPUT_FILE_DIR and INPUT_FILE_NAME thanks to Miguel’s comments.

Now, whenever the shader source changes, it generates a header file like this:

unsigned char PassThrough_fsh[] = {
  0x0a, 0x0a, 0x76, 0x61, 0x72, 0x79, 0x69, 0x6e, 0x67, 0x20, 0x6c, 0x6f,
  0x77, 0x70, 0x20, 0x76, 0x65, 0x63, 0x34, 0x20, 0x44, 0x65, 0x73, 0x74,
  0x69, 0x6e, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x43, 0x6f, 0x6c, 0x6f, 0x72,
  0x3b, 0x0a, 0x0a, 0x76, 0x6f, 0x69, 0x64, 0x20, 0x6d, 0x61, 0x69, 0x6e,
  0x28, 0x29, 0x0a, 0x7b, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x67, 0x6c, 0x5f,
  0x46, 0x72, 0x61, 0x67, 0x43, 0x6f, 0x6c, 0x6f, 0x72, 0x20, 0x3d, 0x20,
  0x44, 0x65, 0x73, 0x74, 0x69, 0x6e, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x43,
  0x6f, 0x6c, 0x6f, 0x72, 0x3b, 0x0a, 0x7d
,0x00};
unsigned int PassThrough_fsh_len = 91;

To compile that shader in the game, all I have to add is two lines:

#include 
//...
const int fs = ShaderUtils::CompileShader(PassThrough_fsh, GL_FRAGMENT_SHADER);

Done! Clean, simple, and minimal cruft.

Update: I haven’t tried it yet because I haven’t had the need for any expensive shaders, but I hear really good things about Aras Pranckevičius GLSL optimizer. In that case, I would add it before the xxd step. You would still use the shader the same way, but it would be optimized and perform faster.

[1] That’s a huge mistake and I hope Apple fixes that ASAP. Loading times for any amount of non-trivial shaders adds up really quickly. That’s the last thing you want on a mobile device! The OpenGL ES 2.0 standard provides an optional way to load binary shaders, and all that Apple has to do is provide a tool that will compile shaders for the iOS hardware. To be completely future-proof, you they can even mandate that if the binary load fails, you still need to compile from source.

That future is a reality today for some games and apps (Netflix, Kindle), and I’m convinced that players will expect that in most games in the next year or so. So obviously, the next bit of new iOS tech I decided to try was iCloud. I would love to turn Flower Garden into that kind of seamless experience, independently of the device you use to access it.

As a quick spoiler, it turns out I won’t be able to make Flower Garden quite so seamless without a lot of extra work. But I learned a lot along the way and I should be able to take a small step in that direction.

Design considerations

iCloud promises to be the “available from everywhere” storage solution that will be a key component towards the scenario of playing on any device at any time. Unfortunately, it’s just a component of that whole scenario and still requires quite a bit of work on the part of the developer.

Since I’m just retrofitting Flower Garden to work with iCloud, I wanted a simple way to simply replicate the game state on iCloud. Then, whenever you play it from any device, you get the latest state and everything works as expected.

The big problem with that approach is that you can’t always count on having an active (or fast enough) internet connection. iPod Touches, iPads, or even iPhone in a plane or a cell tower black spot will make it so your device has no way to communicate with iCloud. So what happens if the player plays without an internet connection, then comes home, grabs another device, plays for a bit with internet connection, and finally launches the original device, this time with internet connection. You’ll end up with two conflicting game states. Not fun!

I can think of two different strategies to deal with this situation:

• Require internet connection to play. Some games do this today. It can be quite frustrating not being able to play your favorite game in the plane, but it does solve the game state conflict problem because they can always communicate with iCloud, so they usually provide seamless multi-device play.
• Detect changes on both game states and intelligently solve them. Sounds good in theory, but it’s a pain in practice. Unless you have a very simple game state (a percentage completion for example), it means not only do you have to record the state, but you have to record the events that led to that state, and be ready to examine them, compare them, and marge them in the case of a conflict. And the worst part is that even if you put lots of care into it, there will be cases where the merge is not ideal and the player will feel like he lost something in the merge.

For Flower Garden, neither solution is particularly attractive. It’s the proverbial rock and a hard place. So for the moment I’ve decided to implement just a small step in that direction: Sync things that only progress in one direction, without any danger of conflict. That includes purchased IAPs and unlocked seeds. Later on, once that’s working solidly without any problems, I can consider adding counts like Fertilizer, Color Dust, or Green Thumb points. That will be a bit trickier because there’s still chance for conflict since the count can go up and down, but it’s possible to change each amount into two different values that always go up: Earned amount, and spent amount. That way I can always grab the maximum value that I find either local or on iCloud and things should work smoothly. (Update: What I wrote there about separating them in two different values is totally wrong, and any DB programmer worth his salt would be laughing at that. Separating them in two different values won’t help at all. That’s what I get for doing brain-dump posts on the fly :-)

Apple provides two APIs to store data in iCloud: key-value storage and file storage.

Key Value storage

Initially, this seems like a great way to go. It’s a very simple API, and it’s very familiar to most iOS programmers because it’s just like NSUserDefaults.

Don’t be fooled into thinking you need to store data in strings or one field at the time. You can stuff whatever binary chunk of data you want with NSData, so it’s quite versatile.

It does have three pretty big drawbacks thought:

• Size. You can only store up to 64KB of data. That’s definitely a big deal if you’re planning on storing large data files. Even for Flower Garden, each pot is about 30KB, so I wouldn’t be able to save the full garden state this way.

• Syncing. The Apple docs say that “Keys and values are transferred to and from iCloud at periodic intervals.” Ouch! What does that mean? Clearly this is intended for non-crucial data (like settings), so the potential delay isn’t a big deal. In my tests, I found that data was often not available when starting the app, but would become available a few seconds later.

• No way to check state. When starting the app, there’s no way to find out if the values you’re reading are up to date. Combined with the slow syncing, it makes it less than idea for important data. On the flip side, you can be notified when the data changes, but that means having to deal with changes while the game is running (which I was hoping not to do).

File storage

File storage might be a better option then since it doesn’t have any of those drawbacks: there’s no size limit, data is synced much more aggressively, and you can check if the data is up-to-date, and wait until it is otherwise.

What’s not to like about file storage then? The cumbersome and intrusive API that Apple created around it. If you read the docs, they make it sound like you need to inherit from UIDocument and load all your data through that class. I like to keep things simple and portable, so I’d really rather not introduce UIDocument into the file-loading process if I don’t have to.

It turns out that Apple’s docs on the iCloud SDK are quite sparse and lacking details. I was able to put together a demo from those docs and some experimentation, so hopefully this will be useful to other devs as well.

The device has an iCloud storage daemon running, monitoring specific directories for changes. You get the directory assigned to your app by calling URLForUbiquityContainerIdentifier.

To add a new file, the docs recommend first creating the file somewhere else, and then calling NSFileManager:setUbiquitous:itemAtURL:destinationURL:error: to move it to iCloud. Interestingly, I accidentally skipped this step and just wrote to the iCloud directory directly, and the files were stored correctly anyway. Might as well leave it just in case that behavior changes later on, or there’s some side effect I didn’t notice.

After that, every time you write to the file, the iCloud daemon will detect the changes and push them out to iCloud. This is an important point because a) You don’t have explicit control to say “start send it now” or even “This file is ready to be sent to iCloud” (that would be my choice), and b) I don’t know what it does with partial updates, so I would be very careful about writing to those files and make sure it’s an atomic operation (save somewhere else, and them move the file in one operation).

To get the latest version of the files on iCloud, you can check whether they’re fully downloaded or not by calling NSURL:getResourceValue:&isDownloaded forKey:NSURLUbiquitousItemIsDownloadedKey error:. If they are up to date, you can move on, otherwise, you can initiate a download of the files by calling NSFileManager:startDownloadingUbiquitousItemAtURL:error:.

One weird thing is that the startDownloading function doesn’t have a callback (that I can see). So I had to set up a timer to check periodically if the files are synced.

Since all the syncing happens at startup, there’s no complexity involved with data changing while the app is running. If that’s a case you need to handle, you might be better off using UIDocument since it at least detects conflicts. If you do it this way, the latest one will overwrite any past changes.

Also, working this way, it seemed easier to keep the files in Application Support (or Documents), and only move them to/from iCloud when I wanted to. That has the advantage of iCloud not changing things from under you while the game is running, and the fact that, if for some reason the files in iCloud are corrupt, you always have good local files to fall back to.

Demo

iCloudTest.zip

The demo iCloudTest saves data both with the key value pair, and the file storage system directly like I described above. If you run it from different devices, you’ll see that it’s amazing how quickly file data gets propagated, but key-value data takes a few more seconds.

The demo project also works in the simulator (there’s no iCloud support, so it just uses local files), and it even works with iOS4 (also using local files, and it avoids using any iOS5 symbols while detecting iCloud support).

Sharing Data Between Multiple Apps

Once you’re at this point, sharing data between multiple apps is really straightforward.

First you need to make sure the app IDs of both apps start with the seam Team ID. For some unknown reason lost in the midsts of time, Flower Garden and Flower Garden Free use different prefixes, so that option is out for me. Hopefully most people having been using the Team ID only.

Then you need to decide which type of data you want to share. If you want to share files, you need to add the app ID of the other app to your iCloud entitlement, and then as for the correct app ID (including prefix!) when you call URLForUbiquityContainerIdentifier. If you just want the app’s own iCloud data, you can pass NULL as the parameter.

As far as I can tell, each application can only have one set of key-value data. So sharing it between two apps means changing one app to use the app ID of the other app in the com.snappytouch.icloudtest field of the iCloud entitlements file. As long as both apps use the same Team ID prefix, it should work fine without having to do anything else.

One of the first features I looked into adding was multisample antialiasing (MSAA) support for OpenGL, which was originally introduced in iOS 4.0. The geometry generated for the petals in Flower Garden is fairly high contrast, and since it’s not like the textures were carefully created and laid out by an artist, the result is pretty bad aliasing around the edges. Perfect candidate for multisampling!

I based everything on the Apple documentation on multisampling. It was very straightforward and it works for both off-screen and view-based render targets. It was also extremely helpful to keep both the ability to use regular and multisampled render targets. That way I can easily run performance and visual comparisons, and, if necessary, I can disable multisampling on a particular device.

The main gotcha was making sure I used the GL_RGBA8_OES color format on the multisampling color buffer (otherwise it won’t work, and all you’ll get are 1282 “invalid operation” OpenGL errors). Also, if you’re in the same boat as Flower Garden, which uses OpenGL ES 1.1 and the fixed function pipeline, you’ll have to add _OES to just about every constant in the documentation.

Visual results

I will let the screenshots speak for themselves.

In this screenshot you can see the rendering of the pots using off-screen render targets.

Pretty impressive improvement, even if I say so myself! The improvement is even more striking in-game because the animation of the flowers moving in the wind doesn’t have jaggies popping in and out.

The improvements are more noticeable on the iPad because the pixels are bigger, and, not surprisingly, less so on retina-display iPhones. But even on the retina displays, jaggies are less noticeable during the flower wind-swaying animations.

Performance

So, no doubt: They look pretty. But how about performance? Under the hood, the rasterizer is generating four samples for every pixel, and then combining them at the end in a separate step. So you’ll get more of a performance hit with complex pixel shaders. Edit: My bad. I spaced out and I forgot that MSAA only evaluates the pixel shader once, so performance doesn’t depend on pixel shader complexity. Instead, the performance hit probably comes from the extra writes (four per pixel) to the render target, and should be fairly similar between games.

It turns out that Flower Garden is still using OpenGL ES 1.1, which is implemented using shaders at the driver level. Fortunately, even though I’m using some texture combiner operations and several input textures, those pixel shaders aren’t all that complex.

These are the frames per second I recorded with one particular flower pot on the different devices I have for testing. Notice that the lowest device I have listed is the iPhone 3GS. That’s because I have also stopped supporting arm6 CPUs to keep things simpler (and the market share is minimal).

Update: I was only running the game loop at 30 fps, so the initial performance numbers I had listed are pretty meaningless. Here are the correct numbers running at a max of 60 fps.

Of the devices I tested, MSAA didn’t slow down things much on the iPhone 3GS, and the iPhone 4S was maxed out at 60 fps both ways. The iPad 1 was a different story, and performance crashed from 60 fps to 18 fps. Like Rory pointed in the comments, looking at the actual time instead of the fps gives a better insight. Using MSAA adds 38.9 ms to each frame! The iPhone 4 also suffered from a big performance hit due to all the extra pixels in the retina display. I don’t care how pretty the flowers are, that’s just not acceptable (and no, I’m not adding user-tweakable graphics settings like PC games).

I should also add that Flower Garden is hugely CPU bound. It generates all that geometry every frame on the CPU, and that’s a lot of vector transforms. So if your game is GPU bound, you’re likely to see higher performance hits.

I was initially very surprised to see that the performance on the simulator tanked big time (as in, going from 30 fps to 5 fps). This was news to me, but apparently the iOS simulator runs completely in software, so the quadrupling of pixels brings it to its knees. I’m really, really, impressed at how smoothly it usually runs for being in software though. It had me fooled thinking it was using OpenGL under the hood!

As far as memory goes, after an animated discussion on Twitter, it seems that the iPhone does create full buffers for the multisample frame buffers, so there is a significant increase in memory usage. It’s not something easy to track because it all happens at the driver level, but it’s something to be aware of. Because of this, I might consider turning multisampling off on retina displays, since the improvement is not mind-blowing (and the extra memory is very significant because of the amount of pixels). I’ll also probably turn it off in the simulator so I can achieve a decent frame rate during development.

Conclusions

Multisampling only required adding a few lines of code and resulted in an impressive visual improvement and minimal performance impact in some devices. It’s a no-brainer on the 3GS and iPad 2. I’m wishing I had implemented it earlier!

Pre-iOS5, if you added a view with [self.view addSubview:myView], myView didn’t get any notifications. That was weird, but we learned to live with it. Tens (hundreds?) of thousands of developers worked around that and wrote gobs and gobs of code that worked with and counted on that behavior.

Then along comes the iOS5 SDK and someone decided that it would be good to “fix” that behavior, but doing it silently. By silently I mean no compile-time errors or warnings, but apparently it wasn’t deemed worthy of including in the iOS5 release notes either. I’m sure they thought they were doing us a favor. After all, if someone had a problem with it, it’s because they hadn’t structured their code correctly.

So now every view you add/remove will get those notifications. Which is fine, except if you had decided to call those by hand yourself. In that case, now they get executed twice, so you may be allocating things twice, making multiple network calls, and just causing general mayhem.

I also noticed that if you call presentModalViewController with a view controller, all the views underneath the modal view controller will get the viewWillDisappear/viewDidDisappear event. In my case this causes total chaos because those events trigger the freeing of some views that the modal view controller will need.

But wait, it gets even better! From what I’ve been able to tell, if your app compiled with the iOS5 SDK runs on iOS4, then you don’t get those events! That means that now you need to be ready to both deal with receiving them and not receiving them at the same time. Is that useful to anyone (other than devs making iOS5+ apps)?

Fortunately, existing apps compiled with the iOS4 SDK are consistent running both on iOS4 and iOS5 (no view events automatically generated). Phew! Dodged that bullet.

It seems I complain a lot lately, but this seems like another very justified complaint. Wasn’t there a way for Apple to add that behavior to new functions without changing the old ones? For example, they could have introduced UIView:addSubview:withNotifications: and eventually deprecated the old ones. Yes, that means that they would have had to duplicate 10-20 functions related to adding/removing views, but they wouldn’t have broken half the iOS code out there.

This is probably my fault for relying on viewDidAppear events and calling them myself. I started working around this problem by being super-careful about how and when I call viewDidAppear, but as soon as I realized that iOS4 does it differently, I threw in the towel and went for a different approach. Now, I just implement my own function in the different view controllers and call that instead of viewDidAppear. That way Apple can change those events all they want and it won’t affect me anymore.

Of course, all of this only matters if you’re making heavy use of view controllers (which unfortunately I am doing in Flower Garden). I’ve already said that my future game projects are going to be UIKit-free, so I won’t have to deal with this kind of problems again.

I have to say, I’m not a huge fan of the wobble movement, but it does indicate that icons are “loose” and movable. And since most players are already familiar with that metaphor, and the overhead view of Flower Garden resembles the launchboard quite a bit (not coincidence), I might as well go with it.

Each pot is a UIButton with a custom image (rendered from OpenGL into an off-screen target). So when I enter edit mode, I need to wobble them like the launchboard. Easier said than done.

I searched online and asked on Twitter, but surprisingly, nobody had done a perfect, reverse-engineering of the wobble movement. Most mentions just do a z rotation on a sine wave, which is not that close of the launchboard animation.

I found that to get closer to the real thing, you need to do that rotation around a random point offset from the center. That’s better, but it’s still not perfect. There’s an additional extra twitch in the original Apple animation. I’d love it if someone already reverse-engineered it and has a better model for that animation.

In the meanwhile, I figured I would share the core I’m using. It’s all very straightforward, except for the part about rotating a UIView around a different point other than the center. I initially thought I could just concatenate transforms, but no matter how you do it, UIKit always interprets the transform around the center.

To be more precise, it interprets the rotation around the anchor point, and that’s what you need to modify. The anchor point is defined in units that are a percentage of the layer’s size, so by default it’s 0.5, 0.5. When you move the anchor point, the layer itself will move, so you need to fix it up by moving the layer’s position by the same amount in the opposite direction.

This is what the final code looks like:

void StartPotWobble(UIButton* button, Random& random)
{
	const Range posOffset(0.10f, 0.2f);
	const float amplitude = random.GetFloat(1,1.5f);
	const Vec2 startCenter(Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset), Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset));
	const Vec2 endCenter(Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset), Sign(random.GetFloat(-1,1))*random.GetFloat(posOffset));

	CGPoint center = button.center;	
	button.layer.anchorPoint = CGPointMake(0.5f + startCenter.x, 0.5f + startCenter.y);
	CGRect bounds = button.bounds;
	button.layer.position = CGPointMake(button.layer.position.x + bounds.size.width*startCenter.x, 
									button.layer.position.y + bounds.size.height*startCenter.y);
	button.transform = CGAffineTransformMakeRotation(-amplitude*DegToRad);
		
	[UIView beginAnimations:nil context:NULL];
	[UIView setAnimationRepeatAutoreverses:YES];
	[UIView setAnimationRepeatCount:FLT_MAX];
	[UIView setAnimationDuration:0.12];
	[UIView setAnimationDelay:random.GetFloat(0,0.09f)];
		button.transform = CGAffineTransformMakeRotation(+amplitude*DegToRad);
	[UIView commitAnimations];
}
	
	
void StopPotWobble(UIButton* button)
{
	[button cancelAllAnimationsRecursively];
	button.transform = CGAffineTransformIdentity;
	CGPoint anchor = button.layer.anchorPoint;
	CGPoint offset = CGPointMake((0.5f - anchor.x)*button.width, (0.5f - anchor.y)*button.height);
	button.layer.anchorPoint = CGPointMake(0.5f, 0.5f);
	button.layer.position = CGPointMake(button.layer.position.x + offset.x, button.layer.position.y + offset.y);
}

Ah yes, and I couldn’t find a way to loop the animation infinitely (without using the new UIView animation syntax), so FLT_MAX will have to do :-) Any cleaner way?

If someone has an animation that more closely resembles the iPhone launchboard, I’d love to hear about it. Let me know and I’ll update this post.

I use the URL shortener in Flower Garden to send bouquets through SMS. Space is limited in a text message, so the message just contains some text explaining what is it and the URL pointing to the bouquet image. (Yes, I would much rather send them through MMS, but Apple isn’t exposing that yet to developers).

In this case, the full URL is http://flowers.snappytouch.com/sms.php?id=949618b4b3c6f3d76e32b45446e238a0 which gets thankfully shortened to http://goo.gl/IV5cq.

Sending bouquets through SMS has been in Flower Garden for several months, but it was using bit.ly before, which is probably the most popular URL shortener out there. I like their web interface and their super-easy to use API, but unfortunately it seems that I hit some mysterious API limit during the Mother’s Day Flower Garden promotion. That limit isn’t public anywhere, and as far as I can tell, I can’t even see it myself through the web interface or through an API query.

Finding out that I reached the API limit was quite shocking, because sending bouquets through SMS isn’t a particularly popular feature. Unfortunately I don’t have good analytics hooked up to that step, but I can’t imagine there were more than a few thousand per day.

They were very nice and contacted me instead of shutting down my account since it was just a spike. They also tried to sell me their “Enterprise” account, but $995/month is a tad too expensive for me. By about $990 probably, so I had to look for other options.

After a very quick research, goo.gl was the perfect alternative. Not only is it very fast (and backed up by the giant Google no less), but they have an API limit of 1,000,000 queries/day. If I ever blow that budget, I’ll be able to afford the $995/month without a problem :-)

All URL shorteners are very easy to use. You need an API key, and figure out the exact format of the HTTP message you send and the response you get.

goo.gl

Goo.gl has a great Getting Started Guide that tells you everything you need to know. Get your private API key from here, and you’re ready to rock.

Drop this in your app and start shortening away. You’ll notice I used a synchronous HTTP request, which is usually a big no-no. Here I felt it was justified since the user is blocked waiting for the SMS to be prepared and sent. Besides, goo.gl is very, very fast, so it’s never even noticeable.

const NSString* GooGlAPIURL = @"https://www.googleapis.com/urlshortener/v1/url?key=YOUR_API_KEY_HERE";

NSString* ShortenURLWithGooGl(NSString* longURL)
{
	NSURL* apiUrl = [NSURL URLWithString:GooGlAPIURL];
	
	NSMutableURLRequest* req = [[NSMutableURLRequest alloc] initWithURL:apiUrl];
	[req setHTTPMethod:@"POST"];
	[req setTimeoutInterval:Timeout];
	[req setValue:@"application/json" forHTTPHeaderField:@"Content-Type"];
	
	NSString* body = [[NSString alloc] initWithFormat:@"{\"longUrl\": \"%@\"}", longURL];
	[req setHTTPBody:[body dataUsingEncoding:NSUTF8StringEncoding]];
	[body release];
	
	NSError* error = [[NSError alloc] init];
	NSHTTPURLResponse* urlResponse = nil;
	NSData* data = [NSURLConnection sendSynchronousRequest:req returningResponse:&urlResponse error:&error];
	[error release];
	if (data == NULL || ([urlResponse statusCode] < 200 && [urlResponse statusCode] >= 300))
		return NULL;

	NSString* response = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding];
	NSDictionary* responseDict = [response JSONValue];
	NSString* shortURL = [[responseDict objectForKey:@"id"] retain];
	[response release];
	return shortURL;
}

I’m using a JSON framework to parse the answer, but it’s so simple I probably wouldn’t even have to. I only used it because it’s already part of the project because of Facebook Connect.

bit.ly

Even though it’s not my favorite shortener, I’m adding it here for completeness (and because I had the code already written).

The one thing that bit.ly has going for it is that it’s even easier to use than goo.gl. No JSON involved, and you don’t even need to send a body with your request. As usual, get your API key by signing up with bit.ly.

const NSString* BITLYAPIURL = @"http://api.bit.ly/v3/shorten?login=%@&apiKey=%@&format=txt&";

NSString* ShortenURLWithBitLy(NSString* longURL)
{
	NSString* urlWithoutParams = [NSString stringWithFormat:BITLYAPIURL, LoginName, APIKey];	
	CFStringRef encodedParamCF = CFURLCreateStringByAddingPercentEscapes(kCFAllocatorDefault,
															 (CFStringRef) longURL, 
															 nil, (CFStringRef) @"&+", kCFStringEncodingUTF8); 
	NSString* encodedURL = (NSString*)encodedParamCF;
	NSString* parameters = [NSString stringWithFormat:@"longUrl=%@", [encodedURL stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
	NSString* finalURL = [urlWithoutParams stringByAppendingString:parameters];
	
	NSURL* url = [NSURL URLWithString:finalURL];
	
	NSMutableURLRequest* req = [[NSMutableURLRequest alloc] initWithURL:url];
	[req setTimeoutInterval:Timeout];
	
	NSHTTPURLResponse* urlResponse = nil;  
	NSData* data = [NSURLConnection sendSynchronousRequest:req returningResponse:&urlResponse error:NULL];
	if (data == NULL || ([urlResponse statusCode] < 200 && [urlResponse statusCode] >= 300))
		return NULL;

	NSString* response = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding];
	return response;
}

That’s it. You should be able to drop in either one of those snippets in your project and spend your time working on the things that really matter in your games.

Recording particular events as part of the analytics is only part of it. The most important part is how that data is presented to the developer. Having tables with millions of entries does me no good, and as a busy indie developer, I can’t afford to spend hours writing scripts to analyze it. I want something that allows me to easily visualize the data and makes sense out of it at a glance.

One possible snagging point about analytics is that Apple was cracking down on some applications with analytics enabled a while back. Specifically, the iOS developer agreement states:

3.3.9 You and Your Applications may not collect user or device data without prior user consent, and then only to provide a service or function that is directly relevant to the use of the Application, or to serve advertising. You may not use analytics software in Your Application to collect and send device data to a third party.

Where does that leave us? Reading it carefully, it seems that the restrictions are limited to “user or device data”. I’m interpreting that to mean things like UDIDs and emails, not anonymous player usage data (how long did it take to reach level 5, how long are play sessions, etc), so I think we’re clear there.

The puzzling thing is that a lot (all?) of the third party analytics libraries do report device information, like what kind of hardware or iOS version is running. That is extremely important information that developers really benefit from knowing, but it seems to go against point 3.3.9. Maybe “device data” only applies to information about that specific device? (as in, the UDID that is now going away). I hope so.

Not having analytics isn’t really an option. Unless you make a game that you plan to throw on the App Store, never touch again, and hope for the best, you’re flying blind without analytics.

What are some of the options we have then?

Home brewed

If you read this blog regularly, you probably know that I’m a low-level, do-it-myself kind of guy, with a deep mistrust and suspicion of middleware. So you would think that I would want to write my own analytics package. After all, how hard can it be? Collect the data you want and ping your server with it. If you get fancy, you can even use a scalable server back end like AWS or GAE. Done.

Not so fast. To do that well, it’s a lot more involved than that. You want to batch when you send out the information, and you might want to distinguish between WiFi and 3G connection (to avoid causing extra data usage for players on a limited data plan).

That in itself is not even that bad. The real pain comes in visualizing that data, and that’s where you can easily sink in days or weeks, and you would still not have something as good as some of the other alternatives.

The other drawback is that if you have some successful applications, you may be generating Terabytes of data per day. Think about the storage and bandwidth costs for that. Yes, I know that sounds insane, but Playfish reported generating that much analytics data at a GDC 2011 talk (video for paid GDC Vault members).

Flurry

Flurry Analytics appears to be the most common analytics package out there among my indie iOS dev friends. It’s free and it’s easy to integrate. The visualization page is pretty good, and it even offers some fancy features beyond session length and events, such as flow through the application.

So what’s not to like? I was never able to make heads or tails of the application flow. When you get at that level, you start needing to spend some serious time making sense of data, which is what I don’t have as an indie. The web page to visualize the data is written in Flash, so for those of you using an iPad to check it, it’s not a good option. Update: Flurry apparently added a Flash-free web page since I last looked at it a few months back. Thanks Charilaos Kalogirou for the tip.

The killer deal for me was bloat. Adding the Flurry analytics library to an app increased the executable size by 500KB. I’m sorry, but that’s completely unacceptable for me. Memory is tight, and half a MB is very significant. I would rather add another large texture or another music track. And if you think about it, why does it need 500KB to buffer and send some events? That’s simply ridiculous.

Google Analytics

I never actually tried out Google Analytics. They have an iOS SDK and it integrates quite well into the web page Google Analytics environment. The main drawback I heard from other developers is that it’s designed more for web pages rather than for apps and games, so it wasn’t a perfect fit.

Anyone who used it want to expand on this in the comments?

Localytics

Localytics is a relative newcomer to the iOS analytics field, but it was love at first sight for me.

It has the same ease of integration of Flurry, and it provides very similar functionality. Localytics, however, is completely open source, so instead of a black box library, you get the source code and you can add it directly to your game. How much does it increase executable size? 4KB! You have to wonder what the other 496KB were for in the Flurry library.

As a bonus, their visualization web page works great on an iPad, although it can be a bit slow for very large data sets sometimes.

One of their biggest selling points is that they report the analytics in real time, but I really don’t care one way or another. Waiting 12 or 24 hours to see the analytics doesn’t bother me one bit.

Unlike Flurry, you can only add strings as parameters to events. That works fine if I have a set of discrete options. For example, when someone sends a bouquet in Flower Garden, I can send a “bouquet sent” event with a parameters that is “email”, “facebook”, or “sms”. As a result, I can see a nice pie chart with the breakdown of how people are sending bouquets. Very useful stuff!

But how about things that don’t have discrete options? For example, in Casey’s Contraptions, we wanted to see how long players take to solve each level. It turns out you can’t have a number as a parameter, but you can easily get around that by discretizing it yourself, which in the end, is easier to visualize. So when we send the LevelXXFinished event, we look at how long the player took to finish it, and we break it down into ranges: under 30s, 30s-1min, 1min-2min, etc.

This is what the report looks like for one of Casey’s Contraptions levels:

It looks like a fairly balanced level with the majority of the people spending under 3 minutes to solve it.

Random tips

A couple random things we learned along the way about analytics:

• Less is more. Start with just a few events and go from there. If you have tons of data, you might never have the time to look at it.
• Use analytics during playtesting. One thing is what people tell you, and another thing is what they really do. Since most of our playtesting is done remotely and we can’t observe as people play (which is invaluable), we can at least gather some hard data about it.
• Turn off analytics reporting in debug mode. Trust me on that one.

How about you? What’s your favorite analytics package and why?

[1] For example, Flower Garden has been on the App Store for almost two and a half years, and it has changed radically in that time!

For those of you who have been living under a rock and haven’t seen the Casey’s Contraptions video, go watch it now. I’ll wait. Or even better, here it is. You don’t even have to leave this page:

The core interaction loop of Casey’s Contraptions gameplay is placing some items, pressing the Play button, seeing the simulation, and repeating based on what you learned from seeing the simulation. We designed this loop to be very tight and without any penalty: Running/stopping the simulation is instant, there’s no limit on the number of times you run it, and you can even stop the simulation by tapping anywhere on the screen. Even if you painted yourself in a wall by creating a solution that needs a very specific placement of items on the screen, making small changes is very quick and painless.

There’s a very important, underlaying assumption in that loop: Running the same simulation multiple times will result in the same behavior. Imagine how frustrating it would be to create a complex chain reaction, just to find out it only works every other time you run it. That would truly deserve a ONE STAR WANT MY MONEY BACK!!

Determinism

That’s referred to as the game being deterministic: Given the same inputs, it produces the same outputs. It’s not the first time I’ve had to deal with that. Actually, it seems that I’ve had to deal with that in one form or another for all my games in the last 10 years (except for Flower Garden). Most recently, it was a key component of gameplay for the unreleased game we were working on at Power of Two Games.

To make a game deterministic, you need to remove the obvious sources of “accidentally different” inputs. That’s usually random number generators, and making sure the initial state is truly the same. It’s too easy to have some leftover state from the previous simulation that throws things off a little bit.

Another potential source of problems are uninitialized variables. If at some point the simulation depends on an uninitialized variable, different runs will cause different results based on whatever value happened to be in memory at that time.

Once you fix all of those little things, that should be it, right? Same input should create the same output. Not really. We’re missing the most crucial input: The timer.

Casey’s Contraptions runs at 60 fps on an iPad one, but the timestep isn’t set to a fixed 16.667ms. Instead, I use a high-resolution timer to measure how much time has really elapsed since last frame, and I advance the simulation by that much.

The problem is that the timer doesn’t always return the exact same amount. It’s not super-precise, and it can be slightly affected by other things going on in the device. It won’t be off by more than 1/10th of a ms, but that’s enough to cause different results and start diverging the simulation.

Fixed timestep

One way to get around this problem is to hardcode the timestep to always be 16.667ms, independently of what it really was. That would fix the determinism problem, but it would add its own drawbacks. If the simulation can’t keep up with 60 fps, the game will appear to slow down, which is not the effect we want. Casey’s Contraptions includes a level editor to make your own free-form contraptions, and even though we have a cap in the maximum number of items you can add, it’s probably possible to add enough of them to start slowing down an iPad 1.

Recording timesteps

A tempting solution (and one I’m ashamed I even briefly tried), is to record the exact timestep during the first run of the simulation. Then, in subsequent runs when nothing has changed, we use the initially recorded stream of timesteps instead of the real ones from the clock.

Apart from being a clumsy-looking solution (I hate having two modes for doing the same thing), the solution only works in the case of replaying the exact same input. This approach falls apart if you make a change to an item that doesn’t affect the simulation until after several seconds have passed. At that point, you’re running a new simulation with new timesteps and everything can diverge before the affected object is changed. Bad, idea. Bad.

Fixed simulation timesteps

This is the correct solution and it’s what we’re doing in Casey’s Contraptions.

You probably already know that physics simulations are a lot more stable if you take small steps, always of the same size. So you really never want to advance your physics simulation by your frame time. Instead, you want to have a small and fixed simulation step (we’re running at 120Hz, but 200 or even 300 are not unheard of). Then, you run the physics simulation as many times as you can fit into your larger timestep. It’s also important to keep around the amount of leftover time you haven’t simulated, to apply it to the next frame.

The simulation loop code looks something like this:

	const float timestep = 1.0f/120.0f;
	accumulator += dt;
	while (accumulator >= timestep)
	{
		// Do physics simulation by timestep
		accumulator -= timestep;
	}

Once we have this loop in place, our real frame time doesn’t matter anymore. The physics simulation will either run for a full step (or multiple steps), or it won’t. There’s no half-way states. So it doesn’t matter if in the first run of the simulation the loop gets executed 3 times in the first frame and 2 times in the second, and in the next simulation is 2 times in the first and 3 in the second. The state of the world will be the same.

Glenn Fiedler writes about this kind of simulation loop in much more detail in this excellent article.

Jitterbug

There’s still a slight problem with the above loop. Nothing horrible; the simulation is deterministic at this point (assuming everything else is taken care of correctly). But you might notice some annoying jittering as things move around.

That’s because how we’re sampling the simulation. We might render a frame after 3 steps of the physics simulation, but another one after 2. So movement isn’t going to be very smooth.

To get around it, we need to interpolate the state of the world to match the time at which the frame is rendered. To do that, we need to simulate one timestep in the future, and then interpolate between the previous one and the future one by the percentage amount left in the accumulator.

Something like this:

	const float timestep = 1.0f/120.0f;
	accumulator += dt;
	while (accumulator >= timestep)
	{
		GameState lastState = gameState;
		// Do physics simulation by timestep
		accumulator -= timestep;
	}

	const float t = accumulator/timestep;
	GamePhysicsUtils::LerpState(interpolatedState, prevState, gameState, t);

The interpolation is just the positions and rotations of every item in the world. That’s only used for rendering, so no need to worry about velocities or forces (unless those are affecting rendering in a very obvious way too).

This is when it comes really handy to have the game state as a contiguous, relocatable block of memory. You can really easily copy states around without having to worry about allocating any memory or fixing any pointers. Yes, I really like my simple, pre-allocated data.

One added benefit of this approach: If you do it right, you can have extreme slow-motion in your game and everything will be right. Even if you only run one physics simulation loop every 10 rendering frames, the interpolation will take care of making sure everything is super smooth.

Odds and ends

A couple gotchas to watch out for (that’s code speak for “I didn’t think of this and it bit me hard”).

If you have any game logic that affects the physical state of your game objects, it needs to be executed in the inner, simulation loop. Anything that deals with visual or audio stuff can go in the regular update loop and only be executed once per frame.

A good example of this was the balloon code. Every frame, I iterate through all existing balloons, and apply some upward force based on buoyancy and other factors. Initially that was done once per frame, after the physics simulation, but that’s obviously wrong because it will leave balloons (and everything else) in a different state depending on your frame delta time. I moved it to the inner simulation loop and everything became deterministic again.

This second gotcha sounds silly, but it was a big deal: Make sure you deal with the situation where you have different numbers of items in the previous game state than in the next game state. For example, if a balloon is destroyed, between the two states, the item count will be different. In my case I don’t free any memory, but I was initially making the assumption that I could interpolate based on the index of the items on both states. But since I removed the balloon and pushed all the items behind it forward, the interpolation was totally wrong.

I solved that problem by marking items as invalid, and removing them only after the inner simulation loop was complete. That allowed me to still interpolate in a very straightforward way and not have to worry about missing items.

Taking it further

Not only are we relying on this determinism while you play a level of Casey’s Contraptions, but also to let you replay solutions from your friends. We simply load their initial layout and run the simulation locally.

[Pause]

Ah, yes, astute reader, you’re right to be puzzled about that. How do we make the simulation deterministic across platforms and versions? Good question. Stay tuned.

TL;DR

Great book for someone starting out on iOS development. You would be at a severe disadvantage if you don’t know about most practices described in the book. Single resource for lots of good practices you’d have to pick up from blogs or Twitter otherwise.

In More Detail…

Don’t be fooled by the title. The Business of iPhone and iPad App Development by Dave Wooldridge and Michael Schneider isn’t one of your boss’ stuffy business book. This is a practical, hands on, guide to making a successful iOS app. It assumes you already have an idea and know how to develop it, but it guides you through the steps of focusing the app, designing it so it can be profitable, and releasing it with the best possible chance of becoming a good seller.

You’ve probably heard a dozen stories of developers who create a great app, submit it to the App Store, and then wonder why they only sold a dozen copies. This is the book they need to go along with that great app.

The book roughly follows the development timeline of an app, from the initial concept, design, implementation, testing, and release. At each of the stages, it covers any aspects that can have a significant impact in the sales success of the app. Even though you can read the book cover to cover, the chapters are very well defined, so it’s easy to jump directly to the part that interests you the most.

With Casey’s Contraptions almost ready to submit to Apple, I read with particular interest the chapters on creating prerelease buzz and increasing awareness of the app. Lots of good advice there.

Don’t expect anything groundbreaking though. If you’ve been following this blog for a while, or you’ve been hanging out on Twitter with all the iOS developers, you will know most of what the book has to offer. It might still be worth it for a few pearls of wisdom here and there to fill some blind spot. However, the book should be required reading for any new iOS developer. Easily the best $20 you can spend as far as impact in the final app sales.

I usually have no patience for technical books with filler chapters and sections. This book is very good about getting to the point, although it has a few sections that feel a bit out of place in that they’re quite basic and technical (like details of generating provisioning profiles, did we really need that in this book?). All in all, that’s a pretty minor point and easy to get around them.

Delayed Release

Probably my main criticism is that the book doesn’t mention one release technique that I consider to be a requirement for any major launch these days: The delayed launch. As the authors mention several times in the last few chapters, once you submit your app, you have no control over when Apple approves it, so you have to play some guessing games.

Instead, you can delay the release of the app once it has been approved, and set it to a known, fixed date in the future (say, a week from approval). At that point, you can really kick in your PR in high gear, contact media outlets, and, most importantly, send them promo codes for your app, even though it’s not available for sale yet.

The goal is to have all the PR hit on launch day or shortly after. The more you can make that happen, the more successful any PR efforts will be, and the bigger the initial launch (and hopefully the following sales) will be.

All in all, The Business of iPhone and iPad App Development is an easy recommendation for the new iOS developer. Go read it right now before you even think of shipping another app.

What can we tell by looking at those games? I see two clear categories: Games with a strong, established IP (Street Fighter, Sonic), or independent games with a huge amount of polish and style.

It’s All About Polish

The love and care developers put into those games shows the moment you start them up. Look at the textures in Tiny Wings, the sound effects in Angry Birds, the feedback animations in Words With Friends, or all the little details in Cut The Rope. All the tiny particle effects, transitions, sounds, and general squish and responsiveness. Every single one of those games is oozing with its own style and contributes to a very enjoyable first (and repeat) experience.

And that is the main point of this post: To make a successful game on the App Store, the main thing you need is love. You can skimp on features, on content, on marketing, on a web site, or even on gameplay balance. All those are things that you can add or improve after shipping, but polish and style are responsible for that crucial first impression. Miss the chance to hit the player with all you’ve got the first time they play your game, and that might be a lost sale (and a lost advocate of your game since word of mouth is such a strong force on the App Store).

Not convinced about the difference polish and style makes?

This game is essentially Tiny Wings with just a little bit of polish (and it does have *some* polish).

And this is Tiny Wings.

I rest my case.

Ship As Soon As Possible?

Traditional game development (especially for consoles) usually goes along these lines: Plan everything, create a game with everything that you want/can fit, ship it once it’s done, and hope not to touch it again. On the other hand, in this day of web/Facebook/mobile development the favored approach is to release a product as soon as possible, and then iterate from there.

My preference in the last few years has been more along the shipping as soon as possible lines (even if I haven’t always been successful at it). But then I paused and really thought about why and what I would accomplish by shipping early. These are the main reasons I could think about:

• Getting to market first. This is a big one in the web world (and maybe even in the hardware world). Even if your product is imperfect, or its UI is less than ideal, getting that initial critical mass of users could be what tips the balance in your favor.
• Canceling the project early. Maybe it takes as long as the first version of a product to realize there isn’t demand for it. So it was better to have spent 6 months instead of 3 years before canceling the project.
• Focussing your efforts. An impending ship date will make wonders to keep people on track and focused on what’s important to ship a game.
• Become profitable as soon as possible. Even if you make the same amount of money and spend the same amount of time working on a project, if you start bringing in money at the 6 month mark rather than at the 3 year mark, you’ll be profitable earlier. And as any RTS fan will tell you, getting extra resources early in the game can put you at a huge advantage.
• Changing the product based on early user feedback. Otherwise you might spend years working on a product that people don’t really want, or they would prefer something slightly different.

How do those reasons apply to iOS games?

• As an iOS game, your biggest moment is launch. That’s when you can get most momentum and get the word of mouth ball rolling. First impressions matter a lot and a lot of people will make snap decisions about your game in the first few seconds. If it’s not looking its best, it doesn’t matter if it came earlier than another game. Besides, games, for the most part, aren’t providing as much of a service as they’re a form of entertainment. Barring brand new genres or whole new platforms, getting to market first doesn’t mean much. And even if you’re making a brand new genre, chances are it’s unique so the clones won’t start showing up until after you launch and becomes popular (unless you announce way in advance).
• Stopping development on an unsuccessful game earlier rather than later is always a good thing.
• Likewise, having a milestone around the corner does wonders for focussing your efforts. That was one of the big benefits we got from submitting Casey’s Contraptions to the IGF.
• The last one is tricky. It might seem like a benefit for iOS games as well, but I’m going to argue it isn’t. Don’t get me wrong, I think that testing and user feedback is very valuable. But games ultimately are a form of art[1] and you are the creator. In the end, you need to decide what your game and your vision are like. Feedback will help with usability and balancing issues, but not with what the game is fundamentally. Stick to your vision.

My Approach

Looking at those lists, it makes it clear to me that iOS game development is not all about getting a product out of the door as soon as possible. There’s no need to create a finished product for your first release. Instead, save every feature and content you can for free updates or even future in-app purchases.

I’m convinced that polish and style are one of the most important things an iOS game can have. It’s not the first time I say that. So get the product out as soon as you can, but do not, under any circumstances, cut any polish from your game. Plan on spending a good month or longer after your game is “done” polishing it. That time will definitely be well spent and will increase the value of your game more than any other month you spent developing it.

What I’m suggesting here is actually quite different from what Chris Hecker talked about at last year’s GDC. Even though we’re both saying “take your time and do your game right”, he’s emphasizing the completeness of the game (in the sense of exploring all its potential), while I’m emphasizing the presentation. I think the main reason our messages are so different is the platform we’re developing for. On a platform like iOS, I really think you can explore the full potential of a game after it ships without any real drawbacks.

Right now we’re in the polish phase in Casey’s Contraptions. The game has been “done” for a while, in the sense that we have all the items, lots of levels, you can play through all the puzzles, make your own contraptions, etc. Even though it already has a lot of style and polish, it definitely needs that extra layer of shine to make it really stand out and bring it to the quality of those games in the top 10 list. We can only hope that Casey’s Contraptions joins them after we launch!

Interested in keeping up with Casey’s Contraptions as we’re gearing up for launch? Join the Facebook page.

[1] Feel free to substitute whatever word you want there that isn’t offensive to you: entertainment, interactive media, etc. Games are something *you* create from your imagination, so art seems like the best term to me.

One of the most important steps on the way to becoming a profitable independent iOS developer is diversifying your revenue stream.  While business lingo like that makes me throw up a little, all it really means is discovering all the ways you can earn money using the platform.  New developers sometimes pigeonhole themselves into a single App Store strategy: “Sell as many copies at 99 cents as possible”.  More savvy developers mix  multiple strategies: “Paid apps”, “In-App Purchases”, and “Advertising”.  I want to make sure all developers know about another additional option often overlooked: LinkShare.

LinkShare is a company which pairs publishers with retailers who pay said developers for driving clicks to their sites that result in sales.  How does this apply to iOS developers?  Luckily Apple (specifically iTunes) is one of the retailers which uses LinkShare.  A good FAQ page for the iTunes affiliate program can be found here, but the basic gist of it that you earn a 5% commission on items bought on the App Store from your affiliate links.  As an iOS developer you are probably already using links to your apps (and perhaps others) in lots of places, including “More Games” screens, twitter, newsletters, banner ads, or your web site.  Replacing all these existing (and future) links to the App Store with your affiliate links is a great start.  Retro Dreamer even wrote a nice quick guide to creating links that work seamlessly in iOS (there are some pros and cons to different link formats).

Now you might think the chances of someone actually buying an app you link to are relatively low, but that’s where things get interesting.  If you read the fine print it turns out affiliates get paid 5% of any purchases made within a 72 hours after following your link.  Lets say Joe clicks on a link to say, Pocket Frogs (our latest free game) which included your affiliate id, which even doesn’t result in a paid purchase even if the app is downloaded.  But perhaps Joe ends up buying Angry Birds ($0.99) an hour later earning you $0.05, or Real Racing 2 ($4.99) that night earning you $0.25, or just maybe the Beatles Box Set ($149.00) the next morning earning you $7.45!  The cool thing about the iTunes affiliate program is that it gives the affiliate 5% of any and all purchases made through iTunes within 72 hours including ring tones, songs, apps, in-app purchases, movies, tv shows, or rentals.

This of course means you can still earn revenue from linking to free apps,  which can end up being a powerful thing.  For example, in Pocket Frogs we run a promotion every week where we offer an in game item for downloading a certain free app (with a LinkShare link of course).  This not only keeps players checking back, but lets us promote apps we like (like Flower Garden) or even our own.  Like most other revenue sources LinkShare isn’t going to make you a whole lot of money if there aren’t that many people clicking your links, but it will certainly grow along with the number of users you have.  While the majority of revenue generated from Pocket Frogs (which fluctuates between 150k and 200k daily active users) comes from the IAP included in the game, it also generates a healthy amount of revenue from LinkShare (in conjunction with some links inside other apps) as seen below.

The great thing about LinkShare is that it gives you a lot of freedom on how you use it. It doesn’t use up any bandwidth or take up CPU cycles, and it doesn’t require you to shoehorn 3rd party code into your app. It is as invisible or invasive as you want it to be. So whether you’re a new iOS developer just starting out or an experienced dev, you owe it to yourself to take a look at using LinkShare if you’re not using it already.

Fast-forward another year, and this morning I woke up to a very pleasant and unexpected surprise: Flower Garden was featured on the App Store under Apps For Valentine’s Day!

Flower Garden is still going strong, but I wasn’t expecting that at all. Thank you, Apple! Not only that, but this feature also appears on the device App Store. Flower Garden was featured twice before by Apple, but never before on a spot that appeared on the device. So that’s a first for Flower Garden!

To make things more interesting, I had been planning on doing a bit of promotion around Valentine’s Day like last year. So a few days ago I released a new update, and included another in-app purchase for the most asked-for feature: More pots in another garden space.

Finally, to round things off, I planned on doing a similar promotion to what I did last year around Mother’s Day, and I set Flower Garden to be free from today until Valentine’s Day to encourage even more people to try it. To get the word out of the price drop, I got some promotion going from Pocket Frogs and a few other apps encouraging users try out the now free Flower Garden. I’m also hoping a few media outlets cover the sale to get the word out as much as possible.

As of this moment, Flower Garden is in the top 100 apps in the US and in the top 50 games, so the combination of everything seems to be working. We’ll see how things develop over this coming week. Until then, it’s going to be an exciting ride.

For the latest news on Flower Garden, join the Facebook page by clicking “Like”:

This was my third 360iDev Game Jam, and it gets better all the time. It’s great to see that it has become a 360iDev tradition, and that the number of people participating is going up every time. The last couple of times we had one invited guest to participate remotely (and preside over everybody else in the big video screen), but this time we opened it up so anybody, anywhere in the world could join us and participate in the updates and discussions through the web site (big thanks for Mike Berg for all the excellent work on the web site!).

What’s The Point

Some people don’t understand what the point of the game jam is. Other people see the value in it, but disagree with what other people see. The point of a game jam is the same as a jamming music session: To create something while surrounded by other developers and feed off each other’s energy and enthusiasm.

In addition to the jamming aspect of it, different people have different goals, and they’re all just as good and valuable:

• Trying a new game idea
• Learning a new API or technique
• Making a finished product
• Starting something new
• Being totally experimental
• Stretching their comfort zone

There were even people using the game jam as a means to make progress in their own game or app they had already started. It’s a bit far from the original intent, but why not? It’s the jamming part that is the most important.

I was glad to see that most people decided to work the theme (“changing the world”) in the game somehow. I definitely find that having some constraints helps me focus and be more creative at the same time.

One of the most attractive aspects of a game jam for me is that it’s a very focused, but very short effort. Yes, it sounds epic: “A full night of pizza, coffee, and coding…” but it’s only 8-10 hours. That means the cost of “failure” is minimal. It’s about a work day. That’s it. So that means it’s possible to try new, risky, experimental things, and, most importantly, be OK if they don’t work out. You don’t learn by succeeding at everything.

Swapping Roles

The last two game jams, I experimented with different kinds of game designs (heavy use of multi touch and limited visibility). This time around I’m in the middle of a new project (Casey’s Contraptions), and Miguel and I did about 5-6 prototypes earlier this year, so I wasn’t itching to do another experimental gameplay prototype.

So instead, Miguel and I paired up again, but with a twist: He would do all the programming and I would do all the art. How’s that for crazy? Actually, he’s in a lot better shape because he’s a good programmer in addition to being a great artist. Me, on the other hand, I can barely find my way around in Photoshop to copy and paste images from Google Images, so this was definitely going to be way out of my comfort zone.

As you can expect, we didn’t make as much progress as we had hoped. On the other hand, I never had more fun or learned more new things at a game jam before! It helped a lot that I wasn’t just flailing around with Photoshop, but that Miguel was there giving me pointers and showing me what the right way of doing things was. I went from not knowing that there was such a thing as a path tool, to becoming relatively proficient with it over the course of the night. It was like drinking a potion of +5 to Photoshop skills.

Apart from learning a lot, I also developed an even deeper appreciation and admiration of game artists. I knew it wasn’t easy stuff and that you needed a lot of talent. What I wasn’t quite fully appreciating is how technically involved art creation is! It’s very different from traditional painting and drawing, and it’s very highly technical. In a way, it’s almost like 3D modeling in how it requires mastery of a very complex tool and you need to work on very small parts for a long time.

Here’s a screenshot of the game showing all the assets I created during the jam:

Lessons Learned

Some random, unsorted, lessons learned from this jam:

• Come ready with an empty project you can start working on. The jam is not the time when you want to start stripping out old code. I learned that one in my first game jam, but didn’t come prepared with an iPad project (Hint: the iPhone -> iPad automatic conversion sucks–does anything automatic not suck?).
• Everything takes longer than you think. If you think you’ll just finish the game by morning, it’s probably too big. Choose something smaller.
• Learning stuff during the jam is great. Just adjust expectations about what you’ll create (we knew this going in, but still caught us by surprise).
• Take a moment to interact with the people around you. We’re all in a hurry to make something awesome, but take some time to talk to other developers. It’s well worth it, and makes the long night more bearable (and energizes you more).
• Pizza and coffee is a killer combination. I suspect I might never have to go to sleep if I keep the two in balance ;-b
• When wifi sucks, it’s hard to take the time to post updates or read other people’s updates.
• Hotel wifi always sucks.
• The jam is not a popularity contest. Sure, it’s great to show it off the next day, but make sure you create what you want for yourself and not based on what will demo best the next day.

If you haven’t done a game jam, you should. I strongly suggest collaborating with at least one other person, and doing it live with a bunch of other developers. The energy is incredible and it will be an experience you’ll learn a lot from and will remember for a long time.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter. This will be my last post for iDevBlogADay for a while (need to give those people in the massive waiting list a chance!), but I’ll definitely continue posting regularly.

Session description

The common-sense approach to make money on the App Store used to be to do anything to get on the top charts. In-app purchases changed all of that. Good in-app purchases can make your app profitable without being anywhere on the charts, and are the best hope for the independent developer. Come to this session to learn why IAPs can be so effective and how to leverage them effectively: what makes a good IAP, how to increase your user involvement, how to present IAPs in an attractive way, what things attract users, and what things turn them away. We’ll go through lots of detailed real-world data from Flower Garden and other games with strong IAPs.

Presentation slides: [Slideshare] [pdf]

Today I want to share my latest experiment, and how it was a total and complete failure: Adding the option to gift IAP items from within the game.

Promo Codes

Before I can talk about how I implemented the “Gift This” feature, we need to talk about promo codes. Since Flower Garden has so many in-app purchases, I figured it would be very handy to have the ability to give some of them away to people for any reason: They mistakenly downloaded the wrong thing, they bought it in the free version and want to upgrade to the full one, or they supposedly paid for one but they never got it. Whatever the reason, having my own promo codes for in-app purchases was one of the best decisions I could have made. I would highly recommend it if you have IAPs, especially consumables.

The implementation of promo codes was totally straightforward. I have two tables in the Google App Engine: One for active promo codes and one for redeemed ones. The active promo code includes the code itself, the IAP item it refers to, the amount, and whether it’s limited to one user or not (if it’s limited to one user, the code goes away as soon as it’s redeemed, otherwise, any amount of users can redeem it).

Here’s an example of a code I just added (yes, feel free to redeem it in the Flower Shop):

Whenever a promo code is redeemed, I enter that data in the other table. That way not only do I have a log of what codes where redeemed and when, but I can also check and prevent the same device from redeeming the same code multiple times.

Another important reason to keep a redeemed promo code table is that I want promo codes to be as valid as purchasing the IAP directly. That means that if you ever attempt to purchase an item, I check first to see if you’ve redeemed a promo code for it, and if so, you can re-download it for free. Same thing when you do a restore purchases (although I believe I haven’t gotten around to implementing that part yet :-)

Here’s my plea to Apple: Please, please, please, give us an “iTunes Account ID” along with the IAP data. Right now the best we can do is associate a purchase with a device (which is not good enough), or have a whole registration system for users (which is a pain and more time consuming for users). They’re already doing this with a Game Center ID, so why not with an iTunes Account?

Gift This

Once the promo code system was in place and field tested for a couple of months, I finally implemented the Gift This functionality. In the Flower Shop, users have the option to buy an item for themselves, or for someone else.

The first time you use the Gift This feature it explains how it works: You purchase the item and then you send it to someone else through email.

Under the hood, it purchases the IAP, contacts the server to generate a new promo code for that item, and then creates an email with the promo code and even a custom URL. Whenever someone receives a gift email, they can just click on the custom link and they immediately receive the item (assuming they have Flower Garden installed, of course).

One interesting consequence is that to implement this, you need to create one new IAP item for every item you want to gift (especially if they’re not consumable). Otherwise, someone couldn’t gift an item they had already purchased, or they couldn’t gift it more than once. This can add quite a few extra IAPs in your list!

In the case of Flower Garden, I started with the easiest case, and I only implemented gifting for fertilizer purchases (because they’re consumable, so I don’t have to keep track of who receives them and restoring them).

Total Failure

I really had great hopes for the Gift This feature. I had already envisioned writing a blog post showing IAP revenue going up 20-30% because of that feature. Not quite! It was pretty much a complete flop. The only positive thing I can say about it is that it didn’t actually lower regular sales.

See for yourself. In a period of about a month and a half, all the fertilizer gifting in the free and paid versions of Flower Garden amounted to a whopping $191!

Definitely not worth the 3-4 days it took me to implement it (and the opportunity cost of not being able to add some other feature or IAP).

Compare it to fertilizer sales during that period of over $7,000:

(That’s the spike of the new feature plus the Pocket Frogs cross promotion if you were wondering about it).

I’d love to know how the Gift This feature on the App Store is working out for Apple. I’m sure it’s doing better than my attempt at it, but I’m going to bet it’s still a very small percentage compared to regular sales.

Here comes the important question: Why was it a failure? Do people don’t like to gift? Was it presented badly? Did most people not know it existed?

There’s no way to know for sure, but my current guess is that people don’t like to gift something they don’t already own. Psychologically, there are several too many steps involved: Oh, I want to gift something, look for it in the store, purchase it, and send the email. Not a very fulfilling experience.

On the other hand, gifting something you already own is much more appealing. You have it in front of you, you’re proud of it and it looks great. You tap on a button and send it to someone. That is a lot more satisfying. So in the future I’ll take that approach and allow people to gift things they already own, even if they had to previously pay for it in some way.

What do you think? Do you have a better theory? How could it have been improved?

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

But that was because of the kind of games I was making, which were very light on content, with mostly procedurally generated assets (the consequence of working by myself and being much better at programming than at Photoshop).

That game that Miguel and I are working on right now is a lot heavier on assets. It has locations, and levels, and the whole shebang. And that’s where XCode starts falling short.

Explicit Resources

Before, I was adding all my game assets to the Resources folder in XCode. That adds the file to the “Copy Bundle Resources” step. And as you expect, when you do a build, it checks the date of the existing file, and only copies it if the source file is newer than the destination file.

Personally, I really like this approach. I like to be explicit about what gets included in a game, and I don’t mind at all having to add files manually to the project.

Unfortunately, it has one major flaw: It collapses all assets at the root of the application directory, ignoring the directory structure where they came from. I have no idea what the rational is for this “feature”, but someone needs to be taken out to the public town plaza and whipped for that. Actually, make that a double-whipping session if the reason was “convenience”.

The reason this becomes a big deal now is that we have per-level resources. To keep things sane, we decided to use a directory hierarchy, so Levels/Level00 contains all the files necessary for that level. Same thing with Level01, etc. The problem comes that both those levels have similarly named files: Background.jpg Layout.bin, etc.

Any guesses what happens if you add to XCode two files with the same filename in different paths? Yup. One of them overrides the other. Not a single warning either. Let’s make that a triple-serving of whipping, please.

I briefly considered prefixing all the files with the level name (Level00_Background.jpg), but if later I decide to move Level00 to Level05 that’s a lot of files to rename, so I would end up having to write scripts, or create a separate file with the level ordering, or just generally waste my time doing something that should have been taken care of by the tool.

Folder References

Even though I had read they had their share of problems, I decided to look a folder references (at Miguel’s prompting mostly).

When you add some resources to XCode, you have an option to check “Create Folder References for any added folders”. That option automatically adds any files in those folders without having to explicitly add them to XCode. So you could add the Levels folder, and then any files you create there will be copied with the game.

I’m not a big fan of assets copied automatically, but as a side effect, that step preserves the directory hierarchy each of those files was in. So any files copied this way can be accessed from within the game by using their full directory structure.

I have to ask again: Why are directory structures preserved here but not with explicit resources added to the project? The mind boggles.

But hey, at least it works, right? Not exactly. There are a couple of gotchas.

The big one I had read in multiple places, is that XCode doesn’t detect any changes to files inside the referenced folder. So you can be making all sorts of changes, building the game, and not seeing anything different. The recommended solution was to add an extra step to the build process that would start by touching the reference folder, forcing a full copy of all assets.

I tested that, I’m glad to report that at least in XCode 3.2.4, that’s not the case. If you modify any file inside a referenced folder, the file will get copied over correctly during the build process without the need of extra steps.

The bad news is that all the files in the referenced folder will be copied. Why oh why??? They clearly know which file changed, why do they feel the need to copy all of the other files? No idea. This is not a big deal early on, but as you start to accumulate dozens and hundreds of megabytes of assets, build times start increasing quite a bit, especially on the device itself.

This is what the copy command looks like for referenced folders:

CpResource build/Debug-iphonesimulator/Test.app/Levels Levels
cd /Users/noel/Development/Test/trunk/Test
setenv PATH "/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Developer/Library/PrivateFrameworks/DevToolsCore.framework/Resources/pbxcp -exclude .DS_Store -exclude CVS -exclude .svn -Testve-src-symlinks /Users/noel/Development/Test/trunk/Test/Levels /Users/noel/Development/Test/trunk/Test/build/Debug-iphonesimulator/Test.app

It’s nice touch that it automatically excludes .svn directories though. I was wondering why they use CpResource instead of plain, old cp, but I guess that’s to be able to -exclude specific files. Fair enough.

However, what CpResource apparently doesn’t do is to process any of the resources in ways that were processed before by XCode. For example, a png file would have been processed by premultiplying it and byte swapping it so loading it in the iPhone would be slightly more efficient. CpResource just does a regular copy and leaves it alone. So if you were relying on that behavior, you need to do it explicitly yourself in your asset baking step.

What I Really Want

For now, I’m using folder references for the levels, and explicit references for everything else. That way I keep the data size to a minimum but I get to have the directory hierarchy. Not ideal, but at least it works.

This is what I would really like thought:

1. Easiest: Explicit assets with paths. I really want to just add resources to XCode and have it preserve the directory structure. It’s not that hard. If XCode were open source, I would have made that change a long time ago. Can we at least have this as an option?
2. Second easiest: Folder references that only copy the changed resources. That would also be OK in my book, and I can’t believe it would be much harder to implement either.
3. Best: A remote file system hosted on the Mac during debug build. All file references go out to the host machine and get loaded on the fly. This would allow for fastest build times and loading times would not be that different from a fragmented drive on an old device probably. I know some of you already have something like this. Has anybody made one open source (preferably minimalistic and standalone)? I’d love to check it out.

Of course, all of this has probably changed already with XCode 4, but I’m deathly afraid of installing it while working on a production game. Has anybody tried it yet? Have they fixed anything, or is it even more broken?

To wrap things up, and since Miguel is spilling the beans on Twitter, I’ll share a few assets from our current game. Now back to the game because we’re submitting it to the Independent Games Festival on Monday. Next Thursday I’ll talk about the IGF. Wish us luck!

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Most often, the advice stops there. So you get your initial sales spike and then sales go way down. What do you do then? Usually, developers release new features and updates. That’s great, but how do you get people to notice it. You need to establish some form of communication with your players.

Update Messages

The simplest form of communication is through the “What’s new” section in the update. You can use that section not just to list what features you added and what bugs you fixed, but also to let your players know about other things: plans for the future, other games to try, or even the URL for your Facebook group.

Credit goes to Igor for bringing up this idea and pointing out the URLs are even clickable in this field (but they aren’t in the app description).

Of course, if you’re like me and you update your apps only once in a while, this technique isn’t as effective. Right now my iPhone tells me I have 67 new updates available. I’m clearly not going to be reading through the release notes of each one.

In-Game News

A more direct way of reaching out to your players is to have some sort of in-game news system. At any point you can update a file in your web server with any news, and it is displayed in the game. It can be implemented in many different ways depending on “on your face” you want to be about it: a pop up that comes up when the user runs the game, a ticker that runs constantly across the bottom of the screen, or, what I did for Flower Garden, a news icon with a badge indicating how many unread items there are, that brings up the news page when you tap it.

Make sure players are able to click on URLs in your news messages so you can direct them to different web pages easily. More on that on a bit.

Emails

Update messages are only good for players who update their apps (ahem, ahem), and in-game news for active players who’re currently launching your apps. For maximum effect, you can send an email newsletter and that way you can also reach users who played the game at some point in the past, but aren’t currently playing it now. They’re the ones probably most interested in new updates and features, and chances are you can rekindle their interest in the game.

To do this, you should encourage users to register for your mailing list, or collect their emails with their consent in some other way. This was a technique I started using back in December of last year with great success.

I’m currently using Your Mailing List Provider as a means to delivering thousands and thousands of emails [1]. By the way, don’t miss a chance to join the Flower Garden mailing list :-)

Facebook

Similar to the mailing list approach, Facebook groups can be a very effective form of communication. An additional benefit is that friends of your players might see them participating in the page and might make them try out your game.

Case Study: Pocket Frogs Cross-Promotion

All that is fine in theory. How does it work in practice? I have been using all four forms of communication for a while, and I’m definitely seeing good bumps of sales and downloads with each update and each major communication.

Last week, Ian and Dave from Nimblebit and I, decided to set up a cross promotion between Pocket Frogs and Flower Garden.

I updated the in-game news and send out an email newsletter coinciding with the latest Flower Garden update telling the players that if they downloaded Pocket Frogs from within Flower Garden, they would be awarded 5 doses of fertilizer. Nimblebit awarded players a flower if they downloaded Flower Garden Free from within Pocket Frogs.

When you have over a million downloads in a week like Pocket Frog did, that kind of player communication is the equivalent of a nuclear cannon. The effects of the cross-promotion were obvious the instant the news went live:

As you can see, Flower Garden Free made it all the way to the number 56 in the iPhone Top Apps chart in the US! The effect even spread to the paid version of Flower Garden:

Pocket Frogs at the time was hovering at around #9 on the charts, so it was difficult to have much of an impact on that position without major numbers, but we suspect it might have hovered there a little longer because of the extra downloads from Flower Garden.

Here is what the downloads for Flower Garden Free looked like for the last month. The Pocket Frogs cross-promotion is quite noticeable:

All those downloads also translated into in-app sales through the Flower Shop. Here are the revenues for that time period:

One consequence I wasn’t expecting, but in retrospect I’m not that surprised about, is that the ratings for Flower Garden Free dropped by a whole star (from 4 to 3), with a large percentage of 1-star reviews. That’s because a lot of people who wouldn’t have downloaded Flower Garden otherwise did it anyway, didn’t like it, and deleted it right away.

To wrap things up on a better note, there was yet another side effect of the cross promotion. The Pocket Frogs link was using my LinkShare referral code. Sending all those users to the App Store to download a free game link resulted in about $200 in referral profit for the week.

Conclusion

Communicating with your players is more than just profitable: It’s crucial to the sustained success of your games. Make sure you try to engage with them in every way you can, keep them up to date with developments in your game, and don’t hesitate to run the occasional cross-promotion, especially with other games that are a good match for your target audience.

[1] If you decide to use them and wouldn’t mind using my referral code (WQHVUF), I can get a small percentage back.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Lag In Games

I’m defining lag as the time elapsed between the moment the player performs an input action (press a button, touch the screen, move his finger), until the game provides some feedback for that input (movement, flash behind a button, sound effect).

Mick West wrote a great article on the causes of lag in games, followed up by another one in how to measure it. I’m going to apply some of that to the lag I was experiencing in my game.

Lag can be introduced in games by many different factors:

• Delay between gathering input and delivering it to the game. Delay updating the simulation to reflect new inputs.- Delay rendering simulation state.
• Delay displaying the latest rendered state on screen.

The new game runs on the iPad and involves moving objects around the screen with your finger. To make sure it wasn’t anything weird with the rest of the game code, I wrote a quick (and ugly!) program that draws a square with OpenGL that follows your finger on the screen. When you run the sample, the same lag becomes immediately obvious.

The iPad is a much larger device than the iPhone, and it encourages a physical metaphor even more. As soon as you attempt to move an “object” on screen, the lag kills that sense of physicality. Instead of moving an object around with your finger, you’re dragging it around with a rubber band. It moved the player from applying direct action on screen, to being removed and disassociated with the actions on screen.

Loop Structure

The place to start looking for lag is in my main loop. The main loop looks something like this:

	ProcessInput();
	UpdateSimulation();
	RenderWorld();
	PresentRenderBuffer();

So I was reading the input correctly before the simulation. Nothing weird there.

Touch input is delivered to the code as events from the OS. Whenever I received those events (outside of the main loop), I queue them, and then process them all whenever the main loop starts in ProcessInput().

The loop runs at 60Hz, so the lag here is at most 16.7 ms (if you’re running at 30Hz, then you’re looking at a delay up to 33.3ms). Unfortunately, the lag I was seeing in the game was way more than one frame, so there was to be something else.

Rendering

For some reason, I thought that iDevices were triple buffered. I ran some tests and fortunately it looks like it’s regular double buffering. That means that if I render a frame and call presentRenderBuffer(), the results of that render will be visible on screen at the next vertical sync interval. I’m sure there’s a slight lag with the iPad screen, but I’m willing to be is close to negligible when we’re talking about milliseconds, so we’ll call that zero.

Main Loop Calls

The game uses CADisplayLink with interval of 1, so the main loop is called once every 16.7 ms (give or take a fraction of ms). I thought that perhaps CADisplayLink wasn’t playing well with touch events, so I tried switching to NSTimer, and even to my old thread-driven main loop, but none of it seemed to make any difference. Lag was alive and well as always.

That the simulation and rendering in the game are very fast, probably just a few ms. That means the rest of the system has plenty of time to process events. If I had a full main loop, maybe one of the two other approaches would have made a difference.

It looks like the lag source had to be further upstream.

Input Processing

On the dashboard, press and hold on an icon, now move it around the screen. That’s the same kind of lag we have in the sample program! That’s not encouraging.

A touch screen works as a big matrix of touch sensors. The Apple OS processes that input grid and tries to make sense out of it by figuring out where the touches are. The iOS functions eventually process that grid, and send our programs the familiar touchesBegan, touchesMoved, etc events. That’s not easy task by any means. It’s certainly not like processing mouse input, which is discrete and very clearly defined. For example, you can put your whole palm down on the screen. Where are the touches exactly?

TouchesBegan is actually a reasonably easy one. That’s why you see very little lag associated with that one. Sensors go from having no touch values, to going over a certain threshold. I’m sure that as soon as one or two of them cross that threshold, the OS identifies that as a touch and sends up the began event.

TouchesMoved is a lot more problematic. What constitutes a touch moving? You need to detect the area in the sensor grid that is activated, and you need to detect a pattern of movement and find out a new center for it. In order to do that, you’ll need several samples and a fair amount of CPU cycles to perform some kind of signal processing on the inputs. That extra CPU usage is probably the reason why some games get choppier as soon as you touch the screen.

Measuring Lag

Measuring lag in a game is tricky. You usually can’t measure it from within the code, so you need to resort to external means like Mick did in his tests.

I decided to do something similar. I pulled out my digital video camera, and started recording my finger moving on the screen. The quality leaves much to be desired, but it’s good enough for the job. I can see how far my finger gets from the center of the square, but that’s not enough information to quantify the lag. How fast is my finger moving exactly? Fortunately, that’s something I can answer in code, so I added that information to the screen [1]. Now, for a given frame, I can see both how far the finger is from the center of the square and how fast it’s going.

The square is 100 pixels wide. When I move my finger at about 500 pixels per second, the center of my finger is on the edge of the square. That makes a rough 100 ms total delay from input until it’s rendered. That’s a whopping 6 full frames at 60 fps!

What Can We Do About It

As iOS developers, there isn’t much we can do. Make sure your loops are set up correctly to avoid an extra frame delay. Make sure you provide feedback as soon as you can and don’t delay it any longer than you have to. Other than that, there’s nothing much we can do.

I’ve been saying this for a while, but I’m a big fan of layers as long as you can get to the underlying layers when you need to. Here’s a perfect case where it would be fantastic if Apple gave us raw access to the touch matrix input. Apart from being able to process the input faster (because I know what kind of input to expect for the game), can you imagine the possibilities that would open up? Input wouldn’t be limited to touch events, and we could even sense how “hard” the user is pushing, or the shape of the push.

At the very least, it would be very useful if we had the option to allocate extra CPU cycles to input recognition. I’m not doing much in my game while this is going on, so I’d happily give the input recognition code 95% of the frame time if it means it can give me those events in half the time.

I’m hoping that in a not very far distant, iDevices come with multiple cores, and maybe one of those cores is dedicated to the OS and to do input recognition without affecting the game. Or maybe, since that’s such a specialized, data-intensive task, some custom hardware could do the job much faster.

Until then, we’ll just have to deal with massive input lag.

How about you? Do you have some technique that can reduce the touch event lag?

LagTest source code. Released under the MIT License, yadda, yadda, yadda…

[1] I actually shrank the OpenGL view to make sure the label wasn’t on top if it because I was getting choppier input than usual. Even moving it there caused some choppiness. This is exactly what I saw last year with OpenGL performance dropping when a label is updated every frame!

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Every so often, something happens that bumps up the priority of one of the items in my list. Maybe it’s another related blog post, or a game coming out with something relevant to what I wanted to write about. In this case it was a tweet from Paul Pridham [1]:

Customizing colors in a sprite or texture is very frequent in games, from changing player characters into blue and red teams, to creating color variations of an armor piece, to letting the player pick the exact shade for their pet’s fur color. Or, in the case of Flower Garden, to change the colors of the petals on the fly.

There are two requirements for this:

• We want to change colors dynamically.
• We only want to affect certain areas of the original texture.

That rules out creating texture variations ahead of time, although that might be a valid approach sometimes if you have lots of art resources, don’t mind increasing the download size, and you have a fixed number of variation to deal with. It also rules out modulating/blending the texture by a particular color because it would tint all the texture, and we want to limit the effect to particular areas (leave the player’s arms their normal color, but change their shirt color).

This is one of those funny cases that it was a lot easier to do many years ago, when we used palletized color modes. You could set all the custom color areas to a particular palette entry, and then update that entry on the fly. Ah, all the awesome tricks palettes opened up the door to! I still miss them to this day.

In modern hardware it’s also really easy to do with a shader, but Paul wanted to use it across any iPhone device, and the majority of them are still stuck on OpenGL ES 1.1, so fixed-function pipeline it is.

The simplest approach would be to just render the model twice: First pass renders the texture, and second pass renders the custom color bits (you can render them with a white texture modulated by the global color to get the right color). The main drawbacks are that you’re doubling the number of draw calls, and, with 3D objects, it gets a bit tricker because the second pass needs to use the glDepthFunc(GL_EQUAL) depth comparison function.

The better way to do this is using the texture combiners. Texture combiners allow us to perform a limited number of operations to control the final look of a pixel. We can add two textures, or multiply them, or even do a few more complex operations. The true power of the combiners is that they can be chained together, so the output from one feeds into the input of another, allowing us to create much more complex operations.

The iPhone 3G is limited two two texture combiner units [2], but even two combiners are good to create a good range of effects.

Let’s think about what we want to accomplish. We want to leave some parts of the texture completely alone and display the original pixel value. In some other parts of the texture, we want to replace the pixels there with a custom color. Actually even better, we probably want to multiply those pixels by a custom color. That way we can author the part of the texture that is going to change with grayscale details, and our color adds the tint to it.

Let’s express it mathematically. Let’s make a function M that is 1 for every pixel we want to color, and 0 for the ones where the original texture is supposed to be displayed. Our desired color is c and the texture it t. In that case, the final pixel color (p) is:

p = M*(c*t) + (1 - M)*t

We could express that with two combiners: The first one is a modulate (multiply) operation with c and t, and the second one an interpolation operation between the result of the previous combiner and the original texture, based on the function M.

Obviously M is just a mask texture. We can paint it white where we want to color the texture, and black elsewhere. We could even use the alpha channel of the original texture, but there’s one big thing to watch out for: If you have your texture as a png and process it through the default iPhone resource operations, the image will be premultiplied for you (whether you want it or not), so your color information will be set to zero everywhere that the alpha channel is zero. Oops. You’ll probably want to use the alpha channel to store transparency anyway, so we’ll keep the mask separate. If not, make sure you encode the image yourself (as raw or PVRT formats) so it’s not premultiplied ahead of time.

Are we ready transfer that formula to the texture combiners? Not quite. Apparently (and this was just trial and error, I haven’t seen it documented), the texture assigned to a combiner can only be the one at that stage. If you look at the second combiner, we would need to have the first texture as one of the parameters, in addition to the mask.

So instead, we can reorganize the function above like this:

p = c*(M*t) + (t - M*t)

What did we gain by that? The color is what’s going to change dynamically, but the mask and the texture always stay the same. We could precompute the M*t term by simply multiplying the texture and the mask. We can call that new term A. We can do the same thing with the (t - M*t) term, which just means turning black all the pixels in the texture where mask will go. That one will be B. The easiest way to “precompute” those values is just doing it in Photoshop and exporting it as a new png.

Our new formula is now:

p = c*A + B

Nice and simple! Now we can really add that to the texture combiners like this:

// c
glColor4f(m_customColor.r, m_customColor.g, m_customColor.b, 1);

glActiveTexture(GL_TEXTURE0);
// A = M*t (precomputed)
glBindTexture(GL_TEXTURE_2D, m_maskHandle);
glEnable(GL_TEXTURE_2D);
// c*A
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);

glActiveTexture(GL_TEXTURE1);
// B = t - M*t (precomputed)
glBindTexture(GL_TEXTURE_2D, m_textureHandle);
glEnable(GL_TEXTURE_2D);

// c*A + B
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
glTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_ADD);
glTexEnvi(GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);
glTexEnvi(GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE);

One more thing to watch out for: Because we’re using two textures, you need to have two sets of texture coordinates. In this case, we want them to be the same, so we can just point them to the same set of data:

glClientActiveTexture(GL_TEXTURE0);
glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), &vertices[0].u);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glClientActiveTexture(GL_TEXTURE1);
glTexCoordPointer(2, GL_FLOAT, sizeof(Vertex), &vertices[0].u);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

That’s it! You can see the results in the included project and play with the register combiners to achieve different operations.

At this point I was going to describe the texture combiner setup I use in Flower Garden to render the petals, but this post ended up taking longer than I had hoped for (I’m trying to shoot for an hour per post, but this has taken me already two hours between the code and the the post itself), so I’ll save that for another time.

• Demo source code. Released under the MIT license.

[1] Paul developed Sword of Fargoal, by far my favorite iPhone RPG. [2] The 3GS allows up to eight I believe.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Fast-forward to now, and as more companies are jumping into the bandwagon of games that need “points” to make progress, we’re still bundles. Again, I chucked that up to legacy reasons and doing what worked with the standalone apps.

Discovering Bundles

It was at the last 360iDev in San Jose, that Mark Johnson said something that really stuck with me. I can still hear him say it with his fine British accent: “I think we might be underestimating how much people are willing to pay for in-app purchases”. Really?

As soon as I had a chance, I looked at the best-selling IAPs for some popular games. The screenshots below were taken today, not back when I looked at them, but the results are very much the same. I let you guess which games these IAPs came from.

I was very surprised with what I saw. The top-selling IAP was never a $0.99 one, and there were bundles of $49.99 or higher towards the top! That was crazy! I was indeed underestimating what players are willing to buy by only offering a measly $0.99 fertilizer bottle in Flower Garden!

Bundles In Flower Garden

As part of the next Flower Garden update, I decided to run a little experiment and add two more fertilizer options: A $2.99 one and a $5.99 one, each of them giving you a slightly better deal on fertilizer (20, 70, and 150 doses). That was still nothing compared to the price tags I was seeing in those other games, but I didn’t want to alienate users by slapping some ridiculously high bundle prices.

The results?

The most popular item by number of sales was still the single fertilizer bottle for $0.99. But a lot of people took advantage of the the other two bundles as well. This is how fertilizer sales for Flower Garden Free have been for the last two months:

But now, let’s look at that same period by plotting revenue (again, only Flower Garden Free, the full version is very similar but it wasn’t easy to combine the two to display them here):

Now the two bundles are a lot closer to the single bottle, especially the larger, $5.99 bundle.

More Than Meets The Eye

In the end, were bundles effective, or are people buying the same amount of fertilizer and leaving less money in the process? Unfortunately I can’t answer that question from a pure data point of view. Looking at fertilizer sales before and after I introduced the bundles is no good because the number of users increased dramatically at each update. I can’t even normalize them by the number of sales, it would have to be by the number of daily users, and unfortunately that’s not a statistic that I’m tracking.

However, I think we can argue two really good points about why bundles are great.

1. More choice

Having different levels of bundles give players more choice on how they want to purchase something. From what I’ve read about buyer psychology, people love having choices when buying something (just don’t give them too many choices!). They are more involved in the buying process, they evaluate it, and they feel better about the decision they eventually make. So that seems to indicate that more people might buy fertilizer if there are a few bundle options than if there’s only one.

2. Commitment

This is the biggie. Whenever a user purchases a $5.99 bundle (or a $49.99 one!), they became more committed to your game. You can also guarantee they will come back again to get their money’s worth from that purchase. Even if they had the intention of coming back to your game without the purchase, having spent that money is a nice reminder to do so. And having people come back to your game is what this is all about: They will explore more of the game, get hooked more, make more in-app purchases, show it to more of their friends, and send more bouquets to their family.

I have no doubt that I’ll be using bundles in the future. Players get a good deal, and you get committed players. It’s a win-win situation.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

One of the things you potentially give up by keeping the game runtime to a minimum is an editor built in the game itself. But that’s one of those things that sounds a lot better than it really is. From a technical point of view, having an editor in the game usually complicates the code a huge amount. All of a sudden you need to deal with objects being created and destroyed randomly (instead of through clearly defined events in the game), and you have to deal with all sorts of crazy inputs and configurations.

The worse part though, is having to implement some sort of GUI editing system in every platform. Creating the GUI to run on top of the game is not easy, requiring that you create custom GUI code or try to use some of the OpenGL/DirectX libraries available. And even then, a complex in-game GUI might not be a big deal on a PC, but wait and try to use that interface on a PS3 or iPhone. After all, making games is already complicated and time-consuming enough to waste more time reinventing the widget wheel.

Remote game editing manages to keep a minimal runtime and allow you to quickly create native GUIs that run on a PC. It’s the best of both worlds, and although it’s not quite a perfect solution, it’s the best approach I know.

Debug Server

Miguel Ángel Friginal already covered the basics of the debug server, so I’m not going to get in details there.

The idea is that you run a very simple socket server on the game, listening in a particular port. This server implements the basic telnet protocol, which pretty much means that it’s a line-based, plain-text communication.

The main difference between my debug server and Miguel’s (other than mine is written in cross-platform C/C++ instead of ObjC), is that I’m not using Lua to execute commands. Using Lua for that purpose is a pretty great idea, but goes against the philosophy of keeping the runtime as lean and mean as possible.

Instead, I register variables with the server by hand. For each variable, I specify its memory address, it’s type, any restrictions (such as minimum and maximum values), and a “pretty name” to display in the client. Sounds like a lot of work, but it’s just one line with the help of a template:

registry.Add(Tweak(&plantOptions.renderGloss, "render/gloss", "Render gloss"));
registry.Add(Tweak(&BouquetParams::FovY, "bouquet/fov", "FOV", Pi/32, Pi/3))

And yes, if I were to implement this today, I would probably get rid of the templates and make it all explicit instead (ah, the follies of youth :-)

TweakUtils::AddBool(registry, &plantOptions.renderGloss, "render/gloss", "Render gloss");
TweakUtils::AddFloat(registry, &BouquetParams::FovY, "bouquet/fov", "FOV", Pi/32, Pi/3);

The debug server itself responds to three simple commands:

• list. Lists all the variables registered in the server.
• set varname value. Sets a value.
• print varname. Gets the value for that variable.

For example, whenever the server receives a set command, it parses the value, verifies that it’s within the acceptable range, and applies it to the variable at the given memory location.

Telnet Clients

Because we used the standard telnet protocol, we can start playing with it right away. Launch the game, telnet into the right port, and you can start typing away.

However, most telnet clients leave much to be desired for this. They all rely on the history and cursor manipulation being handled by the shell they assume you’re connected to. Here we aren’t connected to much of anything, but I’d like to be able to push up arrow and get my last command, and be able to move to the beginning of the line or the previous word like I would do in any text editor. The easiest solution I found for that was to use a telnet client prepared for that kind of thing: A MUD client! Just about any will do, but one that works well for me is Atlantis.

So far, we’ve implemented the equivalent of a FPS console, but working remotely. And because the code is fully portable, our game can be in just about any platform and we can always access it from our PC. Not just that, but we can even open multiple simultaneous connections to various development devices if you need to run them all at once.

Custom Clients

Game parameter tweaking is something that is OK through a text-based console, but really comes into its own when you add a GUI. That’s exactly what we did at Power of Two Games. We created a generic GUI tool (based on WinForms since we were on Windows at the time), that would connect to the server, ask for a list of variables, and generate a GUI on the fly to represent those variables. Since we knew type and name of each variable, it was really easy to construct the GUI elements on the fly: A slider with a text field for floats and ints, a checkbox for bools, four text fields for vectors, and even a color picker for variables of the type color.

It worked beautifully, and adjusting different values by moving sliders around was fantastic. We quickly ran into two problems through.

The first one is that we added so many different tweaks to the game, that it quickly became unmanageable to find each one we wanted to tweak. So, in the spirit of keeping things as simple as possible (and pushing the complexity onto the client), we decided that the / symbol in a name would separate group name and variable name. That way we could group all related variables together and make everything usable again.

The second problem was realizing that some variables were changing on the runtime without us knowing it on the client. That created weird situations when moving sliders around. We decided that any time a registed variable changes on the server, it should notify any connected clients. That worked fine, but, as you can imagine, it became prohibitively expensive very quickly. To get around that, we added a fourth command: monitor varname. This way clients need to explicitly register themselves to receive notifications whenever a variable changes, and the GUI client only did it for the variables currently displayed on the screen.

During this process, it was extremely useful to be able to display a log console to see what kind of traffic there was going back and forth. It helped me track down a few instances of bugs where changing a variable in the client would update it in the server, sending an update back to the client, which would send it again back to the server, getting stuck in an infinite loop.

You don’t need to stop at a totally generic tool like this either. You could create a more custom tool, like a level editor, that still communicates with the runtime through this channel.

Flower Garden Example

For Flower Garden, I knew I was going to need a lot of knobs to tweak all those plant DNA parameters, so I initially looked into more traditional GUI libraries that worked on OpenGL. The sad truth is that they all fell way short, even for development purposes. So I decided to grab what I had at hand: My trusty tweaking system from Power of Two Games.

I’m glad I did. It saved a lot of time and scaled pretty well to deal with the hundreds of parameters in an individual flower, as well as the miscellaneous tweaks for the game itself (rendering settings, infinite fertilizer, fast-forwarding time, etc).

Unfortunately, there was one very annoying thing: The tweaker GUI was written in .Net. Sure, it would take me a couple of days to re-write it in Cocoa (faster if I actually knew any Cocoa), but as an indie, I never feel I can take two days to do something tangential like that. So instead, I just launched it from VMWare Fusion running Windows XP and… it worked. Amazingly enough, I’m able to connect from the tweaker running in VMWare Fusion to the iPhone running in the simulator. Kind of mind boggling when you stop and think about it. It also connects directly to the iPhone hardware without a problem.

VMWare Fusion uses up a lot of memory, so I briefly looked into running the tweaker client in Mono. Unfortunately Mono for the Mac didn’t seem mature enough to handle it, and not only was the rendering of the GUI not refreshing correctly, but events were triggered in a slightly different order than in Windows, causing even more chaos with the variable updates.

Here’s a time-lapse video of the creation of a Flower Garden seed from the tweaker:

Drawbacks

As I mentioned earlier, I love this system and it’s better than anything else I’ve tried, but it’s not without its share of problems.

Tweaking data is great, but once you find that set of values that balances the level to perfection… then what? You write those numbers down and enter them in code or in the level data file? That gets old fast. Ideally you want a way to automatically write those values back. That’s easy if the tool itself is the editor, but if it’s just a generic tweaker, it’s a bit more difficult.

One thing that helped was adding a Save/Load feature to the tweaker GUI. It would simply write out a large text-based file with all the variables and their current values. Whenever you load one of those, it would attempt to apply those same values to the current registered variables. In the end, I ended up making the Flower Garden offline seed file format match with what the tweaker saved out, so that process went pretty smoothly.

Another problem is if you want lots of real-time (or close to real time) updates from the server. For example, you might want to monitor a bunch of data points and plot them on the client (fps, memory usage, number of collisions per frame, etc). Since those values change every frame, it can quickly overwhelm the simple text channel. For those cases, I created side binary socket channels that can simply send real-time data without any overhead.

Finally, the last drawback is that this tweaking system makes editing variables very easy, but calling functions is not quite as simple. For the most part, I’ve learned to live without function calls, but sometimes you really want to do it. You can extend the server to register function pointers and map those to buttons in the client GUI, but that will only work for functions without any parameters. What if you wanted to call any arbitrary function? At that point you might be better off integrating Lua in your server.

Future Directions

This is a topic I’ve been interested in for a long time, but the current implementation of the system I’m using was written 3-4 years ago. As you all know by now, my coding style and programming philosophy changes quite a bit over time. If I were to implement a system like this today, I would do it quite differently.

For all I said about keeping the server lean and minimal, it could be even more minimal. Right now the server is receiving text commands, parsing them, validating them, and interpreting them. Instead, I would push all that work on the client, and all the server would receive would be a memory address, and some data to blast at that location. All of that information would be sent in binary (not text) format over a socket channel, so it would be much more efficient too. The only drawback is that we would lose the ability to connect with a simple telnet client, but it would probably be worth it in the long run.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

The Plan

Mother’s Day happens at the beginning of May (in the US and Canada anyway, I’m afraid I was too busy in April and I missed Mother’s Day in a lot of European countries). I figured it would be the perfect time to do another push.

If there’s something I learned from past experience, is that the more you manage to concentrate any kind of promotion, the more effective it will be. So in preparation for Mother’s Day, I created a new update (with iPad support), a couple of new in-app purchase items (new set of seeds and some fertilizer bundles), and sent out the usual announcement on the Flower Garden mailing list, Facebook page, and Twitter.

But in addition to all of that, I tried a new strategy: I gave Flower Garden away for free. Yes, completely for free.

The idea sounded really scary at first. After all, I would be giving away my baby for free. Would I lose a lot of money doing that? Would it depreciate the perceived value of Flower Garden? Would it annoy loyal users seeing an app they paid for given away? Fortunately it appears that the answer to those questions was no.

The reason I decided to give Flower Garden away for free was mostly to get it into more people’s hands. I was thinking I would lose some money initially, but then more than make up for it when I turned it back to paid because of all the extra users and word of mouth. There is already a free version with a limited number of pots and seeds, but people are hungry to download paid apps for free.

To add extra impact to this price change, I had Flower Garden featured as the free app for Mother’s Day weekend in Free App Calendar. Unlike other free app web sites, the folks at Free App Calendar are very developer friendly and are not out to take a cut of your profits or charge outrageous fees. It was an absolute pleasure dealing with them.

Mother’s Day

On Saturday May 8th, a few minutes past midnight the day before Mother’s Day, I switched Flower Garden over to free. Now I was committed!

Right away there was a lot of positive reaction around the announcement. Everybody on Twitter and Facebook were responding really well and spreading the word. Major sites like Touch Arcade and 148Apps covered the Mother’s Day promotion and got lots of extra eyeballs on the sale.

After the first day, the data was in: Flower Garden had been downloaded 12,500 times. That was great! As a reference, Flower Garden Free was usually downloaded between 800 and 1,000 times per day, so that was a 10x improvement.

On Sunday, Mother’s Day, things got even better. News had time to propagate more, and people were sending bouquets like crazy, so by the end of the day there had been an additional 26,000 downloads. That’s exactly what I was hoping for!

As a matter of fact, it was doing so great, that I decided to leave it for free as long as the number of downloads was significantly higher than what the free version was normally getting. After Mother’s Day downloads started going down, but they were still pretty strong the following Sunday. Here’s what the download numbers looked like for those 9 days:

The important question is how much revenue was there during that time? I was giving the app away for free but it had in-app purchases. Would they make up for it? The answer was a resounding yes!

Mother’s Day went on to become the biggest day in terms of revenue since Flower Garden was launched. Bigger even than Christmas or Valentine’s Day! Things started going down after that, but still at a very high level. The little bump towards the end of the week is a combination of the weekend (which always results in more sales), and the feature of Flower Garden on the App Store across most of Europe.

These numbers took a bit to sink in. It really shows that in-app purchases are definitely tied to the number of downloads. If you manage to give away twice as many copies, you’ll probably get close to twice as many in-app purchases. That effect is amplified if you have multiple in-app purchase items available.

It’s also interesting to notice that revenue didn’t follow the same drop-off curve as downloads. It wasn’t nearly as sharp. I suspect two things are going on in there:

• Some users downloaded Flower Garden during the sale weekend and weren’t interested in it at all. Downloading it was a knee-jerk reaction to any app that goes free, so that never translated into an in-app purchase. Users later in the week however, probably downloaded it because they received a bouquet or were interested in it, so they had a much higher likelihood of buying something through the Flower Shop.
• Fertilizer. Fertilizer is the only consumable item available for purchase in Flower Garden. Unlike a non-consumable item, the number of sales is not tied to the number of new users, but to the number of current, daily users. The more users launch your app every day, the higher the sales of consumable items. Some of the new users of Flower Garden went on to buy fertilizer later in the week, making revenue higher than you would expect from the download curve.

Flipping The Switch

The number of downloads on Sunday May 16th was slightly over 2,000. At that point I decided that it was close enough to the number of downloads Flower Garden Free was normally getting, so I flipped the switch back to paid. Things were going great, so messing with it was a pretty scary thing to do. Even scarier than it had been setting it free in the first place.

During that week, Flower Garden rose up on the charts. It reached #73 in the top games in the US and was charting very high in all the subcategories and on the iPad charts. As soon as I flipped the switch back to paid, it dropped out of sight from the charts. Fortunately, within a couple of days it came back to its position before that crazy week.

Most importantly, Flower Garden Free, which had dropped quite a bit during that promotion, immediately went back up to the top 100 in the Kids and Family subcategories like before.

As you can expect, as a result of giving it away for free, the ratings on the App Store went down quite a bit. While it was a paid application, the ratings were around 4 stars, but they dropped down to 2.5 stars after that week. It seems people love a free app, but are very quick to criticize it and give it a low rating (especially if it has in-app purchases).

Fortunately bad ratings can be easily fixed with a new update, and some encouragement to users to leave positive rating on the App Store. Now it’s back up to over 4.5 stars.

Aftermath

Now it’s two months later and the dust has had a chance to settle down. Apart from the very nice sales spike during the sale, was it worth it? Again, the answer is a definite yes.

Here’s the revenue since the start of the promotion:

As you can see, it quickly went down, but it settled at a reasonably high level. In fact, compare this two-month period (highlighted in blue) with the previous sales:

Before the promotion revenue was hovering around $1,500 per week, now it settled down to about $2,400 per week. An average day today is bigger than Christmas day! Very nice change!

I think the reason why it settled at a higher revenue level than before is because it got more exposure during that week. Lots of people sent bouquets, which introduced new users to Flower Garden. It’s the viral effect I was hoping for from the start, and although it never reached epidemic proportions, it has been enough to keep Flower Garden alive and well.

Adding iPad support as part of the latest update probably helped too. The iPad market is smaller than the iPhone one, but a lot of early adopters are eager to find good apps for their new toys. The smaller market size also allowed Flower Garden to appear in the iPad charts more easily, increasing exposure that way.

Here’s a breakdown of where revenue came from in the last month (I’m excluding the period where Flower Garden was free to get a more accurate view):

As you can see, consumable items (fertilizer) account for almost half the revenue. Consumable items are a factor of your current userbase, so getting a large influx of new users can result in a permanent revenue increase instead of just a sales spike. It also shows what a small percentage actual app sales are, which explains why even while Flower Garden was free, revenue was still up.

Conclusion

This was a wild ride again! It was definitely worth doing the promotion and it definitely brought home how powerful free can be. However, I’m trying to decide the pricing scheme for my next game, and even though free plus in-app purchases is very tempting, I’m not sure it’s the way to go.

What do you think? Are new games better off being free with in-app purchases, or can indie games be successful being paid (and still having in-app purchases)?

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Joey was kind enough to share the story behind Unearthed, some of the decisions leading up to the final game, and the initial reception and sales numbers. Thanks Joey!

Inspiration

Nine months ago, without warning, a gnome crept into my head. It was an idea inspired from a friend’s chance mention of an activity called geocaching, where participants use a GPS to hide and seek containers across the world. Within hours, I had envisioned a global cross between geocaching, the Amazing Race, and online travel agency representatives. The idea didn’t look much like the resultant product nine months later, but it formed the most critical ingredient to any venture: the obsession to see it completed.

I spent my evenings for a few short weeks hammering out a design, scoping and cutting features, and beginning a prototype, but it didn’t take long for me to admit to the unavoidable truth that such a project would take months working full time or probably 3 to 4 times as many months working nights and weekends. I had to sit and carefully consider the pros and cons of leaving my job to pursue something I desperately wanted to create.

Half-Hearted Dissent

For two weeks, I debated with my wife and close friends with startup experience. I drafted a list of pros and cons to quitting my job to pursue an iphone project and stared at it for hours. Those of you who have made the leap or considered it may recognize some of the points or have more of your own to add:

Advantages of quitting to work full time on an iphone idea

• Focus effort, complete project 3-4 times faster
• Gain valuable unique experience of running solo
• Avoid coding burnout, alienating loved ones, loss of sanity
• Resume padding

Advantages of keeping day job while working on iphone idea

• Steady income in a scary economy
• Not having to job search in a scary economy
• Peace of mind (in a scary economy)

You can see where a large portion of the dissenting argument forms its basis. After two weeks of listening to unanimous encouragement (bordering on persistent nagging) to quit my job, two weeks of trying my best to convince myself why I should not quit my job, I did what my gut knew from day one was going to be best for me. I marched to my boss’s room and quit my job. Ok, I had maybe two false starts where I turned around and went back to my seat.

The Project Unearthed

Over the next 8 months, scoping and an inclination to appeal to a casual segment evolved the project into a global paranormal investigation titled Unearthed. I tried my best to figure how to maximize the success of the product, and compiled a list of all the ways I could imagine increasing the product’s exposure:

• Banner ads
• Spamming blogs and websites to review my product
• Spamming friends on facebook
• Writing a blog
• Viral app features

I had trouble justifying the cost to pay for banner ads, and I had too much urgency to implement the product to devote time to a blog, so I focused on occasionally talking about the app on facebook, compiling a list of potential blog candidates for the day the app released, and devising viral features.

Apart from typical facebook posting and email-a-friend features, I decided to employ a “refer-an-agent” feature which would enable users to invite others to join their network, essentially a grouping of users that correlated with how effectively their app could process scanned creature data. The larger the network, the more credit users would receive for uploading data, and the better they would perform in leaderboards and achievements. The approach was an “everybody wins” style where anytime any user in the network gained a referral, every single person in the network would benefit from the growth of the network. The hope was that this feature would gain a viral quality.

Friends placed immense pressure to release the product as soon as humanly possible under the theory that doing so would reveal the 70% of my design that was wrong, so I divided Unearthed into three releases. The app itself has three game modes, each incrementally accessible as a given region “levels up” from users’ data uploads. I would have time to release the latter modes while the first mode of the game, the most casual mode where users look around where they stand and scan for anomalies, was being played.

In App Purchases and Ads

Considering the App Store was flooded with free apps and that I had no name in the industry to immediately convince users to immediately pay for my app, I concluded that the most likely approach for success was to release a free app with In App Purchases. This appeared to be the best way to get as many users to at least try the app and decide how much they wanted to spend to access more functionality. Initially, I offered the following items:

• All content, present and future ($5.99)
• Scanner upgrades level 2-3 ($1.99)
• Scanner upgrades level 4-5 ($1.99)
• Bounty Mode (coming soon) ($1.99)
• Blitz Mode (coming soon) ($1.99)

However, I hit a snag with Apple’s terms which did not permit me to even mention any features that were not yet implemented. The first item was intended to be a bulk pricing investment in the forthcoming completion of the app, and the ‘coming soon’ items were just client-side displays to tease of the future modes (not actually registered products in the IAP servers). Because I had to remove them, I revised my IAP content to the following:

• Scanner upgrades level 2 ($.99)
• Scanner upgrades level 3 ($.99)
• Scanner upgrades level 4 ($.99)
• Scanner upgrades level 5 ($.99)
• Scanner upgrades 2-5 ($2.99)

The app essentially gives users access to all features of the game, but with a lowly basic scanner that doesn’t boast the speed, range, and creature clearance levels of a fully boosted scanner.

I added Greystripe’s ad system as a means to offset the cost I might incur from using Google App Engine as my server solution. Considering the large amount of rank tracking required by my app, I estimated the revenue from ads to break even with the cost of using App Engine.

Release and Reception

The app was approved in the early afternoon of June 21st, a Monday. Excited, I quickly moved up the release date and it hit the stores later that afternoon. One week later, the sales are dismal, with about 400 total downloads and only a handful of purchases.

I considered possible contributors to this could be the following (in order of impact):

• Requiring 3GS
• Releasing 4 days before the iPhone 4 (dropping off New Releases)
• Requiring OS 3.1.3 (instead of 3.1)
• Releasing the app in the late afternoon (dropping off New Releases faster)

Without knowing the specifics on the sales of the 3GS versus the 3G and the iPod Touch, the fraction of 3GS users able to even see my app in the store might be a small fraction. Unnecessarily releasing under an OS that prevented users from installing unless they went back to iTunes to update their OS was likely a dealbreaker for browsing users (quickly remedied but days later). And considering how many of the 1.5 million users would be browsing the App Store for free apps Thursday, releasing a few days too early may have been the biggest avoidable mistake yet.

Moving Forward

As uninspiring as it was getting only a few hundred downloads and enough revenue for lunch, I had heard that word of mouth was a powerful vehicle, possibly the best vehicle, for an unknown developer, so my plan is to continue giving it more time and implement the GPS-enabled Bounty Mode which will take considerably less time, possibly a short 1-2 months. One week is certainly not a large enough measure of success, and already I’ve received a few responses from blogs willing to write reviews, so I’m hopeful of seeing the userbase grow and eagerly anticipating the next big server issue. In the coming weeks, there will definitely be no “sitting back while the cash rolls in”, as I recently had the blessing/curse of another inspiring must-create iPad app revelation and am sweating bullets designing and scoping while scheduling in work on Unearthed, all the while keeping a grave eye on the lifeline of my business.

Looking back at the struggling decision I made to quit my job, I’m reminded of some advice that was given to me beforehand. “Quitting your job will be the hardest decision, but it will make you feel great.” And like an enormous burden lifted from me, it did. And to this day, with earned lunch money in hand, it continues to.

First one bit of good news: That prompt-on-delete feature seems to be gone on iOS 4.0. That should make everybody happy. Even so, taking a pro-active position on this can only benefit developers.

Next a personal opinion without any real hard data to back it up: I don’t think App Store ratings matter very much. I see plenty of quality, 5-star apps that never go anywhere, as well as horrible apps with close to 1-star rating on the top 10. I’m sure good ratings help a bit, but not as much as some people may think.

One of the little features I snuck in the latest update of Flower Garden, was a prompt to rate (or re-rate) the app. This idea isn’t new, and I’ve seen quite a few apps doing it already. I think it makes a lot of sense and provides rating that is much more balanced and representative of how users feel about the app.

You have to be careful about how you prompt users though. This are the priorities I had in mind when I implemented the rating prompt in Flower Garden, roughly in order of importance:

1. Don’t be annoying!
2. Disrupt the user as little as possible
3. Make rating the app as easy as possible.
4. Prompt at every update.

Don’t be annoying

This is by far the most important priority. If your prompt for review is annoying, you might get more angry users and one-star reviews than you would have without it. Be respectful of the user and don’t nag.

For quite a few versions, I’ve had a review button in the “Feedback” tab in the settings screen. Not many people use it or even know about it because it was several taps away from the normal flow of Flower Garden. That’s an example of a feedback prompt that is too unobtrusive. Clearly, I needed something a bit more noticeable.

What I did was to add an actual alert view with the prompt. That alert comes up very infrequently, and gives users the option to either rate it right away, be reminded later, or just stop asking altogether. Many more users rated the app through this mechanism (and I haven’t gotten a single complaint about it being annoyed yet–keeping my fingers crossed).

Disrupt the user as little as possible

First of all, you should never ask the user to rate the first time they launch it. They haven’t had a chance to check it out yet! Give them a few days (or a few launches of the app). That will benefit you in two ways: users will have a better chance to give an honest rating, and users who didn’t like your app probably won’t be around in two days, so they’ll never see the prompt.

Second, choose a good time to ask. Please, don’t ask me as soon as I launch the app! Chances are I want to do something with it, so being pestered with a review prompt is disruptive, especially because adding a rating involves leaving the app and going to iTunes. At the same time, don’t ask me in the middle of a level or when I’m engrossed in game. A good moment to ask for a rating would be after completing a level or two, or, in the case of Flower Garden, after sending a bouquet.

For extra bonus points, catch the user on a “good” moment. Maybe only ask them to rate the app if they actually beat the level. They’ll probably leave a better review than if they just lost and are in a bad mood.

The exception I made was if a certain amount of time went by and the user never got to the point of being prompted (some people just don’t send bouquets in Flower Garden). In that case, I will ask at startup or at some other, non-ideal point.

Make rating the app as easy as possible

This is the funnel principle at work. For every action the user has to do in order to leave a review, the fewer users will actually do it. It would be ideal if users could rate the app directly from the alert box. That would involve no extra actions (or leaving the app) and would result in the maximum number of ratings [1]. Unfortunately, that’s not the case, so we have to do the best we can with what we have.

So we want to minimize the amount of actions from the moment the user taps “Rate now” until they can enter the rating. We could send them to the product page on the App Store, but that would still involve them scrolling around, finding the rating button, tapping it, and entering the rating. We can do better than that: We can send them directly to the rating screen. Check out this great post for a dissection of iTunes links and how to create one to the review page. Make sure the technique you choose works on an iPhone (not all of them do!).

Prompt at every update

This one is easy: Just store the number of the last version the user wrote a review for, and if it changes, start from scratch again. That way you don’t have to write any custom code at every release. Also, make sure to respect the “Don’t ask anymore” option if the user selected that in a previous update.

Source code

Here’s the review request source code (released under the MIT license). It consists of only two standalone files, and all the review state is kept in the default, global settings. There are only three functions and it should be very self-explanatory:

	bool ShouldAskForReview();
	bool ShouldAskForReviewAtLaunch();
	void AskForReview();

The ShouldAskForReviewAtLaunch() function simply adds an extra condition of launching it X number of times before asking for review (this is in case the user never triggers the review condition).

Results

Does this prompt for ratings work? This is a screen grab from iTunes 5 days after Flower Garden 2.4 was released:

A few interesting observations:

• Ratings are higher than they were before. Before the free day, Flower Garden had an average of 3.5 to 4 stars.
• Reviews are often shorter and less useful than unprompted reviews. There are a lot of 5-star “I love this app!” reviews without much more substance. (I’m not complaining, really).
• Still a huge number of users chose not to leave a review. There are only 148 ratings, but there have been 30,000 upgrades to the latest version. A lot of people might have upgraded and not launched it, but even so, it’s a very small percentage.

Overall, it was a very small time investment and the results show it was definitely worth it. I’ll be using this approach in my future projects (unless future iOS versions take care of it automatically somehow).

[1] Apple, can we fix that? How about a REST API for leaving ratings and reviews? Pretty please?

And if you haven’t picked up your free copy of Flower Garden, make sure to do it now. It will probably go back to full price after this weekend.

Gracias! Obrigado! Grazie! Σας ευχαριστώ! Tak!

So here we go with the second part. How did Flower Garden fare after the new year? Was it just the Christmas purchasing frenzy that had a momentary effect on sales, or was there something more to it?

Recap and Overview

Here’s where we left off last time. The unusual part was how profits increased as soon as I added in-app purchases to Flower Garden in early December. It made for a very atypical sales plot.

And here is how things look now. This plot includes the previous data so it’s easier to contrast before and after. The area in blue is the new data since the last post.

Just glancing at that chart makes it clear that that the increase around Christmas wasn’t a fluke. It actually wasn’t even done going up. After all the spikes, and the weekly ups and downs, Flower Garden ended up settling to about $1,500/week. And that, even in California, I would consider it to be a comfortable living. What a different from the $50/day it was making last year!

So what exactly happened there? Let’s look at the new data in more detail.

At a glance, there are three, very different sections.

The Feature

The first one starts with a significant increase in sales (A), and is in large part due to being featured on the App Store worldwide as a Staff Favorite. It’s a nice spike, but it’s nothing like the x10 spikes other developers have seen with App Store features. That’s because the Staff Favorite slot, even though it’s a very prestigious one, it does not appear on the iPhone, only on iTunes. I do all my browsing and shopping through iTunes, but apparently I’m in the minority, so the effect on sales is greatly reduced.

That spike is also in part due to my last “numbers post”, which happened right at the same time (not completely accidentally). The page attracted about 15,000 views in a few days, so I’m sure a few of them translated in people checking out Flower Garden out of curiosity.

Valentine’s Day

The second spike isn’t hard to guess: It’s the weekend of February 14th, Valentine’s Day. The more things happen at once and the more something is in the public eye, the more of an impact it has. PR people have known that for a long time, and it was really brought home for me back in December.

Fortunately, I managed to make quite a few things happen in the days leading to Valentine’s Day weekend:

• I released an update with couple new in-app purchases: A new set of seeds (Seeds of Love), and a greenhouse garden, for $0.99 each.
• I sent out a newsletter to the 25,000 subscribers to the mailing list announcing the new items.
• I put Flower Garden on sale for $0.99 (down from the regular price of $2.99).
• Several web sites, including TouchArcade, covered the sale and the new update, giving it lots of visibility.
• Flower Garden Free was the free app for February 14th on the Valentine’s Day Calendar.

All of that combined to cause the big spike in profits (B). You really need to look at the first plot to put it in perspective. Two days in around Valentine’s Day had higher profit than the initial release spike back in April of last year!

Winding Down

Of course, everything that goes up, must eventually come down. So the weeks following Valentine’s Day profits went rapidly down. It was at the very end of April that I started working on Lorax Garden, so for that period of time I wasn’t able to do anything related to Flower Garden. For a while sales were dropping quite rapidly, but they eventually flattened out to about $1,500/week (C).

The good thing about having consumable items as in-app purchases (fertilizer in this case), is that profits are related to active user base, not just initial sales. So even though the amount of downloads decreased significantly during this time, the user base had grown a large amount, and with it, the daily profits.

Flower Garden Free

Back in December, there seemed to be a connection between the amount of downloads of the free version of Flower Garden and profits. They both picked up right around the time I added in-app purchases, although I was never able to tell if it was cause or consequence.

This is the amount of downloads of the free version for this period of time.

It stays pretty regularly at about 800 downloads per day (which is not much compared to a lot of free versions out there), and has a massive spike on Valentine’s Day (caused by word of mouth, lots of sent bouquets, and the Valentine’s Day Calendar).

Notice that the App Store feature for Flower Garden (full version) in January had virtually no effect on downloads of the free version. It seems that people are willing to buy something full price without trying the free version first if Apple features it.

Both versions of Flower Garden (free and full) have in-app purchases in them. Even though there’s a higher percentage of users with the full version that buy in-app purchases, the free version is much more popular and the majority of the revenue comes from the free version (orange). This is a tren that was already noticable around the holidays, but now is much more clear, with over 50% of the revenue coming from in-app purchases in the free version.

The Future

The data for this post stops at May 5th. That’s because on May 6th I released a new set of seeds and gave Flower Garden away for free as part of the Mother’s Day promotion. As soon as the dust settles from that, I’ll write a third post detailing how it turned out.

Surprisingly, there wasn’t that much documentation on how to go about making a universal iPhone/iPad version. There’s a document from Apple showing some initial steps, but that’s about it. So I wanted to share what I learned along the way, including some very useful tips I learned through trial and error or by doing a lot of digging through Twitter and the development forums.

Flower Garden is a strange hybrid of OpenGL and UIKit, which made things more complicated than if it were just one or the other. Learning curve and all, it took two full days of my time. If you’re using just OpenGL or just UIKit, the conversion to a universal app will be significantly faster.

Universal Project

The first thing you need to do is understand what’s going on with all the SDK versions. At this time, the latest iPhone OS version is 3.1.3, but you’re going to be developing the universal app with SDK 3.2. You want the resulting binary to run on both 3.X OS on iPhones and 3.2 OS on iPad. It’s a very similar situation to when we were writing apps that worked on both 3.X and 2.X.

So fire up XCode 3.2.2 (yes, all those version numbers start getting very confusing–that’s the XCode version that comes with SDK 3.2), and load your iPhone project you want to make into a universal one. If you look under the Project menu item, you’ll see an entry called “Upgrade Current Target For iPad”. The Apple documentation even warns you not to create a universal app in any other way.

Go ahead and use it if you want. It will work… as long as you have a single target you want to convert. For some inexplicable reason [1], it will only work once per project (even though it’s phrased as working with whatever the current target is). When would you have more than one target executable? If you have a free and a paid version for example.

Besides, I’m uncomfortable with automated “smart” tools that do things behind my back without me knowing exactly what’s going on, so I upgraded by hand by looking at the diffs of what the upgrade command did. It turns out it’s extremely simple.

1. Under the project properties, set your base SDK to 3.2.
2. Set Architectures to “Optimized (arm6, arm7)”
3. Uncheck “Build Active Architectures Only” 5. In the Deployment section, set it to SDK 3.1.3 (or whatever 3.X you want to target)

That’s it, really. That’s all you need to compile and run your app both on an iPhone and an iPad. When you build for the device, it will compile both arm6 and arm7 versions and create a combined fat executable with both. And yes, this means the size of your executable is going to double (which could be an issue if you’re near the 20MB limit). In the case of Flower Garden, the combined executable is 3.4MB, so that’s not a big deal.

iPad Functionality

What about that new xib file that the upgrade process creates? You don’t really need it. It’s there in case you want to have a different set of xibs for each platform, and it’s hooked up to the info file so the app knows to load it at startup.

For the universal version of Flower Garden, I wasn’t trying to make a whole new brand experience on the iPad. Instead, I was looking for a quick and easy way to make it look much better. Because of it, I decided to reuse the same xib files as for the iPhone version.

That meant I had to go in Interface Builder, and adjust the autosize properties for a lot of the views. Some of them I wanted to stretch and get bigger with the high resolution iPad screen (background views). Others, I wanted to leave at the same size, but remain at the same relative distance from a particular border (buttons). Some other ones, I left the same size and their position just scaled up with the resolution (info boxes). All in all, that was the most time-consuming part of the process. It also required a few tweaks here and there to support the resolution change correctly.

The other big change was updating the resolution of the 3D views. Fortunately, that was just worked without a single line change. The render target code I’m using, takes the view dimensions and creates a frame buffer of the correct size. And it’s not just the dimensions: Remember that the iPad has a different aspect ratio (grumble, grumble), so you need to make sure your perspective and orthographic projections take that into account.

The only other changes I had to make was supporting an upside-down portrait orientation. That was very easy because the frame buffer didn’t have to change. Make sure you support it both at launch time and during gameplay. If you have a root controller whose view is attached directly to the main window from the start, it’s as easy as adding this to your controller:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation 
{
    return (interfaceOrientation == UIInterfaceOrientationPortrait ||
            interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown);
}

And make sure you add the supported orientations to your plist.

Finally, before you submit it to the App Store, you’ll need an iPad-specific icon. The documentation explains how to explicitly list all the icons in the info file, but at the very least, you can provide a file called Icon-72.png that is a 72x72 image and you’re done.

Running On The Simulator

This is one that should be a lot easier than it is. You’re creating a universal binary with SDK 3.2. Now you want to run it on the simulator. No problem, you run it as usual and you get the iPad simulator. You can debug it and do everything you normally do.

Now you want to run it on the simulator on iPhone mode. It turns out, that’s not so obvious.

You can’t just turn the simulator hardware setting to iPhone, because whenever you launch it from XCode it will override that again with the iPad one. Building and running on the 3.1.3 SDK is a no-no because you’re really running a different build than you’re going to be submitting (3.2) and all 3.2 SDK features you’re using are going to result in compile errors.

So after much searching and tweeting, here’s the solution:

• Build for 3.2 SDK on the simulator platform.
• Change project drop-down to 3.1.3 SDK - Launch with debugger (Cmd + Options + Y). Don’t build and run!

That will launch the simulator on iPhone mode, but still run your 3.2 build. Talk about unintuitive! [2]. The worst thing is, when you’re done, you need to switch the project to 3.2 again or you’ll get tons of compiler errors. That definitely has to go for SDK 4.0.

Here’s an invaluable tip. Maybe it’s obvious to long-term Mac users, but it baffled me for a while. The iPad simulator is very well thought out, and it has a 100% and a 50% mode. That makes it possible to use the simulator on screens without very high resolution. Even my external monitor at 1680x1050 can’t display the iPad simulator at full 1024x768 resolution in portrait mode because of the window borders.

The problem comes in when you want to take a screenshot to add to the App Store or anything else. On the iPhone simulator it was easy, but how do you do that with the iPad since you can’t fit it on the screen? Cmd + Ctrl + C will take a screenshot at full resolution even when running at 50% mode and add it to the clipboard! Switch over to Preview and select New from Clipboard and voila! Full resolution screenshot!

SDK 3.2 Features

Chances are that even if you do a simple iPad port, you’re going to end up using a few 3.2 features. The main one I used in the case of Flower Garden is a UIPopoverController. Here you should follow the steps outlined in the Apple documentation down to a T. But it comes down to this: If a symbol that is defined on 3.2 appears anywhere, even as a member pointer variable in a class, it will compile and run on the iPad fine, but will crash and burn on the iPhone.

So you need to both check that the 3.2 features are available, and you need to “hide” the new symbol so it never appears anywhere: Use an id variable and cast it based on the class info. Even casting it directly to the symbol you want will cause a crash.

Class classPopoverController = NSClassFromString(@"UIPopoverController");
if (classPopoverController)
{
    m_moreGamesPopover = [[classPopoverController alloc] initWithContentViewController:moreGames]; 
    [m_moreGamesPopover setDelegate:self];
    [m_moreGamesPopover setPopoverContentSize:CGSizeMake(320, moreGamesHeight) animated:NO];
    [m_moreGamesPopover presentPopoverFromRect:m_moreGamesButton.frame inView:self.view
                        permittedArrowDirections:UIPopoverArrowDirectionUp animated:YES];
}

Not pretty, uh? It works, but I couldn’t imagine doing this all over the place.

Gotchas

In the process of creating a universal app, I found a couple more things to watch out for.

When you submit the new binary through iTunes Connect and it’s accepted, the application status will change to something like “Missing screenshot”. If you go back and edit the app information, you’ll see there’s a new set of screenshots you can submit. You’ll need at least one for your application to enter “Waiting for Review” state. And if you have localized descriptions of your app, you’ll need to do that for every language.

Last, and perhaps most puzzling because I never figured this one out: I was not able to get in-app purchases to work with a test account from a development version of a universal app running on the iPad. I must have tried everything, but whenever I tried purchasing anything, it never brought up the familiar “sandbox environment” message. Also, items that hadn’t been approved yet did not show up in the list of available items. The exact same code worked fine on an iPhone, so that’s quite puzzling. Is it a major bug on Apple’s part, or did I miss some obscure “enable IAPs in debug mode” checkbox somewhere? It was a bit of a gamble submitting it like that, but fortunately, the approved version on the App Store allows in-app purchases without any problem.

I thought afterwards that maybe that was because the app version on the App Store was no universal, so the Store Kit server was not allowing the iPad version to access the store through the test account. But I tried it again even after it was approved and I had the same problem.

Has anybody managed to use an App Store test account from an iPad on a universal app?

Conclusion

All in all, it was a relatively painless process considering it’s different hardware, with a different resolution, and it’s the first iteration of the SDK. Was it worth it? I think so. Apart from looking a lot better on an iPad, universal apps get ranked on both iPhone and iPad charts. Flower Garden managed to get all the way up to #14 on the free games chart on the iPad (and around #60 free app overall on the iPad). I’m sure it got some exposure from being so high up, which in turn helped the iPhone rankings as well.

I can’t imagine that my next game is going to be iPad-only, but I’ll certainly have the iPad in mind from the beginning and release it on both platforms. Whether I choose to go universal or separate apps will depend on the game and business decisions, but at least it’s good to know that it’s fairly easy to create a universal app.

[1] Actually, there’s a pattern that is clear by looking at the hoops we have to jump to do a universal build: Apple was clearly scrambling to get this out the door. As a result, things are buggy, unintuitive, and clunky. Hopefully all that will be fixed for SDK 4.0.

[2] See? That confirms point [1].

Am I going crazy? Giving away the fruit of my labor for so many months? The App Store will do that to people, but this is a bit more sane. The idea is to encourage many more people to try it out. I’m actually hoping some of them will like it so much, they’ll buy a few of the in-app purchases from the Flower Shop. And even if they don’t, hopefully they’ll spread the (good) word about Flower Garden and they might also sign up for the mailing list. And in this business, expanding your user base is a great strategy that can be leveraged for future projects.

The idea of giving away a free app isn’t anything new. There are whole sites like FreeAppCalendar dedicated to doing exactly that, and other developers, like NimbleBit have been doing that on and off very successfully to reach a wider audience with their games.

How will it work out? I don’t know yet, but Flower Garden is quickly going up the charts even early on Saturday. It’s currently in the top 50 free apps in Japan, and about to get in the top 10 kids games in the US, so it’s looking good.

If you haven’t picked it up yet, this is the time. And if you have, make sure you tell your friends and family to download it and check it out before it goes back to the regular price. I’ll report back on the results of this promotion in a few days.

In late February I agreed to collaborate with Oceanhouse Media on a game project. They had the Dr. Seuss license and I had the flowers. Perfect match for a Lorax-themed game! And so the Lorax Garden was born.

I was originally hoping to write some entries here on the progress of the game as I worked on it, but I quickly realized that I wouldn’t have any spare time for anything other than the project. We wanted to have the Lorax Garden (and the Lorax book app) on the App Store by Earth Day (April 20th), so that left us with a very aggressive 5-week schedule (and GDC somewhere in the middle!). Fortunately, we managed to hit our deadline, and you can see the results today by yourself by downloading it from the App Store.

It was very interesting starting a totally new project from the existing Flower Garden codebase. I had to add some new flower-tech to make flowers more Seussian (curvy, uneven) and make Truffula Trees. Lorax Garden has a definite game structure and progression, so all the game code was completely new. It even has a flower-growing minigame to earn extra care hearts. All that had to be created by ripping out Flower Garden code and writing new one. It was a pleasure to see how easy it was to reuse all the flower-tech code that was well isolated and tested from the beginning though.

The Lorax Garden is currently featured by Apple on the App Store, and it’s on sale for $0.99 (down from the regular price of $2.99). All of that combined with a strong launch and mentions on USA Today and other media outlets have brought it up to the #39 (edit: #37!) paid app overall in the US App Store charts. A fantastic result, and with any luck it will continue climbing for another day or two.

The main difference is that I’m going to go in detail about each of the different cases of mixing OpenGL and UIKit, and what better way to do that than with a live demo. I’ll be switching back and forth between Keynote and XCode and going over the details, which is where a lot of the tricky parts are.

Here is the source code for the demo. That way you can look at it now and come to the session prepared with more questions, or ready to discuss what works and what doesn’t work for you. I love to have interactive sessions, so definitely come ready to ask questions.

If you’re not coming to 360iDev… shame on you! It’s the best iPhone conference around. You’ll be missing not just my session, but tons of other great talks, and the iPhone Game Jam (sponsored by TouchArcade this year). If you can’t make it this time, make a note on your calendar for next time!

• Demo source code. Released under the MIT license.

It was a 30-minute slot, so the material is pretty condensed without the chance to expand on the topics. I’m giving an extended version of this talk at 360iDev in a few weeks, so I’ll be able to get into more details then and have a cool sample app that shows off all those concepts.

It was great seeing a bunch of you at my session and at around the iPhone and Indie Summits. It was a great couple of days!

• Presentation slides (pdf format)
• Sample code

On a personal level, this nomination means quite a bit for me. Flower Garden has gotten some great reviews, and some incredible user feedback, and it was even featured as an Apple Staff Favorite on the App Store, but it had never been up for an award of this importance.

It’s also the category that it was nominated for. It makes me really proud that it was nominated for Most Innovative Game, because one of my original goals was to create something unique and original.

Finally, these awards are particularly meaningful because they’re not based on popularity, sales, or voting, which are bound to bias awards towards best-selling titles. Instead, these finalists were hand-picked by the editors of Pocket Gamer. With the crazy amount of good apps out there, it really is an honor that they selected Flower Garden as one of the top 5 for 2009.

Thank you, Pocket Gamer!

Shortly after the unveiling, people divided themselves in to two camps: the iPad haters, and the iPad defenders. Each of them was intent in convincing the other camp that their view is the right one. Just like most of the pointless human conflict over the last two thousand years minus the bloody wars part.

Of course, I felt the same way. As a consumer, I was very disappointed by the lack of video camera and the non-widescreen form factor. But I stepped back and realized that the iPad is here, and it is what it is. All the wishing and convincing in the world isn’t going to make a difference. The platform is here to stay, and with Apple’s genius behind it, I’m sure it’s going to be anywhere from “moderately successful” to “a huge success”.

The only question to answer as a developer is, how can I make the most out of the iPad? And for that, we need to understand what the iPad is.

There’s been a lot of talk on the iPad specs: 1024x768 resolution, a custom A4 chipset including a CPU and a modern GPU, etc. But those are just dry facts about the hardware. They will be crucial things to keep in mind to develop for the iPad, but they don’t help us that much understanding it.

Some people are claiming the iPad is a large iPod Touch, but I think that nothing could be further from the truth.

Precisely because the iPad is larger, it’s not a device you’re going to carry in your pocket. It’s something that’s going to be laying on your desk, or piled on top of a few books on the coffee table. And that changes everything.

Whereas on the iPhone/iPod Touch users could use an app for a few seconds or minutes during the day, the iPad is going to encourage longer sessions, just once or twice a day. The kind of apps, and in particular the kind of games that are going to be well suited to the iPad are going to be much more than a higher-resolution iPhone game. For the most part, they’re going to be totally different genres.

For example, Civilization never made much sense for me on the iPhone, but it now becomes a perfect iPad game. On the other hand, Flower Garden, was designed from the beginning to have multiple, short sessions throughout the day, so it will make very little sense as an iPad game. I suppose that makes me one of the first developers going on record saying I’m not going to port my existing iPhone app to the iPad :-)

The differences with the iPod Touch go beyond how frequently people use it. For example, games controlled by tilt are going to be restricted to a more hard core audience. Someone who really wants to sit down and spin the iPad around like a driving wheel controlling a car. Casual users will be less likely to grab the iPad and play a quick game of Scoops or Doodle Jump because it’s going to feel like a bigger deal than slightly tilting the iPhone in your hand.

The target demographic for the iPad is very different than the iPhone and iPod Touch. It will appeal mostly to people in their 30s and older, whereas the iPod Touch is really spreading on the younger demographic of middle and even elementary school. That will also radically change the kind of apps and games people will play on the iPad.

So it’s clear that the iPad is not a large iPod Touch, and it doesn’t pretend to replace it. That’s a key point. Instead of replacing it, us as developers should think about it as complementing the iPhone and iPod Touch. The kind of experience I expect from the ideal iPad application is one that lets me access the same data set or game state I was using with my iPhone during the day. Maybe I’ll put up with the iPhone interface to play some Civilization while I’m commuting to work, but I expect to come back home, sit down on the couch, pick up my iPad and continue the same game with a much better interface. So we’re going to see a trend towards more apps and games that store all their state in the server, and let you access it from any device.

The older demographic, deeper games, and server integration, combined with a higher-resolution screen is going to make people expect a more polished experience, and development costs are going to increase significantly. It’s definitely a new challenge in a market that’s ever changing, and whoever figures it out will have a good chance to have an early iPad hit in their hands.

I want to share the sales data for Flower Garden. Not just the raw data, but a bit of the story behind it, my thoughts, struggles, and why things happened the way they did.

The first thing that you’ll notice is that Flower Garden is a strange in-between app. It’s far from being very successful or being at the top of any chart, but at the same time it probably made more money than 99% of the apps on the App Store. It was also relelased on April 10th, so this represents 10 months of data, an age after which most apps are usually on drip support. So this should be an interesting new data point.

The Full Monty

I know that if I put it off, you’re just going to skip to the end to see the sales plot, so let’s get that out of the way. Here it is.

The vertical axis is daily profit in US $ (after Apple’s 30% cut). Flower Garden generated a bit over $21,500 over a period of 10 months. I would hardly consider that an entry-level salary, much less in California, but it’s enough for someone without a family or mortgage to (barely) make a living. I supplemented that with some teaching, writing, contracting and consulting, so overall I managed do fine and even save a bit of money last year, all while being totally indie and having full creative control over what I did every day. I’m not getting rich, but it’s not a bad life, really.

How many hours of work does Flower Garden represent? It’s really hard to say. It was 6 solid months of work from conception to release, but then there was the fuzzy time spent on marketing, updates, support, new features, etc. I would estimate it was a total of 8 months of full time work, which, at 50 hours per week, makes it 1600 hours. So that’s a depressing $13.44/hour. At least it’s over minimum wage! :-) On the positive side, Flower Garden should continue to sell in the foreseeable future, so that amount will go up a bit over time.

There’s clearly a story behind that graph. It’s not the usual exponential drop off you expect from most (unsuccessful apps) and shows how an aging app can pick up steam on its own after many months on the store, without ever being featured by Apple.

Launch

Let’s start from the beginning. Release day!

After six hard months of work, I submitted Flower Garden to Apple sometime at the beginning of April, and on April 10th I was surprised to see it had been approved. It caught me a bit off guard without my marketing campaign in place, but I announced it high and wide on this blog, Twitter, Facebook, and I even spammed all my friends with an email. The results are the area marked as (A): About $50-$60 in revenue per day (so about 25-30 sales). Not bad considering that was mostly my friends taking pity on me and people randomly seeing it on the new releases list, but it was far from an auspicious start.

I also contacted all the media sites I knew with a press release and promo codes to entice them to write a review. I was lucky that many reviews appeared over the next couple of weeks, but unfortunately they were all spread out, minimizing the PR effect. The biggest effect was when Flower Garden was simultaneously covered on TouchArcade and MacRumors. That’s what caused the big sales spike (B). From there, it was a standard exponential drop off, until, on the last day of the month, just three weeks after launch, revenue dropped below $100/day again. If that was all there was to it, Flower Garden was a big flop and I should start dusting off my resume.

Mother’s Day

I wasn’t ready to throw in the towel yet. I had a couple cards up my sleeve that I was hoping would change things around. After all, May 5th is Mother’s Day in the US. What better time to do some promotion and get Flower Garden noticed?

I decided to run a contest and give away $100 in real flowers to the winner at the same time I put Flower Garden on sale for $1.99 for the week of Mother’s Day. The result? The revenue dip you see in (A).

Mother’s day is probably the small, second spike in that period, but overall, that week was a loss. Lesson learned: Don’t make a sale unless your app is in a visible position (on a top chart somewhere). Flower Garden was nowhere to be seen, so the sale had no effect other than to cut profits by 33%.

I released a couple updates and did the trick updating the release date to get on the new releases list (which no longer works) and I got a couple minor spikes with (B) and (C). Subsequent updates later that summer had almost no effect anymore on sales. The trend was worryingly clear as profits dipped as low as $10/day in mid June (I have no idea what happened that day, but it was the lowest day ever for Flower Garden).

App Treasures

In early June we launched App Treasures. App Treasures is a label for indie iPhone game developers with top-quality games, and one of the main tools we’re leveraging is some cross-promotion for our games, both through the web site, and from an in-game view liking to each other’s games. Initially there was no measurable effect, but then Harbor Master was released and shot all the way to the #2 position on the US store and held its position on the top 50 for a while. The results is the area under (D). It definitely brought in some sales to Flower Garden and reversed the downward trend.

Unfortunately all good things come to an end, and referrals from Harbor Master dropped off and its slipped down the charts, and Flower Garden sales continued sinking.

Facebook and Lite

At this point I had to face reality. Was it time to give up on Flower Garden and move on to another project? I was ready to do that, but every day I would get several emails from users saying how much they loved Flower Garden, how much happiness it was bringing to their lives, etc. Some of the stories were really touching.

At the same time, every time I would show the game to someone, they usually really liked it. Not liked-it-because-I’m-there, but really, genuinely liked it. Why weren’t more people buying it then? Two problems: First, screenshots were not conveying how cool growing, animated flowers you could touch were, and second, most people didn’t even know Flower Garden existed. It had never been featured by Apple on the App Store, and the audience I was trying to reach didn’t read TouchArcade or other iPhone review sites.

It was at this point that I decided to give it one more try. My goal wasn’t adding more features as I had done with the updates so far, but to make Flower Garden more visible. I wanted more people to know that Flower Garden existed.

The first thing I did was to add Facebook integration. Not only could you send bouquets through email, but you were able to send them directly to your Facebook friends. The advantage of that approach from my point of view is that all your friends also saw the flowers so for every bouquet sent on Facebook, hopefully dozens or hundreds of people were being exposed to Flower Garden. The result on sales: Not much. Maybe it made the early part of July a little higher than it would have been otherwise, but no noticeable difference.

The second approach was to release a lite version of Flower Garden in early September. I was confident that Flower Garden was a good app, and I was hoping that once people had a chance to try the lite version, they would purchase the full version. Fortunately I was right and the effect on sales was very noticeable, pretty much doubling sales (E), but it never really took off in any significant way, and sales slowly declined over time.

Second Wind

You’d think that I would give up at this point, wouldn’t you? And I don’t say that with pride. I mean, it probably would have been smarter to quit a long time ago. But somehow, every time I was ready to move on , something else would come up that would entice me to try something else with Flower Garden.

This time it was in-app purchases (IAP). Apple had announced IAP back in June. They seemed like a very natural fit for Flower Garden, but given how few units Flower Garden had sold, I would have a very limited audience for IAP. A small percentage of a small number is a tiny number! :-( However, in late October Apple announced that IAP were finally allowed from free apps as well. That encouraged me to give Flower Garden one… last… try…

To be totally honest, I wasn’t expecting very much. Even including all the units of the Lite version out there, there just weren’t that many units. Especially not that many people using it on a daily basis (I’m sure a lot of the free ones were downloaded and quickly forgotten). But I thought it would be a good experience and if I only spent a week on it and made $1,000 I could call it even.

The result was totally unexpected. The Flower Shop opened on December 6th and revenue immediately shot up (A). On December 21st I released a new IAP called Seeds of Winter with 8 new winter-themed flowers, and people loved it and immediately purchased it. Christmas day came and went with somewhat of an increase in sales (C) but nothing really spectacular. Finally, to wrap up the year, there was a big spike on New Year’s Eve (D) (do people send flowers on New Year’s Eve? Really?).

Afterwards revenue flattened out, but at a much higher amount than before. Before IAP, daily revenue was about $50/day. Now it’s more around $180/day. That’s totally beyond any of my expectations!

But hang on, where is the revenue coming from? There are three possible sources: You can purchase Flower Garden, you can make IAP in the full version, and you can also make purchases in the free version. Here’s the breakdown:

It looks like sales for Flower Garden (blue) continue to be more or less the same, with a slight increase after Christmas. The IAP from the full version of Flower Garden (green) account for most of the extra revenue, especially at the beginning. But it’s very interesting that the purchases coming from Flower Garden Free (orange) are steadily increasing and, as of last week, they became almost as large as the ones from the full version.

That can be explained because more and more people are getting the free version and upgrading it instead of buying the full version (which is exactly what I was hoping for). What’s also really interesting is the downloads of Flower Garden Free.

Flower Garden Free was never a big player. It had the usual big initial spike, but then it settled down at around 100-200 downloads per day (which is very few considering there were 50-60 purchases per day of Flower Garden Full during that period). But, as soon as the in-app Flower Shop was released, downloads started climbing, and on Christmas day they went through the roof (relatively speaking). So it’s no surprise that IAP from Flower Garden Free picked up in these last few weeks.

The Future

I have no idea what the future will hold for Flower Garden. This week Apple selected Flower Garden and featured it on the App Store as a Staff Favorite worldwide (that period is not show in the sales graphs). I’m also already preparing a new update and some more IAP for Valentine’s Day, so I’m sure there will be more ups and downs in the near future. I’d certainly like to continue supporting Flower Garden for as long as it’s profitable.

I’ll follow up this post in a couple of months with the aftermath of the App Store feature and Valentine’s Day. Also, stay tuned for another post with more details of the IAP, what’s successful, purchase patterns, and more.

This is the first time Flower Garden has received any kind of “Apple love”, so it’s particularly exciting, especially considering that Flower Garden was released all the way back in April. I imagine the recent update, which included the Flower Shop with in-app purchases, must have caught someone’s eye.

The only downside is that the featuring might throw off the sales data I was collecting to show the effect on sales that in-app purchases and the holiday season had. But I’m not really complaining. That’s a very nice reason to have the data thrown off :-) Thank you Apple!

Purchase States

When you first create an in-app purchase in iTunes Connect, it is listed as “Pending Developer Approval”. This means that if you ask for info on that product id with a SKProductsRequest, you’ll get the info for the item only on development builds, not in distributions builds.

Once your in-app purchase item is ready, you need to upload a screenshot of it working in the app, and approve it yourself. At that point it enters the queue to be approved by Apple. Once an item has been approved by Apple (marked as Ready for Sale), it will appear both in development and distribution builds.

This behavior is very convenient because you can add in-app purchases normally for development, and not worry about them showing up for all your existing users until they’re done. Just make sure to keep around a distribution build of your app to test what the end user sees.

In addition to that, you can flag items as available for sale or not. That way you have the added flexibility of temporarily removing an item from sale, or making it available at a later time.

Approval Process

The first time you submit any in-app purchases, you’ll probably do it along with a binary update (since you need to code in support for displaying and allowing the purchases of items). You’ll have an option to mark the items to be approved along with the binary, so everything will become available on the App Store at the same time. In that case, the approval process is just like for a regular binary update (it seems to be averaging a week lately).

You can also submit in-app purchase items by themselves, without an app binary update. I did this for the Seeds of Winter pack in Flower Garden. Somehow, I was expecting a turnaround time of a day or two. After all, I figured they would look at the provided screenshot and approve it. Unfortunately, that wasn’t the case. In this particular situation, approval took almost a week, and I’m not sure it was because of the normal process, or because I emailed Apple asking what the procedure was to submit a product by itself (the product was approved within an hour of me getting a response from them saying they would look into it).

I was monitoring iTunes Connect pretty obsessively at the time it was approved (because it was right before my two-week break for the holidays) and I saw that the Seeds of Winter pack went from “Waiting for Review” to “In Review” to “Approved for Sale” in a matter of two minutes. That was one quick check! (I’m not complaining though).

What’s even more interesting is that I didn’t know that an item wouldn’t appear on a distribution build unless it was approved by Apple, so I had added an extra layer on the shop catalog file on my server that allowed me to prevent an item from showing up on the Flower Shop until I turned it on myself. And since that check wasn’t turned on, it means that Apple approved the in-app purchase by looking at the provided screenshot, without running it in the app.

This shouldn’t be too surprising. After all, I’m not even sure what the point is for in-app purchase approvals. For content that comes from the server, I can change it at any time, so the only thing they can approve is the name and description provided in iTunes Connect. I suppose the screenshot is fine for that, but I would also expect really speedy approval times. After all, not having to wait for lengthy approval processes is one of the big draws for in-app purchases.

I did learn one important lesson from going through this process. Next time I submit a binary prepared for more in-app purchases, I’m going to create stand-ins for all possible in-app purchases I’m considering and submit them for approval at the same time as the app binary, but marked as not ready for sale. That way they will all be approved at once, and I can take my time creating the final version for those items and making them available instantly whenever I want.

Purchasing Items

The same way that non-Apple approved items only show up in development builds, the only accounts that can purchase any items on development builds are test accounts using the sandbox environment. These are accounts you create on iTunes Connect and allow you to purchase items in your programs without spending real money (otherwise I’d be in trouble considering how many times I ended up purchasing items during the development of the Flower Shop!). Conversely, distribution builds only work with non-test accounts and non-sandbox environment.

One thing that threw me off was that I started getting support requests from people who had trouble logging in with their account to make in-app purchases. They claimed they were being asked about this “sandbox environment”. That threw me in a panic for a second, because I thought that everybody was somehow accessing the sandbox environment and nobody could make any purchases (because they had full iTunes accounts). It turns out, that’s a problem that happens with jailbroken phones with a particular app installed. It’s nicely documented here so I’ve been pointing people in that direction.

Finally, I believe there’s no provision in iTunes Connect to deal with different binary versions, but that’s something that’s very important to handle. If I release a new binary with some new feature built into the app, and an in-app purchase to unlock it, I don’t want people with an earlier version purchasing it and getting mad that it’s not working. Ideally this should be an option in iTunes Connect, but in the meanwhile, I build a version check into the shop catalog itself. That way only apps with that version or higher can even display a particular item. Or I can even take it a step further and display the item but notify the user that they need to update the app before the purchase it.

Even so, I decided to take a few extra steps that at least will make things a bit more difficult to crack and keep things more secure. I could have gone way beyond this, but I don’t think that would have been worth my time.

Verify the purchase

Right now, you can download programs that will automatically crack an app by extracting its data and resigning it so it works on any jailbroken phone. There’s no doubt that even if you implement in-app purchases just like I described in earlier posts, crackers will have to analyze the code and do some steps by hand, so that might be enough to slow down the pace of cracked apps. Even so, an experienced cracker won’t take long to crack your in-app purchases unless you take some extra steps. All they have to do is find the function that you call in response to getting the go ahead from the App Store and they’ll gain access to all content.

The first thing you should do is to verify that the purchase happened correctly. To do that, once you get the notification in your app that the payment was complete, you send the receipt to your server, and have your server verify it in turn with the App Store. Since crackers don’t have access to your server (if they do you’re in more trouble than a few cracked apps), that step is secure. If your app was cracked and the user didn’t pay for the purchase, the App Store will fail the verification of the receipt and you don’t have to deliver the content.

How do you check that the receipt is valid? First of all, you need to send the receipt of the purchase to your server. I send it along with some other info, like the user’s UDID, what product was purchased, etc so I can keep general usage statistics. The relevant bits of code are the following:

NSString* receiptString = [self createEncodedString:transaction.transactionReceipt];
//...
[postBody appendData:[[NSString stringWithFormat:@"\r\n--%@\r\n", boundary] dataUsingEncoding:NSUTF8StringEncoding]];
[postBody appendData:[@"Content-Disposition: form-data; name=\"receipt\"\r\n\r\n" dataUsingEncoding:NSUTF8StringEncoding]];
[postBody appendData:[receiptString dataUsingEncoding:NSUTF8StringEncoding]];
//...
[req setHTTPBody:postBody];

The createEncodedString function takes some arbitrary data and creates a base64 encoding. That’s one of the parts that is not particularly well documented in the SDK documentation.

- (NSString*) createEncodedString:(NSData*)data
{
    static char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";

    const int size = ((data.length + 2)/3)*4;
    uint8_t output[size];

    const uint8_t* input = (const uint8_t*)[data bytes];
    for (int i = 0; i < data.length; i += 3)
    {
        int value = 0;
        for (int j = i; j < (i + 3); j++)
        {
            value <<= 8;
            if (j < data.length)
                value |= (0xFF & input[j]);
        }

        const int index = (i / 3) * 4;
        output[index + 0] =  table[(value >> 18) & 0x3F];
        output[index + 1] =  table[(value >> 12) & 0x3F];
        output[index + 2] = (i + 1) < data.length ? table[(value >> 6)  & 0x3F] : '=';
        output[index + 3] = (i + 2) < data.length ? table[(value >> 0)  & 0x3F] : '=';
    }    

    return  [[NSString alloc] initWithBytes:output length:size encoding:NSASCIIStringEncoding];
}

That just sends the receipt to my server. Once the server receives that request, it needs to verify the data with the App Store. The exact format of the App Store request is, again, not well documented. It turns out it needs to be sent as anonymous data in a POST request. After some trial and error, this is the php code I’m using in my server to verify the receipt:

function isReceiptValid($purchase)
{
	$data = array ('receipt-data' => $purchase->receipt );
	$encodedData = json_encode($data);

	$url = "https://buy.itunes.apple.com/verifyReceipt";

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, $url);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
	curl_setopt($ch, CURLOPT_POST, true);
	curl_setopt($ch, CURLOPT_POSTFIELDS, $encodedData);
	$encodedResponse = curl_exec($ch);
	curl_close($ch);

	if ($encodedResponse == false)
	{
		logError($purchase, "Payment could not be verified (no response data).");
		return false;
	}

	$response = json_decode($encodedResponse);
	if ($response->{'status'} != 0)
	{
		logError($purchase, "Payment could not be verified (status != 0).");
		return false;
	}

	$purchase->storeReceipt = $response->{'receipt'};
	return true;
}

If things check out, the server returns a valid code, and you can go ahead and make the content available to the user. Otherwise, it means the user is trying to pass up a fake purchase as valid and you can deal with it any way you want.

Get content from the server

Of course, if the content is already embedded in the app itself, the cracker can bypass both the App Store purchase and the receipt verification through your server, and just access the content directly. If you want a better chance of not being cracked, have your server deliver the content. That way, if the receipt doesn’t check out, you never transfer the content.

In the case of Flower Garden, all seed packets are downloaded from the server, but the other purchases (extra pots, extra fertilizer) are just changing a few internal variables, so they would be a lot easier to crack.

One of the easiest ways that crackers can get around this verification is by buying the content once and saving the receipt that comes with it. Then, cracked versions can pass that receipt to your server, they’ll be validated as correctly, and they’ll be able to download the content. So, as an added precaution, you might want to keep track how many times a certain purchase is re-downloaded, especially from different UDIDs. I can’t imagine a legitimate reason for a user to download the same purchase more than 20-30 times from different devices, so denying the purchase at that point in the server seems justified.

Save those receipts

The last step I to make cracking more difficult was to save the receipt itself to disk along with the content that was downloaded. Then, periodically, the game can pick one of those receipts, and verify with the server that it’s still valid. If it’s ever reported as an invalid receipt, the game deletes the content for that purchase. This is not as draconian as it sounds, because even if it’s ever triggered for a legitimate user (and I have no idea how that could be other than data corruption), they can always re-purchase it again for free (and they would want to do that to fix their data corruption anyway).

To be able to delete things easily and cleanly, I keep each downloaded in-app purchase on a separate directory. So it’s very easy to delete the whole directory without having to access files everywhere. The hardest thing is making sure the game deals with the missing data and that nothing is referencing it. I’ll touch on that on a future part of this article.

Keeping purchases in separate directories also makes it easier to reset all purchases. That’s something I didn’t originally include in Flower Garden, but I should have. Sometimes, data can get corrupted or maybe a bug occurs because of some combination of purchases (hopefully not, but you never know!). Allowing the user to reset the purchases and re-download them allows them to fix those problems without having to reinstall the app and lose their progress.

[1] I know from first hand experience that one dedicated teenager with all the time in his hands can spend inordinate amounts of time bypassing the most elaborate anti-piracy schemes. The harder it is, the more of a challenge it becomes, and the more fun it is. To this day, I still remember the thrill of finally bypassing the copy protection of 1943 on the Amstrad CPC after two days of non-stop hacking, which included several loops XORing all the available memory (including the currently executing code), and messages from the developers taunting me!

Purchasing a product

The store is fully populated, the items are displayed and, if all goes well, the user presses the buy button. What now?

At this point I check that in-app purchases are enabled and if they aren’t, I put up a message box. Apple says you can also do this earlier, but I figured I’d rather show users what’s available and entice them to buy it. By the time they get that message, they’ll be much more likely to enable them and continue the purchase than if they never saw the store in the first place.

Actually, before I even do that check, I see if the item is currently offered for free. If it is, the code takes an alternative path that doesn’t involve the App Store because apparently you can’t set an in-app purchase to free. Really! Why not? It’s yet something else we need to implement ourselves. Please, Apple, fix that. In the case of free purchases (like the Bonus Seeds included in the full version of Flower Garden) I contact my server directly and download everything from there. If you’re thinking that a hacker can just set the free flag to true and have access to all your content, it’s not that easy, because the server checks that the product is really marked as free when it’s contacted, and if it isn’t, it declines the transaction. So they have to work a bit harder than that to crack things (more on that next time).

But if the product is not marked as free and in-app purchases are enabled, then you can add the payment to the StoreKit payment queue which is, of course, another asynchronous call. So now we’re back to having to make a decision of what we want the user to do after they attempt to purchase something. Does someone really want to move away from the screen before they complete the purchase? I don’t, so I set another blocking activity screen explaining what’s going on with an activity indicator.

if ([SKPaymentQueue canMakePayments])
{
    SKPayment* payment = [SKPayment paymentWithProductIdentifier:m_product.m_id];
    SKPaymentQueue* queue = [SKPaymentQueue defaultQueue];
    [queue addPayment:payment];
    [m_progressViewController setText:@"Accessing store" completed:NO];
    [m_progressViewController display:YES animated:YES];
}

To be able to test the actual purchase, you need to create a test account in iTunes Connect. It’s slightly annoying that you need to explicitly log out from the Settings | Store screen and you can’t do that from the app itself, but it’s not nearly as much of a big deal as not being able to test purchases from the simulator at all. That’s a big fail as far as I’m concerned, and I can’t imagine a single reason why that was done that way (other than lack of time/manpower on Apple’s side).

Completing the purchase

You think we might be done by now, but not. Far from it. We’re just getting warmed up.

Now that the payment has entered the queue, you’re going to get a callback notification every time its status changes. That means you’ll get one right away because it was just added to the queue, another time when the payment is approved by the App Store, or when it fails, or if it’s detected that it was already purchased and this a re-purchase.

While that’s happening, the StoreKit code will bring up those ugly message boxes asking the user if they’re really sure they want to purchase the item for that price, and possibly ask them for their login info. It’s funny that the first time I implemented this part, I thought that it was up to me to put those message boxes up, so they were showing up twice. You don’t have to do anything for that, whether you want to or not. What’s worse, is that each time one of those message boxes comes up, your app gets a message putting it on hold, which usually means the sound is temporarily muted. Looks very unprofessional and I’m surprised Apple forces that on us while they leave everything else so open ended and requiring so much work.

Once the purchase is marked as complete, you can obtain the content for that purchase and make it available in your app. After that step is complete, you can remove the payment from the queue and the transaction is considered complete. In the case of Flower Garden, most purchases involve accessing my server and downloading some data from there for new seeds. Some purchases don’t require any downloading though, and all they do is twiddle a few bits internally.

It’s important to understand the payment queue well. First of all, it’s persistent, so once a purchase payment has been added to it, it will be there next time the application starts if it was never removed. It was designed that way to make sure an application can deliver on the product that was purchased even if the app is stopped, crashes, or is interrupted in any way. So initially, a payment is added to the queue meaning that the user has initiated the purchase transaction. At that point, the transaction can fail for multiple reasons: User cancels payment during one of the prompts, wrong user ID, the servers are down, the product was removed from the store, etc. Assuming the purchase is successful, the user account will be charged the cost of the product and the payment will be marked as successful. It’s at this time that you have to deliver the goods. Only once you’ve successfully done that you can go ahead and remove the payment from the queue. Otherwise, next time that the app starts, your code should detect a payment there and continue processing it. You really never want to get in a situation that the user pays for something and it’s never delivered to them.

I’m happy with how the StoreKit API will keep track of past purchases, and if a user tries to buy the same item again, they’ll be given the option to redownload it for free. It’s a great relief not to have to keep track of that ourselves. It will also cut down on customer support emails a huge amount because users can always redownload something if they had to uninstall their app, or somehow, in spite of all our precautions, they bought something but it was never updated in their app. In that case a quick re-download should fix it (just make sure your code is pretty stateless and can deal with re-downloading the same content multiple times).

It gets a bit trickier though. It turns out the payment queue can have more than one payment in it. Why is that? First of all, because the buy process wasn’t blocking the way Apple designed it, a hyperactive user could initiate multiple purchases at once. The other, more realistic situation is that the user initiates a purchase, it’s verified with the App Store, but before you can complete the download, your application is shut down. The Store Kit queue will be restored next time the application starts, but at that point the user could go to the store again and start another purchase.

In any case, you really need to deal with that situation, otherwise you risk losing purchases and angering users (and you really don’t want to rely on users re-downloading something for free if you can avoid it). This is trickier than it sounds when you’re dealing with downloads from your own server because it might involve multiple downloads, multiple files, etc. So in my case, whenever I get an update of status in the SKPaymentQueue, I add it to my own queue. Then I can process that queue sequentially, one purchase at the time.

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
    for (SKPaymentTransaction* transaction in transactions)
        [m_transactionQueue addObject:transaction];

    [self processNextTransaction];
}

- (void)processNextTransaction
{
    if (m_processingTransaction)
        return;

    while (m_transactionQueue.count > 0)
    {
        SKPaymentTransaction* transaction = [m_transactionQueue objectAtIndex:0];
        [m_transactionQueue removeObjectAtIndex:0];

        switch (transaction.transactionState)
        {
        case SKPaymentTransactionStatePurchased:
            m_processingTransaction = true;
            [self completeTransaction:transaction];
            return;
        case SKPaymentTransactionStateFailed:
            m_processingTransaction = true;
            [self failedTransaction:transaction];
            return;
        case SKPaymentTransactionStateRestored:
            m_processingTransaction = true;
            [self restoreTransaction:transaction];
            return;
        default: break;
        }
    }
}

Whenever a transaction is complete, you can flag it as finished and it will be completely removed from the payment queue: [[SKPaymentQueue defaultQueue] finishTransaction:info.m_transaction];

A whole  step I skipped for now is verifying the purchase with your server. I’ll cover that in the next part of this post when I talk about anti-piracy measures.

The situation improved as soon as Apple announced the availability of in-app purchases in free apps. Flower Garden Free had been out for a few weeks at that point, so that effectively doubled the potential audience.

The final consideration that convinced me to plunge ahead was the realization that while only a small percentage of users would buy extra content, a fraction of those would make multiple purchases, and some people would probably buy every available item. So maybe it would be worthwhile after all.

Having said that, I gave myself one week to completely implement in-app purchases in Flower Garden. That included everything, from implementing the actual purchasing through StoreKit, to server code, and, of course, creating the additional content itself.

For those of you familiar with Flower Garden, the new content I created specifically for in-app purchases was a flower shop offering:

• An extra garden screen with 12 pots
• Liquid plant fertilizer that speeds up plant growth. This is a consumable item with a fixed number of doses and can be repurchased after it’s used up.

Additionally, the flower shop in the free version of Flower Garden had these items that would bring it functionality up to par with the full version of Flower Garden:

• Extra pots in the main garden
• Extra common seeds
• Set of bonus seeds

My initial estimate of one week turned out to be very optimistic, and it ended up taking closer to two and a half weeks. Most of it was spent creating the new content and integrating it smoothly in the game.

In this post and the next few ones, I’ll share my experiences with in-app purchases. From implementation details, tips and tricks, how it might help with piracy, mistakes I made along the way, and even how many sales in-app purchases generated.

Displaying Store Items

Apple did a good job documenting the overview of how to implement in-app purchases. Some of the details are missing, but they’re small enough that I was able to fill in the blanks pretty easily and get things working in a couple of days.

However, I really think the process should have been implemented very differently in Apple’s part. The sequence of actions that needs to be done feels overly complicated. It may be great if someone is trying to do a very customized and integrated store with all sorts of crazy features, but really, in 99% of the cases, developers just want to sell something and be done with it. Forcing us to go through all those steps seems overkill. A simplified higher-level set of helper functions would be a welcome addition to the SDK. For suggestions on how to go about it, look at the SDK for game consoles. They got that part right (or at least much more right than the iPhone SDK).

Getting the catalog

The first step towards implementing in-app purchases, is to get a list of all the products you want to sell in your store. It’s a good idea to keep this list off your app and on a web server instead, that way you can add, remove, or edit any products without going through a full app update. That in itself makes in-app purchases very attractive, doesn’t it? You can have a look at the master Flower Garden shop catalog.

Getting product info

Step two is to go through each of those products, and get the official product information from the App Store. That involves creating a set with the product ids you want to query, and sending a request.

The code in Flower Garden to query for product ids looks like this:

NSArray* products = m_appData->m_shopCatalog.m_products;
NSMutableSet* productIds = [[NSMutableSet alloc] initWithCapacity:32];
for (int i=0; i<[products count]; ++i)
{
    ShopProduct* product = [products objectAtIndex:i];
    if (!product.m_alreadyIncluded)
        [productIds addObject:product.m_id];
}

SKProductsRequest* request = [[SKProductsRequest alloc] initWithProductIdentifiers:productIds];
request.delegate = self;
#ifdef WORK_WITHOUT_APP_STORE
[self productsRequest:request didReceiveResponse:nil];
#else
[request start];
#endif
[productIds release];

There are a couple interesting things in that code. First of all, notice that before we ask for the product info, we check if the product is already included in the app. That’s because some items, such as the extra pots or the common seeds, already come as part of Flower Garden Full. But at the same time, I wanted to show them in the store and mark them as purchased. So I need to have a parallel path for those items that doesn’t go through the App Store. More on that in a future post.

The other interesting bit is the #ifdef. This one really sucks, so get ready: The simulator can’t make any StoreKit calls. It fails with a nice message box explaining why, but it fails nonetheless. To put it in highly technical terms: That blows! Seriously, that means you’re stuck developing on the device. Turnaround times are about 20-30 seconds, and debugging on the device directly is no fun at all. I’m convinced that alone was part of the reason it took me longer than my initial estimate. So that #ifdef was my attempt to try to get as much done on the simulator as possible. At least I was able to display the products on the flower shop. The actual buying had to be done on the device though. No way around it as far as I know. Why, oh, why, doesn’t Apple let us add a test account on the simulator? Maybe a feature for SDK 4.0?

Displaying the products

Some time after sending the request for info on the products, and assuming we have a valid internet connection and that the App Store is in a good mood (to their credit, Apple’s servers have been very reliable), we’ll get a response. The response will include more information for each of the products we requested, including localized name, description, and price. This is all information taken from the in-app purchases you created in iTunes Connect. And yes, that means that you need to keep multiple sets of data in sync: Your shop catalog and the in-app purchases in iTunes Connect.

Notice that because everything we’ve done so far has been asynchronous (and asynchronous is the name of the game for a lot of the remaining steps as well) it introduces a lot of complexity. What do we do during that time? Do we let the user wander around to other parts of the program? Do we block and make the UI modal? I went with the latter approach for simplicity both coding and in the UI for the user.

At this point you can display them in your shop. In my case I ended up using a very similar interface to the App Store on the iPhone. I figured users are already familiar with that kind of interface, so might as well build on top of that. So that meant the flower shop is a table showing all available products. Clicking on a cell brings up a view with details and a description of each product.

To make my life easier, the only elements that are hardwired on the product page are the icon, the title, and the price/purchase button. The actual description and screenshots is just an embedded web view and part of the product description in the catalog has the correct URL for each project. You can even access some of them directly here.

So far all this has done for us is let us populate a list of products that are available to be sold. Next entry will cover the details of the actual transaction and a few things to watch out for.

The class is aimed at iPhone developers without previous OpenGL or 3D graphics experience. As part of the class, we’ll create both 2D and 3D OpenGL applications, and we’ll cover a broad range of topics, start with the basics of setting up OpenGL and rendering triangles on screen, to multitexturing and point sprites in the last day. This is definitely a hands-on class, so you’ll need to bring your laptop and be ready to do some coding.

Check out the Mobile Orchard page for discounts and registration details. Feel free to contact me if you have any questions.

Hope to see you there!

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!

Gameplay footage of Space in Stereo

Session description:

The iPhone has a very powerful engine under that shiny hood when it comes to floating-point computations. This is something that surprises a lot of programmers because by default, things can slow down a lot whenever any floating point numbers are involved. This session will explain the secrets to unlocking maximum performance for floating point calculations, from the mysteries of Thumb mode, to harnessing the full power of the forgotten vector floating point unit. Stay away from this session if he thought of reading or even (gasp!) writing assembly code scares you.

• Presentation slides (pdf format)
• Sample project

Thanks for everyone who attended the session and for the great feedback so far. If you’re going to be in China next month, I’ll be giving a very similar talk at GDC China.

Session description:

This session will describe the iPhone performance optimization lessons learned through many hours of tuning. We’ll start with an overview of the performance analysis tools available on the iPhone SDK to help you narrow down your performance bottlenecks. Then we’ll cover the best way to set up your render loops, rendering best practices, how to deal with the limited memory, or even how to drop down to assembly to use the forgotten vector floating point unit.

Presentation slides (pdf format)

#defining The Problem

The first approach that came to mind was to use #ifdefs. Hopefully, if I did things well, it wouldn’t require too many of them. As soon as I gave it some more thinking, it was clear this was a pretty flawed approach.

I like to be able to create a build with zero human interaction: Press a button, wait, and the build is ready. I don’t want to have to do any manual (read, error-prone) steps. So I couldn’t just have an #ifdef that I turned on and off depending on whether I was building the lite version or the full one. I can get around that by creating a new configuration in XCode, except that it wouldn’t be one, it would be one for every existing configuration I already have: Debug, Release, Distribution Ad Hoc, and Distribution App Store. So this would make a total of 8 configurations. That’s rather ugly!

In case the explosion of configurations wasn’t ugly enough, there was one other, even bigger problem: An #ifdef wouldn’t allow me to change the assets included in each version of Flower Garden, and, most importantly, I couldn’t change the Info.plist file to have a different bundle id (although maybe I could change the Info.plist for each of the new configurations and point it to the new one).

Not an attractive option. So how else can we do it?

New XCode Project

The idea is straightforward: Make a copy of the existing project for the full version of the game, and change it in any way you want: Remove resources, add new ones, change Info.plist, etc. You can still share common source files and define a preprocessor macro LITE in the new project to #ifdef parts of the code.

This approach sounds more promising, until you realize that changes made to one project don’t carry over to the other one. So if you’re done developing the full version, and you create the lite version at the very end, maybe that won’t be a problem (although, how can you be sure you’re done?) And making changes to two separate projects is never fun.

You could improve things a bit by starting out the lite version as a branch in source control. That way, changes made to one of the branches can (hopefully) be merged back into the main line or another branch (have fun merging xcodeproj files). I think it’s because I’ve had the displeasure of working in projects that went totally overboard branching, that just the word branch makes me recoil in disgust. Yes, this method might work, but it seemed cumbersome and error prone.

Any other solutions?

Stay On Target

It turns out I kept thinking in terms of a solution I could have implemented in Visual Studio (that’s what I get for spending so many years working with it). But fortunately we’re not in Windows-land anymore. This is XCode, and XCode totally rocks.

XCode’s build system, once you wrap your head around it, is much more flexible and natural than Visual Studio’s. It’s much more like a make file (and I say that in a good way–I do like make files!). You have files, and then you have targets. And there’s nothing that says a file can’t be in multiple targets (and the file only appears in the project once). Once you have multiple target, whenever you add a new file you have the option to add it to both targets the same time if you want. Perfect!

My Flower Garden project contains about 15 targets: 7 “engine” libraries, 7 test executables for each of the libraries, and one main executable target for the game itself. So the (now obvious) solution, was to simply create a new target for the lite version, in that same project, with the same files. It turns out this solution had all the advantages of the previous approaches with none of the drawbacks.

Lite Target Details

Once I landed on the target idea, it really was quite straightforward to create the Lite version by following a few, simple steps:

• Make a duplicate of the target for the full version. Just right click on the full target, and select duplicate.
• Rename new target to something else (Flower Garden Lite–I’m highly imaginative when it comes to naming things like this! :-)
• Make a duplicate of your Info.plist (InfoLite.plist)
• Change the info.plist file setting for the lite target to point to InfoLite.plist
• Edit InfoLite.plist to have a different bundle identifier and maybe a different bundle display name (the name that’s going to show up under the icon on the iPhone).
• Add a compiler define to the lite target called LITE or something like that. That way you can #ifdef a few parts of the code depending on the version you’re compiling.

And that’s almost it. There’s one more trick that made my life a lot easier. It turns out that you will definitely want to change not just some code, but some assets depending on which version you’re using. So maybe you’ll have a Wall.png texture in the full version, but you’ll want to have a different version of that texture in the Lite version. I started out creating a new file called WallLite.png, but then it quickly cascaded into a bunch of code changes loading either Wall.png or WallLite.png depending on the version and it was ugly and time consuming.

A much better approach is to rely on the resource copy step of XCode. By default, XCode will grab the resources in your project and copy them all in the same folder, flattening the hierarchy completely. This can be a pain if you have resources with the same name organized in different folders because they will clash. But here we can use it to our advantage to supply different versions of the resource for the full and lite versions.

Just create a Lite directory and put any variations of your resources there. Then, in the Resources Copy step of the target, remove the resources you’re replacing and add the ones from the Lite directory. Whenever you build, XCode will put those new resources in the same place where the full resources were and your code won’t have to change one bit. This trick works even with xib files, which is great because I had to modify one of them to reduce the number of pots in the garden screen.

Once you have that set up, the rest is just a matter of deciding what functionality goes in the lite version and how it is presented. It can be as simple or as complex as you want.

In the case of Flower Garden, it was very straightforward. I limited the number of pots to two, and the number of different seeds to three. So I just had to change a few resources and add a couple of #ifdefs with the number of total pots and seeds. I also removed the resources that weren’t used in the lite version (the seed data for all the unavailable seeds for example).

Flower Garden lite was finally approved and it has been available on the App Store for a few days. So far it has been downloaded several thousand times, it has been very well received, and has definitely bumped up the sales of the full version. Definitely a few hours well spent!

[1] The lite version took a couple of hours to create and a month to approve by Apple.

[2] It was something I wanted to have created from the beginning, but my hands were tied because email bouquets were being sent through my server and I had a maximum number of emails I was allowed to send per day because of spam limits. Fortunately, as soon as the 3.0 OS was released, apps were able to use in-app email and that restriction went away.

There’s a darker side to Apple’s randomness. Something developers have been complaining for quite a while and it’s just getting worse: The approval process.

This is nothing new though. For a while developers have been reporting random rejections by Apple. Some of them extremely unfair and illogical.

A few months ago, if you got hit with one of those random rejects, it was annoying, but it was bearable. Usually a resubmit would get approved in under a week, so it was possible to fix whatever random thing Apple flagged down (or show them that it wasn’t an issue), and resubmit without wasting too much time.

Now things are different. Supposedly 95% of apps are approved (or rejected) under 14 days (although my informal and biased survey shows very different percentages). A mistake from Apple rejecting an app doesn’t cost you a week anymore, but perhaps as much as an extra 3-4 weeks! That’s a big deal for a company that’s trying to time the release of a product.

So far, I had been one of the lucky developers and I never got a rejection from Apple with Flower Garden. Actually, updates were usually approved withing 7 days to the hour (very suspicious, isn’t it?). But my luck ran out and I joined the group of developers hit hard by random and unfair updates.

Two days ago, Flower Garden 1.7, which had been in review for 24 days was rejected with the following explanation from Apple:

Dear Noel,

Thank you for submitting Flower Garden to the App Store. We’ve reviewed Flower Garden and determined that we cannot post this version of your iPhone application to the App Store because your application contains pricing information in the application, located in the “More Games” page. Providing specific pricing information in this location may lead to user confusion because of pricing differences in countries. It would be appropriate to remove pricing information from your application.

Once these modifications have been made please upload a new binary using iTunes Connect

Regards,

iPhone Developer Program

I was completely floored when I read that email. So apparently displaying a web page with prices for other apps is not allowed unless you localize that based on the language settings of the iPhone. How many apps are doing that? I doubt many (any?) are doing it. I can certainly bring up piles and piles of other games that are showing non-localized prices. But precedence is clearly not an argument with Apple. Even previous versions of Flower Garden had that exact same view with prices and it wasn’t a problem! Random reviewer strikes again.

But wait, there’s more. The prices are shown on a web page fed through my server. I made that change in 30 seconds and emailed them back, hoping they could simply re-test that functionality and approve it on the spot. No, that would be too easy! I had to resubmit a new binary and start the approval process again! I just gave them the change to cut back their work to a fraction of the time (supposedly they had tested other things that they’ll have to re-test because they have no way of knowing I didn’t change/update anything else). Sigh! I resubmitted it and I’m hoping for a quick approval, but somehow I’m ready for another 24-day wait.

So this morning I was excited to receive another email from Apple, I open it and…

Hello Noel,

Flower Garden Lite cannot be posted because it is a feature-limited version. Free or “Lite” versions are acceptable, however the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version.

Users can view unlockable seeds on the “Seeds” tab but cannot access them in the Lite version of the application. Please refer to the attached screenshot for an example.

Please upload a new binary and correct metadata using iTunes Connect .

Regards,

iPhone Developer Program

and they attached the following screenshot:

Users can be unlockable seeds but can’t unlock them? If you follow the included tutorial (2 messages) you unlock the first one. Another message tells them that growing the second seed unlocks the last one. Did they read that, or did they see a locked seed and had a knee-jerk reaction?

I replied to their email right away and explained how to unlock them. I’m afraid I’ll get an email back tomorrow asking me to resubmit and throwing Flower Garden Lite at the back of the queue. I hope not, but I’m prepared for the worst.

It might just be slightly annoying for hobbyist developers, but all of this is making the App Store very difficult to build a reliable, sustainable business around it. The lack of visibility, random approval process, unpredictability, and lack of direct contact make it impossible to have a reliable process or combine release dates with other events such as PR or marketing campaigns. At this point, I would even consider a “professional” iPhone developer account that costs $1K per year and gives you a direct contact in Apple and better visibility and predictability with the approval process. Otherwise, if things continue this way, I’m afraid that professional developers will only put up with this for so long and are soon going to consider the iPhone as a secondary platform and they’ll move on to other pastures like the PSP Mini or new opportunities that come up.

iSimulate consists of two different parts: The iPhone app, which you need to purchase through the App Store, and a static library that you link with your program. Once your app is using the library, launching the iSimulate iPhone app lets you connect your device to your app and forward accelerometer, touch, and GPS events. In other words, most of the things the simulator doesn’t do natively.

iSimulate definitely passed my picky installation requirements with flying colors. I was afraid the installation would hook up with existing framework libraries, add new configurations, and in general mess up my system. Fortunately, hooking up the iSimulate library couldn’t be easier: Copy the provided .a library anywhere you want, link with it in your app (don’t forget the -ObjC linker flag), make sure you’re using the Core framework, and you’re good to go. That simple. That’s how I want external libraries to work.

You don’t even need to initialize anything. Just launch your app in the simulator, launch iSimulate on the iPhone and it detects your program running and lets you connect to it. The iPhone app itself even looks very pretty and polished. The overall package is definitely very professional-looking.

From there, any touch on the device is forwarded to the simulator. So you can finally do off-center multi touches, or two touches that happen at different times, or even 5-touch events (the max the iPhone support). The other big one is being able to tilt or shake your device and see the game react correctly on the simulator, which is would have been very handy when writing the accelerometer code to move flowers around in Flower Garden, but would almost be necessary when you’re making heavy use of accelerometer input for games like Sky Burger. Finally, it also claims to give you location information, but I didn’t have an app I could easily test it with.

Flowers affected by gravity on the simulator

Another situation where iSimulate is a life savior is when trying to capture a video of your game. If you rely on multi touch or accelerometer features, then your only options are to either hack in something yourself, or dig out a physical video camera and record it the old-fashioned way (which is surprisingly time consuming and creates less-than-ideal results). With iSimulate you can still use a desktop video capture software on the simulator and create a top-quality in a fraction of the time.

Not everything is perfect though. I thought the forwarding of touch events would be incredibly useful, until I realize I have no idea what I’m about to tap because the program is running on the simulator, not on the device. So I’m just making a guess about where my finger is going to land. It’s not even like a mouse cursor that you see where it’s going and then you click. You’re literally tapping blind hoping you touch what you wanted. That works with a static UI, but if you have moving elements you need to touch, you’re totally out of luck. I wonder if they could extend iSimulate to capture the image from the simulator and forward it to the iPhone. Even if they only refreshed the image a few times per second, that would be enough to make touch input a lot more friendly.

There’s another big problem with touch input though. From their docs page, iSimulate works great with OpenGL apps, but doesn’t work with the following UIKit controls: Keyboard, UIScrollView (including MKMapView), UIPickerView and UITableView. Wow! Apart from the keyboard one (no big deal, we have a real keyboard attached) the other ones are pretty major. I’m sure they have a good reason why, but I can’t imagine what that might be from my knowledge of how the touch even system works (anybody from Vimov care to comment on that?). Heck, I’d even be willing to add some extra code to my app to hook directly into iSimulate input events if it means it would work with those classes. Apart from that, I found one case in Flower Garden where iSimulate failed: Touching the bouquet tag to bring up the editing mode. It’s weird, it would let me touch-drag it to move it, but it wouldn’t go into editing mode.

The accelerometer input worked flawlessly, but here iSimulate has some competition from Accelerometer Simulator, an open-source app plus library to forward accelerometer data from the device to the app. It’s not nearly as slick as iSimulate, but it’s free, so that migth be a more attractive solution for some people.

Overall, is iSimulate worth the $32 price tag (it’s $15.99 at the moment)? I would say yes if you’re developing OpenGL iPhone games with heavy use of multi touch and accelerometer input and you’re planning on making money from them. In that case, you’re better off spending an hour of your time polishing the game (or taking a break from programming) and buying iSimulate. However, if you’re using UIKit objects or you just need accelerometer input, then you might be better off just using Accelerometer Simulator. If Vimov can fix the UIKit input and display the output of the simulator on the device, iSimulate would become an indispensable tool in every programmer’s toolbox.

Obviously I’m biased when I say the class is going to be awesome (which it is), but I can also say with total honesty that 360iDev is an incredible conference. It’s very different from WWDC, but that’s what makes it so great: It has top-quality content and speakers, but it’s small and intimate, so you get to meet and hang out with all the other speakers and participants. It was at the first 360iDev conference back in March that I met Keith and Owen (among many other cool developers) in person for the first time and that’s how App Treasures was born.

So if you’re on the fence, I hope you give it a try. See you in Denver!

By default, the UIWebView will try to open the App Store link itself, which results in an error. What we want to do instead is intercept the request and launch it directly with an NSURLConnection so the call can be redirected to the iPhone App Store app. The best place to implement this is in the -[UIWebViewDelegate webView:shouldStartLoadWithRequest:navigationType:] method:

- (BOOL)webView:(UIWebView*)webView shouldStartLoadWithRequest:(NSURLRequest*)request navigationType:(UIWebViewNavigationType)navigationType
{
    if ([[[request URL] host] isEqualToString:@"phobos.apple.com"])
    {
        NSURLConnection* conn = [[NSURLConnection alloc] initWithRequest:[NSURLRequest requestWithURL:[request URL]] delegate:self startImmediately:YES];
        [conn release];
        return NO;
    }
    return YES;
}

While we’re in the topic of links, I also recently added some LinkShare links to my apps. The 5% kickback for each purchase is nice, but the tracking capabilities it gives you is the real reason I wanted to use it. The way LinkShare works is by providing a custom URL that contains your referral ID to allow LinkShare to track the transaction. Unfortunately, unlike the Amazon referral program for example, LinkShare is a third party company and is not tied directly into the App Store. That means the links they provide go through click.linksynergy.com and then are redirected to the App Store. The result is that trying to follow one of those links from your app will result in Safari coming up, opening up a new page, shutting down, and then opening the App Store app. Not pretty!

Fortunately, there’s a workaround. Just like we did with the App Store links, we can open the LinkShare link directly with a NSURLConnection instead of letting Safari handle it. Then, once the link resolves to the forwarded one, we can open it directly with the App Store app:

- (IBAction)buyItNow
{
    NSString* link = @"http://click.linksynergy.com/fs-bin/click?........";
    NSURLConnection* conn = [[NSURLConnection alloc] initWithRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:link]] delegate:self startImmediately:YES];
    [conn release];    
}

- (NSURLRequest*)connection:(NSURLConnection*)connection willSendRequest:(NSURLRequest*)request redirectResponse:(NSURLResponse*)response
{
    m_iTunesURL = [response URL];
    return request;
}

- (void)connectionDidFinishLoading:(NSURLConnection*)connection
{
    [[UIApplication sharedApplication] openURL:m_iTunesURL];
}

Voila! The user goes directly to the App Store page, there are no annoying Safari transitions, and you still get the referral bonus.

Incidentally, most of this is already documented in an Apple Technical Q&A note, but it’s kind of hidden away and I think most people don’t know about it.

If you’re using LinkShare, you should also check out this post at Mobile Orchard. One of the things I learned there was the use of the &u1 parameter, which allows you to tag links with arbitrary information so you can track where purchases came from. Knowing where people are buying your app from is extremely helpful to know how to maximize sales!

[Edit: Sam Steele pointed me to the source code for the Last.fm app which handles all the URL redirects. Thanks!]

The demo ended up looking pretty good, so I decided to upload a quick video showing the different lighting modes:

• Diffuse texture only
• Diffuse texture plus ambient and diffuse lighting
• Diffuse texture plus ambient, diffuse, and specular lighting (as usually, per-vertex lighting looks pretty bad, even though this is a relatively high-poly model)
• Fully reflective environment map (using the normal environment map technique)
• Environment map added to the diffuse texture and lighting
• Environment map with a reflection mask plus diffuse texture and lighting (two passes on an iPhone 3G–or one pass if you’re not using the diffuse alpha channel)

The chapter in the book will go in detail into each of those techniques, building up to the last one. Full source code will be included as well.

Some of these techniques will also be covered in my upcoming Two Day iPhone OpenGL Class organized in collaboration with Mobile Orchard.

Trouble With Versions

When you install the 3.0 SDK and create a new project, it will be automatically set up to build only for 3.0. To target earlier versions while still having access to 3.0 features, you need to take a few extra step. These steps are described in detail in the readme of the MailComposer sample (iPhone dev account required). My friend Serban also wrote about how to do it when you add Snow Leopard to the mix.

The required steps are:

• Under project properties, set up the Base SDK setting to be OS 3.0

• Also in project properties, change the iPhone OS Deployment Target to OS 2.2 (or whichever version you want to target).

• Go to target properties, and add a 3.0 library with the features you need. Make sure you set its type to Weak instead of Required.

• In your code, check that a feature is available before using it. For example, you can do this check to see if the in-app mail functionality is available:

Class mailClass = (NSClassFromString(@"MFMailComposeViewController"));
 return (mailClass != nil && [mailClass canSendMail]);

• Make sure you set your app to build with the 3.0 SDK and off you go.

If all goes well, it should run under 2.x and 3.0. If all goes well…

Trouble With Libraries

If that was the end of the story, then we would all be happy and I wouldn’t have to write this entry. And for a while I really thought that was everything I had to do to get Flower Garden to use 3.0 features and still work on 2.x devices. Everything compiled fine, but when I went to run it on a 2.2 device, it crashed.

Looking at the crash logs, it was crashing inside a static library that used Objective C and UIKit. Digging further, it seemed that function calls were being sent to the wrong place. What was going on?

At this point I realized the root of this problem was the linker flags I was using. As soon as I started using the 3.0 SDK, I had to add the -all_load linker flag in order to be able to use the static library. I believe this loads all the symbols used by the libraries and links with them at link time. Without it, the library code would crash at runtime as soon as it was executed

The -all_load flag seems fine, except that the 2.x and 3.x versions of the SDK have different libraries and resolve symbols to different locations. So by doing -all_load, we’re linking against the location of the 3.0 version and trying to run it on 2.x. Bad idea.

I thought long and hard on how to get around this. I came up with all sorts of crazy schemes, and after a couple frustrating days, I gave up. Then, all of a sudden, I realized that it had an embarrassingly simple solution: Don’t use a library! I’m not kidding. Just move the files in XCode directly into your main game target and you’re done. No -all_load and everything works fine.

Yes, I’m still embarrassed for not figuring that out after 30 seconds…

Trouble With Compilers

So all happy with that discovery, I rebuild and run the app and… crash again!

The call stack this time looked like this:

Thread 0 Crashed:
0   dyld                              0x2fe01060 dyld_fatal_error + 0
1   dyld                              0x2fe07ca8 dyld::bindLazySymbol(mach_header const*, unsigned long*) + 484
2   dyld                              0x2fe15eb4 stub_binding_helper_interface + 12

What was going on in there? Some Googling and searching in the iPhone forum later, I learned that SDK 3.0 uses a different version of GCC (4.2 instead of 4.0). That means it will try to use some runtime functions that are not available with earlier versions. In particular, my crash was related to subtracting two uint64_t variables. Re-writing the code by casting the values to uint32_t before doing the operation fixed the problem. There’s an ugly “solution” for you!

So how do you know if something will work on 2.0? I don’t have a good answer for that other than test it as much as you can. Does someone have a better solution?

The good news is that, after I made those fixes, Flower Garden was happily running on 2.2 and 3.0. Now I can finally roll out in-app email without giving up on 2.x devices and cutting my potential customer base (or depriving current users of future updates).

Open Questions

Going through this answered a few questions, but also created a few new ones. Maybe someone here will know the answer or will be able to point me in the right direction.

• Does anyone know how to debug your OS 3.0 app on the simulator set to 2.2? Whenever I launch it from the debugger, the simulator gets set to 3.0. Even if I set it to 2.2, I wonder if it will behave the same as a 2.2 device.
• I’ve heard rumours about somehow, packing two versions of the app in the same executable (kind of like the universal MacOS executables with both a PowerPC and an Intel version). Has anyone done something like that with the iPhone? Any docs on that?

At first, things sounded simple enough: Create 20 different seeds, with varied looks and properties. I had a really cool tool to tweak the flower DNA in real time (more on that another day), so how hard could it be?

The main properties I had to balance were amount of care required (as in, how often you had to water them before they would go dry) and how long the flower took to grow. The first few flowers came along just fine, but after the fifth or sixth seed, they all started blurring together. Did I have a fast-growing flower that needed a lot of care already? To get around this, I started writing all the seeds I had done so far and their characteristics in a text file so I could refer to them easily.

After a few more seeds, I knew I was in trouble again. Reading through all the flowers was a pain, but now I was starting to forget what they looked like. Did I already have an orange flower with a few, large petals? How about a small white one with lots of rounded petals and glossy leaves? The text file didn’t cut it anymore, I had to go graphical. So I created a document with a picture of each flower along with all its relevant information (name, growth time, and amount of care).

This helped a lot, but it eventually became inadequate when I started creating the unlock conditions and balancing and the different seeds in order of difficulty. I just wasn’t able to look at a list of 20 entries, each of them with 3 key elements (care, duration, and unlock condition) and keep it all in my head to make intelligent decisions based on it.

I’m a very visually-oriented person. Whenever I can, I try to solve problem visually instead of memorizing lists or plugging equations. In particular, I love to take a multi-dimensional problem and visualize it along its main axes. So I took the next logical step to help me make sense of all that data and created a seed chart.

This seed chart is a two-dimensional arrangement of all the common seeds in the game, along with their picture and the key information we had before (there are another dozen bonus seeds that aren’t listed in this chart). The horizontal axis indicates how much care a plant needs. Specifically, it shows how many segments in the water meter before it dries out (and each segment is 3 hours). The vertical axis indicates the growth duration for the plant in real time. Instead of making it a straight, linear scale, I decided to go with regions, which is how they are presented in the game (“Instant”, “A few hours”, “Overnight”, “A few days”, “About a week”, and “Quite a while!”). Within the region, they’re roughly ordered by duration (shorter towards the top, longer towards the bottom).

Now it was really easy to see at a glance the key characteristics for each seed, see where I had clusters, and where I had empty spaces that no seeds were currently using. As a bonus, I was able to come up with a rough ordering indicating the level of difficulty for each seed. The further down and to the right a seed was, the more difficult it was to grow.

That allowed me to block out some regions (dotted red lines) indicating difficulty ratings, which are listed in the game in the seed information as “Piece of cake”, “Easy”, “Moderate”, “Hard”, or “Experts only”. Notice how the lines separating the regions are not parallel (even though the vertical axis is kind of logarithmic). That’s because moving along the horizontal axis increases difficulty a lot faster than moving down the vertical axis. So even a relatively complex relationship like that can be observed at a glance from the chart.

Another great benefit of the seed chart is that I was able to draw paths between seeds, showing the unlocking relationships between them. Before it was hard to see these relationships in text, but now it was very visual, and I could make sure that easier flowers unlocked the path to harder ones as long as the unlock relationship flowed roughly from the top left to the bottom right.

As a side effect, the chart allowed me to learn even more things about the data than I had expected. For example, I was able to see which colors I had used so far, and which colors I still needed to use. One really interesting thing I noticed is that colors were clustering around specific areas. Red colors seemed to be mostly in the harder flowers. Yellow colors were predominant with the dry plants, and blue colors with the wetter ones. I thought that was pretty neat, so I tweaked a few seeds here and there to make that color connection even stronger.

The lesson learned here is that the old saying applies even more in this age of information: One picture is worth one mega of words.

The class is aimed at iPhone developers without previous OpenGL experience. It’s going to be very hands-on, and you’ll create both 2D and 3D applications during the weekend. You’ll learn all the basics: cameras, transforms, and how to draw meshes, but we’ll also cover some more advanced topics such as lighting, multitexturing, point sprites, and even render targets. Most importantly, you’ll walk away with a solid understanding of the basis, which will allow you to continue learning OpenGL and advanced computer graphics on your own from the docs, samples, or even browsing the API directly.

The main requirement for the class is that you’re familiar with the iPhone development environment and that you have basic knowledge of the C language. Beyond that, to the the most out of the course, you should be familiar with the basics of linear algebra (vector, matrices, and dot products). Anything else, we’ll cover it all during the class.

Registration is now open, and you can get some great discounts by registering early and attending the 360iDev conference. For more details, check the official announcement page.

Hope to see some of you there!

Notice the other iPhone games that flash at the start of the Flower Garden section: Harbor Master, Up There, and Little Red Sled, all App Treasures games! The video also starts with coverage of Fifa 10, so we’re in pretty good company :-)

Today we finally unveiled a project we had been working on for a couple of months: The App Treasures label.

Only indie games that we consider to be really fun, polished, and of high quality are part of the label. We hope that when players enjoy one of our games, they can turn to the other App Treasures games and find something they like.

With the App Store dominated more every day by big developers and publishers, this is a way for small indie developers to stand our ground. With App Treasures we establish a strong brand, share resources, and get more visibility in the App Store and in the eyes of the users. The same benefits we would get with a publisher, but without giving up our independence, creative freedom, or a percentage of the profits.

The current App Treasures members are:

• The Blimp Pilots (Koi Pond, Distant Shore)
• Imangi Studios (Imangi, Word Squares, Little Red Sled)
• Snappy Touch (Flower Garden)
• Streaming Colour Studios (Dapple)
• Veiled Games (Up There, Payday Roulette)

You can read more details in this interview I did for App Craver. Mobile Orchard also published a really good piece with some interesting views and conclusions on App Treasures.

Oh, and don’t forget to follow App Treasures on Twitter to keep up with the latest news.

As far as I’m concerned, virtual memory paging is the lazy man’s caching scheme. There, I’ve said it. Now let me qualify it a bit and justify why I feel that way.

A lot of applications, and especially games, can’t keep in memory every bit of data they need for their execution. There’s just too much data and not enough RAM to keep all the levels, all the textures, all the characters, and all the movies. Even the thought of keeping everything in memory is ridiculous. Instead, games are architected to strike a balance between memory usage and responsive interfaces. Usually that means loading levels, or parts of levels on demand, and keeping them in memory while they can be needed. Some other times it means loading levels of detail for textures, meshes, and animations depending on the player position. The point is, nobody knows as well as the game itself what needs to be in memory, what can be unloaded, and when the best time to do it is.

A different approach would be to ignore thinking about managing memory as a scarce resource and use as much of it as we need. If we ever go over the amount of available physical memory, the virtual memory system will kick in and page out memory to disk to make room for the memory we’ve requested. But there lies the problem: The virtual memory system is a lower-level system that knows absolutely nothing about our game or application. It can only make guesses about what memory is OK to evict and when it’s a good time to do it. If you’re unlucky it will choose to page out memory when you need performance the most, and it might evict a page that you’re about to use in a few milliseconds. If that happens, you can kiss your performance bye-bye.

Because of that, virtual memory paging will always do a much worse job than we could have done ourselves. But hey, it takes no effort or thinking on the part of the programmers, hence the “lazy man’s caching scheme” I was referring to earlier.

However, virtual memory paging is sometimes a necessary evil. The assumption running through the previous three paragraphs is that we, as programmers of the game, can always manage the physical memory so our game runs efficiently on it. That is true for certain platforms, usually with fixed hardware specs, and ones with minimal or no background processes running. Game consoles are perfect examples of this: We know how much RAM we have to start, we know how much the system needs, how much video memory there is, and we can deal with the rest ourselves. We’ll decide what to load and when to load it.

On something like a modern PC (whether it’s Windows, Mac, Linux, or any other flavor), we have none of those guarantees. We don’t know how much memory we’re going to encounter when we run our game, and, what’s even worse, we have no idea how that available memory is going to change during the execution of the program [1]. In a situation like that, we can plan for some minimum memory requirements, but we’re going to need that virtual memory paging to bail us out of tricky low-memory situations. It might sound like a good idea, but that’s one of the main reasons why PC games are often choppy and with inconsistent frame rates (buggy drivers being the other main reason).

Finally coming back to the iPhone, how does virtual memory paging fit there? There’s no doubt that it would help because it would reduce the number of crashes due to programs unexpectedly running out of memory. But at the same time, it would cause most games and apps to be choppy and unresponsive, especially when it’s just launched. But the iPhone is mostly a fixed spec platform, with minimal background processes [2], so we can always do better than the dumb virtual memory system. Maybe that’s not a big deal if you’re writing an app that interfaces with a web site and writes data to a database, but it’s crucial to be able to write responsible games, which are considered near real-time apps.

On the iPhone there should be no need for virtual memory paging (not to mention that it would probably drain the battery a lot faster). Instead of solving the memory problem by throwing more and more complex systems at it, what we really need is a guaranteed amount of memory for our app to run and we can take care of the rest. But Apple needs to take the first step and set that memory aside.

We’re waiting, Apple.

[1] We could go totally hard core and allocate the memory we need and then mark it as not swappable by the virtual memory system. That wouldn’t do any good because if other processes start requesting memory and they run out, the virtual memory system will swap out other pages (and possibly cause other processes to thrash) and kill our performance as well. So things are pretty much out of our hands as soon as virtual memory paging comes into play.

[2] There are a lot of background processes, but they should be relatively well-behaved. None of them should be pulling in massive amounts of data while the game is running.

My recent rant

As a response to that post, some people suggested some intriguing ways to increase the available memory on the iPhone. I’ve been experimenting with that a bit, but I don’t have any conclusive solutions yet. Right now it’s all totally unreliable hacks. Hopefully in a followup post I can present some solutions.

In the meanwhile, I wanted to talk about a piece of the puzzle, which is keeping track of the memory status on the iPhone. How much memory is available? How much memory does the program use? We need to be able to answer those questions accurately in order to do anything about memory. Unfortunately, there doesn’t appear to be a good answer even for this!

Finding Total Memory

Let’s start with the easy part: Finding the overall memory on the device. Right now all iPhones and iPod Touch models have 128MB RAM, so it’s kind of pointless, but it’s interesting anyway. To accomplish that we need to dig into some of the low-level functions that query hardware capabilities. In particular, the function sysctl() reports both physical memory and user memory.

    int mem;
    int mib[2];
    mib[0] = CTL_HW;
    mib[1] = HW_PHYSMEM;
    size_t length = sizeof(mem);
    sysctl(mib, 2, &mem, &length, NULL, 0);
    NSLog(@"Physical memory: %.2fMB", mem/1024.0f/1024.0f);

    mib[1] = HW_USERMEM;
    length = sizeof(mem);
    sysctl(mib, 2, &mem, &length, NULL, 0);
    NSLog(@"User memory: %.2fMB", mem/1024.0f/1024.0f);

The output of that code is:

Physical memory: 116.00MB
User memory: 91.30MB

Interesting. Physical memory is not quite reported as 128MB. That’s probably because the video memory takes up 12MB of the total. The kernel apparently uses 24.7MB, which is not unreasonable if that was all the memory used by the OS. Unfortunately, that’s only for the kernel. The different processes and apps are going to use up more than that. A LOT more than that.

Incidentally, sysctl() is a pretty rocking function. It will give you all sorts of cool information, such as CPU and bus frequency (412MHz and 103MHz respectively for my iPhone 3G), cache sizes, and whether a vector unit is present (it claims it isn’t, so it must not be referring to the vfp).

Finding Available Memory

As cool a function as it is, sysctl() only returns static information about the hardware. If we want to find information about the current status of the memory, we need to look elsewhere.

As far as I can tell, the best function to get this information host_statistics() with HOST_VM_INFO_COUNT to get virtual memory statistics. Querying that function fills out the following structure:

struct vm_statistics {
    natural_t	free_count;		/* # of pages free */
    natural_t	active_count;		/* # of pages active */
    natural_t	inactive_count;		/* # of pages inactive */
    natural_t	wire_count;		/* # of pages wired down */
    natural_t	zero_fill_count;	/* # of zero fill pages */
    natural_t	reactivations;		/* # of pages reactivated */
    natural_t	pageins;		/* # of pageins */
    natural_t	pageouts;		/* # of pageouts */
    natural_t	faults;			/* # of faults */
    natural_t	cow_faults;		/* # of copy-on-writes */
    natural_t	lookups;		/* object cache lookups */
    natural_t	hits;			/* object cache hits */

    /* added for rev1 */
    natural_t	purgeable_count;	/* # of pages purgeable */
    natural_t	purges;			/* # of pages purged */

    /* added for rev2 */
    /*
     * NB: speculative pages are already accounted for in "free_count",
     * so "speculative_count" is the number of "free" pages that are
     * used to hold data that was read speculatively from disk but
     * haven't actually been used by anyone so far.
     */
    natural_t	speculative_count;	/* # of pages speculative */
};

Lots of good info there! (at least for a hardware geek like me). The most interesting one is free_count. That number combined with the page size (which is defined in the handy global variable vm_page_size–which is unsurprisingly 4K on the iPhone) should give us the amount of available memory, right? Right?

Kind of. Unfortunately virtual memory is managed at many different levels. The OS will keep some pages on reserve to use on a rainy day. So it’s possible that there is more memory available than reported in this function. It will however give you a good minimal bound on the amount of free memory. You can count on that amount for sure.

This function puts it together to return the amount of available memory in KB:

int getAvailableMemoryInKB()
{
    vm_statistics_data_t vmStats;
    mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;
    kern_return_t kernReturn = host_statistics(mach_host_self(),
                             HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);
    if(kernReturn != KERN_SUCCESS)
        return -1;
    return (vm_page_size * vmStats.free_count) / 1024;
}

To check that available memory roughly matches what I do in the app, I allocate a 1MB block, run it again and… surprise! I get the same amount of memory available. Apparently the OS is waiting to actually set those memory pages aside until you really need them (I hate it when machines try to out-think me). So to really get them to count as allocated, we need to write to every page of the memory we just allocated. The easiest way is just go bzero(mem, 1024*1024);. Running the function again correctly shows that the available memory has gone down by 1MB.

(Not) Making Sense Of Used and Total Memory

An old habit I picked up during my engineering days is to always confirm my calculations through a different path. If the total amount of memory reported by the virtual memory system matched up with the total amount of memory reported by sysctl() I would leave this happy and be able to sleep soundly tonight.

The total amount of virtual memory is calculated by adding together the free, used, wired, and inactive pages. It should come up to be roughly around 91MB. The answer: 89MB. OK, close enough, right? Not really.

Here’s the biggest mystery so far: If I malloc a chunk of memory (and write to it to have it marked as not available), host_statistics() correctly shows that those pages are not available anymore, but they don’t show up as used, wired, or anything else!!! So simply adding free, used, wired, and inactive reports a totally bogus number that doesn’t take into account allocations from your program. What’s going on there? Obviously I’m misunderstanding something, so maybe someone with more knowledge of kernel and vm features can help me out. Otherwise I won’t be getting much sleep I’m afraid :-)

Just to prove that I’m not crazy, here’s a code snippet and its output:

- (void)updateStatus
{
	vm_statistics_data_t vmStats;
	mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;
	host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);

	const int totalPages = vmStats.wire_count + vmStats.active_count +
                               vmStats.inactive_count + vmStats.free_count;
	const int availablePages = vmStats.free_count;
	const int activePages = vmStats.active_count;
	const int wiredPages = vmStats.wire_count;
	const int purgeablePages = vmStats.purgeable_count;

	NSMutableString* txt = [[NSMutableString alloc] initWithCapacity:512];
	[txt appendFormat:@"Total: %d (%.2fMB)", totalPages, pagesToMB(totalPages)];
	[txt appendFormat:@"nAvailable: %d (%.2fMB)", availablePages, pagesToMB(availablePages)];
	[txt appendFormat:@"nActive: %d (%.2fMB)", activePages, pagesToMB(activePages)];
	[txt appendFormat:@"nWired: %d (%.2fMB)", wiredPages, pagesToMB(wiredPages)];
	[txt appendFormat:@"nPurgeable: %d (%.2fMB)", purgeablePages, pagesToMB(purgeablePages)];

	NSLog(txt);
	[txt release];
}

- (void)viewDidLoad
{
    [super viewDidLoad];
    [self updateStatus];
    const int sizeInBytes = 1024*1024;
    int* mem = (int*)malloc(sizeInBytes);
    bzero(mem, sizeInBytes);
    [self updateStatus];
}

And the output is:

Total: 22128 (86.44MB)
Available: 8124 (31.73MB)
Active: 6361 (24.85MB)
Wired: 6408 (25.03MB)
Purgeable: 359 (1.40MB)

Total: 21880 (85.47MB)
Available: 7888 (30.81MB)
Active: 6344 (24.78MB)
Wired: 6412 (25.05MB)
Purgeable: 359 (1.40MB)

Notice how the available pages go down by about 1MB but everything else stays about the same?

While we’re at it, does someone know of a better, lower-level way to allocate memory than malloc()? I’d like to just allocate memory pages directly. I looked into vm_allocate() but I wasn’t able to get the correct port rights. Anyone?

Update: Thanks to Colin for pointing out that mmap is the low-level memory allocation function I was looking for. You can allocate pages directly without going through malloc. Perfect!

Next Up…

This is a stepping stone towards the memory experiments I’m running. In the next day or so I should be able to report some good ways to clear up as much memory as possible for our apps.

Except when it comes to memory, that is.

I really like most of the design calls that Apple made designing the software for the iPhone: Using C and Objective C (instead of Javascript or web-only apps), building it on top of a Unix-like core, and even providing OpenGL (although I would love to have lower-level access to the graphics hardware).

Developing for the iPhone is a mix of PC and game console development. One one side, it’s a fairly open platform with standard APIs (like PCs), and on the other, it has (almost) fixed hardware [1] and a regulated distribution channel (like game consoles). I would even argue that the iPhone borrows the best of both worlds. When it comes to memory, however, the iPhone adopted the worst of both worlds. I feel that Apple completely dropped the ball there. Completely.

On a PC (whether it’s Windows, Mac, Linux, or whatever), you can’t count on having a fixed amount of memory. When your program runs, it can be running in a machine with RAM to spare, or in one with barely enough to run the OS. Or maybe it’s running on a machine with enough RAM but there are fifty other programs running and there’s no memory left for your program.

Fortunately (or unfortunately depending on your point of view), virtual memory allows the operating system to write memory pages back to disk and free up space for your program. Yes, it can cause the program to halt and crawl while memory is being paged out, but it will run. Definitely not an ideal solution for semi-real time applications like games. That’s one of the main causes for choppy, underperforming PC games, but it has worked for many years and will do in a pinch.

On consoles on the other hand, you have a fixed amount of RAM from the start. You know what that amount is, and you can plan for it. In this latest generation of consoles, you still need to give up part of that precious memory to some other processes for user interface and network updates, but even that amount is known ahead of time. You can plan for it, and make your game fit in the memory that you have left.

The iPhone memory situation is… a mess. It’s like a console in that you have a fixed amount of RAM: 128 MB (although I’m sure Apple doesn’t want developers thinking about it so they can roll out iPhones with more memory without affecting existing programs). Because it has a fixed amount of RAM, the iPhone doesn’t provide virtual memory swapping [2]. So far so good. But here’s the kicker: Unlike a game console, the iPhone makes no guarantees about how much memory your application has available when it runs.

Let me say that again: You’re dealing with a fixed-memory environment and you have no way of knowing how much memory will be available to you. Did that sink in yet?

So how are you supposed to deal with that? Apple wants us to be able to dynamically load and unload anything in our programs in response to low-memory warning events. That might work well if you’re loading web pages and just need to unload some cached ones, but that’s far from ideal for games. What are you going to do? Unload part of the level? Get rid of some sounds? Not every game can do that, and even if you could, it would add a huge amount of complexity to something that should be pretty simple.

You can’t even plan on using a fixed minimum amount of memory. From my experiments on my iPhone 3G, it seems that it’s relatively safe to use between 15 to 18MB. Any more than that, and you start getting low memory warnings, and unless you program does something about it, the OS will promptly terminate you. On an iPod Touch, since it’s not running as many background services, you usually have more memory available. I learned that the hard way, because I developed most of Flower Garden on an iPod Touch, only to find out that it was too slow and running out of memory on the iPhone 3G.

And this is out of a total of 128MB. Where did the rest of the memory go? Come on, even with phone, GPS, and music processes in the background, where did the rest of the memory go? Probably the worse culprits are the mail program and Safari, which are left in memory even after you exit back to the springboard (Bad design decision, no cookie!).

And what exactly does it mean “to do something about it” when you get a low-memory warning? You’re supposed to free up as much memory as you can, but is it enough? Who knows! Maybe you free up one megabyte but the OS still decides that you’re taking too much memory and it will kill you anyway. It seems like the worst memory handling scheme ever designed.

As an extreme situation, I have seen as little as 3.5MB available when starting my own program! What are you supposed to do in that case? Most games will just crash back to the springboard. Want to test this? Launch Safari, load 10-15 heavy web pages, quit, and then launch your favorite game. A crash is almost guaranteed. For my next project, I’ll be tempted to respond to a low-memory warning by killing the Safari and Mail processes. That will free up some memory!

To make matters worse, I had the bright idea of combining OpenGL and UIKit for Flower Garden. Some things worked really well, like being able to quickly create some screens with Interface Builder and take advantage of all of Apple’s UI widgets and fonts. Creating the seeds screen or the settings panel was a breeze with UIKit. However, UIKit uses an undetermined amount of memory behind the scenes, which makes all attempts at staying below a certain memory threshold pure black magic. In particular, drawing images to a context apparently causes mysterious caching of bitmaps taking huge performance hits and memory chunks over which we have no control. And game programmers don’t like to feel they have no control over what’s happening!

Another consequence of such a horrible memory situation is that game developers aren’t able to make full use of the resources available. If we’re aiming for 15MB, but have to drop back to 5-8MB, most developers are not going to try to write a game that uses 30 or 40MB (which might be available). What a shame!

I’ve said before that the iPhone very closely resembles the great Sega Dreamcast (which is my favorite game console of all time). The Dreamcast only had 16MB of main RAM and 8MB of video RAM, but the best games on the iPhone, still pale in comparison to the best Dreamcast games. Why? Mostly because of the memory situation. If we had a guaranteed 16MB of RAM and the possibility of using all the extra free memory, iPhone games would look very, very differently.

My plea to Apple: Please, give us some minimum memory guarantees for OS3.0! That, more than anything else, will make the biggest difference in the look and reliability of future games.

[1] There are slight differences between iPhone 2G, 3G, iPod Touch 1st and 2nd gen (especially the latter, which has a faster CPU and faster file system).

[2] It has virtual memory in the sense that there’s a paging system with virtual addressing (so two memory pages far apart in real memory could be made to seem to be continuous), but there is no automatic paging in and out of memory pages to/from disk.

When: April Wednesday 22nd at 7:30PM until whenever Where: O’Sullivan’s Pub in Carlsbad (home of the Appy Entertainment Secret World Headquarters)

Appy is being a great host again and providing some munchies. You’re responsible for your own drinks though :-)

Hope to see you there!

The interview topics range from high-level topics like business aspects of iPhone development, down to the nitty-gritty of how the procedural flowers were created, or how I had to use assembly language to take advantage of the vector floating point processor on the iPhone to do all the heavy lifting for matrix transforms.

Flower Garden was finally approved and it’s available right now! This is what I’ve been pouring my heart and soul for the last six months. You can buy it directly from the App Store.

If you like it and would like to help out, here are some of the things you can do to promote it:

• Go back to iTunes and write a fair review
• Grow flowers and send bouquets to your friends
• Join the Flower Garden group on Facebook
• Tell all your friends how great it is :-)

Thanks everybody for all the encouragement and support along the way. I hope you enjoy playing it as much as I enjoyed creating it.

And don’t worry, this is just the beginning. I have lots of updates planned, so keep an eye out for lots of fun new features!

With all the excitement last week with GDC and the last push for Flower Garden, I completely forgot to announce that I submitted Flower Garden to Apple last Friday. It’s currently listed “In Review” and hopefully, if all goes well, will be available on the App Store either this weekend or early next week. Keeping my fingers crossed!

The presentation went very well. The room was *completely* packed, with every seat taken and people standing along the walls. In retrospect I shouldn’t be surprised because it was the only iPhone presentation in the main GDC conference. Clearly there is a huge amount of interest in the platform. I’m already pushing to have a lot more iPhone content for next year, so you can all look forward to that.

Because it was the only iPhone presentation in the main GDC, I had to keep it very high-level and focused on the question of “what can you expect if you switch to develop games on the iPhone”? Not like I can really answer that, but at least I can share what my experience was. Hopefully next year I can really dive into some juicy tech topics.

In the meanwhile, if you’re dying for some more technical content, go check out my latest column in Game Developer Magazine dealing with multi-touch input devices with the lessons I learned from Flower Garden.

Update: Ari Braginsky recorded the audio of the session (part 1 and part 2), so if you want, you can follow along with the slides. Thanks Ari! I believe that the synced audio and slides will be available through the GDC web site for registered attendees too.

The point is that as March 20th approached, I was slaying bugs left and right. Flower Garden went through two rounds of beta testing and it had some great feedback. All the crash bugs and top priority tasks were done and taken care of a few days before the deadline. Things were looking good for a submission to Apple on the expected date! Yay!

Then, with just a day to go, I decided to step back a second. Something had been nagging at me for a bit and I had to be honest with myself. Yes, all the crashing bugs and major features were taken care of. But how come my issue tracking system still had 50 entries in it marked as “Final release”? It wasn’t a big deal. Those were all marked as “low priority” or “trivial”. And that’s the great thing about the iPhone, I can submit the application and then start pushing out updates as I get to the little stuff. Right? Right?

This wasn’t a case of taking Old Yeller behind the shed. The app was looking good. Really good. And it wasn’t just a puppy, but a fully grown, beautiful app. It’s just that it was a bit… slow and rough around the edges.

This is were things got really tough for me. On one hand, I was ready to ship this baby. I have been working on it for almost six months (where did time go??) and a lot of people were loving it. But when I allowed myself to give it one hard look, I realized that the experience I was hoping for wasn’t there. Yes, the functionality was there, but not the experience. With a tool that gets a job done, maybe that’s not a huge deal. But Flower Garden is all about the experience.

I tried to rationalize it by thinking how I could get all those little, low priority things done in an update right away: Improving the performance of the rendering, making the transitions more responsive, adding those subtle animations and sounds, making load times shorter… In short, it was missing the key ingredient to a successful experience: polish. I could always add that polish later, but what about all the people who bought it right away? What kind of impression were they going to get? In a saturated market like the iPhone App Store, and especially with a title aimed at a casual audience, first impressions are everything. If people don’t fall in love with your product right away, you might not get a second chance.

So it was with a very heavy heart that I decided to slip my target date. I really needed one more week to get to the point that Flower Garden could be the experience I had envisioned. And of course, to make it twice as hard, this coming week it’s GDC, so that means that the release date is pushed out two weeks.

Coming from the console world, where updating your game is a rare opportunity and you better get everything right for the big release,I was really counting on releasing frequent updates. Does it mean that updates are useless in the App Store? That we shouldn’t take advantage of them? Not at all. I realized that I was looking at them the wrong way. Updates are supposed to provide bug fixes and new functionality. They are not a crutch for sloppy development and an excuse to release products before they’re ready.

Now I have regrouped. Reassessed where I’m at, and prepared the final plan of attack. If all goes well, I will be submitting Flower Garden to the App Store the last week of Mark/beginning of April. When exactly? When it’s ready. Lesson learned.

Last night was particularly frustrating because I had just called it “beta” on Flower Garden and celebrated with the requisite victory dance, when the fun of sending out the beta build started. What I thought would be a ten-minute task, turned into a long nightmare and I didn’t get the build out until 1AM.

This is not the first time I run into issues with provisioning profiles and distribution in general. It’s a very finicky process, and other developers are going through the same pains. Mark Johnson suggested I collected all the gotchas I’ve learned into a single place so it can serve as a form of reference. That’s a great idea, because the process is so byzantine that I will have forgotten most of them next time I need to do another big submission.

This is not a “how to” document on preparing your builds for ad-hoc or App Store distribution. Apple has the basic flow documented in their site, and other people have also talked about the process. This is intended to be more of an appendix explaining details, clarifying assumptions, and correcting things that are just plain wrong.

To make this more comprehensive, I’d like to open it up to other people’s experiences, not just mine. If you have gone through some pains with the iPhone Developer Program (and who hasn’t?) and found a way to deal with them, please post in the comments and I’ll update this page to reflect it.

iPhone Developer Program

1. App identifier is case sensitive. This is the string you need to enter when you create an app ID through the developer web site, and the one you need to set in your Info.plist. My usual development id is com.snappytouch.* so I can use it for anything I do. But in preparation for sending out the beta build, I created one just for Flower Garden: com.snappytouch.flowergarden. I thought that everything on the build side of things would be fine because my default app ID was: com.snappytouch.${PRODUCT_NAME:identifier}. Unfortunately, this failed to create a working build without any helpful errors. After much hair-pulling, I figured that was because my app is called “FlowerGarden” not “flowergarden”. Changing the app ID in XCode to com.snappytouch.flowergarden fixed that.

2. Easy UDIDs. Forget about asking your testers to go to iTunes and get the UDID from there. Instead, tell them to get BetaHelper and email you all the information directly. Easy and no typing errors!

3. Bulk device upload. I got a great response to the call for beta testers for Flower Garden, so I was left with about 30 new device UDIDs to enter in the developer web site. Entering them one at a time with a slow-as-molasses interface isn’t my idea of fun so I decided to use the bulk upload option. Unfortunately the format isn’t described exactly anywhere, and the errors displayed if the format doesn’t match exactly are meaningless.

The exact format is:

Device ID	Device Name
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx	Whatever name here
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx	Lalalala
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx	Whatever

So, tab separated, not comma separated. First column is the device ID (40 digits). Second is the name, no quotes around it. First line is ignored. Here’s the killer: You cannot have any blank lines after the last entry. And the error message if you do is simply a “Bad format”. Come on Apple, throw us a bone over here! One last thing: You can’t upload a device ID that is already in your database. Really annoying. Still, beats cut and pasting all those IDs by hand.

4. Ad-hoc zip file for Windows users. Apparently it can’t be created with the Compress option in finder because it puts extra files. I used zip from the command line and it worked correctly. (Thanks to Mark Johnson for that one).

5. App Store zip file has to be created through Finder with Compress. I heard that on Twitter somewhere, but needs confirmation. Anyone?

6. Adding provisioning profiles. Forget about dragging them on XCode and manage them manually. Check out my earlier entry about it.

7. Set correct provisioning profile everywhere. And I mean everywhere. You need to do it both in the Info for the target and the info for the project itself. Yes, both dialog boxes look identical and have 99% the same information, but the provisioning profile setting is different apparently. Fail to set it in both places, and your app won’t load in the device.

I’m sure there are a lot more. If you’ve found some of your own, leave a comment and I’ll update the list.

Session description: This session will cover the experiences of a professional game developer, used to 200+ person teams, multi-million dollar budgets, and 3+ year schedules, who left all that behind to become a one-person indie company developing exclusively for the iPhone. It will explain how things are different and how some things are very much the same, and will show specific examples of graphics technology, development environment, and asset pipeline. I will be using my current iPhone project, Flower Garden, as an example. The audience will learn what the transition is like and what to expect going indie making games for the iPhone.

BecomingIndie.key.zip

Or maybe I just had gadget envy. Whatever.

But I’m not writing to rub in what a cool gadget I have now. I had a couple interesting experiences adding new devices to XCode and I figured I would share them with other iPhone devs.

SDK and firmware compatibility

This is something I noticed a few weeks ago, but I was able to confirm it with my new iPhone. Each new version of the iPhone SDK warns you to upgrade your device firmware to that version before you attempt to run any programs on it with the new SDK. I always took that literally, but I realized it’s not as restrictive as it sounds.

With each version of the SDK, you have the option to target your build to that version or any of the previous ones. I discovered quite by accident that is perfectly fine to use a certain SDK (like 2.2.1) to build for an earlier version (2.0) and run it on a device with older firmware matching that version. It really makes a lot of sense, because otherwise the only way you could test your app on older firmware would be by reinstalling an old SDK. So maybe this is old news to most people, but it was certainly nice to first upgrade the SDK, and only later the firmware to minimize potential for problems.

Updating provisioning profile

So with my new shiny iPhone in hand (actually, it was a $99 refurbished model, but it shines like new and has that new car smell… oh wait), I set to run Flower Garden on it. The process involved the following steps:

• Add a new device with the UDID of my iPhone to the Apple Developer Program account. I made the mistake of having to type it manually from iTunes–didn’t realize that XCode allows you to copy and paste it, doh!. Check.
• Add the new device to the development provisioning profile I was using. Check.
• Download the updated provisioning profile and add it to XCode and my iPhone. Since the iPhone was plugged, all I had to do was drag it onto XCode. Check.
• Clean all, build, run. And….

Yeah, you guessed it, I got an error. Otherwise I wouldn’t be writing this if it had behaved as expected, would I? The error kindly informed me that the provisioning profile I was using to build the app wasn’t available on my device. But I could see it in the organizer window of XCode. I double checked it was the correct one and that Flower Garden was being built with that one. Check. Check.

What was going on?

Here’s the fun part, which took me a few minutes of digging through the docs. When I added the updated provisioning profile, XCode decided that it was a different one from the one I was trying to replace. But, here’s the kicker, they both had the same name and description. So XCode was still building my app with the old one, but it was the new one that was installed on the iPhone.

I discovered this by going to the source. XCode stores all the provisioning profiles in the folder ~/Library/MobileDevice/Provisioning Profiles. You can’t tell much of anything by looking at the filenames since they’re a bunch of UIDS, but you can crack the files open with a good text editor and you’ll see they’re a mix of text and binary data. From there, you can see which file corresponds to which profile by looking at the text between the tags. All I had to do was delete the two development provisioning profiles, re-add the new one to XCode and the iPhone and I was back in business.

I had heard so many horror stories of upgrades to 2.2.1 that I was afraid I was hitting one of those. Fortunately it was quite simple. Next time I’ll know where to look right away.

Now it’s back to work for me. I still need to finish the slides for 360iDev and then I need to fix a couple of things in Flower Garden and get it ready for the first round of beta testing. Sleep? What’s that?

I’ll be sharing my experiences transitioning from traditional AAA console game development, with teams of 100+ people, multi-million budgets, and several years of development, to indie iPhone development. There are a surprising amount of things that carry over from “big game development”, and quite a few that are totally different. I’ll go into what’s involved making games for the iPhone, and what game developers can expect when making the transition.

Apart from my talk, I’m particularly excited about this year’s GDC. It seems that the amount of content on indie game development and iPhone game development has shot through the roof. On Monday and Tuesday we’re treated to not just one, but two great summits: The Independent Games Summit and GDC Mobile! Last year, the Independent Games Summit was the best part of the show. Meeting all the other indie game developers out there and hearing their experiences was great. This year I’m hoping for more of the same plus all the iPhone-specific content.

Of course, the main conference is packed with great content too, but I haven’t had time to go through all of it and pick the sessions I want to attend yet. Too busy wrapping up my current project.

So if you see me around the show, stop by and say hi. I’m always glad to meet other fellow developers, and it’s always nice to put a face with a name for those of you that I know know through Twitter or online blogs.

It is true that Objective-C can be a bit more verbose than plain C++, but it more than makes up for it with named parameters (which increase readability a huge amount), and not having to duplicate many things between header and implementation files.

Yet, even though I like Objective-C so much, there was one last, really annoying feature that was preventing perfect interop between C++ and Objective-C. Something so simple, yet so fundamental, that it really got in the way. Something that wouldn’t allow me to write something as simple as this:

@interface MyView : UIView
{
    // ...
    SingleTouchEvent m_singleTouchEvent;
}

SingleTouchEvent is a custom C++ class. There’s nothing wrong with that right? There shouldn’t. But if you try and compile it, you’ll get this warning:

warning: type `SingleTouchEvent' has a user-defined constructor
warning: C++ constructors and destructors will not be invoked for Objective-C fields

Some of you might be saying, no big deal, you can dynamically allocate objects and have their constructors called as usual. That’s true, but I hate allocating objects on the heap just because of something like this. My preference is always to make them member variables if I can. It’s faster, more efficient, less error prone, and easier to read. Needless to say, this was bugging the hell out of me.

I looked all over the build options in case there was some setting I could toggle to enable C++ constructors to be called, but no luck. I did a bit more research, and lo and behold, it turns out there is a custom setting you can pass directly to gcc to do exactly that! It’s nowhere in the XCode settings GUI, so you have to enter it by hand. Go to Project | Info, and in the Custom Settings section, enter the following: GCC_OBJC_CALL_CXX_CDTORS = YES

With that setting enabled, Objective-C and C++ now play together better than ever!

Without any barriers to writing new code in Objective-C, I expect it will slowly (or maybe not so slowly) replace C++ as my main language of choice for future projects.

So we’re back at it again. Anybody involved in iPhone development or interested in learning more about it is welcome to come.

When: Wednesday Feb 11th from 8PM until whenever. Where O’Sullivan’s Pub in Carlsbad (home of the Appy Entertainment Secret World Headquarters)

If you’re interested, you might also want to join the San Diego iPhone Developers group to keep up to date with any future announcements.

See you all there!

From UIKit to OpenGL

This is definitely the most common way of sharing image data. Loading an image from disk in almost any format is extremely easy with Cocoa Touch. In fact, it couldn’t get any easier:

UIImage* image = [UIImage imageNamed:filename];

After being used to image libraries like DevIL, it’s quite a relief to be able to load a file with a single line of code and no chance of screwing anything up. So it makes a lot of sense to use this as a starting point for loading OpenGL textures. So far we have a UIImage. How do we get from there to a texture?

All we have to do is create a CGContext with the appropriate parameters, and draw the image onto it:

byte* textureData = (byte *)malloc(m_width * m_height * 4);
CGContext* textureContext = CGBitmapContextCreate(textureData, m_width, m_height, 8, m_width * 4, 
            CGImageGetColorSpace(image), kCGImageAlphaPremultipliedLast);
CGContextDrawImage(textureContext, CGRectMake(0.0, 0.0, (CGFloat)m_width, (CGFloat)m_height), image);
CGContextRelease(textureContext);

At that point, we’ll have the image information, fully uncompressed in RGBA format in textureData. Creating an OpenGL texture from that is done like we always do:

glGenTextures(1, &m_handle);
glBindTexture(GL_TEXTURE_2D, m_handle);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, m_width, m_height, 0, GL_RGBA, GL_UNSIGNED_BYTE, textureData);

And we’re done.

A word of advice: This is a quick way to load textures and get started, but it’s not the ideal way I would recommend for a shipping product. This code is doing a lot of work behind the scenes: loading the file, decompressing the image into an RGBA array, allocating memory, copying it over to OpenGL, and, if you set the option, generating mipmaps. All of this at load time. Ouch! If you have more than a handful of textures, that’s going to be a pretty noticeable delay while loading.

Instead, it would be much more efficient to perform all the work offline, and prepare the image into the final format that you want to use with OpenGL. Then you can load that data directly into memory and call glTextImage2D on it directly. Not as good as having direct access to video memory and loading it there directly, but that’s as good as it’s going to get on the iPhone. Fortunately Apple provides a command-line tool called texturetool that does exactly that, including generating mipmaps.

Another use of transferring image data from UIKit to OpenGL beyond loading textures is to use the beautiful and full-featured font rendering in UIKit in OpenGL applications. To do that, we render a string into the CGContext:

CGColorSpaceRef    colorSpace = CGColorSpaceCreateDeviceGray();
int sizeInBytes = height*width;
void* data = malloc(sizeInBytes);
memset(data, 0, sizeInBytes);
CGContextRef context = CGBitmapContextCreate(data, width, height, 8, width, colorSpace, kCGImageAlphaNone);
CGColorSpaceRelease(colorSpace);
CGContextSetGrayFillColor(context, grayColor, 1.0);
CGContextTranslateCTM(context, 0.0, height);
CGContextScaleCTM(context, 1.0, -1.0);
UIGraphicsPushContext(context);
    [txt drawInRect:CGRectMake(destRect.left, destRect.bottom, destRect.Width(), destRect.Height()) withFont:font 
                                lineBreakMode:UILineBreakModeWordWrap alignment:UITextAlignmentLeft];
UIGraphicsPopContext();

There are a couple things that are a bit different about this. First of all, notice that we’re using a gray color space. That’s because we’re rendering the text into a grayscale, alpha-only texture. Otherwise, a full RGBA texture would be a waste. Then there’s all the transform stuff thrown in the middle. That’s because the coordinate system for OpenGL is flipped with respect to UIKit, so we need to inverse the y.

Finally, we can create a new texture from that data, or update an existing texture:

glBindTexture(GL_TEXTURE_2D, m_handle);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0,0, m_width, m_height, GL_ALPHA, GL_UNSIGNED_BYTE, data);

From OpenGL to UIKit

This is definitely the more uncommon way of transferring image data. You would use this when saving something rendered with OpenGL back to disk (like game screenshots), or even when using OpenGL-rendered images on UIKit user interface elements, like I’m doing in my project.

The process is very similar to the one we just went over, but backwards, with a CGContext as the middleman.

We first start by rendering whatever image we want. You can do this from the back buffer, or from a different render target. I don’t know that it makes a difference in performance either way (these are not fast operations, so don’t try to do them every frame!). Then you capture the pixels from the image you just rendered into a plain array:

unsigned char buffer[width*(height+30)*4];
glReadPixels(0,0,width,height,GL_RGBA,GL_UNSIGNED_BYTE, &buffer);

By the way, notice the total awesomeness of the array declaration with non-constant variables. Thank you C99 (and gcc). Of course, that might not be the best thing to do with large images, since you might blow the stack size, but that’s another issue.

Anyway, once you have those pixels, you need to go through the slightly convoluted CGContext again to put it in a format that can be consumed directly by UIImage like this:

CGImageRef iref = CGImageCreate(width,height,8,32,width*4,CGColorSpaceCreateDeviceRGB(),
                            kCGBitmapByteOrderDefault,ref,NULL, true, kCGRenderingIntentDefault);
uint32_t* pixels = (uint32_t *)malloc(imageSize);
CGContextRef context = CGBitmapContextCreate(pixels, width, height, 8, width*4, CGImageGetColorSpace(iref), 
                            kCGImageAlphaNoneSkipFirst | kCGBitmapByteOrder32Big);
CGContextTranslateCTM(context, 0.0, height);
CGContextScaleCTM(context, 1.0, -1.0);
CGContextDrawImage(context, CGRectMake(0.0, 0.0, width, height), iref);    
CGImageRef outputRef = CGBitmapContextCreateImage(context);
UIImage* image = [[UIImage alloc] initWithCGImage:outputRef];
free(pixels);

Again, we do the same flip of the y axis to avoid having inverted images.

Here the trickiest part was getting the color spaces correct. Apparently, even though it looks very flexible, the actual combinations supported in CGBitmapContextCreate are pretty limited. I kept getting errors because I kept passing an alpha channel combination that it didn’t like.

At this point, you’ll have the OpenGL image loaded an a UIImage, and you can do anything you want with it: Slap it on a button, save it to disk, or anything that strikes your fancy.

The now gone CrashLander sample, in spite of some atrocious code, was the best example on how to get a simple, OpenGL app on the iPhone. It covered the basics: creating an OpenGL frame buffer, loading some textures, drawing some polys, and presenting the result to the screen. It was very useful because it was a very small and concise and it made for a great starting point for any OpenGL-based app.

Unfortunately, because it was so basic, it didn’t show how OpenGL can play with the rest of UIKit user interface. Instead, it took the approach from many games of taking control of the full screen and viewing it a a single resource. That’s fine as long as you’re making those kind of games, but I found myself having to mix OpenGL and UIKit quite a bit in my current project. And eventually, I even had to use multiple OpenGL views in different parts of the app.

Single OpenGL View

To render with OpenGL to a view, you have to first set the class-static method +layerClass so it creates the right type of layer. Specifically, we need a CAEAGLLayer:

+ (Class)layerClass
{
    return [CAEAGLLayer class];
}

You can create a view of that type in code, or you can lay it out on the Interface Builder. I actually like the Interface Builder quite a bit, so that’s how I end up creating all of mine.

Then, you need to create an OpenGL context:

    m_eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];
    [EAGLContext setCurrentContext:m_eaglContext];

Finally, you need to create a valid frame buffer object from the CAEAGLLayer from the view you just created:

    glGenFramebuffersOES(1, &buffer.m_frameBufferHandle);
    glGenRenderbuffersOES(1, &buffer.m_colorBufferHandle);
    glGenRenderbuffersOES(1, &buffer.m_depthBufferHandle);

    glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle);
    [m_eaglContext renderbufferStorage:GL_RENDERBUFFER_OES fromDrawable:drawable];
    glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &buffer.m_width);
    glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &buffer.m_height);

    glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_depthBufferHandle);
    glRenderbufferStorageOES(GL_RENDERBUFFER_OES, GL_DEPTH_COMPONENT16_OES, buffer.m_width, buffer.m_height);
    glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle);

    glBindFramebufferOES(GL_FRAMEBUFFER_OES, buffer.m_frameBufferHandle);
    glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_COLOR_ATTACHMENT0_OES, GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle); 
    glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_DEPTH_ATTACHMENT_OES, GL_RENDERBUFFER_OES, buffer.m_depthBufferHandle)

It’s all pretty standard frame buffer OpenGL stuff. The renderBufferStorage:fromDrawable function is the one that actually allocates buffer storage for that particular view.

After that, you’re home free and you can use OpenGL the way you’ve always done. The only difference is that to present, you call this functions instead:

    [m_eaglContext presentRenderbuffer:GL_RENDERBUFFER_OES];

Done.

Integrating OpenGL and UIKit

After you have the basic OpenGL app set up, you can treat it as a full-screen, exclusive resource and do all your output through it. That works fine for a lot of games, but there are a lot of games and apps that benefit from using some amount of UIKit functionality. After all, UIKit is a great UI API, and it seems like a shame to reinvent it all if it’s not necessary.

The good news is that OpenGL rendering is happen in a view, so you can do everything you can do with views: Animate it, do fancy transitions, add them to nav bars or tab bars, etc. The bad news is that, unless you’re careful, performance will suffer.

Apple has some best practices on what to do with OpenGL views, but it comes down to avoid doing transforms on them (instead, use the transforms in OpenGL), and avoid putting other UIKit elements on top of it, especially transparent ones. Although, I seem to be able to get away with small buttons and such without affecting the frame rate, so that’s always a plus.

So having realized that, now you can make your application transition between the OpenGL view, and other views. Maybe you have a table view with settings, or some sort of UIKit dialog box, or a high-score table. You can safely do all of that with UIKit (and add your own graphics and custom rendering if you want to give it a totally different look).

One thing to watch out for: Whenever your OpenGL view isn’t visible, make sure to stop doing frame updates (for simulation and rendering). Otherwise, the rest of the UI is going to be very unresponsive (and you might not find that out until you run it on the device, because the simulator is very fast). The UIViewController viewWillAppear and viewDidDisappear functions are perfect to find out when you should start and stop frame updates.

Multiple Views

Things get more complicated when you want to have multiple views with OpenGL rendering. I don’t mean multiple viewports in the same screen, but multiple views in the sense of multiple UIViews. My current project, for example, has different views connected with a UITabBarController. Some of the are custom UIViews and some of them are OpenGL views.

My first thought was to try to have different OpenGL contexts for each view, but that would complicate things because I wanted to share the same textures and other resources. I know there’s a shared groups option, but that was definitely not the way to go.

The best solution I found was to use multiple frame buffers, binding each of them to the correct OpenGL view. That way, when I switch views, I switch frame buffers and everything works correctly.

On the -viewDidLoad function for each view controller with an OpenGL view, I call the function listed above to create a new frame buffer bound to that view, and it returns an index. Then, in the -viewWillAppear function, I set the frame buffer corresponding to that index:

    const FrameBuffer& buffer = m_frameBuffers[bufferIndex];
    glBindFramebufferOES(GL_FRAMEBUFFER_OES, buffer.m_frameBufferHandle);   
    glBindRenderbufferOES(GL_RENDERBUFFER_OES, buffer.m_colorBufferHandle);
    glViewport(....);

That’s it. Now you can switch between different OpenGL views and UIKit views without any problems. Just make sure to only render the visible views! That can be trickier than it sounds because the viewWillAppear and viewDidDisappear functions only get called for views that were layed out in the Interface Builder. If you added them by hand, you need to call those methods yourself (why??!?!). So keep tabs on that, otherwise everything will slow down to a halt.

And To Wrap It Up…

You thought I had forgotten about the promise to slowly unveil art from my current project, uh? Fear not, here comes the next teaser. This is an actually screenshot taken a minute ago. Incidentally, this is not one of the views using OpenGL. We’ll have to save those for another day :-)

- (UIView *)pickerView:(UIPickerView *)pickerView
        viewForRow:(NSInteger)row forComponent:(NSInteger)component
        reusingView:(UIView *)view;

Once I did that, the bug mysteriously went away. Ah, the joys of dealing with code you have no source to.

So being the tinkerer that I am, I couldn’t just stop there, and I spent an hour fixing something else that was annoying me to no end: When you start Tea Time! there’s always a “click” sound that the picker plays because I’m selecting the last used tea configuration during initialization.

I looked high and low how to fix that, but there seemed to be no way to do it. Nothing in the published SDK information that I could see. But digging through the header file for UIPickerView, I saw this:

@protocol UIPickerViewDataSource, UIPickerViewDelegate;

UIKIT_EXTERN_CLASS @interface UIPickerView : UIView <NSCoding>
{
 //... snip....
  @package
    struct {
        unsigned int needsLayout:1;
        unsigned int delegateRespondsToNumberOfComponentsInPickerView:1;
        unsigned int delegateRespondsToNumberOfRowsInComponent:1;
        unsigned int delegateRespondsToDidSelectRow:1;
        unsigned int delegateRespondsToViewForRow:1;
        unsigned int delegateRespondsToTitleForRow:1;
        unsigned int delegateRespondsToWidthForComponent:1;
        unsigned int delegateRespondsToRowHeightForComponent:1;
        unsigned int showsSelectionBar:1;
        unsigned int allowsMultipleSelection:1;
        unsigned int allowSelectingCells:1;
        unsigned int soundsDisabled:1;
    } _pickerViewFlags;
}

See that last flag? soundsDisabled. Sounds promising, doesn’t it? Unfortunately _pickerViewFlags has @package protection, which means I can’t get to it. Or so the theory goes.

Objective C is surprisingly “good” about letting you get under the hood and bypass protection levels. So I tried accessing those flags with NSObject function setValueForKey, but the stubborn picker would refuse to let me have access and throw an exception instead. Now he was starting to really annoy me. After all, I’m supposed to be working on my other project, not hacking this little app.

I couldn’t stop though. It’s not in my nature.

Oh yeah, Objective C is refusing to give me access to those flags? Fine. I’ll resort to the hackiest or hacks. But I will turn that damn bit off! An object is just a block of memory really, and each member variable is located at a fixed offset from the start of the object. See where this is going? Are you horrified enough? Yup. In the debugger I saw that _pickerViewFlags was exactly 16 bytes from the start UIViewPicker. So I grabbed the pointer to the picker, moved forward to the _pickerViewFlags variable, and stomped the soundsDisabledBit. Mwahahahaha! That will teach you, annoying picker!

Compile, run, and…. “click”. WTF!?!?!? I went in the debugger and checked that I was changing the right bits. Everything was fine. Except that, somehow, the picker was ignoring that. Defeated, I gave up in disgust.

It was that evening when I saw a tweet from @jeff_lamarche about accessing an undocumented function to turn off the sounds in the clicker. Nice timing! He pointed me to his blog post about how to get a listing of all the undocumented SDK functions and how to access them from your programs. I couldn’t believe that there was a function to do exactly what I wanted, but Apple wasn’t exposing it. And for something so simple too!!

It was as simple as

@interface CustomPicker(hidden)
- (void)setSoundsEnabled:(BOOL)isEnabled;
@end

followed by

    [m_picker setSoundsEnabled:NO];
    [m_picker selectRow:settings.m_teaType inComponent:0 animated:NO];
    [m_picker selectRow:settings.m_teaStrength inComponent:1 animated:NO];
    [m_picker selectRow:settings.m_teaFormat inComponent:2 animated:NO];
    [m_picker setSoundsEnabled:YES];

Finally! I had defeated UIPickerView!

Now the catch is, you’re not supposed to use undocumented SDK functions. Apparently that’s grounds for getting your app rejected by Apple and having to resubmit. But I figured I had nothing to lose, and it might be an interesting learning lesson. After all, how exactly does Apple check for undocumented functionality? Do they scan the submitted executable against a set of forbidden entry points? I couldn’t imagine that’s a manual process. But on the other hand, there are reports of other apps getting onto the App Store using undocumented SDK features.

I figured, what the heck, it was a tiny little thing that wasn’t going to hurt anyone. Might as well try it.

I went ahead submitted the update last Friday, and today (Tuesday) I got the official email with the approval of my new version. Not a bad turnaround time since I imagine they don’t work weekends. It even just made it to the App Store as I was writing this. Shweet!

I’m still left wondering how Apple tries to monitor undocumented SDK usage. Did they not bother with my app since it was so small? Is it really a manual process? (I feel bad for the person in charge of that just thinking about it). Did they catch it and realized it was totally harmless and let it through? Only Apple knows I’m afraid. They really should make their process both more transparent and more consistent and fair for everybody.

But hey, I’m not complaining. No more annoying click at startup :-)

So last week, I was excited to learn there was a new iPhone development conference  called 360|iDev (not the greatest conference name–sounds too much like an Xbox development conference). It looks like a very hands-on, for developers by developers kind of conference, instead of half-marketing, half-development like Apple’s offerings (Yes, we’re already on board, you don’t have to sell us on how cool the iPhone is. We know. We’ve banked our life and savings on it actually). The lineup of speakers looks really promising (including Urban Tycoon author, Mike Huntington).

What really excites me the most is meeting the other attendees though. It looks like it’s not going to be a huge conference (hundreds instead of thousands or tens of thousands like GDC), and we’re all staying at the same hotel, so there should be plenty of opportunities to meet people, chat, trade tips, and compare horror stories over beers.

I actually liked the idea so much, that I decided to jump in and submit a session proposal, and the organizers very kindly accepted it (which is great because otherwise I might not have been able to have afforded going :-)). I’ll be talking about my experience going from a AAA console development environment, to a single-person iPhone development team. Both the obvious differences, the not so obvious similarities, and how a single person can really deliver a top-notch iPhone game.

I encourage everybody to have a look at the 360|iDev site and register if you haven’t already. It’s not very expensive (especially if you buy the ticker sooner, rather than later), and it’s going to be a blast. It’s in San Jose in early March, a couple of weeks before GDC, so no conflicts for game developers there. Also, if you’re interested in speaking, check out their call for speakers while they’re still accepting new submissions. I hope to see some of you there!

On a totally different note, a couple of weeks ago, Evan at Veiled Games (Up There), which is one of my favorite indie iPhone developers, promised to put a daily image with a teaser of their upcoming project. This was soon picked up by Gavin at Antair Games, who is letting us peek under the covers of what’s coming up after Sneezies.

I figured it would be fun to follow their steps, but don’t hold your breath of a daily update. Maybe weekly if you’re lucky. Maybe.

So here’s this week’s teaser. Draw whatever conclusions you want from it :-)

I guess I really got out too easy and Apple had to remedy that. Today I found that Tea Time! shows up in the App Store listings, but it’s unavailable when you try to buy it. When I looked in the app management site, much to my surprise, Tea Time! was listed as “Pending Contract”.

What I thought was a relatively fast switch from individual to a company status, just propagated through their database and cancelled my previous contract. So I had to enter all the banking and tax information (exactly the same as before) and wait for the bureaucracy to approve it. So it looks like Tea Time! is going to be out of commission for a few days (or weeks or months?).

It really blows because it will kill whatever little momentum it had. Boy am I glad I went through this now and not with my other project!

The only difference is that now it’s listed with Snappy Touch being the seller instead of my name. Will this be the end of the App Store saga? Let’s hope so.

In the meanwhile, a sales update for those of you curious about it: In the first three days, Tea Time! sold 83 units. On one hand, that’s more than I expect (although I suspect that half of those are people following this blog and my announcement on Facebook). But on the other hand, it’s nothing if you’re trying to make a profit from it, even if it just took a couple of days to put together.

Granted, this is an extreme example. It has gotten exactly zero marketing of any kind, and it’s aimed at a very specific audience. I’m sure if a place like Republic of Tea or Adagio Tea advertised it in their catalogs, sales would go way up. But it gives you a base line of what you can expect in the worst case.

A couple of weeks ago, I decided to take a few days off from my project to enjoy the holidays with friends and family. Of course, I couldn’t stop thinking about the project. Soon my thoughts turned to how much more I had to go, and how some parts of the development process were still unknown to me, like the Apple submission process, or making a build for distribution on the App Store.

At that point, inspiration struck, and I decided to use one day during the holidays to write a quick, one-day app. That way it wouldn’t take any time away from my project and I would learn a lot from it. And maybe, just maybe, I would make a buck or two in the process.

The app itself was a very simple tea timer, inspired by tea maker machines: Enter the type of tea you want, the strength, and whether it’s loose leaves or in a bag, and it starts a timer with the correct steeping time for that particular tea. This was such a simple app, that it ended being exactly the way I had visualized the first time I thought about it.

Coding The App

Just coding the app itself was an interesting learning experience. Up until that point, I had spent most of my time on the OpenGL side of the iPhone. Tea Time! on the other hand, was 100% Cocoa Touch, so that was a nice change of pace.

Why did it take me a day? It’s such a trivial app that I should be able to throw it together in a few hours, right? Not quite. I had to deal with all the little quirks of Cocoa Touch, and get around the crippled functionality that Apple exposes in their API (while their own apps use a different API).

For example, it was a bit of a letdown to see I couldn’t add images to the picker control. But my disappointment was immediately replaced with excitement when I saw how easy it was to subclass it and display whatever you wanted in it. Unfortunately, the excitement gave way to annoyance trying to work around some of the bugs Apple still has on the picker control.

It’s really frustrating not having access to the same API Apple uses internally. I wanted to be able to turn off the iPhone while the timer was counting down, and have the device turn back on when the timer ends, just like the built-in alarm. Oh no, can’t do. Apparently that’s reserved for Apple. Fortunately, the longest you’re going to steep a cup of tea is 6-7 minutes, so I just disabled the power-saving feature of the iPhone so it doesn’t go to sleep while it’s counting down.

Even for such a simple application, getting a polished user interface in place takes some effort and time. The Interface Builder allows me to throw a user interface together in a snap just to get the basic functionality up and running. Later, I can come back and tweak it until I’m happy with it. Surprisingly, there are lots of things that the Interface Builder doesn’t allow you to do, so a lot of controls have extra code to tweak some of their parameters (increasing the target area of the info button on the top right corner, or setting the background images for he start/stop buttons, which require a special stretching pattern). Looking on the bright side, it’s very easy to combine a layout from the Interface Builder with custom code, which is a very important lesson for content-creation tools of any kind (and one that a lot of game tools get wrong!).

The rest of the coding time went into all the little things we don’t usually think about: Saving preferences, remembering the last used combination of parameters, getting the right splash screen, etc. All in all, the coding was about a day’s worth of work.

Creating The Content

There’s more to an app than code and a nice GUI layout, especially if you don’t want it to look like a boring spreadsheet: Graphics and sounds. In my first pass, while I was coding the basic functionality, I just grabbed whatever images I found through Google Images and threw them in. Then, once the app was pretty much finished, I set to replace them.

Original photo of my tea cup that became the icon for Tea Time!

That’s harder than it sounds because I’m not a graphic designer. I’m semi-proficient at the Gimp, but that’s about it. I do quite a bit of photography and I love tea though, so I decided to take pictures of the tea I was preparing at home. The main icon of for Tea Time! is just my tea mug with the tea I was having that morning.

The images had to be processed in the Gimp quite a bit. Tweaked colors and brightness, removed background objects, and even altered to fit the constraints of the GUI. For example, the little cups in the picker are the same picture that was then carefully colorized in the Gimp to match different tea types.

For the alarm sound, I was hoping to be able to play the system alarm sounds that come with the iPhone. But again, Apple lets us down by not giving us access to those (Why not???). So I hit a couple web sites with free sounds, selected a few that I liked, and tweaked them with Audacity to get the right length and sampling rate.

It was a really fun process getting all the content ready. I really enjoyed it and it was a nice break from coding, but it sucked almost another full day of work. So my “one day” app, was already almost up to two days. But at least I was done now. Right?

Submitting The App

I had done ad-hoc builds before, but I hadn’t prepared one for submission to the App Store. So I had to figure that out: Create a new distribution certificate, create a new configuration in XCode, test it… Not too bad.

Then I had to sign up for iTunes Connect and agree to a bunch of legalese non-sense. It was all done online and really quick, so that wasn’t a problem either. Finally I was ready to submit the app and be done with it. I had to write up a description, figure out the categories it would be listed under, take screenshots, and prepare a high-res cover art. I get all that ready, I fill out the submission form, and press submit. Done!

Oh wait, I get a message about not being able to get paid until I get a contract in place. What? Apparently when I signed up for iPhone development that only covered free applications, but I needed to set up a new contract in place with Apple if I was going to sell anything. So I had to enter bank ids, account numbers, tax information, and everything else. Once all that information was in place, my contract was in “Reviewing” state, and a couple days later it was approved without any hitches. Be warned that if you’re not in the US, apparently you have to mail a physical form to them before they approve the contract, so the process is likely to be much longer.

Along with the price (a very obvious $0.99), I had to set the “Availability date” for the app. I had read horror stories of developers who finally had their app approved, just to find it buried ten pages into the “New Releases” list in iTunes. The guys over at Veiled Games, explained how the release date is a combination of when the app is approved and the availability date you set. So I set the availability date to two weeks in the future and was ready to tweak it if necessary.

Are we done yet? Not quite. The submission page wanted a URL for a web page describing the app, and I didn’t have anything ready. I didn’t want to just point to a page in this blog, and I had been thinking that I should set up a company as a real legal entity for doing iPhone development and consulting. Fortunately, I had gone through this process before with Power of Two Games, so it was relatively easy and painless, especially since this was a single-member LLC. So the rest of the day was spent coming up with a company name (Snappy Touch), registering the domain (http://snappytouch.com), registering the LLC (in the state of Oregon no less because it’s a lot cheaper than California), installing Wordpress in the new domain, and setting up a basic page describing Tea Time!.

Finally done! Total time: Three days.

Waiting And Waiting

But Tea Time! wasn’t on the App Store yet. It had just entered the review process. Now I had to wait for Apple to approve it (or reject it so I can fix it). I heard from other developers that the usual wait time was about two weeks, but between this coinciding with the new year, and Apple getting swamped with submissions for the holidays, I figured I would be more like three or four weeks. Glad nothing was riding on this app getting out quickly.

A few days later, when I was checking out the info for Tea Timer! in the Apple submission site, while it was still in review, I was shocked to see it was listed as requiring SDK 2.2. That made no sense! I made a point to develop it for SDK 2.0 so every iPhone and iPod Touch user could buy it. I made really sure I selected SDK 2.0 when I created the iTunes distribution build. What gives? Apparently just building against SDK 2.0 wasn’t enough. I actually had to change the project settings to set SDK 2.0 as the default. That’s a sneaky one!

So what to do? I rejected my own binary and uploaded a new, updated one. This one was correctly listed as requiring SDK 2.0. I wasn’t too happy at having to do that because I’m sure it put me back to the end of the line, but this is exactly the kind of thing I was hoping to learn with Tea Time! in a no-pressure situation.

Waiting is no fun, so I made things a bit more interesting. Since I had gone to the trouble of creating a legal company, I decided to change my Apple Developer account to be a company instead of an individual. That way the company information would show up correctly in iTunes whenever Tea Time! was available. I figured this would be a matter of checking off a checkbox in my account settings, but apparently not. I had to email the Apple Developer Connection support with the request, wait a few days for an answer, and then provide some legal proof that the company existed (like the articles of incorporation). Once I emailed those, they initiated the conversion process, during which time I was locked out of my account for three days.  What does it take to change one bit in my account record??? Fortunately I had nothing else better to do than wait by this time, and it wasn’t impeding any work on my other project.

Finally!

The very next day after getting changed over as a company status, I got the much-awaited email from Apple announcing that Tea Time! was approved. That was just a week and a half after my initial submission. That was fast, especially considering I re-submitted the binary half way through. I reset my availability date to that day, and within a couple of hours, there it was, in the App Store. Mission accomplished!

Now, I get to learn about the sales reports, and, if I ever sell enough units, getting payments from Apple. They won’t make a payment until you accumulate at least $250 in profit from a single territory, so I’m not holding my breath for that one :-)

The “one day” app really took three days of work plus a week and a half of waiting. All in all, two weeks from idea to the moment it was available on the App Store. The process could be faster, but it wasn’t too bad. The experience was a lot of fun, and I certainly learned a lot from my mistakes and what things to watch out for next time, when it really counts.

What am I doing writing a little app like that? Don’t worry, that’s not what I’ve been doing for the last few months :-) It was an experiment to see how quick I could put a simple app together and getting the experience of going through the whole cycle with the App Store. Tomorrow I’ll write an entry with all that I’ve learned so far.

Enjoy your tea!

When: Wednesday January 14th from 7PM until whenever Where: Karl Strauss Brewery in Mira Mesa

Hope to see you all there!

I even ran it through some of the iPhone performance gathering tools and saw that it was spending half the time in the simulation and half the time rendering. A bit surprising, but it’s not like I had much to compare it against since this was my first performance-intensive iPhone app.

That was until this morning. Prompted by some of the comments in my previous post, I did a quick search about the iPhone floating-point performance. I had heard conflicting information on it: does it have hardware floating-point support? do you have to use fixed-point numbers for best performance? Apple is very tight-lipped about the specific hardware specs of the iPhone, which seems very strange to those of us coming from a console background. But people have been able to determine that the CPU is a 32-bit RISC ARM1176JZF. The good news is that it have a full floating-point unit, so we can continue writing math and physics code the way we do in most platforms.

The ARM CPU also has an architecture extension called the Thumb. It seems to be a special set of 16-bit bitcodes that claim to improve performance. I image the performance increase comes from a smaller code footprint and faster code fetching and processing. As a bonus, you also get a smaller memory footprint, so it seems like a win for a lot of mobile platforms. XCode comes with the option to generate Thumb code turned on by default.

But, and this is a huge but, it seems that floating point operations cause the program to switch back and form between Thumb mode and regular 32-bit mode. I would be interesting to look at the assembly generated, but I haven’t had time to do that yet. So the more floating-point calculations you do, the less of performance gain you’ll get from Thumb optimizations. Or, in the extreme, you might even get a performance degradation.

Most 3D games are very floating-point intenstive, and my app is no different, so I decided to turn off Thumb code generation on a whim. The results:

• Thumb code generation ON (default): 15 fps
• Thumb code generation OFF: 39 fps

Whoa!!! That’s a saving of 41 ms per frame! That has to be the optimization with most bang for the time spent on it that I’ve ever done. This also probably means that my app is now totally render-bound, which is good news. I’m sure I can optimize tons of stuff there

So if you’re doing any kind of a 3D game, turn off Thumb code generation. Now!

Edit: I realized I never explained how to turn the Thumb code generation off! Oops. Go to your project settings, add a new User-Defined setting called: GCC_THUMB_SUPPORT and set it to NO. That simple (but surprisingly there wasn’t an already existing setting to check it on and off).

Don’t worry, I’m not going to get into the details of the iPhone API. You can get all that and more from Apple’s iPhone development web site. I’m just going to talk about my experience starting with a new set of APIs and how they hold up in the process of a full project development.

Starting Out

Apple has done a great job holding the hand of developers new to the iPhone. As soon as you sign up for iPhone development, you’ll have access to several “Getting Started” documents and videos. Some of the videos are a bit on the fluffy, advertising side (“look at our new platform, it’s sooo cool!”), but they’re not a bad intro anyway. The docs on the other hand are pure gold. They’re a perfect introduction but with a fair amount of detail as well. They cover everything, from UI, to graphics and sound, to platform-specific features such as the accelerometer. I still find myself referring back to those every so often.

When the “Getting Started” docs aren’t enough, you have a full reference of all the classes and APIs at your fingertips, both online and through the XCode help system. I found the quality of the class reference to be pretty good. Usually, when something isn’t clear from the function name, the help is good at clarifying things.

I have to admit that I’m not a read-the-manual-first kind of guy. So while all those documents are great, and I use them a lot now, that’s not how I started out. Apple provides a bunch of sample code, covering all the major APIs, so I just downloaded the ones I was interested in, compiled them and fired them up. Then I used the docs to answer my questions about what the code was doing. The Crash Landing project was a perfect example of how to get started with games. I must have spent a whole day just pouring over that code the day I got my hands on the SDK.

Keep in mind that while Apple does a great job of getting the experienced developer up and running on the iPhone, they’re certainly not catering to new programmers. It’s a shame because the iPhone is such a fun, little platform, that I could see lots of kids wanting to jump in and getting their first real programming experience there. I hope that books and other resources pop up with that audience in mind.

Low Level Stuff

Things will look very familiar at the bottom of the API chain. Most of the low-level functionality can be accessed through pretty standard POSIX libraries: thread, file IO, sockets, etc,  all in straight C. My code ported over to using this libraries without having to make a single change.

As game developers, the first thing that we worry about is how are we going to do graphics. Fortunately, the iPhone includes an OpenGL implementation, so that’s very familiar territory. Specifically, it’s OpenGL ES 1.1 with a few extensions thrown in. The hardware itself is a fixed-function PowerVR chip with hardware vertex processing and texture combiners. Very 1999 :-) All of that makes writing 3D graphics app on the iPhone a breeze, even if performance isn’t top notch. At least they didn’t throw yet another proprietary API at us.

Surprisingly, the online help falls short with OpenGL. There are actually hardly any docs on that, and they mostly cover a couple functions to interface with their view system. I guess they figured you can just go to the internet and read all about it there, but I would have expected them to integrate them with the rest of the references at least.

OpenGL meshes relatively well with the user interface libraries, in the sense that you can render to almost any surface and combine it with other user interface elements. Unfortunately, it seems that putting any user interface views on top of OpenGL causes pretty major performance hits, so the integration isn’t perfect.

I haven’t used it yet, but Apple also provides the Open AL API for 3D sound. Again, props to Apple for sticking to an existing API.

Cocoa Touch

This is where the real fun starts. At least for me, this is all new territory. Mac programmers should be a lot more familiar with it. Cocoa Touch are the libraries for all the high-level user interface and accessing device-specific features. Since the iPhone is such an interface-centric device, this is where a lot of your time is going to be spent. The exception is if you decide to make a game that is 100% OpenGL, user interface and all. In that case, you’ll only be using this layer to access a few things, like touch inputs and accelerometer readings.

My impression coming to Cocoa Touch from an MFC/WTL/.Net background and no Cocoa experience was a breath of fresh air. Sure, the interface on the iPhone is simpler than the horrible monstrosities you can create with MFC, so maybe that’s why the API seems simpler. But whatever the reason, it just makes sense. You have one window, views, and view controllers. Once you get how they relate, the rest just comes together. I find myself guessing how things should be and getting it right most of the time. That tells me they’re doing something right (for the record, I never manage to guess anything with the .Net framework and it’s always a struggle).

When something isn’t obvious, you can look it up in the extensive online help, or just crack open the header file and look at what properties each class exposes. The class hierarchy isn’t too crazy, and each level adds a manageable number of functions.

It’s also really easy to extend controls and create your own versions to have special behaviors or even draw them in different ways. To me it was always a pain to create custom controls in MFC with their own rendering, but here it’s a breeze.

I also really like how a lot of controls don’t own your data, or even keep a copy that you need to refresh, but simply ask you for it when they need it. For example the picker (which you can quickly guess it’s called UIPickerView) will ask a delegate how many columns and rows to display and what data or views to render in each of them. Nice and simple.

We’re done with the fan boy raving. Not everything is perfect and some things are downright annoying.

Initialization of views and view controllers can be a bit weird. Sometimes the initFromNib gets called, sometimes it’s the viewDidLoad, sometimes it’s none of those and I have to hook up the loadView function, and sometimes I just have to make one myself. All depending on how the particular view gets created. Annoying.

Then there are some bugs and weird behaviors that you have to put up with. Because Apple doesn’t provide the full source code, you can’t just fix them or copy them and make your own version. Some controls are pretty elaborate so writing them from scratch is quite time consuming. For example, the segment control behaves as a toggle if you only have two segments, but as a button if you have more than two. There is a boolean variable that allows you to turn the toggle behavior off, but, guess what, it’s protected. So to make such a simple change, you need to create your own class and extend the UISegmentedControl. Doh!

Sometimes you’re not even so lucky. Looking at the header file for the UIPickerView class I noticed there was a flag to turn off the sound it makes when rotating the wheels. But it was marked as private (as @package actually), so I couldn’t do a thing about it. Double doh!

And it’s more than a flag here or there. Maybe you’d like to change the background of the picker, or the way the selection works? Out of luck. That’s all neatly wrapped up inside the picker class itself and you have no access to it. If you want to make a change, you need to reimplement it all from scratch. Hopefully Apple will continue refining the API and exposing more functionality where needed.

All of this leads me to my number one complaint about the Cocoa Touch API. It’s something that annoys me profoundly and I can’t believe Apple is doing. The API you have exposed to you is different than the one Apple uses internally. Why oh, why?? It violates everything I hold true and sacred about library and API design. I understand their wish to keep thing simple and clean, and to provide good documentation to everything is there. They managed to do those things admirably well. But why not provide whatever API calls they consider to be “expert” without documentation and a big warning saying you’re on your own? Why???

But wait, it gets better. Apple has been actively rejecting apps from the App Store from people who went to the trouble of reverse engineering the libraries and calling undocumented functionality from them. What is up with that? Is it Apple’s way of ensuring future compatibility? Then how are their own apps going to work when changes happen since they’re obviously using a bunch of undocumented features. Not only that, but they get it wrong sometimes!

I thought this was as bad as it was going to get, but wait, there’s more. Apple is playing favorites. So if you’re a big company and have two Os in your name (and your name doesn’t start with M) then you get to use their undocumented APIs without getting rejected. How totally annoying is that?

All In All…

Apart from the questionable decisions of what to expose in the API and a few stray bugs, the iPhone has a great set of APIs to develop for. I found it really easy to get into them and became productive in no time. If only they would expose the full functionality, it would be an almost perfect setup.

I loved the sound of that! I’ve been an indie developer for a year and a half, and I’m seeing more and more people taking tha route. I think indie development is necessary for a healthy game development industry. Where else are people going to try weird ideas, experimental development techniques, an commercially unproven designs? I think it’s a sign of maturity that we’re seeing a need filled by independent development next to the Maddens and Worlds of Warcraft and other chart-toppers.

I think 2008 will go down as the year that indie games made it to the big time: Braid, Schizoid, and World of Goo are just the top of the iceberg. It showed that it was possible to become an indie developer and make a living from it. 2009 has to be the year that indie development really explodes, right? The trend is certainly there. I’m constantly hearing about people or even whole teams leaving large development houses and starting their own, small companies. These developers are not trying to become the next EA, but they want to keep things small, creative, and, above all, fun.

If the only path for indie game development were downloadable console games on XBLA and PSN, the future wouldn’t look so bright. I used to be really excited about those platforms, but the restrictive zeal of Microsoft and Sony, the dingy royalty deal on XBLA, plus the high-development costs required for most games in those platforms, makes them very difficult to develop for and make any money from them. More and more, I’m hearing of donwloadable console titles with budgets around a million dollars. A million dollars!! That’s “just” a tad bit out of my indie pocket range.

Fortunately there are other paths. We have the usual PC market, which seems to be on its way to being abandoned by the major players but leaves a void for indies. Some guys seem to be doing well there, especially if you consider the Mac and Linux markets in addition to Windows.

Then there’s Nintendo’s WiiWare, which seems surprisingly much more open than the Xbox360 or PS3. I don’t have any friends who are personally developing for WiiWare, but I hear the barriers of access are not insurmountable. I’d love to see some sales numbers though. Nintendo certainly has the name to attract players and developers. Maybe they need to open up their DS development a bit too. Bob would like that for sure!

And then we have our last, best hope for indie game development: The iPhone [1].

The iPhone seems to hit all the right marks: Hardware advanced enough that you can develop really interesting and good-looking games, yet simple enough that one or two people can create a top title. Very open (the SDK and tools are available for free to anyone!!) but with a very clear distribution channel.

Given the low prices of games (between $0.99 and $10) on the iPhone, not only is it possible to make great games with a team of two people, but actually having larger teams can make development much less profitable. I can’t imagine how EA or Maxis are making any money from their iPhone games if they put even just 10 or 20 people to work on them for a few months.

In order for indies to succeed in the app store, it’s important that we get enough visibility. Right now, the big money is on the top lists that Apple publishes which are unfortunately out of reach for most of us. A trend I’ve noticed lately is that big publishers are starting to elbow out indies out of the Top Ten charts. I hope that’s not a trend that continues much further.

I’m glad to see that the app store has related links when you browse a product, and also a variety of independent web sites that are appearing trying to sort the iWheat from the iChaff. It’s a start, but we need more initiatives along those lines. In the meanwhile, support your indie iPhone developers. Or at least go out of your way to learn a bit more about them. If you haven’t seen it already, check out the New Year’s App Blowout Sale and pick up Sneezies, Up There, and Mouse House. All three totally adorable, very polished games.

Happy New Year 2009 to everybody! I’m sure this year will bring a lot of surprises and interesting developments.

[1]Yes, I shamelessly stole that line from my favorite sci-fi show.

I’ve only been doing iPhone development for a few months, so I don’t claim to know everything. But they have been some intensive couple of months, that’s for sure. This is my attempt to share my experiences, and hopefully encourage more game developers to take the leap and consider this really fun little machine.

As I explained in a previous post, I was a Mac-virgin. Sure, I had used one here and there, but never as my primary platform. Not only was I able to get up to speed and functional in a matter of days, but I totally love it and switched to it as my main computer. So, with that out of the way, how about the iPhone development itself? Over the next few days (or weeks, depending how busy I get), I’ll try and cover the major areas of iPhone development that I’ve experienced so far.

Let’s get the most obvious one out of the way: Objective C.

Somehow, its very mention seems to fill people with fear. When other programmers hear I’m doing iPhone development, they lower their voice, they get closer, and ask “Do you _have_ to write it in Objective C?” I think the main reason people are scare of it is because it’s not very well known. It’s not a sexy newcomer that the web is buzzing about like Rails, or a language with the backup of corporate giants like C# or Java. Objective C has been around since the early 80s, which is pretty amazing because it feels very modern in a lot of its features. Frankly, I’m surprised that Microsoft chose to create C# instead of adopting/extending Objective C (or maybe I’m not that surprised coming from Microsoft–OK, that was the last dig at MS and C# for today. Promise).

I had never used Objective C before I started doing iPhone development, but it was a breeze to get up to speed coming from a strong C and C++ background. The most important thing is that the interop between Objective C and C/C++ is nearly flawless. It’s a pleasure to call Objective C functions from C++ and the other way around. So much so that the lines get all blurred between what is what. Take that C#! (oops, so much for my promise).

Objective C is organized like C++, with header files and implementation files. That’s both good and bad. Good because it’s familiar, it gives you a good separation between the public interface of a class and its implementation, and allows for fast build times. But it’s bad because there is some annoying duplication between both files. Fortunately, Objective C gets this one right (again), and allows you to keep the header file to purely the public interface of the class. That means I can declare all the private member functions in the implementation file, which keeps duplication to a minimum.

A word of warning: You’ll probably have to change all your .cpp files to be .mm so they compile as Objective C and you can freely include any Objective C headers. Also note that Objective C files are usually .m which only parses C header files. If you need to call C++ files you need to make them .mm, or you’ll get some really bizarre errors.

If you’re really a died-in-the-wool C++ fanatic, you can isolate yourself from all the Objective C stuff by writing a few wrappers that interface with the operating system. If not, you can go with the flow and embrace it and use it when it’s needed.

Assuming you’re willing to look at Objective C, how is it coming from a C++ game programming background? At first glance it’s a bit ugly. I admit it. It looks like it’s full of - and + and [[square:brackets] everywhere]. But it’s very superficial. Objective C is a superset of C++, which means they introduced a different way to create Objective C classes (as opposed to C++ classes). The worst thing about the brackets, which are used for sending messages to objects, is that typing them is cumbersome. I often find myself having to move back to the beginning of the line to add new brackets as I’m making new function calls.

Internally things are much more dynamic than C++, and instead of member function calls they’re really messages that get passed around. That makes it easier to deal with null objects or objects that might or might not implement specific interfaces. I don’t know if you can add new message handlers on the fly, but I suspect you could (although why you’d want to do it other than for geek achievement points is beyond me–I’ve certainly never felt the need to do it).

One of the features that I’m using quite a bit are properties. You can declare member variables as properties, tag them with what kind of access is permitted (read-only, read-write, whether you want to take ownership or not, whether it’s an atomic assignment, etc), and all the code is automatically provided for you. Nice time saver.

Protocols are also a nice, clean way to provide interfaces. Certainly much better than the madness of C++! It makes working with objects that implement certain interfaces very easy. It’s also really easy to pass “pointers” to specific member variables through the use of selectors.

Enough with the raving. What’s not to like? Only a couple of things, really. Or at least so far. Ask me again in a year and I’ll probably have a laundry list of complaints. I doubt it will ever reach my level annoyance with C++ though. That’s pretty much impossible.

My biggest complaint about Objective C is that, get this, C++ constructors for member variables in Objective C classes are not called. Yup. You read that right! I’m sure there’s a good reason, but it does suck. Fortunately most of the Objective C code is high level classes, so it’s OK to new the C++ classes I need to work with. Still, it’s annoying. I also wish that Objective C played better with namespaces, but that’s a relatively small complaint.

This might sound like a strong statement, but if I were to design my ideal development language today, it would be pretty darn close to Objective C.

Something I still don’t know much about: Performance. I haven’t been doing much profiling on the iPhone yet, and all my performance-sensitive parts are written in C++. Still, I’d be curious to see how much overhead Objective C adds on top of C++. I suspect that a fair bit given the message-passing architecture and the more dynamic nature of the language.

Someone asked me what am I using for unit testing with Objective C. Hmm… errr… I’m not doing any unit testing in Objective C. There I said it :-) Not yet anyway. I’m sure I will as soon as I start using more of it. Most of the Objective C code is high-level code interfacing with the iPhone API, so I haven’t felt much the need to use TDD with it. If anybody has some recommended Objective C unit-testing frameworks that are lightweight and minimalistic, I’d love to hear it.

If you’re interested in learning Objective C, this document was the best resource I found to learn Objective C. It’s simple enough that you can use it to get up to speed, but detailed enough that I still refer to it from time to time. I haven’t felt the need for any books or any other tutorials.

Coming up next: The iPhone API, Xcode, and more goodies.

Starting iPhone development was a bit of a change since it required me to work exclusively under OSX and use a new IDE (XCode). I had talked to people who found the change very cumbersome and found the new environment got in their way, so I approached it with a bit of trepidation.

It’s An OS X World

With my new Macbook Pro under my arm (actually, it wasn’t new, I bought it used off Craigslist because I couldn’t afford a new one), I embarked on an adventure to this strange, new world of OS X development.

Some background is necessary here: I"m a minimalistic, no frills kind of guy when it comes to my preferences when working with computers (although now that I think about it, it probably applies to most other things in my life as well). The first thing I do with a new install of Windows is turn off all the GUI animations (don’t get me started on the search puppy dog!!), most of the sounds, all the auto-complete and auto-spellcheck features, and automatic upgrades. When I want the computer to do something, I’ll tell it to do so. Otherwise I want it to be quiet and responsive.

My ideal Visual Studio setup is also pretty similar: No fancy web startup page, no animations, no autocompletions by default (unless I press CTRL-Space), out with all the toolbars, just give me two text windows side by side and control everything from keyboard shortcuts (which I’m still using the ones from Visual C++ 6.0).

Needless to say, I was afraid of clashing with Mac OSX’s environment. I had a suspicious that it was full of eye candy, GUI frills, and required a mouse for everything. Not a good match.

There wasn’t as much of a learning curve as some getting-used-to. There are some Mac quirkiness that I just don’t get: The disembodied menu on the top of the screen, the lack of change of mouse cursor when you can resize a window, or not being able to automatically restore a file to its original location from the recycle bin.

But those are all relatively small things that don’t overshadow the fact that I just love this new environment. I used to like the Windows fonts, but after a week of using a Mac, I can’t go back to those tiny, jaggedy Windows fonts. Handling of multiple monitors is perfectly integrated and works like a charm. In general, things Just Work (TM).

Then there are the things that I love from my time in Linux that I can’t live without: Multiple desktops with Spaces, a decent command line shell, or being able to tweak settings directly in low-level config files.

And the thing that has changed how I work the most: Spotlight. No need for icons everywhere, or “Start | Programs” or anything. Just start typing what you want and there it is. It’s like the return of the command line on steroids. Between Spotlight, Firefox smart locaton bar, GMarks, and Ubiquity, I feel right at home. Now combine them all somehow and I’ll be in heaven!

But Wait, What About Windows?

I ended up falling in love with OS X so much, that I quickly moved to it as my primary environment at home for everything. Frankly, these days, it’s pretty easy for me to change environments since most of what I do is online. Just give me Firefox (or a good browser) and I’m there: GMail, Google Calendar, Google Reader, Google Docs (hmm… I sense a theme here), and a Wiki cover most of what I do on a daily basis.

For the rest of the apps, almost everything I need runs under OS X: good media visualizer (Preview), photograph organizer (Lightroom), image editor (The Gimp/Photoshop), audio editor (Audacity), music player (iTunes), and a few more odds and ends. OS X comes with some great utilities out of the box too, like Grab, Preview, or Activity Monitor.

Unfortunately, there are still a couple of things that I can only run under Windows. The main thing are games unfortunately, so I need to keep my Windows box around just for that. Although I just started playing World of Warcraft and it runs great on my Mac. Thanks Blizzard! Apart from that, every so often I need to do something in Visual Studio, or run some application I wrote in .Net. For that, I go about it in two different ways.

I can run it on the Windows box itself. Instead of keeping two sets of keyboards and mice (or a switch box), I used Synergy for a while. It was pretty cool being able to move the mouse cursor from one screen on the Mac to the screen on Windows and continue working there, and that might be a great solution if you’re working 50-50 on both platforms. In my case, it was more like 90-10 at the time (more like 99.9 to 0.1 now), so it felt a bit of a waste to have a full monitor dedicated to Windows. Instead, I decided to use Remote Desktop to control my Windows computer from the Mac. Amazingly enough, Microsoft wrote a Remote Desktop app for OS X that works like a charm, much better than some of the VNC programs I tried.

Whenever I don’t need to run something that is performance critical, I reach for Fusion. I’ve tried many products in the past that claim to run programs for another platform in your own computer: Wine, CrossOver Office, earlier versions of VMWare, but they’re always plagued by problems and incompatibilities. VMWare Fusion really surprised me by running anything I threw at it flawlessly, including Quicken (yes, I need to switch to Mint or Buxfer) and some hardware-accelerated 3D programs (those were a bit chuggy though, but they worked). And the coolest feature ever: Unity–I can run Windows apps in a window of their own directly on the Mac desktop. Totally awesome! On top of all that, I can have multiple snapshots, restore earlier states, and I can even run other operating systems like different versions of Linux. A geek’s true dream!

Some people will claim that I have drunk from the Apple kool-aid, and to a certain extent, they’re right. But I’d like to think I was swayed by many good reasons having to do with using the computer and being more productive, rather than Apple’s brainwashy, lifestyle marketing message. That and the smooth feel of the Macbook against the palm of my hands, its sleek profile, and sexy design. :-)

What about XCode and development? That’s another story for another day.

The big news is that we decided to call it quits on Power of Two Games. It was an amazing experience and I learned a huge amount. I’m sure we’ll write a postmortem with some of the gems we learned along the way sometime soon. Unlike most postmortems, we really don’t have any office politics, bosses to suck up to, or publishers to keep happy, we’ll be able to be brutally honest.

Against my better judgement, especially with the current horrible economy, I’m still burning the indie development candle. This time by myself and on the iPhone. I’ll get into many more details in the future, but so far iPhone development has been surprisingly fun and smooth.

One of the most attractive things about iPhone development is the short projects. Some of the top selling iPhone applications were written in just a week or two. The game/toy I’m working on is a bit more involved than a fart generator or a rotary dial, so I expect it will take me a total of three months. Still, much better than trying to make a game for XBLA or PSN!

Another big plus of iPhone development is the approval process. Yes, Apple needs to approve the application, but the process is infinitely simpler than trying to certify your PS3 or 360 game. I haven’t gone through that myself yet, but that’s what I keep hearing from other developers.

And then you have the App Store. Ah, the App Store. A captive audience of impulse-buyers with their credit cards already in the system because of iTunes. Genius. The cut that Apple takes is very reasonable, just 30%. Let’s hope they keep it that way and don’t pull the Microsoft move on us!

So, what’s not to like? That everybody and their grandmother is writing iPhone apps and throwing them on the App Store on the hopes of making a quick buck. And the worst thing is that it’s actually working. So people keep gambling with crappy apps hoping to become the next iBeer or Koi Pond. As a result, the App Store is flooded with stuff, most of it horrible, some OK, a few good, and a very few great apps. Right now the App Store interface isn’t ideal for discovering new, high-quality games and applications, and most of the exposure is limited to the Top Seller lists. I’m hoping in the next few months they move towards something more along the lines of Amazon.

And speaking of interfaces, whose retarded idea was it to only be able to access the App Store from within iTunes? I like Apple, and I’m totally digging Mac OS X (more on that later), but I hate having to use a slow, bloated application to do something that amounts to browsing a few web pages. Besides, you’d think they would hook more people by making it more accessible. Oh well. That’s not changing any time soon.

Stay tuned for more updates on my iPhone development adventures and maybe, just maybe, an early glimpse of the game :-)