Some Interesting Graphs

Written by David Frampton @ 10:42 pm, February 18, 2011

I’ve often been asked how various events have changed sales/revenue. So I thought I would look back through my sales stats and share what happened over a few key moments.

All of theses graphs are generated using the invaluable App Store sales tracking app AppViz.

First up, the launch curve. This is a curve that I have seen in every single launch of any app on any platform, and looks like this:

Sales tend to halve every week or so, then after a month or two it starts to level out. There are exceptions to this rule, which I think can mostly be chalked up to a large amount of post-launch hype or a feature or other marketing. But as I said, every single product I have launched has followed this curve. So (even though the temptation is overwhelming) don’t bother multiplying launch day sales by 365!

This next graph is of Chopper for iOS’s sales during a period where nothing much was going on:

Each of the spikes is a weekend. Without any external influences, Chopper (and Chopper 2) always have troughs from Monday to Wednesday, and spikes around Sunday. Thursday and Friday are usually a bit better than earlier in the week. It’s still too early to isolate whether this effect is also present on the Mac App Store, though early indications are that it probably doesn’t.

iOS games and entertainment apps will probably all see graphs like this. From what I have heard, productivity apps see the inverse.

This graph is a little silly perhaps, but it compares sales of Chopper 2 and DuckDuckDuck:

I have seen little to no effect on DuckDuckDuck when Chopper is selling well. It’s worth noting that I don’t have a ‘More Apps’ advertising page in any version of Chopper, which might help, and the games are targeted at totally different audiences. But I think the lack of any transference at all is interesting, as it shows customers are currently not in any way being influenced by the Majic Jungle brand to try another one of my apps.

On the other hand, Chopper 2 had quite an influence on Chopper 1’s sales (not to scale):

I worry a little that this is partly due to people downloading the wrong app. But I also expect that there is a certain number of people who bought Chopper 1 first, wanting to experience that before Chopper 2, as well as those who after having played Chopper 2 then bought the original.

This next graph has a couple of interesting points. It shows revenue in the UK only for the Mac version of Chopper 2 compared to the iOS version:

The surge in early Jan is the launch of the Mac version on the Mac App Store, combined with the 99c sale of the iOS version. It’s hard to isolate the effect of the sale vs. the effect of the launch of the Mac version during this time, but iOS revenue did go up substantially. It pales into insignificance compared to what happened two weeks later however, when Chopper 2 got ‘game of the week’ on iPhone and iPad in the UK and Europe.

Game of the week isn’t something that developers have control over, but it is clear to me that it is by far the best out of all the feature spots, and drives an insane number of sales. I’m sure it’s no coincidence that it happened just after the surge (and high Mac App Store presence) in early Jan though. On the App Store, success breeds success.

It’s a little hard to see, but Mac sales did also increase with the iOS game of the week feature, though not by much. Where iOS sales went up to around 20x previous levels, Mac sales were doubled.

This graph shows Chopper 1 sales over the Christmas period 2009 (again not to scale):

This was another interesting period. Late November I dropped the price to 99c. This increased the number of sales leading up to Christmas, though decreased revenue. Then just before Christmas I put the price back to $2.99.

I’m not sure how much of an effect this strategy had on revenue, because once again there are more than just one factor at play. However If you ignore the blue line and just focus on the yellow/green one, it’s pretty clear that revenue not only went up substantially on Christmas day, but stayed much higher for an extended period. In fact this post-christmas increase lasted about 3 months before returning back to normal levels.

I put this down to two things. Most importantly there are a large number of new iPod Touches and gift vouchers out there on Christmas day, and both of those can last a long time. And secondly, the previous year (2008) Chopper had been the number 1 game over Christmas. To some extent (possibly a crack-pot theory, but possibly not) Chopper may be associated with Christmas as a result.

And one last graph, this is Chopper 2’s revenue on the Mac App Store to date:

It follows the standard launch curve, however it is perhaps a little steeper than normal, leveling out at a much lower point. I put the steepness mostly down to there being two product launches being multiplied together. It was not only Chopper 2’s launch, but also the Mac App Store’s launch. And the launch couldn’t have gone better, with Chopper 2 being at #1 or #2 in nearly every region for the first couple of weeks. So I very much felt the effects of the initial boom, then quick decline of interest in the Mac App Store as a whole.

