But that is wrong. I have learned to fight that reaction, to the extent where if it even has any chance of making my job easier, and I can afford it, I get it. Nine times out of ten that software will go on to either save or make far more money than what it cost to purchase.

From shareware apps like Soulver or AppViz to big fat apps like Cinema 4D or Photoshop to hardware like a faster Mac or a bigger display, I never regret buying any of them. They allow me to do things I wouldn’t otherwise be able to do in less time, of better quality, and nearly always ultimately pay for themselves.

A bad craftsman may well blame his tools, but a good craftsman never has to.

In the past few months, I often stopped coding to imagine this very moment. When times got tough and the end looked to be getting further away, I imagined sitting on a deck chair by a pool in the sun, Chopper 2 sitting in the App Store top 100, beer at my side, and a MacBook on my lap, tapping out the Chopper 2 postmortem.

And here I am! Through a lot of hard work, a tremendous amount of support, some careful planning, a bunch of tough decisions and a hell of a lot of luck, Chopper 2 is complete, and as I write this has spent over two weeks in the US top 100. Before it had even had its first sale I felt like all the effort had been worthwhile, but even better, it looks set to beat the success of the first version of Chopper for iPhone.

Chopper 2 reaches the top grossing iPhone game in New Zealand

Chopper history

Many who read this may not be familiar with the history of Chopper so I’ll start at the beginning.

One of the very first builds of Chopper for the Mac. Gotta love that aqua brushed metal.

The birth of Chopper was on the Mac back in 2003. It was one of my first attempts at creating a game, and was a 3 month project. Chopper was entered into the uDevGames contest, where it received a number of awards. It was then left available to the public as freeware.

Following that release I switched focus to a series of day jobs doing mostly graphics/real time programming. During this roughly 5 year period I experimented a bit with shareware apps, including making the original version of Chopper for Mac OS X shareware.

Another early Chopper for Mac build

The shareware version of Chopper for Mac sold a few thousand copies over the next year or so – definitely not enough to make a living. But it was enough to make me think that working full-time on games could be possible.

So during my last year of full-time work I was saving most of my income, and looking for any opportunities to go out on my own.

As it turned out, the iPhone SDK and the App Store showed up with absolutely perfect timing. I knew the platform would be huge (though was surprised by just how huge!) and I already had a moderately successful Mac game ripe for the port. I also had experience with touch screens, accelerometers, UI design and a bunch of other useful skills due to my day jobs. So during my last few months of full-time work I was also spending the evenings and weekends re-writing Chopper for the iPhone.

The shareware version of Chopper for Mac

Chopper on the iPhone

When the App Store went live in July 2008, Chopper was there. It initially got to #13 in the US at $7.99, had a few more surges at $4.99 and $2.99, and then hit the #1 game at 99c over the holiday season ‘08/’09.

It would go on to sell more than 350,000 copies in the first couple of years, and even now is selling a few hundred copies a day.

Chopper was far more successful than I had imagined possible, and had set me up nicely for a long indie game development career.

Such a thing as too much success?

DuckDuckDuck - A fun, but not particularly successful diversion

During that initial period of success, I did exactly what I’m doing now: I took some time out to reflect on how things went, what the the future might hold, and on life in general. I’d never had a lot of money, and in fact had been a struggling artist on the unemployment benefit when I wrote the original Mac version. So it required quite a mind shift, and I actually had some pretty low moments when I considered that I may never be able to come close to that success again. I had structured a lot of my goals in life around becoming financially independent and creating a successful business. So when I actually got there, I no longer had any goals. And as it turns out, having no goals makes me miserable.

But of course I got past that. I played around with a few new ideas for apps and games, most of which haven’t yet seen the light of day. I released some updates to Chopper, and had some fun making DuckDuckDuck. After some point I also started constantly thinking about Chopper 2. I’m not sure it was always definitely going to happen, and I even dreaded the idea for a while (in much the same way that the idea of Chopper 3 currently flicks the off switch in my brain). But eventually, in March 2009, I started work on Chopper 2.

'Mac first, iPhone port' - most of what was written here bears little resemblance to the final game

The beginnings of Chopper 2

The initial phase of a project is always hugely exciting, and Chopper 2 was no exception. It was supposed to take a mere six months at this point, and I was full of energy and ideas – ready to code like crazy. During this phase my time was mostly split between planning/thinking/writing down ideas, researching the technologies I wanted to use, and beginning the code involved.

While in planning mode, I’d appear catatonic to passers-by. Most of it was visualization: imagining how the worlds might look; how enemies would behave; resolving the conflicts between realism and enjoyment, challenge and accessibility, beauty and performance.

Initially I had ideas of planes dropping paratroopers and artillery from above, wind gusts and mini-tornados to avoid, deformable terrains, luscious jungle environments, and a bunch more. However, things had to be removed due to the numerous constraints: enemies dropped from above could add months to development; wind gusts would be hard to convey and would detract from the environment; deformable terrains offered little utility but huge game engine complexity; and complicated environments would be prohibitively slow on older hardware.

