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
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.
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.
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.
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.
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.
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.