I’m still very happy with the revenue in this tail end though. The increase in the past week is due to a ‘Staff favorite’ feature, and it currently sits at around #30 in paid apps in the US. I don’t think many people are currently making huge amounts of money on the Mac App Store, but it’s off to a healthy start, and will only get better from here.

So hopefully these graphs are of interest. I intentionally didn’t post any actual numbers, which might be a little disappointing, but doing so always seems to lead to ‘Developer makes $X overnight’ posts, which I’m really not keen on. So sorry about that, but hopefully this post has still been interesting anyway!


Written by David Frampton @ 3:52 am, January 24, 2011

My last post stirred up a bit of controversy, and though there were many nice comments, there were also those who thought that after ‘making 100k’ in a week I shouldn’t dare to complain about nasty emails.

I totally disagree with that. Just because someone is successful doesn’t mean they lose the right to speak out about the bad things that come with that success. Such a point of view is foolish, and often shows that such people are allowing envy and hatred to cloud their minds. I wouldn’t be surprised if these people are the exact same who I was targeting in the post. Outraged at being called out for being mindless thugs, they did what they know best.

ANYWAY. There was some truth in such comments. The post was not adequately balanced. It was, as I titled it, a rant.

I could go on and on about all the wonderful things that have gone right for me, and my apps. This would make boring reading, so I won’t.

But I do feel the need to give a little perspective. Chopper and Chopper 2 have done amazingly well, and I am blown away on a daily basis by the incredible things that happen to me and my apps. From the fan comments to Apple’s feature spots to just seeing the ranks and sales reports. I am very, very grateful and feel insanely lucky to be where I am.

Less than a decade ago I was selling paint in a retail outlet 9-5, Monday to Friday and getting paid about $10 an hour. I did this for 2 years, before it finally did my head in and I quit to go on the unemployment benefit.

During the next couple of years I managed to survive as an artist, where I occasionally only ate porridge or lentils for days due to a lack of money to eat properly. I also taught myself to program, which really was what put me on the path to where I am today.

I won’t go in to my whole life story, but that part of it perhaps helps to offer a bit of perspective.

There is absolutely no doubt that I have got from there to where I am thanks to a lot of hard work over the past decade, but also a lot of kind, generous, and helpful people, and a shit load of luck.

I didn’t make 100k in a week, I made it in years of hard work. But that doesn’t stop me from being hugely grateful for my privileged situation.

Though comments from idiots can make me angry enough to type up a rant, deep down I’m the happiest guy in the world.


Written by David Frampton @ 1:49 am, January 18, 2011

Chopper 2 launched on the Mac App Store on the 6th of Jan, at 99c, and as the #2 paid app. In the first week it sold over 100,000 copies at 99c, and continues to sell well (currently at #5). Keeping an eye on tweets about it, and listening to feedback, it has overall been well received.

It has made enough money to make the port, and even the resulting support headache worthwhile.

But I am angry. I’m angry at a small percentage of customers who actively work towards harming its success. I’m angry at the customers who send me nasty emails or reviews, threatening me with ‘telling Apple to remove it’ or rating it 1 star with a ’should be cheaper than free’ remark because after paying the ridiculously exorbitant 99c, they found it didn’t live up to expectations. The absolute worst is users who condescendingly ‘try to help’ by outlining every little thing they think is wrong with it.

I’m not sure if it’s that Mac users have more time on their hands to bitch to developers and leave nasty reviews, whether they expect more than iOS users, or if something else is at play, but I have clearly scraped the bottom of the barrel by having such high visibility at such a low price at launch. And I don’t like what I’ve found there.

It has changed me.

Once upon a time I looked forward to support emails. They gave me an opportunity to improve the product, and find out what my users think.

But no longer. I am now incredibly cautious of engaging my customers. Paying too much attention to support trolls has ended up costing me huge amounts of time and always ultimately proved pointless. These people don’t care about Chopper, they don’t care about me, they just want to vent and be noticed. And I no longer have any time for them.

The majority of support emails and reviews have been from nice people who genuinely want to help, but they are overshadowed by 10-20% that aren’t. The anger, the sense of entitlement, and the overriding theme that I owe them something for daring to take up any of their time is sickening. It makes me angry at the world.

What really makes it difficult for me is that I put my heart and soul into this game. I’m not just the support guy. I’m the guy who spent 16 months creating the thing. I take this reckless disregard for my hard work and care personally, and always will. I totally feel like I have worked my ass off to create something for people to enjoy, only to have it thrown back in my face.