So that side of the planning phase was very important in making a cohesive and enjoyable game, and it never really ended (but certainly was a large focus early on).

The incessant flying tanks

Another side to the planning phase involved the technologies I would use to create the game. There were plenty of these early decisions that heavily influenced the direction of the game and its development. Perhaps the first was to use the Chipmunk physics library. Chopper 1 had a very simplistic physics engine that I had created. The world was a grid of tiles, and the game objects were simple squares or collections of squares. The enemies didn’t move, and nothing ever fell onto anything else in a realistic way. It was all very rigid.

In Chopper 2, I wanted enemies to fly off with flailing arms when they were hit by an explosion and I wanted the chopper to feel the impact of explosions. Most importantly I wanted terrains and buildings to be at any angle (to allow for hills and angled roofs) with the game elements responding correctly to these environments. Chipmunk gave me this, and was quick and easy to get up and running. It had a nice support system and docs, was under active development by a friendly guy, and was open source.

So it was great, and provided a much better final result than I could have come up with on my own. However the more complicated/realistic physics system caused its own set of problems – tanks flying off into space being a common one. Initially my tanks were just a few quads sitting on the ground and I’d push them around with forces, but they didn’t behave in anything like a realistic manner. So I changed them to one quad and two wheels, and all hell broke loose. There must have been about fifty unique bugs in the way I implemented it, each one causing the inevitable ‘WTF is that tank doing flying in the air’ bug. From being initialized a little underground and the physics engine over-compensating, to accidentally applying massive torques, to lack of friction and sliding off cliffs, to driving head first into an obstacle and spinning off, I had it all.

The level editor

Another influential early decision was how the levels and terrains were to be constructed. In Chopper 1, I had built the level editor alongside the game, and found that to work quite well, so this was also what I did in Chopper 2. However, creating the Chopper 2 level editor was a much larger task due to the vast number of new features.

The editor ended up having as much code as in the game itself, and added at least four or five months to the development. It was absolutely invaluable, though. I can’t see any way that I could have created all thirty six missions, or had the level of polish I achieved without having this editor.

Very early screenshot of the Level Editor

The editor ran on Mac OS X, and had a full cocoa GUI for all of the configurable parameters of each mission. It also had a keyboard/mouse controlled view that largely ran exactly the same game code as the iPhone/iPad version. So I could make a change, hit reload and the level immediately reflected this change. It also allowed me to set up all the camera fly-throughs and text positions for the mission briefings relatively painlessly. If I had been trying to do this in text files and then building and running on a device or the simulator, I would have given up on the project before it got off the ground… no pun intended.

Editing Text

Creating worlds

The river was placed manually into the mesh using Cinema 4D

The terrains and 3D models were created with a fairly complicated process. I’d decided long before I even began that I would have mesh-based 3D terrains in Chopper 2. Mesh terrains were something I’d had a fair bit of experience with in my day jobs and in various hobby projects, so I had a good idea of what approach I would take.

Terragen 2 being used to create a sky box for the canyon location

Firstly, I downloaded freely available height data for real world locations as a base. The canyon level is using elevation data from the Grand Canyon, and the volcano in the background in Misty Valley is Mt. St. Helens.

From there, I opened up the height data in Photoshop to make small adjustments to make it work better in the game. Then, I ran it through a simple tool I had created to turn that into a mesh, optimized for Chopper 2 with more polygons in the foreground. I also took a slightly wider area of the height image and used that as a base for Terragen 2. And after a lot of playing around, learning how to use it, and many (some times half a day long) renders and re-renders, Terragen 2 would spit out a sky box and a great sunlit texture I could map onto my mesh.

The majority of that work happened over a large trial and error period, which lasted three or four months near the middle of the project. Before this, I had already decided on the number of missions and locations I would have, and so while I was familiar with all of the related tools, I focused on getting every one of the terrains/landscapes done. It was a long hard slog, and though it was very rewarding work, getting all twelve of the landscapes looking nice took much longer than I had anticipated. So long, in fact, that around this time I reluctantly removed the intended ocean based locations from the game (though I hope to add them in some future version).

A procedurally generated city

I also created a city generator application, to allow me to easily generate and modify the meshes for the three city locations in the game. I’d played around with placing large buildings onto meshes by hand using Cinema 4D, but the results were ugly, perhaps largely due to my rather poor 3D modeling ability. This city generator worked out great, and I am really happy with how the city levels ended up looking in game. The reflections in the windows combed with interior lights (all smoke and mirrors, of course) worked really well too, and I have Keith Bauer to thank for guidance on the texture combiner code required to achieve that effect.

The camera zoom math problem. Given A B C and theta, solve for x

During this landscape design phase, I was also working on a lot of the more general game elements, I was fixing issues with the physics and refining the feel of the chopper flight.

I designed some of the menu screens to get more of a feel for how the user interface would look and behave, and added many new enemy types and game features.

