I’ve been receiving a lot of questions about how it happened, how’s affecting me, and what my plans for the future are. So here’s my attempt to answer some of those questions.

The Game

It might come as a surprise to a lot of people, but selling Casey’s Contraptions was never in our minds. Miguel and I put all our energy into making a great game and infusing it with lots of personality. Half way through development we realized we had something special in hand, and when Apple selected it as the iPad game of the week and the reviews and comments came pouring in, we knew the game had connected with a lot of people. We were thrilled.

We were in for a big surprise when sometime after the iPad release, Rovio approached us and offered to buy Casey’s Contraptions. We were understandably very attached to the game we had just released, but Rovio eventually made us an offer we couldn’t refuse.

Rovio is one of the biggest players in the mobile market, and sometimes people get tired of seeing the top 10 charts full of Angry Birds. I’ve always had a lot of respect for them: Angry Birds wasn’t just a fluke, it’s a super approachable game, perfectly suited for mobile phones, and crafted to perfection. They deserve all the success they got. I don’t think I would have agreed to sell Casey’s Contraptions to most of the other big game companies.

As the co-creator of Casey’s Contraptions, I’m super excited to see it reach a much wider audience we could have ever dreamed of reaching ourselves. Every developer’s dream is to see people playing your games, and Rovio can make that happen with their huge marketing power and influence. Just look at all the media sites covering the news for the Amazing Alex announcement (most of those sites never talked about Casey’s Contraptions at launch ).

Miguel and I chose not to be involved in future development of Casey’s Contraptions/Amazing Alex. As an indie developer, your time is the most limited and precious resource. Every game you release takes some of that time away even after it launches: new content, higher-resolution graphics, fixing problems with the latest OS version, porting to other platforms, etc. This was a great opportunity to pass the baton to Rovio and be able to focus 100% on new creative projects.

Yes, it’s hard to let go. Not like I have experienced that yet, but it probably feels like sending your kid to college, knowing that he’s starting a new life without you. At least we can rest easier knowing Casey is in good hands. Whenever Amazing Alex becomes a worldwide hit, we can proudly point to that and say we started that game.

Personal life

On a personal level, my life hasn’t changed at all. Flower Garden has been doing a good job at keeping my family fed for the last few years, so getting more money doesn’t have a huge impact. This unexpected deal bumped up those numbers in the bank, but hasn’t otherwise changed much for me. No Ferraris in the garage, or even, for those who know me, no fancy new road bikes (still riding my trusty 12-year old Trek 5200). The only splurge was buying a 30″ Apple Cinema Display.

The deal has, however, definitely affected my future projects. At one level, it means I don’t have to worry about funding for my next few games, which is great. Both Flower Garden and Casey’s Contraptions were done on a minimal budget. Now I can afford to spend more money in areas where it can make a difference, and be able to offer people money up front instead of just some percent of royalties.

One thing I never want to do is have full time employees though. Full time employees bring constant burn rate, and start adding a sense of pressure I do not want. One of the best things about being indie is the flexibility that it brings. Collaborations with other indies have worked really well so far, and I’ll continue to do that as much as possible for future projects.

The other way the deal has affected my future projects is that there will be more pressure to follow up Casey’s Contraptions with a great game. Even though Casey’s Contraptions is the same it was a few months ago, the fact that it was bought by Rovio will make a lot of people take notice and compare it to any of my future games.

I’ve already been struggling with those effects for several months. I’ve been making and discarding prototype after prototype. More than half of those would have made for fine games, but I have no desire to release a “just OK” game for the sake of releasing something. I’ve also decided that I’m not even going to consider potential for financial success for my next game. It’s not going to be aimed at the mass market, it’s not going to be full of zombies, and it’s certainly not going to be a typical freemium game.

Whatever my next game is, it’s going to be a more personal, more niche game. Something that I can be really excited about working for however many months it takes, and something I can be really proud of after launch.

Bye, bye Casey! We’ll miss you, but we can’t wait to see what you do out there!

Here are a few pictures from the new office. Things aren’t completely set up yet (that bare wall is waiting for some Flower Garden and Casey’s Contraptions posters that should be arriving today).

The thing I like the most about this office is the light. It’s a corner office and it’s aiming north, so that means great, indirect light all day long. Oh, and the windows can be opened to let some fresh air in. That might seem like an odd detail to mention to some of you, but you’d be surprised how many office buildings in the US have windows that can’t be opened. Really.

Both desks are adjustable, standing desks. The main desk in the pictures is the large frame GeekDesk one. I used to have the small frame because I didn’t have the room at home, but I love the extra space, especially with the 30″ display! I’ve kept the small desk to the side, that way I can invite other people to come work from here for the day (indie work day!) or even (gasp) hire someone if the right time comes.

The rest is pretty standard: whiteboard (I prefer use one much larger, but that’s what I had around), bouncy ball (gotta have a bouncy ball!), and couch (pretty important to unwind, or just to take a break from standing all day).

So far, I’m very happy with this setup. Working from here is definitely invigorating, and the separation between work and home helps a lot in both locations. Maybe once our daughter is older and going to school I’ll consider working from home again, but this is perfect for now.

What does your work setup look like? Post some pictures and let me know. I love seeing other devs work setups.

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.

Fortunately, display technology caught up over the years and I’ve been happy with the LCD monitors I have since then.

Until now.

I’ve been looking into large LCD monitors to set up in my new office with my Macbook Pro, and I find myself pushing into the limit of technology once again. The results: I went through 3 monitors of about $1K each. Two fell completely short, and one was perfect.

The Shiny: 27″ Apple Thunderbolt Display

The top contenders starting out were the 27″ Apple Thunderbolt Display, and the 27″ Dell U2711. I read reports that they both use the same display technology, and the differences between the two were relatively minor. After some conflicting reviews (that should have been the first warning), I decided to go with the Apple Display.

This display seemed perfect for me. It looks gorgeous, like an oversized iPad. The image quality is fantastic, with text being sharp and clear and having a great resolution. Since I’m only connecting a Macbook Pro to it, the connections are perfect: The Thunderbolt cable is great because it deals with display, USB, ethernet, and even audio in one fell swoop. The display also has a power cable for the Macbook Pro, so it’s like a perfect docking station.

It really was almost perfect. Almost.

The glare was simply horrible and I could see myself reflected on the screen, even with a white background. The shiny display was almost a perfect mirror. It might be the ideal display if you like to work in a dungeon, but I like light, the more the better. Even though my office has no direct sunlight, just the indirect light coming in was enough to see everything brightly reflected on it.

