Safe from the Losing Fight

The last time I spoke of my upcoming iPhone game, I was soliciting recommendations for graphics and sound designers. Since then I’ve hired a sound designer and had the sounds completed. I had originally intended to write about my experiences with sound and graphics designers in one article, but I actually just hired a graphics designer, so my experiences with him will have to wait until next time.

This is a description of my experiences with finding and hiring a sound designer to create royalty free, custom sound effects for my game. My experience with hiring and working with a sound designer was quite pleasant. The entire process was completed exactly one week after I first started contacting designers.

Preparation

Before I started contacting designers I sat down to figure out what exactly I needed from the sound designer, and what information he or she would probably need from me. I’ve never worked with sound designers before, so I had to make some educated guesses. In the end, my guesses seemed to be at least adequate. I wrote down everything I thought the designer would need in a specification document.

The specification document I create was pretty simple; it had two sections: an introduction and a description of the sounds. In the introduction I gave a brief overview of the game, how the sounds were going to be used, the “theme” I wanted, and a total count of sounds to be created. I managed to fit this into five sentences, on the assumption that the designer wanted to know about the sounds, and not my life story, fascinating as it is.

For each of the sounds, I created a description for it. I gave each sound a short, unique name so they were easy to refer to. I then described what the sound was, for real world sounds (e.g. card placed on a table), or what I wanted it to sound like, for abstract sounds (e.g. a sharp, clicking sound). I also tried to give the context in which the sound will be played (e.g. when a button is pushed). Finally, I stated the length I wanted the sound to be. Most of mine were only one or two seconds in duration.

Selecting the contestants

With the sound specs in hand, I was ready to start contacting designers. The only problem was that I didn’t know any, nor had I heard of anyone recommending any. Being put in such a desperate situation, I did what any engineer would do — I googled for some, and blogged about it. In the end, I contacted three different sound designers:

• SoundRangers
• Sound for Games Interactive
• IndieSFX

I originally found about six companies that I thought could possibly do the work, but I whittled down the choices to these by using the following criteria:

1. Did it look like the designer had experience creating sound effects for games? Since that was what I wanted, it made sense to see if their portfolio reflected that.
2. Could I navigate the designer’s site well enough to actually find a way to contact them? I didn’t originally intend for this be criteria, but it ended up being one. Advice for sound designers: hire a good web designer.

For each of the three designers I selected, I sent out an introductory email. In the email, I briefly described the project and asked if they were available and interested. I mentioned that I had a spec and would like a rough estimate before work began. In retrospect, I should have probably attached the sound specification to the introductory email, because that was the first thing everyone who was interested ask for.

Of the three designers I contacted, SoundRangers and IndieSFX replied to me within 24 hours. Sound for Games never got back to me. SoundRangers and IndieSFX charge by the sound, and offer both stock and custom sounds. For stock sounds, prices range from around $1 to $5 per sound, although IndieSFX only sells them in packs. For custom sounds, prices range from $10 to $40 per sound. None of the stock sounds were quite what I wanted, so I elected to go for all custom sounds.

Between SoundRangers and IndieSFX, I chose IndieSFX. Both seemed to be comparable in quality, but IndieSFX had better prices.

Creating the sounds

Once I had signed a contract for IndieSFX to create the sounds, I began working with Mark to do just that. Based on my specification, Mark created a first draft of the sounds by the next day. Some sounds had multiple variations for me to pick from, while others I was just given one choice to refine.

Mark and I went through about seven or eight different variations of the sounds before we settled on something. In general, I got a new revision of the sounds every day, which was highly motivating.

Along the way I learned a couple of things about sound. First, there’s the concept of “wet” versus “dry” sounds. Wet sounds have more echo and reverb and, at least in my case, sounded better. Dry sounds are shorter, which can be good if you have a tight time interval in which to play a sound. Second, I found out that playing the same sound several times in a row makes it sound like a typewriter or machine gun. Fortunately Mark knew how to fix this: create several variations of the sound and randomly pick a different one to play each time.