I was also working on the behavior of the camera, and ended up creating quite a sophisticated mixture of manual spline placement with automatic camera zoom and tilt. Thanks to Bruce Hoult for helping out with some of the math involved there.

Motivational issues

This takes us to around six months, or roughly a third of the way through the project. Things were moving pretty slowly at this point, and in fact I had some pretty major motivational issues for a good couple of months. I was making steady progress, adding features to the game and refining everything all the time, but I was also getting a lot of surfing done! I put the lack of motivation during this time down to a few things. Firstly, as I’ve said earlier, I expected the entire project to take six months. At this point I was already around six months in, and could see there were still many months to go.

There were many wrong turns along the way

Initially, I saw Chopper 2 as roughly twice as complicated as Chopper 1, so thought it would take twice as long. But this was a mistake. I’d neglected to think about all the complexities introduced by the relationships between all of the new features. An analogy would be a number of people shaking hands. Two people means one handshake, but double it to four people and you get six handshakes. Much of the coding complexity is in the handshakes.

It also just took a lot longer as I ventured into new territory, and tackled unforeseen difficulties. The end result was that ‘twice’ the game ended up being at least ten times the work.

Another factor in the motivational issues at this point was the type of work I was doing at the time. It seems to be a pattern I’ve experienced in most projects, where the first 20% or so of the work is really enjoyable. You’re working with a clean slate, you’re seeing rapid progress with little effort, and to an extent are just prototyping. You’re rapidly adding features and making tweaks that have a huge effect, and so you’re getting rewards on a daily or hourly basis. The last 20% or so I find equally enjoyable. It’s putting the icing the cake, and seeing it all come together.

But that 60% or so in the middle is a killer. It requires dedication to get through, and is hard work, no matter how much you enjoy your job. It’s full of repetitive tasks, tough decisions, re-creating the same art/code over and over, or getting stuck on seemingly insurmountable problems. Perhaps the worst part was the long list of tasks where each one takes a week or more before I could see any tangible benefit in the game.

Getting feedback

So that part was difficult. One thing I did around this time that I think really helped me get through it, was to release a private alpha version. I split my ‘to do’ list in half, putting everything that would be needed for an enjoyable playable alpha in one list and everything that wasn’t essential in the other. Then I asked on twitter for volunteers and got to work. About 2 months later I had something I felt I could show people, and sent it out for feedback.

This was a great thing to do for two reasons. Firstly, it gave me a medium-term goal to work towards, when the long-term goal of completing the whole game still looked miles off. And secondly, it gave me some feedback at an early stage when I could still make larger changes relatively easily.

Sending out development builds is a bit of a tricky thing. I’m always conscious of just how much work I am asking of the (enthusiastic but unpaid) testers, and also how much more valuable it is to have feedback from someone fresh to the game. So I try to keep the number of versions I send out to a minimum. In Chopper 2’s case this was two builds during this alpha period around halfway through the project, and two beta builds right at the end of the project, when I only thought I had a few minor bugs and features left to go.

Apple’s 100 Ad Hoc devices limit was a major pain, and caused me to not be able to get out all the versions to all the testers I wanted. Hopefully Apple will do something about this in the future, but in the meantime I learned to try to keep the number of testers in each version low, and make sure I only sent it out to people who I believed would give me feedback. This was really tricky to gauge at times, but overall I was amazed at the feedback a lot of the testers provided, and that feedback helped a great deal with the quality of the finished game.

Saving and loading

After the alpha build it was really a matter of just finishing the remainder of the game. The major task was creating the remaining 75% or so of the levels. This included adding all of the enemies that hadn’t yet been created, many tweaks to difficulty and graphical elements, completing all of the user interface and game saving, and a whole bunch of other stuff probably not worth going into.

An early screenshot of the location summary screen

However, during this phase there were a number of hurdles and breakthroughs that are worth mentioning. State saving comes high on the list. If you’re not a programmer you probably have no idea just how hard it is for a developer to save your current progress when you exit a game, and load it all back up again when you resume. For starters, the developer has to have the game designed well enough that this is even possible. Unlike in Chopper 1 for the Mac, Chopper 2 was designed with this in mind, with all parts of the game being able to be loaded either freshly from a level’s defaults or from a game save file.

Where it becomes really difficult though, is the elimination of all of the associated bugs. For instance, every projectile must save its position, direction, velocity, target object and a bunch of other parameters. And when any one of these things is neglected for some reason or loaded or saved incorrectly, bizarre behaviors show up on reload.

Projectiles would disappear or spin off in the wrong direction or suddenly all target the player. With the complexity of the Chopper 2 game state, I simply couldn’t have found all of the issues if I had been actually exiting and starting the app again on a real device. So what I had was a button in the editor, that saved and loaded the state exactly as if I had exited and re-launched the app. This meant that in a fraction of a second I could save and reload the state, and so I played through every level clicking this button every second or so until all the save-related bugs I could find were squashed.