These emails have a very real affect on my motivation levels. I have not had the motivation to even fix many of the issues that are causing some of the emails/reviews. I really have a sense that it is me vs. them. If they are going to be such cocks about it, why should I even bother. I can see now why many companies provide rubbish support, and have a ‘give us your money then piss off’ attitude. They have no doubt learned the hard way how soul destroying taking pride in your products can be.

I now have my brother helping me with support, and he has taken over the majority of the load. This is helping quite a bit, though I still find myself reading App Store reviews and the emails as they come in, as any good developer would. It’s still very hard to watch, and will continue to be as long as the thoughtless, negative comments keep rolling in.

In the mean time, I’ll keep going. I’ve left two previous jobs/careers in part because I was fed up with the customers therein, but have somehow managed to land myself in the thick of it once again. Hopefully things will improve over time, or I’ll develop a thicker skin.

I knew I was taking exactly this risk when pricing it at 99c on launch, especially with the remote feature which was always going to fail for some people due to obscure network/firewall issues. Over time hopefully improvements to the apps will help, and I’m itching to put the price up so I can get a better caliber of customers, but I still have to finish the free remote app first.

Thanks for putting up with my rant. Don’t worry, I’m not jumping ship just yet.

UPDATE – A follow up post adding some needed perspective is here.

App pricing strategy

Written by David Frampton @ 6:14 am, January 5, 2011

I’ve read a lot of opinions on how to price apps from iOS and Mac developers over the past few years that make me cringe. Particularly lately with the Mac App Store launching, many developers have really struggled with how to price their apps, and some are making the wrong choices.

I’ve seen developers state that they will charge 1.4x their shareware price, to make up for Apple’s 30% cut. I’ve seen developers say that they will price based on the time spent, or the complexity of the app. Others have said they will price it at what they ‘feel it is worth’ or what they think customers should pay.

All of these ideas are wrong.

For any given time period there is a single price point that will make the most money. There is also a single price point that will get the most downloads. And neither of these can be figured out by any of the above reasoning. In fact they can’t be figured out at all, it’s a best guess situation. But that best guess can be a hell of a lot better than ‘add 40% to the shareware price’.

The first thing a developer should do when pricing an app is to decide on what their goal is. Whether they want to make the most money, or grow the largest customer base, or probably somewhere in-between.1

The ideal price point for any app is going to be somewhere between the ‘most money’ price and the ‘most customers’ price, dependent on how important a large customer base is. It could even lie higher than the ‘most money’ point, to drive customers to another product. The ‘most customers’ price is easy. Without the developer actually giving money to the customer, that price is free. The ‘most money’ price is the tricky bit. This price is something of a bell curve, it is unique to every app, and varies continuously.

To clarify this ‘most money’ price point concept, at 99c, developers are selling their apps at the cheapest price possible to make money – without going freemium which I’ll ignore here for simplicity. Most apps will make less money here than at higher prices most of the time. Despite what you might read, 99c is not the average ‘most money’ price point. At $1.99 you might expect 75 downloads if you were getting 100 at 99c. To continue pulling numbers out of the air, at $2.99 you might get 40 and at $4.99 you might get 10. This is basic economics, and in this particular case means the ‘most money’ price point is $1.99.

I won’t go into exactly where this price lies for any given app. It requires experimentation, and research into the potential customer base and competition. It is also heavily influenced by the app type, any current marketing pushes, and many other external forces.

What is really important here, and really what is the entire point of this post, is that this elusive price point that makes the most money bears no relation to so many of the pricing strategies I have seen. The amount of time the developer has spent, other development costs, Apple’s percentage cut, emotional investment, or ideological concerns do not in any way affect the price point at which an app will make the most money.

Developers will continue to price higher because they think app store prices should be higher, or because they spent 6 months on the damn thing so it is worth $20, but these developers are leaving money on the table. Whether they are actually achieving anything or proving anything by doing so is up for debate, but they are certainly not making the most money they could out of their work.

Price is hugely influential in whether a customer buys an app or not, and is one of the most powerful tools that developers have to position their apps and drive sales. It is incredibly important to get right. Throwing away that opportunity by carelessly pricing on emotional grounds is a huge waste, and can be the difference between a failure and a huge success.

  1. Developers also have to decide how generous (or not) they are going to be. In general there can be more money to be made short term by being evil, but this will eat away at future potential, as customers remember the way they were treated. When Chopper 2 reached the #10 app at $2.99 there was a huge temptation to drop to 99c, get higher in the charts and stay there longer. But I didn’t, as this would piss off everyone who had paid $2.99 already at the ‘launch sale’ price. It probably cost me financially in the short term, but it didn’t destroy my customers’ trust.