That leads me to something I learned about the process: always try out the sounds in the game. Sounds that sound great by themselves may not sound good in context, or when they’re interacting with other sounds. I unfortunately approved a couple of sounds that didn’t actually work well in the game. Fortunately Mark was nice and let me make changes even after I initially said they were OK.

The other thing I learned was that I needed to be as specific as possible when I wanted changes. It was easy to verbalize emotional reactions to sounds (I like this, I don’t like this, etc), but hard to spell out specifically how I wanted something changed, so Mark could actually do it. It turns out sound designers aren’t mind readers. Who knew?

After about a week of revisions, I had sound effects I was happy with. I paid IndieSFX, added their name to the about box, and checked the sounds into source control.

Using the sounds

During the creating process, I was taking the sounds Mark was sending to me and integrating them into my iPhone game. Since Mark was sending me uncompressed WAV files, I had to convert them before I could use them. Fortunately, Apple provides a nifty little command line tool to do just that: afconvert.

At first I was keeping the sounds uncompressed, for quality reasons, so I used afconvert like this:

/usr/bin/afconvert -f caff -d LEI16 <input WAV file> <output CAF file>

Unfortunately, high quality, uncompressed sounds are huge and this app is going to be distributed over the internet. So I switched to a compressed format, using this command line:

/usr/bin/afconvert -f caff -d 'ima4' <input WAV file> <output CAF file>

This gave me a 50% savings in size, with no discernible difference in quality. I chose these formats because I needed the sounds to be able to play simultaneously, and these are the two formats that the documentation say will allow that.

Lifting the veil

Hopefully this article has made the process of working with a sound designer more transparent. When I started this process, I had no idea what to expect — how much it would cost or how the process even worked. But I was quite pleasantly surprised. Getting custom sound effects created for an indie game is quite reasonable, both in time and money.

As I see it, the App Store has three main problems. One of them is a customer’s concern, and the other two are developer’s:

1. Customers hate paying for crappy applications.
2. Developers have a hard time getting exposure for their apps.
3. Developers want high enough prices to support development of their applications.

Identifying these as problems isn’t exactly a revelation, but I want to state them clearly. That way, when I examine potential solutions, I can see how well a given solution solves them.

Customers care about revenue, right?

A common solution that has been bandied about is the idea of changing the application ranking algorithm. Right now, applications are sorted based on how many people have bought it, which strongly favors the $0.99 applications. The “fix” is to rank applications by revenue. The logic is that by incorporating the price of an application into the ranking algorithm, it won’t be so biased towards $0.99 applications, and higher priced applications can flourish.

From what I’ve heard of this argument, it is attempting to fix both developer problems: non-$0.99 applications would get more exposure and applications can have higher price tags.

Unfortunately, this solutions fails the test for a number of reasons:

1. Sorting by revenue heavily favors large companies who produce blockbuster applications, such as Sega with Super Monkey Ball. Since they are well known, they can charge more and still sell a lot. This solution effectively squeezes out any small companies, or anyone with a niche application.

2. This solution only helps the top 100 revenue earners. Everybody else is still screwed. A solution that only fixes the problem for a small fraction of the developers isn’t really a solution.

3. Any ranking algorithm, no matter how complex, can be gamed. If an app is in the top 100, it makes an enormous amount of sales. That’s a lot of incentive to game the system.

4. The solution not only doesn’t address the customer’s concerns, it serves to confuse the customer more. What customer asks how much revenue a product generates, when deciding on a product of any kind? It is possible they might ask what the best selling one is, with the thought that it’s popular because it’s good or at least safe.

   Since this solution hurts the user experience, it’s pretty much DOA. Apple isn’t going to change the App Store to make it more difficult to use, even if it does help a few developers.

I think the proponents of this solution want it because it sounds like a quick fix that will at least shake up the top 100, and maybe give them a chance to squeeze into it. While I can sympathize with the desire to get more exposure, this solution doesn’t actually fix the problem and only serves to make things worse for users. But before I talk about another solution, I want to talk about the problem of getting exposure for an application.