The remote control feature

The remote control feature was also an interesting development. After playing with my shiny new iPad for a couple of weeks it struck me that some iPad games could work quite well controlled exclusively by an iPhone. I immediately realized it would be technically possible, and that I could do it in Chopper 2. So I got to work, and within a day of getting the idea I had a working prototype. The logical next step was to plug the iPad into a TV. So a day later I had that working too, filmed the setup, uploaded the videos to YouTube, started getting press and rapidly had over 100,000 video views.

That turned out to be a great ‘gimmick’ and as such drove a huge amount of interest a couple of months before launch. But it wasn’t only a gimmick. When playing with the prototype, I was pretty blown away by just how well it worked. The remote control method became my preferred way to play, so I could see that other people would really like it too.

The remote control feature in action

Technically, the iPhone controlling iPad feature was easy to implement. I’d already had some basic networking experience, and GameKit made the process pretty painless. I’d also had experience with multiple displays on the Mac, and had resolution independence to the extent where it looked good on both iPhone and iPad. So the TV out thing wasn’t too difficult technically either. And in fact it really only required a few lines of code. However, designing and creating the setup interface, and tidying up the loose ends, allowing people to plug in and unplug the TV at any time, and dealing with bluetooth reconnections and such, did end up adding a few weeks to development. Overall though I feel it was well worthwhile, and would do it again in a heartbeat.

The launch

Lastly, the launch itself also deserves a mention. Chopper 2 came out with quite a bang, getting a solid week of insanely high sales numbers, reaching the #10 top iPhone app in the US, and the #3 top iPad app. In a market dominated by large publishers and 99c licensed titles, this was a pretty remarkable launch for an indie game at $2.99. I put this success down to a number of factors.

The initial spike and decline - The spike was higher and longer, and the decline slower than expected

Firstly, I had set a release date in the future when I submitted Chopper 2, and adjusted this but still gave myself a few days when it was approved. When an app is approved developers can send out promo codes to the press and they can then download and play it, even though the app itself is not yet available in the store. So after it was approved I decided on a release date and sent out nearly all of my promo codes to all the contacts I had. The result of this was a number of reviews and articles on or just after the release date.

It probably shouldn’t be overlooked, so I’ll also say that in general these early reviews were very positive. It definitely wouldn’t have had such early success if it had been in any way poorly received.

Secondly, I already had a pretty large and active customer base playing both Chopper and Chopper Lite. A few months before Chopper 2 was done, I had released an update that put a button in both these apps on the main menu simply titled ‘Chopper 2′. When people clicked this, it showed a built in advertising page, with a button to get more information. As soon as Chopper 2 was available world-wide, this button changed (in the lite version only) to say ‘Available Now!’ next to it and linked directly to Chopper 2 in the App Store. This button had an insane number of clicks in the first 2 weeks. Though of course it wasn’t just the button. The fact that well over a million people had already tried the first version must have helped!

Also, and I’m not sure exactly how much of an effect this has had, I spent about a week carefully crafting the Chopper 2 trailer. I’ve already written a lengthy ‘making of’ post, so won’t go into it here. So far it’s had 35,000 views, which isn’t huge, though not insignificant either. I do wish I could place this on the App Store page somehow. But people were generally impressed with the production values of the trailer, and I’m sure it sells the game well. iPhone game trailers are generally pretty bad, so I suspect just getting anyone to click the play button is a pretty giant hurdle.

There were other factors to the successful launch, too. Fellow developers and many other fantastic people helped to promote it in various ways, including some free advertisement placements and lots of tweets and the like. Apple featured it in the App Store 2 days after launch in many countries, and are continuing to do so, which has an absolutely huge effect.

Chopper 2 featured on iTunes in New Zealand and Australia

I think the launch sale was a great way to go. The base price is $4.99, but it was launched at $2.99. Some developers have launched an app at a high price point then drastically dropped the price a week or two later, which tends to piss people off. I did the opposite. I think people responded pretty well to this, and it seems the right thing to do. Though I’ll never know if it would have been more successful launching at $7.99 and dropping to $4.99 later.

Also, as mentioned earlier, the 200,000+ views of the remote control/TV out videos must have helped. And the iPhone controlling iPad feature alone must be driving a lot of interest, with Chopper 2 being one of the first games to offer the option.

Conclusion

Despite what you might think, I like birds very much.

Overall, I am immensely proud of what I have achieved. Chopper 2 is of the high quality I was aiming for, and has been very well received.

If there was a single negative thing to say about the experience it would be that it just took too long. I’ve mentioned the factors that caused this, and I definitely don’t regret the time spent, but I will be much more cautious about the potential length of future projects I take on by myself. 16 months was too long, and I hope I never work – alone – on a project of that length again.

On the positive side, I am very, very happy with how the game came together as a whole. The music, the landscapes, the simple story and the text/fly-throughs that present it, along with the gameplay itself, all come together to create a cohesive whole that I feel is my greatest artwork. It has been a labor of love, a huge learning experience, and a great success.