One possible way to work with the Apple Display

What’s worse, if one day I had to rearrange things or move to a different office and I had a window behind me, it would go from distracting to impossible to see anything.

Another annoying aspect of that monitor is that the stand height wasn’t adjustable. I like to look at a monitor straight while my arms are about a 90-100 degree angle, so the monitor ended up being several inches too low. I can do the old phone book trick, but it seemed ridiculous having to do that on such a beautiful display.

As much as I liked that display, it just wasn’t for me.

The Ugly: Dell U2711

In spite of some comments complaining about “over aggressive” anti-glare coating, I decided to give the Dell U2711 a try. I had used Dell monitors before and I was never bothered by the screen. And after all, the antiglare coating could fix the problem the Apple display had. Apart from the antiglare, it had some attractive options: Multi-card reader, several video inputs, and better color options. It could be the perfect screen.

It turns out it was far from that. It was the opposite of the Apple display in many ways. Connecting it to the Macbook Pro was a hassle since it shipped with a Displayport cable, but not a Mini Displayport one. I tried using my Mini Displayport to DVI adaptor, but it turns out it was single-link and you need a dual link to drive the full 2560 x 1440 resolution.

Once I finally got it up and running (with a Mini Displayport to Displayport cable), the resulting image was plain ugly. The colors were off, but more seriously, the antiglare coating really was horrible. It made the screen look like there was a fine coating of dust on it, or like it was film with a very obvious grain to it. I had to strain my eyes to focus on the text because the graininess kept throwing me off.

I suppose I could have gotten used to it, but since I use the Macbook Pro display next to it, going back and forth was torture. One moment I would see this clean, sharp, beautiful display, the next moment I would see this horrible grainy mess.

To make sure I wasn’t hallucinating, I took a picture of both displays with my iPhone displaying the same content. The differences are obvious (click on them to see them full size).

Macbook Pro with antiglare

Dell U2711

In case that wasn’t enough, the colors were severely off. I played around for an hour with the custom settings and some advice from the internet, but I just managed to make them a bit better. I still liked the colors on the Apple Display (or the Macbook Pro) way better.

The Good: 30″ Apple Cinema Display

At this point I thought I was out of luck, and that I was going to have to settle for either one of those two monitors (I would take the 27″ Apple one), or something smaller but without those problems.

Fortunately, several people on Twitter encouraged me to try out the 30″ Apple Cinema Display. I never saw paid attention to one, but apparently they had fantastic image quality and a good antiglare coating. That sounded promising!

One of the pleasures of being a small company is that once I decide to do something, I can do it right away. There’s no paperwork, approval, ordering through certain channels, or any of that overhead. Since Apple doesn’t make that display anymore, I hopped on Craigslist, called a guy up, and picked it up a few hours later. Done!

And boy was I glad I did! That monitor is everything that was cracked up to be and more! Since it’s an older display, it doesn’t have Mini Displayport cables, so I had to use a Mini Displayport to Dual DVI adaptor. The image quality is indeed, outstanding, and the colors are quite good (although maybe a touch redder than the laptop).

I actually love that it’s a 16:10 ratio instead of the more common 16:9 in most monitors today. That gives results in a resolution of 2560 x 1600, which gives me some much-needed vertical space when writing code (which is 80-90% of my day).

As a totally minor, but nice side effect, the brightness controls on the keyboard control the screen brightness (which is kind of surprising considering it’s connected over the dual DVI adaptor, but there’s also a USB cable going into the display, so maybe it’s communicating through that channel).

The only drawback is that the back only has two USB ports (I wish it had 4 or more). It does have two Firewire ports as well, although I don’t have any devices that use those.

For completeness sake, I took a picture of the new monitor with the same image I used as a test earlier. It shows how much cleaner the image is than the Dell.

30″ Apple Cinema Display

Conclusion

From left to right: The shiny, the ugly, and the good.

If you’re picky like me about the quality of your displays, and you’re looking for a large monitor, I can’t recommend the 30″ Apple Cinema Display enough. It’s a shame that Apple stopped manufacturing it, so check Cragislist or Ebay for it. If you work in a dark place, maybe the 27″ Thunderbolt one will work as well. Whatever you do, stay far, far away from the Dell one.

We can only hope that Apple will make a revision of the 27″ Thunderbolt Display soon with a high-quality antiglare coating like the laptops. In the meanwhile, I’m thankful both Apple and Dell have good return policies.

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!

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.

Brewing

A new game for me starts as an idea somewhere, sometime, that got jotted down into my “game ideas” personal wiki page. I have that page accessible 24 hours a day on my computer, iPhone, or iPad. Only while I’m running/cycling or in the shower am I away from that page (and unfortunately, that’s the time when most ideas seem to spark). I make a point of not censoring any ideas: If I thought that something would be neat (not just gameplay, but a setting, a visual, a mechanic, or anything), I jot it down.

Over time, I accumulate quite a few ideas. Every so often I review them and I might expand on some and flesh out sub-ideas. Or they might spark different ideas of their own and I jot them down too. I never delete any of them, because I’m consciously trying to not censor anything yet. This is purely brainstorming mode. I’ve even sent emails to friends about possible game ideas straight out of this list, crappy ideas and all.

During this time I’ll rearrange the list. I’ll move more likely ideas up, or ones that I’m more excited about. That has the effect of a kind of bubble sort, so the better ideas somehow rise to the top (except for the brilliant ones hidden in the depths somewhere).

This list is particularly useful when I’m in the middle of a project and I have what seem brilliant game ideas. Do I put the project aside to do this great idea instead? No. Instead, I add it to the list with all the others. If I’m really excited about it, I’ll flesh it out as much as I can, but it needs to wait its turn. As you can imagine, after a few days, the idea doesn’t seem so shiny anymore, so it was a good thing it didn’t derail the current project.

Struggling

Eventually the time comes when I need to pick a new project, and this is where the fun and the pain start.

You would think a good approach might be to read the list and start evaluating ideas. In a way, that’s what I do, but before I evaluate ideas, I need to some frame of reference to decide what’s a worthwhile idea and what isn’t.

In the past my criteria for considering a project involved the intersection of three requirements:

• The game must be interesting for me to work on. I want to learn something new and be excited about what I do. Not interested in cloning something or making a derivative game.
• A game I can realistically implement with the resources at my disposal. I’m not an artist, so that usually means not having a content-heavy game, and relying on code as much as possible (like the procedural geometry in Flower Garden–no artist modeled those flowers by hand).
• A game that has potential to sell well on the target platforms.