Fixing the wrong problem

So the deal is the App Store can’t actually fix all three of the problems I mentioned. Specifically, it can’t fix developers not getting enough exposure for their applications. I know that Apple said they’d take care of all the marketing of iPhone applications when the store launched, but it’s time to face the fact that they can’t and won’t. Apple won’t feature all apps on the front page, and even if they tried, they could only do each one for a short amount of time. It’s simply not enough to bring in a sustainable stream of customers.

This has parallels in the real world. A store, such as Target, may advertise products it sells, but only certain ones and only for a certain amount of time. The manufacturer also must do some advertising in order for people to become aware of the product and actually buy it. This is true for all products, including the $0.99 a pack chewing gum that’s next to the checkout lane (the real world’s version of the top 100 apps).

Developers are too wrapped up in getting on the top 100 as a means for getting exposure. Everybody wants their product next to the check out lane, but the reality is only a few cheap, impulse buy type of products will ever make it there. All the other products are going to be out in the store aisles, where customers will have to be looking for them to find them.

The bottom line is that finding customers for your application isn’t a technical problem, and a technical solution isn’t going to fix it. It is a marketing problem, and it requires marketing to fix it. Since developers can’t count on Apple doing the marketing, they need to do it themselves. I know that’s scary news to those of us who have only ever been engineers, but we need to acknowledge it and work through it.

Taking a test drive

Now that we’ve learned that getting exposure for an application isn’t a problem the App Store can fix, I want to focus on the remaining problems it can fix. Another solution that has been proposed is the now ubiquitous (on the desktop) try-before-you-buy model. The idea is simple: a potential customer can download an application for free and use it for a set amount of time, say 30 days. At the end of the 30 days, the potential customer can either buy it or it’s deleted from their phone.

This solution, while more complicated than the ranking solution, actually solves the problems:

1. Because the customer gets to try out the application before buying it, they don’t have to worry about paying for a crummy application that doesn’t solve their problem.

2. Since customers can try out more expensive apps without risk, they are more likely to buy the more expensive application, since they can figure out if it’s worth the price or not. This allows more expensive apps to survive in the App Store.

As an added bonus, the top 100 becomes more accurate because only the apps that users actually think are worth something increase in rank, instead of apps that had the best screenshots or descriptions.

The thing to remember is that the App Store is still young and still maturing. While it is different from other markets, it’s not that different from the desktop market or the other mobile markets. People still want to try out applications before they buy them, and developers still need market their products if they want someone other than their mother to know about them.

I’m always told to start a speech with a good story, so I assume you’re supposed to start a blog entry with a bad story.

The Parable of Little Timmy

Little Timmy was a developer at BigCoSoft, but he dreamed of working for himself one day with a product of his very own. When the iPhone SDK came out, he set aside all his free time and slaved over a new iPhone application for months.

When it came to pricing his software, he decided to sell it for the lowest possible price, $0.99, because that’s what everyone else was doing and besides he’d make it all up in volume, whatever that meant. Plus, he already had 12 year old boys yelling at him because the software wasn’t free, and he’d hate to upset anyone.

Unfortunately Little Timmy couldn’t live on $4,000 a year, so he died. BigCoSoft cremated his body in their furnace so they could save $14.67 on their heating bill.

The End.

I realize that some of my readers are engineers, and prefer cold hard facts. So for you my friend, some math problems:

Question 1:	Assume Little Timmy could live off of $50,000/year, before taxes (Note: this means you have to assume Timmy doesn’t live in California, New York, or any big city, but in a farmer’s wheat field in some desolate corner of Iowa.) How many copies of his product would Little Timmy need to sell to eat?
Answer:	Since Little Timmy only priced his software at $0.99 and Apple takes 30%, Timmy only makes about $0.70 per copy. He would need to sell 71,428 copies a year or 196 copies a day.

Question 2:	How many copies a day should Timmy expect to sell, after the initial launch?
Answer:	16