Then there were various Chopper 2 videos, one of which has been viewed over 100,000 times now, and now I have just completed the Chopper 2 trailer:

So I’ve been through 3 video cameras, a bunch of different techniques and a few terrible videos, and thought I would share a few things I have learned and techniques that were used to film and produce the Chopper 2 trailer.

So first up, the camera is very important. Chopper 2 uses a Canon 7D digital SLR. Previously I had used consumer level video cameras, with the DuckDuckDuck 2.0 trailer as well as the Chopper 2 bluetooth video being shot with a Sony HDR-SR11. This was OK, though I just wasn’t quite happy enough with the quality I was getting. White balance always seemed to be a problem, and even when it was in focus it always seemed a bit blurry.

I bought the Canon 7D for the explicit purpose of filming the Chopper 2 trailer, and as such I was not very familiar with it, but found I got pretty good results very quickly. Focus was again an issue, which I’ll get to later, but white balance wasn’t a problem and overall setup was quick and I’m happy with the results.

Whatever camera you choose, make sure you have manual control over white balance, focus, and exposure. Without any one of these features your video quality will suffer greatly.

Lighting is the next important thing. You need to have well lit hands (none of that silhouette rubbish) and some kind of lit background as well, but without causing reflections on the screen. I have found that the best way to achieve this is to have lights on either side just a bit above the device level, and a lot of black fabric around and above to prevent any reflections from walls or the ceiling. You also have to constantly monitor for reflections of yourself or the camera, which is just one reason why you need two people to do the job. Someone has to monitor the footage as it is being recorded and constantly tell the player/user to move to the center of the shot, get their forehead out of the reflection,  hide the audio out cable, and refocus as needed.

For the lights themselves I am using 6 roughly 50 watt fluorescent energy saver type bulbs. 3 of them came in a mount designed for photography, and provide a slightly yellower light, while the other three I picked up cheap and stuck in some cheap clip on lamps and give a slightly bluer light. I think in general you can get away with this cheaper option, and don’t need to spend a huge amount on lighting gear. Don’t rely on natural light, you need consistency which that cannot provide. And don’t rely on what ever is hanging from your ceiling. Aside from the reflection issue, that just doesn’t provide enough light, and often has a strong yellow cast.

For the background I went down to an art supplies store and bought a $20 roll of what they called ‘Printable banner material’. which was a little glossy, flexible and very white, which suited my goal of having a pure white background nicely. I taped this to a wall, and rolled it down onto the floor, and then my lights on either side pointed slightly down/back to light it up while still providing enough light for the hands.

I also got a tripod with the explicit purpose of filming this trailer. I have had issues in the past trying to play a game comfortably while remaining out of shot, so opted to get a tripod that had a multi-angle central column, allowing me to get the camera over top and look down on the device while I sat comfortably. This was very important, as there was about 8 hours of filming all up, a lot more than there would have been otherwise!

So now on to focus. This is really really hard, especially with tilt controlled games. All iDevices, the iPad in particular are prone to unsightly moire patterns when perfectly in focus. So all shots have to actually be slightly out of focus. It was also impossible to tell sometimes by looking at the LED display on the camera whether the current shot was too in focus or not. Add to this the tendency to slowly change positions, and the huge distance variation introduced by having a tilt controlled game, and you end up with a bit of a nightmare. Much of the footage I got was too blurry, and a lot of it had the moire patterns too. I just came to accept this, aim for slightly out of focus and just shoot 5x as much footage, expecting to chuck away 80% of it for focus reasons. It pays to regularly stop and view the footage on a computer to make sure you’re at least getting some of it right.

What I did find is that the iPhone 4 is much less prone to the moire effect, and on that device it can largely be ignored. I also found that shots taken off to the side at a high angle mean that the area perfectly in focus is pretty small, and it seemed to just generally reduce the effect a lot.

Exposure wasn’t much of an issue. I pretty much set it and left it, though I did have to balance the screen brightness with the exposure to get the background white, and both hands and screen not too light or dark. Notably the screen in the bluetooth video I shot earlier is too dark. Don’t forget to check for that every time you film.

Audio was an interesting problem too. You almost definitely want to record without any music, as you can add that in later, but you will however want to record any sound effects. This introduces the issue of having an audio out cable in the shot, as you definitely don’t want to just let the built in speaker be picked up by the camera mic. I actually took an old pair of iPod earplugs and spliced the cable onto a cable with a 3.5mm plug on the end. I did this because the other cables I could find all had plugs that were too bulky to hold comfortably while trying to conceal the cable. It also had the benefit of looking like proper Apple gear when it did come into shot, and not just some cheapo cable from the corner electronics shop. If you do decide to chop up some earplugs, note that you can just burn off the coating that would otherwise prevent contact with another cable.