Unfortunately, meeting all those three requirements at the same time isn’t easy, especially given the astounding number of games already on iOS.

Before I go any further, I need to step back and ask myself a very important question: Why do I want to make this next game? This is a question we indies have the luxury of asking (and answering). I think most big (and small) studios are too busy staying afloat to be able to ask anything like that (besides, the answer is almost always “make more money” for them).

It turns out the indie life is treating me very well, so making lots money isn’t one of the main reasons to make this next game. That means I can safely remove that requirement from my previous list, which grants me a lot more freedom.

I’m probably going to spend the next 6 to 10 months working on this project, so it needs to be worthwhile. Does it need to be innovative and break new ground in a way no one has seen before? Does it need to make hard-core FPS players cry to be worth considering? Does it need to be radical, pixelated, mash up 5 different genres, an win the IGF and respect of my peers?

It turns out none of those are the reasons that drive me to make games. In the end, when I look deep down, the reason I want to make games is for the pleasure of taking a vision from the initial idea to something people can play. It’s the creativity involved that drives me. I imagine it’s the same reason people are driven to write or paint. If along the way, some of those games manage to be innovative, make money, or win an IGF award, that’d be fantastic, but in any case, the development process is its own reward.

Given all those factors, I can go down the list of games and evaluate each one. Does it have potential to meet those requirements and be a satisfying project? This might not come as a surprise for those of you involved in creative activities, but this is hands-down, the most difficult time of development for me. As long as I don’t have a project picked, my mind is constantly going over this. Anything I read, see, or hear is filtered and analyzed thinking of how it would fit in a game. During this time I’m often moody, volatile, and prone to depression if this goes on for too long.

Even though it seems I’ll never going to be able to come up with an idea worth doing, eventually something comes along, and the next phase starts.

Prototyping

I’ve already talked about prototyping at length before. I take the idea I’m considering and I try to answer the key questions in the shortest possible time. This is the time to shoot down any bad ideas, or prove why they’re not feasible or just boring.

The prototyping phase is a big high for me. It often involves manic activity and I can get a prototype done in a day or two from the initial excitement on the idea. The bad part is that most prototypes prove not to be that great, and they go back to the drawer of game ideas, and I’m left scrambling for another idea.

Struggle. Prototype. Discard. Repeat.

I usually repeat this cycle multiple times. Each time around I get more anxious, and the lows and highs are a bit more extreme.

Fortunately, at least so far, eventually I find a prototype that seems worth doing. Something I can see spending the next X months of my life doing. I usually run it by a few friends whose opinion I value highly, and if they’re excited about it too, then it becomes an internal green light and I move on to the implementation phase.

Tips

Apart from asking yourself why your making a game, here are a couple of things worth keeping in mind when picking a new project. They’re not new things and I’ve heard them before in one form or another, but they’re worth reiterating:

• Don’t compete with big companies. They can throw a lot more resources, and, most importantly, lots of marketing behind their titles. Don’t try to take Zynga head on. Do your own thing.
• Don’t chase trends. Take risks. Be different. You’re indie and have low overheard. Take advantage of that and do things the big boys would never dare risk $50 million on.
• Keep the scope of the project small and focused. It will be bigger than you envision anyway. By being small, you can come up with new ideas faster than big companies.

How about you? What’s your process for deciding to work on something? Do you struggle until you pick the project? Do you stick with an idea, or do you change and restart?

I was having a discussion today about free games with other developers and I thought I would post here some random thoughts and open it up for discussion.Free-to-play (or freemium–even if they aren’t exactly the same, I’m bundling them all under the same category for this discussion), have have a fairly bad reputation, and they’ve been under fire recently from developers. It’s true that a lot of those games have been rather poor from a game design point of view, while raking in loads of money from players who are apparently happy to play them.

It’s important to separate the financial model (free with other ways for players to spend money in-game), and the quality of those early games or the intentions behind them. I am convinced that free games is the future of mass-market games (it’s already pretty much the present, so that’s not much of a stretch).

There’s no doubt that the financial model of game affects its design. Compare arcade games, retail console games, and subscription-based games just as an example. Free-to-play has a huge impact on the design as well.

Free-to-play games are in their infancy. Not only are they a relatively recent happening, but they were also wildly successful, which encouraged a lot of copying and not much innovation. So they’re stuck in a type of design that results in a local maximum of profit, while providing a not very satisfying experience for a lot of players. As game developers, we need to find out how to make great games while using the free-to-play model.

I’ve been going around this quite a bit recently, because I’m in the stages of deciding what my next game is going to be. The reality of the App Store are pushing me towards free-to-play, but I’m not interested in making a Farm/Store/Pet game.

These are my random thoughts on what we can charge for in a free game and how it affects game design:

• Reduce delays. This is very effective, but feels cheap and somewhat manipulative (yes, this is coming from the guy who did Flower Garden… but that was before IAPs and the whole point of the game was the nurturing/waiting part). It also falls in the category of the question I often ask myself: If I remove this from the game, will it be better or worse? The answer is (almost) always “better” by removing those delays.
• In-game currency. This is seems like a better approach as long as there’s no competitive multiplayer. However, it does wreck havoc with the game balance. Either it becomes too easy and not fun for those who paid, or boring and grindy for those who didn’t. Still, especially on mobile, it’s not a totally bad way to go. You’re letting people make a choice how they want their experience.
• Extra content. That seems to be the traditional, developer-approved way to go. PC and console games have been doing that with DLCs for a long time. The main problem is that not many players want that content, the amount of content you can sell is limited, and it often requires a lot of extra effort to generate.
• Extra choices. This includes different characters, clothes, weapons, etc. I see this as the sweet spot between the last two options. What you buy doesn’t completely throw off the game curve, but it’s also not just new levels or missions. Combine that with letting players earn credits to get those choices (by grinding if they want to, but it’s all optional) and it seems like a good way to go. You can also go the way of League of Legends (which I have yet to play!) and you can rotate in that extra content for limited amounts of time, so players get a taste and they have the option of buying them permanently.
• Cheats. By cheats I mean more lives, rewind/replay, invulnerability, etc. It feels like a throwback to the arcade days. Some players will be put off by it (either by the fact it exists, or by the fact that they finished the game too quickly with the help of those cheats), but it can work in the right game. You’d probably want to do something about high scores, like putting players who used those cheats in a different leaderboard.

What are your thoughts on this? What are some other ways that players can pay for in free games and still allows us to make a great game?

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.

Contrary to popular belief, I’m not that picky when it comes to a development environment. Or at least, it doesn’t feel that way to me. I want the basics, that’s all. Doesn’t everybody want this?