Question 3:	Isn’t Little Timmy just about the biggest moron you’ve ever heard of?
Answer:	haha! Yes!

So now that we’ve finished mocking poor Timmy’s corpse, we should talk about how to price your application before you become firewood.

The Problem

The problem that you’re likely to have, like most developers, is setting a price that you can live on. The temptation will be to price your app too low, such that developing the application isn’t sustainable. You might have the best of intentions, but in the end you’ll cause the premature death of your business before it even gets a chance.

So why might you be tempted to price your iPhone application so low?

Reason #1: Initial store prices

A lot of people were looking at the apps announced at WWDC to see what they would be priced at. In particular Sega’s Super Monkey Ball, priced at $9.99, seemed to receive the most attention. Developers releasing around the App Store launch seemed to use Super Monkey Ball as a barometer as to how to price their app. Unfortunately, most of them seemed to think they needed to beat Sega’s price.

Here’s the thing: engaging Sega in a price war is a sure fire loss. They’re a bigger company with deep pockets and will always be able to undercut you in price. They don’t need make much, if any, profit on their iPhone game, since they have a lot of other products. You, on the other hand, need to make a profit on your iPhone app, and a big enough one to live off of.

Reason #2: Customer expectations

Sega’s initial pricing, and the subsequent following suit of just about everyone else, set customer expectations for iPhone app prices. Developers entering the market in the following months felt compelled to follow the example of the first developers. These feelings were only reinforced by just about every “customer survey” done by TUAW and other bloggers, in which potential “customers” said they wouldn’t ever pay more than $5 for an iPhone application, although they really didn’t understand why those greedy developers felt they needed to charge anything. After all, they could make it up volume.

Unfortunately the blame for setting customer expectations falls squarely on developers. Developers get to set the price, and thus the expectations. By setting the price expectations so low, you are lying to your customers. You are saying “I can sustain development of this app for this price,” when in fact, you can’t. It’s dishonest, and it will kill your business.

Reason #3: Gaming the system

By far the biggest reason why developers price their apps so low is to game the App Store. Applications are sorted by how many copies they have sold. It doesn’t take a rocket scientist to figure out that the lower the price, the more copies an app will sell. The top 100 applications sell tons of copies, while applications outside that top 100 seem to wither away unnoticed. So in order to get more exposure, developers price their applications as low as they can.

The problem is that this scheme only supports 100 applications. Everyone else is hosed. Unless you can get and stay in the top 100, then lowering your price was for nothing.

It is likely that Apple will fix this hole. They want to make money too. For a $0.99 app, Apple is only making $0.30 per copy, which has to cover bandwidth, transaction fees, and advertising. I’m not suggesting Apple isn’t making money off $0.99 apps, but I am saying they’d probably prefer to be selling $9.99 apps.

Reason #4: Short term vision

The App Store is quite young and with all the hype and exposure a few of the first developers struck it rich. This isn’t unexpected for some of the pioneers, but the problem has became that many developers enter the iPhone app market thinking that they too can become fabulously wealthy, just as soon as they release their flashlight app that also doubles as tip calculator.

The problem here is that developers become focused on making money now, instead of nurturing and building up a loyal customer base over the long term. They price their app low so they sell a lot of copies now, but don’t consider how they’re going to make money next year. What is the upgrade price that you charge for a $0.99 app? If it’s $0.99 then you’re not building customer loyalty because that’s not a discount. If it’s free, then you’re totally screwed, because you’re not making any money.

The Solution: $9.99 is the new $0.99

The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99, and so on. With a $9.99 app, you’d make $7 per copy and at 16 copies per day, you’d make about $40,000/year. That’s not a great income, but that could potentially support one iPhone product being developed in some Iowan’s wheat field.

Without question there will be customer backlash when developers increase their prices. Nobody likes paying more for something. However, the sooner the righting of the ship happens, the better. Customers need to know that most applications can’t be built and supported for such a small amount of money.

On the other side of the equation, developers aren’t going to be eager to be the first to raise their prices. So many are convinced that they won’t sell anything if they raise their prices. Here are some of the potential concerns:

Myth #1: No one will find my app!

This goes back to developers gaming the system. If a developer raises their price, they will sell fewer copies and drop off the top 100, which means no potential customers will find them. There are two possible solutions to this problem.

The first is Apple could fix it so applications that are not on the top 100 are easier to find. It may take a while for Apple to implement this, but eventually Apple will because it’s in their best interest. When this happens it won’t matter what the price of the app is, people will be able to find it.

The second possible solution is to do advertising for the application. This will take some trail and error to figure out where to buy ads at or which adwords to buy, but it can definitely be made to work. Advertising is hard for $0.99 applications, because if you spend more than $0.70 per conversion, then you’ve lost money. In other words, if you charge more you can make sure more people see your app.

Myth #2: But those other people sell it for less!

Competing with another application solely on price is a sure fire way to go out of business. Your product should have a selling point other than the price, whether it be more features, better usability, a unique approach to the problem or all of the above.

There will always be students and hobbyists in the market who can sell a competing product for way less than you. They don’t need to make a living off the app, so they’re not trying to. This happens all the time in the Mac market. If you charge enough for your app that you can make living off it, then you can spend all your time improving it. With that extra time you should be able to make a superior product to your lower priced competitors.

People are willing to pay more for superior products. Unfortunately, with the App Store developers haven’t given them the opportunity to do so.

Myth #3: This is the price the market will bear

Another way to say this is: the price of application is what the market is willing to pay.
I don’t dispute this, but there is another side to this equation.

You also need to consider what the price of building and supporting the application is. If the cost of building the app is greater than what the market is willing to pay, then simply don’t build the app because it will be a failure. Building the application regardless is dishonest to the customer, because you’re in effect selling them what you know will be abandonware.

I also contend that, in general, developers don’t know what the market will bear because no one’s really pushed the price. Everyone is currently in a race to the bottom. The App Store is still in it’s infancy, so no one’s had time to tell if raising prices actually kills the application, or if it just means it takes longer for it to take off.

Myth #4: I can make it up in volume!

I’m astounded at the number of developers who believe that this is true. While it is true that some developers have made a lot of money this way, this isn’t sustainable or practical for most applications. In order to make up for the low price in quantity your product needs to have mass appeal. Furthermore, your potential customers have to be able to find your product, which means you have to be in the top 100 and have Apple feature your product in their advertisements. In other words, you’re betting a lot of this on luck, and the odds are stacked against you. You’d have better odds playing slots at a casino.

Judgement Day

The App Store can’t stay at the status quo. There are three possible outcomes:

1. The App Store becomes a market place solely for hobbyists and students, who can price their wares low because they don’t need to make a living off of them. In this scenario, indie developers aren’t in the market anymore and there is only the occasional BigCoSoft game port.

   Eventually this market would become littered with abandonware as hobbyists and students moved on to other projects that actually pay. The occasional BigCoSoft game would keep the iPhone as a second rate gaming platform.

2. The App Store becomes a market for one off apps and abandonware, where apps don’t progress beyond version 1.0 because there’s no money in it. Apps are simple and cheap to build, and developers rely on the initial sales spike to make all their money.

   The store would become so littered with dead apps that falling off the top 100 would be even more fatal. Eventually the store would die as developers ran out of simple app ideas that would generate a sales spike.

3. Developers begin pricing their products in a way that is sustainable. Developers who price too low eventually die off, unable to develop their products further. In this market, prices go up, which encourages indies and BigCoSoft to build and release many apps and games for the iPhone.

There will be an iPhone app bust. The current prices simply aren’t sustainable. Either developers will crash out of the market when they discover they can’t make a living off their current prices, or the gold rush developers will lose interest and leave when they realize they can’t make a quick buck off the store. The developers left standing will be the ones who set reasonable prices for their applications.

I’m willing to put my money where my mouth is. I currently have an iPhone app in development, and when it comes out, I will price it $9.99 or higher. I’ll let you know how it goes for me.