So all of the footage in the trailer has this cable plugged in, and my hands or arms are concealing it most of the time. There was one shot where I crudely edited out a cable post production, and there are a couple of shots where you can see it here and there, but it seemed pretty effective. The audio was wired to a Mac and recorded with Quicktime Player. I had tried plugging it into the 7D but the quality was terrible. So I had to sync up the audio later.

Holy crap this is turning into a book. But while I’m on the subject of post production, the footage was compiled and the trailer made in Final Cut Pro. The Majic Jungle Software intro and Chopper/explosion ending were created in Motion. I love both these apps very much. I’ve never used another proper video editing app (and only got Final Cut a few months ago) but found them really intuitive and just really like them. Expensive, but worth it.

The rest of the footage, the text titles, and the full screen game footage at the end was rendered out from Chopper 2 itself. I cannot recommend enough that if you are making an iPhone OpenGL game, make it compile on a Mac too. UIKit stuff could be a bit harder, but for OpenGL it’s dead easy to make it cross platform. Anyway, with my editor I was able to tweak a couple of things, get it rendering to a 1920×1280 FBO, then readpixels and spit out full frame images at 25FPS. Of course I had to record audio too, which was done using SoundFlower and Quicktime Player. Then I compiled the image sequence, synced the audio and had 1080p footage of Chopper 2. I had tried using screen capture programs to do this, but found the ones I used would drop frames frequently even at lower resolutions.

Using the game engine to render the text was an idea I’d had for a long time. I think it’s great to have as much actual game engine footage in a trailer as possible, and personally loath it when trailers are full of pre-rendered footage you’d never see in game. I just don’t see the point.

The music was a quite heavily modified version of the Chopper theme. I always like to match cuts with music beats, so i actually planned out the whole thing to fit evenly into bars, and gave myself a certain number of bars to fit the music into. It was a bit tricky, but pretty effective I think, particularly with the ramping up at the end. All of the music in the trailer and in Chopper 2 was created with Reason, which is another software package I like very much.

So I think that pretty much sums it up. If you’ve made it this far hopefully you’ve learned a thing or two, I sure have over the past few months. Feel free to ask any questions you might have in the comments, I’ll do my best to answer them.

So the code checks for 4.x, checks for an unknown or flat device rotation and then sets the status bar orientation to UIInterfaceOrientationLandscapeRight. Even if the device is actually being held UIInterfaceOrientationLandscapeLeft, the result is fine, as I am then notified of this, and can rotate to landscape left. I call this code in my main UIWindow subclass method, but I imagine doing so in the app delegate should be fine.

I expect this is a bug in iOS 4.0, but the whole orientation system is such a mess I’m not sure what the desired behavior is supposed to be. So it may or may not change in 4.1, but this code shouldn’t cause any particularly nasty behavior if it does.

BOOL isAbove3_2 = NO;
NSString *reqSysVer = @"3.2";
NSString *currSysVer = [[UIDevice currentDevice] systemVersion];
if ([currSysVer compare:reqSysVer options:NSNumericSearch] != NSOrderedAscending)
{
    isAbove3_2 = YES;
}