• Have 2-3 source code windows opened side by side.
• Build and see the output.
• Do everything with keyboard shortcuts.

There are lots of other things I want (project configuration, debugging, run tests), but those are the ones I’m doing 99% of the time. I never had a problem doing any of those things with past development environments.

The hit list

Having more tools and options is great. I love having the option to do advanced operations on my code, but I want to decide when to use those tools, not being bombarded by them. That, in a single sentence, is why Xcode 4, out of the box, is completely unusable for me.

Attempting to do something as simple as type code and build it is extremely frustrating. Xcode will react to me doing that by flashing all sorts of stuff on screen, bring up sidebars with messages, change which source files are displayed, draw squiggles all over my code, and flash alerts overlays. All of that, while not showing me the build output.

Working on Xcode is an extremely noisy (visually) and distracting experience. I understand it’s trying help me, but it’s failing miserably at it. I’m trying to concentrate on what the code does, and I feel I have a parrot yelling stuff from my shoulder and flapping in front of the screen in some misguided attempt to help me code better.

That might work for some people, but not for me. I’m the guy who turns off “spell check as I type” everywhere because I don’t want to be taken out of flow while I’m typing (I’ll do a spell checking pass later on, thank you). I don’t have notifications on my mail or Twitter; I check them explicitly when I want to. Now take that kind of annoyances and multiply it times 10 and you start getting an idea of what working on Xcode 4 is like. Xcode 4 feels like it’s squarely designed for the texting/ADD generation.

Fortunately, most of it can be remedied and turned into a half-way sane environment.

Here’s how to tame the noise in Xcode 4:

• Autocomplete is one of the worst offenders. Turn it off! Good autocomplete is awesome, but I’d rather ask for it (with a keystroke) than have it bombard me constantly. Not just that, but it’s so badly implemented that it will a) put shadows on top of the text I’m typing b) replace the text I’m typing on the fly so I can’t even see what I typed (see screenshot below). Off with it!



• Having the whole screen flash with squiggles on and off while I’m typing isn’t helping in any way. Xcode is trying to “highlight instances of selected symbol”, which is a really useful tool, but not while I’m typing/thinking! Not just that, but half the time it will add extra squiggles to the screen to make sure I can’t even read the symbols themselves. So off with that one too.

  

  Here’s one very frustrating thing: When I turn off the option to automatically highlight instances of the selected symbol from the settings, I lose the ability to do that at all. Yes, you heard that right: I can’t (as far as I can tell) press a key and have the IDE highlight all the instances on demand. No sir, that’s not the way it was intended.

• Continuing with the theme of noise and distractions, having a sidebar popup and start showing me errors with my code as I’m typing is also definitely NOT helping. Fortunately we can turn off “Show live issues” in the general settings.
• One thing that Xcode 4 appeared to have gotten right is the idea of showing multiple source files at the same time. Now many IDEs do that by default these days, so that was a plus. Unfortunately, it’s part of the “smart” assistant. As a general rule, I end up turning off anything with the word “smart” in it, and this is no exception. The assistant tries to present “relevant” files to the one I’m working on. No, no, no, no! *I* want to decide what to display and what to work on. Just get out of the way and let me do that easily. You can turn off the view to “Manual”, which helps a huge amount.

Just those changes make Xcode 4 into something that at least I can type into and not get sick at my stomach. We’re making progress.

Now I can finally build and… everything goes wrong. Xcode doesn’t show me the build output and it decides to flash a “build completed” screen overlay in case I looked away in the two seconds it took to build. Seriously? Maybe my attention was drawn into some of the flashing squiggles and I forgot it was building.

Fortunately for my sanity, it’s possible to fix both those things. The alert is easy: Go to behaviors, “Build succeeds” and turn off “Show bezel alert” (make sure it’s off for all the others while you’re there).

The other one is a bit trickier, but it’s certainly possible. Set up the “Build starts” behavior to open a named tab and go to the current log. Like this:

Now when you build your project, you’ll get to see something sane like this. It might initially be as a tab, but you can drag that out and make it into a separate window of its own so it doesn’t obscure the source code window:

You should be able to navigate through any issues found during the build with Cmd + ‘, or, if you like the fancy issue display, press Cmd + 4. Things are so much better when you initiate them on demand rather than when they’re forced on you!

Finally, a couple minor UI annoyances that are easily fixed:

• The toolbar is positively huge. I feel crammed in the high-res 15″ MBP (1680 x 1050), so I can’t imagine how anyone works with something smaller. In any case, hiding the toolbar helps tremendously. As a bonus, the setting is per window, so your source code windows get the extra real estate, but the build output window keeps the toolbar so you have easy access to changing the target platform.
• Line wrap is on by default. Seriously? Off.

The suck list

If that was everything, I’d be happy. It means that even though Xcode 4 ships with retarded defaults, it can be whipped into shape into something usable. Unfortunately, there are a two major things I haven’t found a workaround for:

• Can’t build a single file. Someone at Apple, in their infinite wisdom, decided that building a single file was obsolete with the awesome new feature of “show live features”. Except that “show live features” sucks and has to be turned off. Apparently you either take it their way, or the highway, because there isn’t an alternative. As with the case of highlighting symbol instances, there isn’t a command I can use to “show live features” on demand.

  The alternative is doing a full build. Most of the time that’s fine, but whenever you’re doing one of those refactorings that breaks half the codebase, then you’re really screwed. The only way I can stay focused in a case like that is by cleaning up one file at the time, but this makes it impossible as you keep getting errors from all over the codebase. And as you fix one, the first error in the next build might be in a different file. Very annoying to say the least, especially because this was working and they removed it on purpose. I never file radar bugs (long story), but I made an exception just for this.

• Build configurations and schemes. Did you notice that when you built the project earlier there was no option to choose debug vs. release or some other configuration? That’s another one of those decisions that make you wonder if Apple uses Xcode to manage their own projects (and if they do, what kind of developers or projects they have).

  They turned something simple like project configurations that nobody ever complained about, into something byzantine worthy of some of the best efforts from Redmond. This gets the award for “most complicated feature nobody needed or wanted”. It seems now we have an extra layer of indirection. So you act on a scheme, which then decides which configuration to build and what to do. That’s why there are “Build for analysis” (debug), “Build for running” (release), “Build for testing” (WTF?), “Build for archiving” (distribution?).

  After spending some time with it, I’m still confused how I would go about running the release configuration, or how to mass-edit all the schemes at once (every target seems to get a different scheme).

  The whole schemes thing leaves me completely speechless, and that vein on the side of my forehead is pulsating just from thinking about it, so let’s just move on.