Update: You may also be interested in this post by @MarkusN

It describes the pricing strategies and expectations for the Mac App Store launch of myself and other similar minded developers.

FNGradientView – an NSControl for configuring color gradients

Written by David Frampton @ 7:26 am, December 10, 2010


I always intended to make this available to other developers, and now here it is. FNGradientView provides a simple user interface and storage class for creating color gradients in Cocoa. It supports opacity, drag and drop, and view re-sizing. The FNGradient class (the data model) also supports NSCoding and NSCopying, so can be stored in an archive relatively easily.

All you should need is the FNGradient class, the FNGradientView class, and Color.h, and make sure you add QuartzCore.framework to your project.

Included is a demo app with an Xcode project that shows the FNGradientView as well as a preview which uses the control and displays the gradient animating through time.

You’ll have to look at the headers for documentation. It is intended that you create a custom view in interface builder, and set the class to FNGradientView. Then your app can access its FNGradient object, and ask for a color for a given fraction. Though programmatically creating the view should work just fine.

There are a few aspects to the code that seem odd to me now, two and a half years after I wrote it. But it should work on all systems above 10.5/Leopard, and may even work on 10.4, I did have a slightly older version running just fine on 10.4 so it shouldn’t take much.

I will read any emails, but may not respond, as this is just a free blob of code sent out into the wild for the benefit of any who should stumble upon it. I already have enough emails to respond to from my projects that make money!

But I do hope it is useful, and would appreciate any bug reports, even if I can’t find the time to respond. And I’d love to hear where it is used!

The official FNGradient license: Use any of the included code however you wish, but if it goes wrong, that’s your problem!

You can download the source and demo app here.

Just buy it

Written by David Frampton @ 11:49 pm, August 29, 2010

Whenever some software shows up that might make my job easier, my initial, gut reaction is ‘no, I can do fine without it’. I’m sure I’m not alone in feeling that, and I’m sure plenty of people listen to that reaction and go on to make do without.

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.

Chopper 2 Postmortem

Written by David Frampton @ 7:43 am, August 19, 2010


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

Chopper for Mac - early build

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

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

The shareware version of Chopper for Mac

Chopper on the iPhone

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

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

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

From time to time there were a few kinks to iron out

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.

The incessant flying tanks

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

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

Editing Text

Creating worlds

Terrain Mesh

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 sky box

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

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.

Math Problem

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.

Leopard desert

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.

UI Development

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 video that went viral

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.

Remote control feature in action

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.

Launch Sales

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!

The Chopper 2 trailer

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.

Making of the Chopper 2 trailer

Written by David Frampton @ 4:36 am, July 23, 2010

I’ve made a number of iPhone videos in the past couple of years. One of the first was of DuckDuckDuck
That was so awful I tried again. Notably it claims to be ‘Better Quality’ which is a bit of a joke. The focus is perhaps a little better, but it’s still terrible. The DuckDuckDuck 2.0 trailer was considerably better, and around the same time I also helped out with the Burnball trailer.

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.

Launch orientation in iOS 4

Written by David Frampton @ 8:46 am, July 8, 2010

This is just a very quick post, showing code I found I needed to deal with the way my app was launched on iOS4. In a nutshell I was finding that iOS4 would launch my app upside down (UIInterfaceOrientationLandscapeLeft) when the iPhone was being held in the UIInterfaceOrientationLandscapeRight orientation. I then wasn’t ever getting notified that the orientation was actually UIInterfaceOrientationLandscapeRight. I’m not sure if this is a common problem, or if it is unique to something strange I am doing, but I am seeing correct behavior on all 3.x iOSs prior to 4.0.

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;

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

Color profiles and pngcrush

Written by David Frampton @ 10:13 pm, May 23, 2010

I’ve wanted to do this blog post for some time, but have been a bit hesitant, because it’s a complicated subject, and I’m not 100% certain on all the details. But I have had enough frustration and learned enough from it that I should be able to pass on some useful knowledge. If I do make a mistake, please point it out in the comments.

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.

« Newer PostsOlder Posts »