if(isAbove3_2)
{
    UIDeviceOrientation deviceOrientation = [[UIDevice currentDevice] orientation];
    if(deviceOrientation == UIDeviceOrientationFaceUp || deviceOrientation == UIDeviceOrientationUnknown)
    {
        [[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationLandscapeRight];
    }
}

So first up, here is the problem. The PNG file format stores color profile information in its header.

What this means is that when you create a PNG, there is a chance that the software you use to create it may store information about the color profile you have your monitor set to, or the settings of your camera, or the settings you are using in Photoshop in the image file itself.

It is particularly worth noting here that different software and different devices will create and store different profile settings. Some won’t store anything. As well as this, different software or devices will also display the image differently. Some will apply all or parts of the embedded profile to the image before displaying it, some will ignore it completely. Notably, when you build for iPhone, the default build procedure completely strips this information from any PNGs.

You might already see the problem here, but I’ll spell it out with an example I encountered just yesterday.

I have a Mac based level editor for Chopper 2. I also have a few custom or 3rd party tools that I use to generate images for the environments. One of these tools created a PNG for the terrain. One of them created a PNG for the sky box. In the editor, they looked great next to each other, the horizon of the terrain matched the horizon of the skybox perfectly. However on an iPhone, the terrain was much darker, producing an ugly contrast.

Why? Because the tool that created the terrain image saved my color profile information, the tool that created the skybox didn’t, the editor observed the profile information, and the iPhone didn’t.
This image shows part of the terrain file, the left side is the original, how it looked in my editor and Photoshop. The right is after running pngcrush and stripping out the color profile information. It is also how the original looked on an iPhone.

This kind of error (and it’s always a little bit different) usually costs me a couple of hours every time it happens, and it happens about once every couple of months or so. It’s frustrating, and I totally blame the fundamentally flawed concept of storing color profile information in files. I understand the intention and theory behind it, but in practice it’s a stupid idea that never properly achieves the desired effect and causes more harm than good.

ANYWAY… luckily I have found a partial solution. There is a tool that strips the color profile information from PNG files during the iPhone build process. When you come across this problem (or if you’re more organized than me, every time you use software to create a PNG file), you can use this tool to pre-strip it. This is the tool and command to strip all color profile information:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush -rem alla infile.png outfile.png

Luckily, in my experience anyway, Photoshop will not add color profile information to an existing file, but only when you initially create one. So from that point on it should be safe. I can’t vouch for all other software though. I have seen software that re-applies the profile every load, thus making the image incrementally darker every time I saved and re-opened. Such is the state of affairs with color profiles. Also, unfortunately H .264 movies (and other formats) have all the same issues. I’ve seen Quicktime do some truly horrific things to the colors of my movies, and I have no idea how to tell it to just leave the colors alone.

One note of caution, I believe that pngcrush command may also destructively compress the image. You should probably do it only once if possible, however in practice I’ve never seen any artifacts worth worrying about.

But as a developer, I should have looked at them a lot earlier. I have spent hours over the past few days using We Rule and GodFinger. It has been a real eye opener, so I thought I would share some thoughts on them.

I’m going to call them “obligation games”. I’ve heard the words “social obligation” thrown around about these types of game in the past, and while it does apply, I think the genre is better defined by the word “obligation” alone.

The main obligation is to come back and stay a while. They prey on the deeply rooted human need to care for things so they grow, and to not let things die. Stuff grows quicker if you spend more time in the game, and If you don’t start up the game within a certain period of time, things die.

The user part of me, who gave up smoking a year ago, sees this as another smoking habit. It’s a bit nasty to start with, then once you get the hang of it, you feel unfulfilled without it. At a level below the conscious and reasoning mind, you simply have no choice other than to start up the game to harvest the onions you sowed 1 hour ago. Imagine the horror if those onions went bad. You’d lose like 7 fields worth. And that would be 1050 gold, shit, then I wouldn’t be able to sow another 40 fields of onions.

So you spend hours a day looking after your virtual farm. That is the “killing yourself” part of smoking. You are spending hours a day accomplishing absolutely nothing. That farm will not teach you useful skills, it will not help you to create meaningful new relationships, or put food on the table. The hours a day you spent harvesting virtual onions could in fact have been used in the real world achieving all of the above.

But as a developer, I think it’s brilliant. People are hopeless at seeing the real world. People smoke even though it kills them, they gamble even though they will lose over time, they get insurance even though on average they pay more than they get, and they buy on hire purchase even though in the long run they’ll get less stuff as a result.

It’s perfect. Hook people by praying on their most primitive urges, offering them primal candy and punishing them if they don’t come back when they said they would. Make the gaps between the candy slightly larger each time, so just like a real drug the user plays for longer and longer to search for that elusive first buzz. Then once you’ve got them completely and utterly addicted, start charging them.

I’m sure most people who know me would expect I am about to take the moral high ground here and dismiss the whole obligation game genre as evil.

Well I’m not going to.

People have to take responsibility for their own lives. If you’re an alcoholic gambling smoker with insurance playing ‘We Rule” on your credit-card bought iPad, you deserve the consequences. Now all ngmoco have to do is make the games actually fun (they’ve got the addictive part nailed, but the gameplay is poor), and we’ll all be doomed.

Chopper Lite has been available for nearly a year now. It is getting between 1000 and 3000 downloads a day, has been for months, and before that it was getting many more.

How many sales does that amount to? I don’t really know. I have seen echo effects in my stats, which suggested maybe 20-50 sales a day or so at various points, but I really don’t know.

But here is the crazy thing. Until just days ago, I had no up-sell in my lite version. Nothing explaining what the full version offered. No links to the full version. The lite version was stand-alone – I assumed people knew what ‘lite’ meant, and would hunt for the full version.

Madness.

This happened because at the time I released it, lite apps were getting rejected all over the place for selling too hard. I decided to err on the (extreme) side of caution, with the intent to add some links in my next feature update. But a feature update never came.

So that’s my lame excuse.

Turns out though, that putting a few links and a sales pitch in the lite version has contributed to a 300-500% increase in sales of the full version. Unfortunately, the same updates that introduced these changes also made Chopper universal, and coincided with the iPad launch, and I cannot fully isolate this effect from the iPad effect.

However, I have seen that in the past 5 days or so just over 10,000 people have clicked on one of these links. That is 10,000 more than before. Hundreds have bought the full version of Chopper as a result, though just how many, I don’t know. And I don’t know how many of those people would have just bought it by searching in the App Store.

But 10,000 clicks! 300-500%! Hundreds! Fuzzy stats that indicate something good!

So that is my pitch to you. If you don’t have links to your full version in all the right places, and some stuff saying what you are missing out on in the lite version, do it. Now. And be sure to use LinkShare when you do it, and add a signature thing to each link so you can see where in your app people are clicking.

Why make all the effort to go to the movies, when you can watch HD Blu-rays at home a little later, only a little worse, and eventually a little cheaper. A PS3 and a decent sound system isn’t far behind.

But I don’t pick up many Blu-rays. They often cost more than the cinemas, and sometimes don’t play without a player update, or take forever to load up. Does anyone understand those insane menus? And DVDs are way cheaper, play on more systems, and are not much worse.

I hardly ever watch DVDs though, they are full of piracy warnings and I have to go to the store to get them. They get scratches and skip or don’t play. iTunes movies on an AppleTV are much more convenient.

But I don’t download many iTunes movies. The selection is crap, and bandwidth charges really add up. The AppleTV has DRM and such too. It’s easier and cheaper to just torrent them.

I don’t torrent much stuff though, it takes forever, uses up my bandwidth and it’s often shit quality. And I worry that my ISP might be watching me.

I’d much rather just go and watch the movie at a decent quality in a theatre.

UPDATE 2 – It has now been discovered that gifting does not affect ranks. So the scam doesn’t exist now (it may never have) and I regret doing this whole post. I’ll leave it here however, as a reminder to wait until all the facts are known before ranting about what could be. Lesson learned. Now move along :)