The good

After you take the time to fix Xcode 4 into something usable, and (somehow) put up with the new broken features, is there something to like?

I had to dig deep, but I found a couple of things that I like better than Xcode 3:

• Much better project settings UI: Multiple panes, showing multiple values for different configurations, etc. Way better than Xcode 3.
• Better semantic analysis. During the build process, Xcode 4 was able to correctly flag some problems in my code that Xcode 3 never warned me about. Mostly to do with constness of parent-scope variable when using blocks.
• Better keyboard shortcut support for opening files in different windows (assistant pressing the Option key). I never found a way to open a file in a specific window in Xcode 3 without having to use the mouse.

And that’s pretty much the whole good list that I was able to find

Conclusion

Xcode has been progressively evolving from version 1 until version 3.2. I have no doubt that’s the reason for some of the quirks in the later versions. Xcode 4 seems to be a total re-design and re-implementation, and suffers from the classic second system effect. It’s change for the sake of change, most of the time scrapping useful features and not offering useful alternatives.

I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it. I didn’t look very closely at the debugger or the Interface Builder (saving those for another day). I keep hearing about developers with stability problems with Xcode, although I didn’t run into any crashes (but I hardly did any real work with it).

Overall, my recommendation is that, if you’re comfortably working on Xcode 3, stay as far as possible from Xcode 4. We’ll all be forced to move there sooner or later, but in the meanwhile you can continue being productive. Maybe by the time they discontinue Xcode 3, Xcode 4 will have improved a bit.

These are mostly quick notes to myself so I remember what to change when I upgrade my main machine, but I thought other developers hesitant to upgrade to Lion might find it useful as well.

Things that had to go

I found Snow Leopard (and Leopard before it) to be very palatable out of the box. I don’t remember any things I absolutely had to do. Lion, however, had some questionable defaults. Or at least, ones that I just can’t take.

After making these changes, Lion was quite usable:

• Turn off “natural” scroll direction. The fact that before you can run Lion for the first time it forces you to scroll that way should be a tip off that people aren’t ready for this one yet. Maybe in a few years it will make sense to have it as the default, but now it’s just against every single computer out there (including most Macs).

• Autocorrect. This is not an iPhone. It *has* a perfectly fine keyboard. Thank you.

• Setting up Spaces. Oh, excuse me, Mission Control (sigh). This is the one I was really afraid of. I absolutely rely on having about 8 spaces (2 monitors in each) open at all times and swapping with a keystroke. That’s something that I’ve been using for many years (first in Linux, then hacked onto Windows XP, and finally in Leopard/Snow Leopard). I just absolutely have to have that.

  Update: There are still a couple annoying things with the new setup. You can’t see the number of the desktop you’re currently on, like you did with earlier versions of OS X. Daniel Collin pointed me to an interesting thread on StackOverflow where people are discussing how to get access to desktop numbers. Give it a few more weeks. Also, when you restart the computer, Lion is smart enough to restore all the apps to their last state… except that they’re all opened in the first desktop, not in the one they were when the system restarted. How difficult would that have been? Here’s hoping it’s fixed in a patchupdate soon.

  The good news is that it’s possible to set up Lion that way. The bad news is that by default, it’s quite far from that. Bring up Mission Control and create by hand as many desktops as you want. Then go to System Settings | Keyboard | Keyboard Shortcuts and turn on one for each desktop. And for the love of god, please go to Mission Control settings and turn off “Automatically rearrange spaces based on most recent use”. Clearly Apple doesn’t think people want to go to a space directly, and instead prefer to browse them one at the time.

The next few changes just made my experience better, but they’re not absolutely musts:

• This might sound dumb, but Finder didn’t have a good way to easily browse my files. Instead, it has this weird “All My Files” view that jumbles together all your junk there. I have no idea who thought that was a good idea. Maybe Apple is trying to wean users from browsing around the file system. In any case, you can drag your home directory to the sidebar in Finder and that makes it much easier to browse. While you’re at it, turn off the “Hide extensions in files” dumb setting.

• Having used a Mac for several years, I’m much more sensitive to ugly UI elements. That’s why it’s so weird that, by default, Lion has the sidebar font in all programs just very slightly larger than the regular system font. Fortunately I wasn’t the only one bothered by that and it’s an easy fix.

That’s about it. Lion is not very nice and usable (i.e. looks like Snow Leopard). You have that weird “full screen” button on the top right of all windows, but that’s much better ignored (which funny that, was the feature Apple really pushed in their PR for Lion). I have no idea why anyone would want to use that other than the usual word processor that blocks out everything else. If I want to have crippled multitasking, I’ll just use the iPad.

Good things about Lion

So far, if all I’m going to do is disable new features so it looks like Snow Leopard, is there there any reason to upgrade to Lion? I surprised myself, but the answer is yes (although they’re all very, very minor).