Earlier this week, Apple opened up app ‘gifting’. Anyone can give any app to anyone else as a gift. This has been available for music for a long time, but it has only been applied to apps this week.

So that’s great right? Perhaps, but it opens up the potential for a pretty big scam.

The first thing to note, is that developers will still get 70% of the purchase price of gifted apps. So developers can gift their own apps to anyone, and in the end, only pay 30% of the purchase price to do so.

OK, but why would developers do that? Well, doing bulk giveaways was not possible before. Developers had 50 promo codes per update, and that was it. Now developers can do big giveaways of 1000 apps+.

So why do that? The obvious answer is to gain press and interest. Large scale giveaways attract attention, so for $300, a developer can give away 1000 copies of their app, and lavish in all the attention this creates.

But it gets better. To gift an app, you need the email address of the recipient. This is how Apple knows who to credit the app too. So not only does a developer get hype and press, but 1000 email addresses to stick on their mailing list, and announce new products to.

And it gets better still. At this point, no one is certain of whether gifted apps affect ranks in the top 100s. But unless Apple are displaying an uncharacteristic bout of careful App Store planning, they almost certainly will. So currently, there is a very good chance, that the day a developer gifts those 1000 copies, their app hits the top 100, and gets all the extra eye-balls such a placement receives.

The developer need only sell 300 copies due to the higher top 100 placement, and this little scam has paid for itself.

But wait, there’s more.

Developers needn’t pay full price when they gift their app. Right now in New Zealand you can buy 2x$20 iTunes gift cards for $30. I have heard of similar specials being held in the US at places like Best Buy.

So at 25% off, you’re paying only 5c per 99c app giveaway. And in New Zealand’s case, and no doubt some other locations, you’re paying GST for the card, but not on the app purchase. So apple end up actually paying me around 5c (tax free) every time I gift an app.

So, I get press, a mailing list to spam, a shot at the top 100 with the associated extra sales, and Apple pay me $50 to do it.

FTW!

Except I won’t do it. If it’s not legally wrong, it’s certainly morally wrong. I’m posting this as it is interesting, and perhaps as a warning to Apple, but I hope developers won’t do this. It would make a mockery of the store, and is unfair to Apple, and unfair to honest developers.

Unfortunately, some developers will, and some are already trying it out to some degree.

I just hope Apple close the loophole before this gets out of hand. A limit to the number of gifts you can send per account per month would probably do the trick.

To be universal or not to be universal. That is the question.

There are a ridiculous number of apps in the app store, and a decent number of those apps will have native iPad ports available on April the 3rd. Some of them will ask the user to pay for the native iPad version if they already have the iPhone version, some will not.

Some will unfairly demand payment for the same app with twice the pixels. Some will fairly ask for a contribution to the large amount of work involved in tailoring an experience for a uniquely new device.

How developers’ decisions to go universal or not are perceived by the public is currently an unknown. It largely depends on how Apple implement the iPad App Store, and change the iPhone App Store, as well as what other developers decide to do.

But my apps will be universal. Apple are encouraging it, and customers will vocally prefer it.

And though I may halve my sales, I also may double the number of devices I have apps installed on. The maths of this is all a bit beyond me, but a hunch says that the day one iPad users will sell my apps better than anyone else ever will. I want them all, and making my apps universal is a good way to get them.

UPDATE – It has been pointed out to me that Apple are requesting that submissions of universal updates to current apps be left until after April 3rd. See about half way down this page: http://bit.ly/cSmog7 – “Don’t submit a universal app as an update to your existing iPhone app until after iPad ships.”

This sucks, as I’ll be missing out on the launch, but I’ll be going universal anyway, and most of this post still stands. I guess we’ll just see substantially less universal apps at launch.