• Resize a window in any corner and cursor feedback (finally, only 20 years late to the party).
• Perfect contact and calendar syncing with Google. I can’t tell you how much I appreciate that. I use Google as the backend for all my mail, calendar, and contacts. With Snow Leopard you could sync them, but you had to do some digging and mess around with the sync program. With Lion it works out of the box. Totally awesome. That alone makes it worth the upgrade.
• Much improved Mail UI: Better layout, better shortcuts, better conversation view, and, my favorite by far, finally an Archive command for Gmail. Archive doesn’t exactly do the same as archiving in Gmail, but it’s close enough. Finally I can have two different keyboard shortcuts: One for trashing an email and another one for archiving it.
• The jury is still out on how Lion restores the application state when you launch an app. I’ve been pleasantly surprised a couple of times, and annoyed a couple other times that I had to close a bunch of useless tabs. Maybe there’s a shortcut like Shift + Cmd + Q that quits and app without saving state? That’d be handy (OK, that one is not it Oh wow, it’s Option + Cmd + Q! I love it when something makes sense like that and you can guess it. OK, so that makes this feature very cool.
• Slightly improved Safari (better download management). I really don’t see a reason to use Firefox or Chrome when you can use the preinstalled Safari. But then again, I can’t stand web UIs and I use native clients for lots of things.

Must-have apps

It’s actually quite refreshing to use the bare minimum number of extra apps beyond what comes with the OS. But there are some apps I just have to have in order to do anything. The main two are 1Password and Alfred. I can’t recommend them highly enough. They completely change how I work and make me ten times as productive (you’ve probably noticed by now that I’m not a mouse person).

After those two awesome super-apps, is the second tear of very useful ones: JustNotes, Things, and TextWrangler.

Probably Dropbox should be there somewhere, but for some reason, I still haven’t felt the need to use it heavily. I know some people put almost everything on Dropbox and can use across computers. Maybe it’s because I only have one that I haven’t felt the need for it too much. 1Password and Things both sync from the iPhone so it was really handy restoring all my data. I probably could have done the same thing with Dropbox.

Tomorrow I’ll post similar quick notes about Xcode 4. Those might not be quite as positive though.

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.

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!

Casey’s Contraptions is an iOS game created by the two of us, Noel Llopis and Miguel Ángel Friginal. Noel, an industry veteran for over a decade, turned indie over four years ago and found success with microtransaction-based Flower Garden on iOS. Miguel worked as a graphic designer in the advertising industry for years before becoming a web developer. Casey’s Contraptions is his first published video game, although his first paper role-playing game came out almost 20 years ago. We met through Twitter several years ago, and then finally in person at a 360iDev conference. Even thought we didn’t plan it that way, we ended up working together during a game jam, and that set us in the path to collaborate in a future project.

We knew we wanted to target iOS for our next project because we love the platform from a user and a developer point of view, and because it’s a platform where it’s possible for indies to succeed financially. Beyond that, starting a new game is never easy. Even though we have page after page of possible ideas, settling on a specific game idea is always very hard. We wanted something that met three requirements: The game had to be creative in nature as opposed to using destruction as the main gameplay element, it had to be something we were excited about, and it had to be something with the potential to sell reasonably well on the Apple App Store. Easier said than done!We prototyped game idea after game idea, and even though a lot of them were not bad, none were a complete standout. Eventually, after seven or eight different prototypes, we settled on the concept of creating physics-based, Rube Goldberg-like contraptions to solve different puzzles. At its core, the game has similar mechanics to some classic games like The Incredible Machine, but with an emphasis on exploration of creative solutions rather than finding the one right answer to each puzzle, designed around sharing, and built from the ground up for a touch interface on iOS.

We structured this project as a pure 50-50 partnership, and without any external funding or publishers. Miguel quit his full time job (as a web programmer no less!) to do the art for Casey’s Contraptions, and Noel took care of the programming. Design was a fully collaborative activity, where we both contributed equal amounts to everything from the rules, the feel of the game, or level creation. Everything else we split up based on our strengths and expertise: web site, server back end, PR, etc.

This is not a true postmortem, but more of a post-launch analysis. Games today, and especially iOS and Facebook games, are becoming more of a service rather than a product. Development and launch are only the beginning of the story. If all goes well, we’ll have a lot more to say about Casey’s Contraptions in a few months.

What went right

Strong theme and style

Casey’s Contraptions started life without Casey! The initial prototype focused only on the creation of contraptions and the physics simulation behind it. It showed a lot of potential, but it was missing something to make it stand out. It needed more personality.

After some brainstorming, we quickly zeroed-in the idea of a smart 8 year old building the contraptions. Not only did that add the much-needed personality to the game, but it also focused the rest of the development. Instead of doing a physics game with generic pulleys and levers and other industrial-looking items, we naturally went with toys and household items Casey could have access to: His sister’s doll, paper planes, or his RC truck.

The choice of toys as game items not only influenced the level design, but also the goal of the levels. At the beginning we were thinking of doing levels to accomplish tasks Casey would have to deal with in real life, such as putting toys away or popping a balloon. After a while, the idea of “playtime” levels came up, where the setting and the goal were completely imaginary (rescue explorers from a jungle in their hot air balloon) just as Casey would have imagined during his playtime sessions.

The character of Casey also helped anchor the art direction. We were aiming for something that would appeal to a very wide range of people, from the very young to adult casual gamers. Although Miguel looked into everything from a most modern Cartoon Network style to manga, to crazier Warner Bros., we ended up settling with a mix of Calvin & Hobbes and something out of a 50s Hanna-Barbera show, with strong outlines and solid colors, to make people of all ages feel comfortable with the visuals. We were able to carry this distinct style to all the items, locations, and user interface in the game, which gave it a very consistent and unique look.

Social features

Creating something is fun, but creating something and being able to share it with people is twice as much fun. We wanted to make Casey’s Contraptions a very social experience from the start. Not something that you played through and put away, but something you could share with friends along the way.

Since Casey’s Contraptions uses a full physics simulation at its core, it’s possible to come up with very unique, chaotic, and often unexpected solutions to most puzzles. Weeks after launch, we’re still amazed at how some people are solving some levels, coming up with item combinations we never thought about during development. Since these solutions are very unique and fun to watch, they were a perfect candidate to share with friends.

With that in mind, we designed the game with sharing from the start. After you complete each level, you can share your solution with all your friends just with the tap of a button (and, in the latest update, the default is to autosubmit a solution if you improved your score). Your friends’ solutions are equally accessible, as cropped thumbnails in the level completion screen, and tapping on any of them will bring up a full-screen view that you can even replay and watch the full solution.

In addition to sharing solutions, we also included a level editor to allow players to create their own contraptions from scratch. This was the same level editor we used to create all the levels in the game. Nothing like eating your own dog food to make something solid and usable. Initially, players were able to share these levels through email, and, in the first update, we also added the ability to share them publicly through a web site (http://shared.caseyscontraptions.com), effectively giving players access to hundreds of new levels.

As it’s the case with most games that include level editors, we were aware that only a small minority of players would take the time to create their own contraptions. But it’s also those players that are really devoted to the game, and take it upon themselves to spread the word about your game and champion it to all their friends.

Iterative development

For Casey’s Contraptions we used a very stripped down and relaxed form of iterative development. We had short iterations and in each iteration we aimed to fully implement what we considered the most important features at the time. We didn’t do any real estimating of tasks (other than, “yeah, we think we can do that in about two weeks”), and we didn’t set a hard-limit on the iteration (they varied naturally between one and a half and three weeks). The most important concept is that at the beginning of each iteration we would make decisions about what to work on next, and those decisions were made with all the knowledge leading up to that point.

For example, we didn’t start the project by coming up with the full list of items we were going to have in the game. Instead, we had a list on the wiki of possible items (to which we would add more whenever we thought of a new one during development), and we only decided which new items to add to the game at the beginning of each iteration. That allowed us to make good decisions based on what we had learned so far: “Most objects we have so far fall down. We need more items that add forces upwards”, or “The magnet is fun, but we need more metal items to make it more useful”.

This mentality applied to everything: From level creation, to menus, features, etc. Looking back, we can say there’s no way we would have made the same decisions early in the project than we did as we went along.

Strong launch

In less than 24 hours after launch, Casey’s Contraptions worked its way up to the top 10 paid apps in the US and in over 20 different countries. A day later, it reached the #2 overall spot in the US and had great initial weekend sales.

This strong launch wasn’t just pure luck. It was something we planned months in advance and worked hard to achieve (although we did need a dash of good luck). We wanted to build awareness and buzz around the game, but given the short development cycle for iOS games, we would have to do it in a shortened scale.

We started out by announcing the game more than six months before release (25% of the way into development). During the following months, we continued talking about the game on Twitter and our blogs, often showing work in progress or outtakes. The next big milestone was showing the game around at GDC. Not only did we get a lot of other developers to play it and give us invaluable feedback on it, but we also met with some of the game press, and that resulted in some very nice previews afterwards.

The final push came as soon as we submitted the game to Apple for review. We decided to set a fixed release date three weeks after the submission, which would give us enough time to do all the PR work: creating a video, putting together a media packet, contacting media outlets, etc. In the weeks leading up to the launch, we also stepped up our blogging of different interesting aspects of the game.

As a result of everything we had done up to that point, we were very lucky that Casey’s Contraptions attracted Apple’s attention, and they featured it prominently on launch day as iPad Game of the Week worldwide. We had given the press enough time with the game, so a lot of very positive game reviews came in right around launch day, helping get the word out for the game.

Even though we had been originally thinking of pricing the game at $4.99, we decided to shoot for volume instead and priced it at $2.99. That turned out to be the right decision and immediately put us on the top 10. Sales on iOS charts follow a sharp, exponential drop off, so being in the top 5 represents a huge increase in sales over just a few positions down the chart.

Looking at the App Store today, it’s apparent that it’s becoming harder for small, quick games to be really successful and top the charts. With over half a million different apps on the App Store, and hundreds of games released every day, you really need to stand out from the rest to be noticed. Most of the games that manage to do that are ones that required significant time and effort investment and have good production values. The App Store gold rush is over.

Enough development time

From start until launch, Casey’s Contraptions was in development for 8 months. That seems like a long time by iOS standards, although more and more successful iOS games are starting to take that long.

Our initial plan was to ship the game by Christmas. It wasn’t based on any rigorous estimating, just an off-the-cuff estimate. It just “felt” like we could be done by then. Obviously we were wrong.

Taking the amount of time that we did was a very positive thing. We didn’t really waste much time, it’s just that the game needed that amount of time to mature and get to where it is today. If we had chosen to ship it earlier, the final product would have suffered significantly.

One of the hardest things in a game like Casey’s Contraptions is making interesting levels. Having this amount of development time, with a working game editor since the very beginning, allowed us to make a lot of levels along the way. Looking back at a lot of the early levels we made, they were laughably hard and not that interesting. After several months, were able to develop a sense about what made good levels and what the appropriate difficulty was.

Having enough time allowed us to make fairly fundamental changes to the game design when something wasn’t working. For instance, initially each level had three different goals you could achieve. Depending on the number of goals you accomplished, you earned a bronze, silver, or gold medal. It quickly became apparent that players were extremely confused by the three goals and weren’t able to keep them straight.

We changed levels to have a single goal, but since we still wanted to have some replayability beyond “solving” a level, we added optional stars you could collect by touching them with any item in the game. The first star would be very easy to get, the second one a bit harder, and the third one would require some serious thinking. That was a huge improvement, but then we discovered that most players expected to get all three stars in their first playthrough, and would stubbornly keep playing the same level until they got them all or quit in frustration. That prompted us to change the stars yet again. This time the difficulty of getting them was tied to the overall level difficulty, so players could easily get all three stars in the early levels. We’re very happy with the final design, and we would not have gotten there if the project had been rushed.

We also gave ourselves sufficient time at the end for polish and style. Polish isn’t going to make the game design any better, but it’s going to contribute a huge amount to first impressions. Every animation, sound, and particle effect becomes really important in those crucial first few seconds with the game. On a mobile platform, polish becomes even more crucial. If your game doesn’t immediately engage the player, there are lots of other things they can shift their attention to.

What went wrong

No simultaneous iPhone launch.

The initial prototype of Casey’s Contraptions was running on an iPhone. While it showed a lot of promise and it was fun to assemble contraptions even that early on, it was clearly begging for more screen space.

The iPad was the obvious platform of choice. Its large screen can display very nicely detailed graphics, and allows for very natural, direct manipulation of items. It was a perfect fit for Casey’s Contraptions.

Even so, while there are a lot of iPads out there (14 million), the iPhone and iPod Touch are the undisputed kings of the App Store (about 185 million devices). Especially for a game that relies on the social component, getting a critical mass of users playing at the same time, sharing solutions, and sending levels is very important. We definitely stormed up the iPad charts, but that still left the majority of iOS users not being able to purchase our game.

Why didn’t we wait until we had the iPhone version to launch? No particularly good reason other than we were itching to get the game out. We also had no idea what kind of impact a strong launch would have on our servers, so the idea of an iPad-first launch seemed like the way to go. In hindsight, we would have been better off waiting to launch both versions at the same time (or almost the same time, maybe a week or two apart at most).

To make up for this, we’re planning on making the iPhone release a second launch of sorts: We’ll make the iPhone version coincide with a new game update that includes a lot of new content (for free for people who already bought it), and we’ll try to repeat the same strong launch we had on the iPad. The idea is to get everybody who’s already bought the game playing again, along with all the new iPhone players and create that critical mass.

Butting heads too much

We make the perfect two person team: We have complementary specialties, but we also have a lot of overlapping skills. We also seem to always approach things from opposite ends: Aesthetics vs. usability, performance vs. gameplay, simplicity vs. interest, uniqueness vs. familiarity, or tea vs. coffee. That is actually a really good thing and the success of Casey’s Contraptions was in no small part due to our combination of personalities and skills.

There is, however, such a thing as too much of a good thing. We are both very stubborn and it will take a lot to convince us to see things in a different way. There were some times during development that we spent more time debating one point than actually implementing it.

The fact that we’re working remotely didn’t really affect most of our day to day development, but it definitely made hashing out these situations significantly harder, dragging them out for far longer than they should have. This was also the first time we were working together on a significant project, so it made resolving those situations more difficult. Now that we’ve gone through this first project, we’ll hopefully be better equipped to handle similar situations in the future.

Unnecessary rework

Rework is a necessary part of a creative process. You’re unlikely to get everything right in the first draft of a text or a music composition. That’s even more so the case for game development because there are so many parts interacting with each other. Not only is it hard to predict the exact final outcome, but even if you could, you often don’t know exactly what you want until you’ve seen one version of it.

Just about every screen and every item in the game went through several revisions of art, behavior, sounds, or layout. There’s no doubt that every revision made them better. However, we had a few parts of the game that we had to revise a few too many times. This was mostly in some of the UI screens, like the now infamous “level completed” screen, or the look and positioning of the in-game menu, which we must have gone through at least 6 or 7 complete redesigns.

We believe that design doesn’t just flow one way. If you want the best final product, you can’t just decide on the functionality of some user interface (or any part of the game for that matter), implement it, and then give it a pretty face with some graphics. Both the implementation and the graphic design will actually feed back into the functionality of the UI. Once you go around this cycle a few times, you can zero in on a very strong design, both from a functional and a design point of view.

The problem comes when you go around that loop too many times, or when the loop doesn’t converge into a particular design, but keeps shifting around. That was often caused because we were fuzzy on some of the details, or when we were forgetting about some particular feature that had to be reworked into the design. Some other times feedback from our testers made us realize that a screen wasn’t clear enough as we had designed it and caused us to rework it. As tempting as it was to push through and call it good enough since it was already completely done, it was always the right decision to go back and re-work things as needed.

For example, at the beginning of each level Casey explains what goal you need to achieve. This screen seemed straightforward enough, except that the version we had early on was blocking the view of the level while it was up. Our testers complained it was hard to remember what you had to do without seeing the items it was referring to at the same time, so the final design shows Casey’s dialog along the bottom of the screen, and the goal items are even circled with a marker.

We can alleviate this problem by iterating on particular pieces of UI or the game in smaller cycles, without taking each one to completion. Instead of starting by completely implementing a screen, or completely creating a perfect mock up with all the graphic elements, we need to start by laying out a screen with simple boxes and buttons and implement the basic functionality. Then we can make a first pass at a real layout and some graphical element, implement some of the new functionality and animations suggested by that, and continue iterating until it’s done. We got much better about this in the last third of development, and it’s something we want to carry forward to future projects.

Not enough unit-testing

Noel is a big fan of unit testing and test-driven development (TDD). Those are some techniques we used in past projects to very good effect and something we definitely wanted to carry into Casey’s Contraptions as well.

The goal was never to have 100% unit-test coverage or write every single line of code through TDD, but to write only the tests that would benefit the project. That usually meant some code that a lot of other code relied on (the game item management), or something complicated (toolbox interaction), or something prone to breaking (rope manipulation).

In the end, we slipped to the side of not having as many unit tests as we would have liked. Some things like object attachments kept repeatedly giving me headaches during development because of the complicated, untested code. By the time we noticed those problems and wanted to start adding tests, it was too late because some of that code relied on non-unit test friendly APIs like UIKit or Box2d.

We should have taken the time when those problems started appearing to start writing some tests and slowly refactor the code as we fixed the bugs and added new features. Instead, since we seemed to be constantly “just a few months away from shipping”, we decided to skip that and definitely paid the price later on. We even shipped with a few off edge cases that we knew were buggy but we didn’t dare fix weeks before submission.

We’re already working on updates and and an iPhone version of Casey’s Contraptions, so we’ll continue dealing with that code for quite a while to come. We’ll slowly introduce unit tests in areas of the code that we need to revisit during this time.

Fixed price model

The pricing model is something we went back and forth about several times during development. In spite the long-term success of Flower Garden and other free games with microtransactions on the App Store, we chose to go with a fixed-price model for Casey’s Contraptions.

We thought our audience would appreciate a traditional fixed-price model better than a microtransaction-based one. We also figured it was a model that was working well for other similar iPad games such as Angry Birds or Cut The Rope, so it made sense to follow their lead on that.

Unfortunately it seems that might have been the wrong decision from a financial point of view. After a really strong initial launch, Casey’s Contraptions dropped down the charts very rapidly after just a few weeks. Since revenue follows a very sharp exponential drop off, even being in the top 100 iPad games means very little revenue per day, and points to a very thin “tail” to the sales curve.

In spite of the bad reputation microtransaction games have in traditional game development circles, they’re a lot harder to develop than single-purchase, fixed-price games. Not only do you need to implement very robust server features, but you need to finely balance the in-game economy, the pace of rewards, and the cost of new purchases. Our optimistic estimate was that it would add at least a full month to the development time (and given how our estimates were, it probably meant two months for real).

A possible alternative would be to have a traditionally-priced game, but offer new levels or locations as extra purchases. This would have been a lot simpler to implement, but it probably wouldn’t have made much difference in revenue. Usually, only about between 2% and 5% of the players buy any extra content, so for microtransactions to really pay off, they need to be unlimited (in-game currency, fertilizer, etc), or have a very large user base. With a small, fixed amount of possible things to buy, we would need to rely on having lots of players to make much of a difference.

We’re hoping releasing the iPhone version will generate lots of renewed interest in Casey’s Contraptions, spur lots of sales on both platforms, and hopefully increase the long-term chart staying power. If that’s not the case, we can always consider the possibility of experimenting by changing the pricing model in the future.

Conclusion

We’re extremely happy with the development of Casey’s Contraptions and with the initial launch. We managed to create a unique game around creativity that was very well received critically and from a sales point of view.

The first free update should be available by the time you read this. It adds the ability to share contraptions with everybody through the web site, as well as browing public contraptions, which should increase the popularity of that feature quite a bit. It also adds some of the most-requested features, such as multiple player profiles for all the parents playing Casey’s Contraptions with their children out there.

Unlike a traditional retail game though, the story is far from over. What we do in the next few months will have a very significant impact on the long-term success of the game.

Facts

• Web site: http://www.caseyscontraptions.com
• Release date: May 19, 2011 (iPad). Summer 2011 (iPhone)
• Development time: 8 months
• Team size: 2 (full time)
• Development cost: Cost of living for 8 months + a tad over $1000
• Open source code: Box2d, UnitTest++
• Primary tools: Xcode, svn, Versions, Trac, TexturePacker, Adobe Illustrator, Audacity
• Lines of code: 46,518
• Raw asset size: 510 MB
• Total app size: 12.2 MB
• Subversion commits: 2442
• Trac tickets closed: 683
• Gallons of tea brewed: 77
• Shots of espresso consumed: around 1500

This article was initially published on Gamasutra in June 22, 2011. I reprinted it here for completeness, to keep it with all the other Casey’s Contraptions articles.