The Economics of the App Store part 1

So, not a lot of people have been checking out this blog and I've been wanting to write on the economics of the App store for quite some time so I'm writing this with the expectation that nobody will read it so I won't quote a bunch of sources and all that jazz. There're a lot of misconceptions of how the economics of the App store works and I'd like to spend a bunch of lines diving deep into what makes the App store unique and different as a marketplace so that at least I can feel like I "get" it. I'm going to lay out a lot of economic principles below and in subsequent posts so bear with me. To give you an idea of what's to come, it is often said that there is a "race to the bottom" going on in the App store. I don't believe this is the case and I'll lay out why, along with a whole slew of other things, below.

If you were to round up a bunch of economists and ask them what the most important principle in economics is, they would unanimously shout the law of supply and demand. The law of supply and demand simply put is that when supply goes up, price goes down, and when demand goes up, price goes up. In an ideal market, the price of a good is placed where these two lines meet and everything is great. The App store (digital distribution in general) is the first thing I can think of that necessitates an update to the supply and demand model. Why? Because digital distribution effectively gives us infinite supply. Once a product is on the market it costs $0 to maintain that product on the market.* Think of it this way, if someone out there had discovered a way to grow just one carrot and then could infinitely duplicate that carrot for free, how much would you be willing to spend on carrots?

If we forget about demand for a second and ask ourselves what goes into the price of a good, there are many factors. One of those factors is scarcity. Lobsters cost more in Kansas than in Maine because there's just not that many lobsters in Kansas. With infinite supply there is no scarcity in the App store. Another is production cost, as there is no production cost for an individual download of an app, this also is not a consideration in price.* There is the initial cost of development to consider, but if/when that is recouped you're again left with no real supply-side rationale for price.

Now let's look at demand. There are a ton of free apps on the App store. The demand for anything that's free should be infinite.** So we have a lot of apps that have infinite supply and infinite demand, why would anyone ever bother with actually paying for an app. Well in most markets that have huge supply and huge demand, price can often act as a signal for quality (quality is of course subjective as the following example will show). Think of bottled water. In many parts of the US, you have three options for water. You can schlep down to the local waterway with your cup, you can pour a glass from your tap for a nominal fee, or you can spend $1.50 on 16oz. of bottled water. Between the first two options, you'd be hard up to find anyone drinking from the lake, but between the last two you have a more interesting choice. Many people who choose bottled water over tap water do so because of a perception that the bottled water is of higher quality than the tap (another major factor would be a perception of convenience with bottled water). Is the water of higher quality? Well maybe it is and maybe it isn't, most consumers aren't going to break out the lab kit in order to test it. They instead rely on the price to signal that it is of higher quality. Markets have worked like this ever since there have been markets, with price signaling something about a product.

But does price signal anything of note in the App store? At first blush it may seem to indicate quality, but I would argue that quality games with higher prices are able to charge more because of brand recognition rather than price signaling. Cave can charge $12 for Deathsmiles because they're Cave, not because $12 is a particularly meaningful price indicating quality. If you download the next game that is released at $0.99, it's pretty likely it won't be as good as a number of free games available. Now as a consumer, once price loses its ability to signal quality, what are you left with? Well you have brand recognition, and you have word of mouth. In part two I'm going to talk a little bit about word of mouth as I focus more on the consumer. For now let's look at brand recognition in the App store as we continue to focus on supply.

Squeenix is about as powerful a brand name as you can get in gaming. They can and do ask for premium prices on many of their games. Now Squeenix makes quality games as well so you're not really taking a chance when you purchase something from them. You know what kind of game you're going to get and if you're a fan it's usually going to be worth the price. So let's compare some prices: Crystal Defenders: $8 & Field Runners: $3; Final Fantasy: $9 & Ash $5. I bring these examples up because they're two games in the same genres of, in my opinion, similar quality, and the non-Squeenix games are from lesser known developers. Is the price difference here indicating quality, or is it a premium paid for brand recognition? I would argue that it is a premium. If it is a premium then what do the price points of Field Runners and Ash indicate versus 99 cent offerings in their respective genres? The answer is nothing. To the average consumer on the App store, price does not convey any meaningful information, and since this is the case the average consumer is far less likely to "risk" spending a premium amount on a game that ostensibly has cheaper alternatives. In the case of FR and Ash, both games were good enough to have some consumers eventually understand the value of their price, but the price itself did not indicate that value.

So as an unknown developer you really only have three options when it comes to pricing. You make a middling quality*** game and sell it for 99 cents and hope that it competes with the slew of other Apps of middling quality that sell for 99 cents. This is viable especially if your game has a distinguishing hook. You make a high quality game and sell it for 99 cents with the hope that its high quality will increase your brand recognition so that subsequent games can be released for a higher price. This is viable and arguably the best strategy if you plan on long term success for a new development studio, this is also why a lot of games go on sale when a new game comes out from a company. The third option is to make a high quality game and sell it at a premium price, and hope that word of mouth regarding its quality can carry it. This is somewhat viable, but definitely the riskiest choice of all. It also requires that there is a large enough audience for your game that you'll be able to reach without getting lost in the clutter of the App store. I'll talk about that more in the next part as well.

If we assume an even split between these three options we have a reason for why there are such a deluge of 99 cent games, and such a disparity in quality. In actuality, I would guess that the first option is far and away the most popular, and this undermines price as a signal even further by flooding the market with middling quality games that cost a buck. The funny thing is that what prevents other markets from being similarly flooded are the exact things that the App store has removed namely, barrier to entry (anybody with $100 and a bunch of time can make an App) and fixed cost upkeep (it costs nothing to maintain an App on the App store). So is there any hope or are we doomed to some continuing spiral of 99 cent shovel ware that eventually consumes all of the quality on the App store and dooms it as a marketplace. Well I think there is hope, but it comes outside of standard economic models. Tune in next time as I start to get into that hope by taking a look at consumers.

* One could argue that there is a cost of at least $99/year for the developer's license and additional ongoing upkeep should one continually update their App, but these costs are so low that we can consider them for all intents and purposes as free.

** Obviously demand and supply can never be truly infinite. There is a finite amount of bits in the world and not everyone is going to want every free App. The point is more that supply and demand lose meaning when there's no cost to supply and no price to pay for a good demanded. For this reason free Apps stretch the capabilities of the standard supply and demand model. There are things outside of price that give nominally free Apps a price such as advertising, but for the purposes of modeling the App store, I've chosen to ignore that consideration.

*** By middling quality, I don't necessarily mean bad, I mean projects that aren't as good as they possibly could be. If your a developer who has a viable 99 cent game that you could add additional polish to for some price why would you if you're still going to charge 99 cents for it? There are plenty of reasons to add polish, but there are plenty of reasons not to hence both ways being viable options.

Lots of work being done

Wow, the past couple of days have been super busy. The game is coming along nicely, and I feel pretty good about getting to an alpha phase around the end of August. We have some new art that looks really sweet, and the story is coming along nicely. I updated the balance of the battle system a little bit and that seems to be working out well. I like where we are in the development phase because it's all coming together pretty quickly after working super hard and not having much to actually show for it. Today I added two cut scenes, a new map, a character, introduced the runes, three new enemies, and two new map animations that help with moving around. Not bad for one day of programming.

I really hope to start sharing some more artwork and info about the game. I don't want to give away too much of the mechanics until we're closer to release, but seeing some sweet art always helps get everyone excited. I will say that all of the mechanics are designed with the iPhone in mind. The controls are all specific to the device, and I think they're really intuitive. Hopefully others will find that to be the case as well.

Anyways, I'm kind of on a roll so I'm going to head back to coding. I don't think anyone's really reading just yet, but I'm gonna keep posting just in case.

The Engine

The engine for the game is pretty much complete. It still needs polish here and there, but I'm feeling pretty good about it. The AI is particularly awesome, but a whole lot of other things are streamlined to make building the game easy. That's the nice thing about building an engine from scratch versus using something already out there, you get to make it do exactly what you want it to do as you build it.

The engine is based on the engine built in Learning iOS Game Programming by Michael Daley. If you're at all interested in game development, but aren't too familiar with iOS and Objective C, I highly recommend this book and his site http://www.71squared.com/, which has some great tutorials.

The number one thing for me with the engine, as it affects the player, is that it be really fast. I've tried my best to keep everything really simple and small. This should lead to a minimum of waiting for the player. So far in everything that I've done, I've noticed no load time for anything and a drop in frame rate only once or twice. Both times, it was easy to make a quick tweak to improve performance. Hopefully this will continue all through development to lead to no noticeable loading for the player.

Now it's time to start putting everything together. It seems sort of like what directing a movie is like. Characters move with stage directions, and dialogue has to flow. There're fades in and out and special effects. It's really exciting. Building the engine was exciting too, but for as awesome as I think it is, there's really not a whole lot to actually see. Now that we're building the story, the work is more visible. To use an analogy, the engine was a lot like making drywall from scratch, most people would just buy it and never try and learn how its made or how it works. But now that it's done, I can start using it to build a house. 

AI!

As a programmer, the things I get most excited about are usually the things that are the least visible to the player. That said, the AI system is up and running and I think it's really awesome! The framework of the code lets me add AI combinations for specific enemies with just a small array of integers. This lets the decision-making happen really fast, and makes it really fast to add different logics to an enemy. The visibility of the system to the player shouldn't be anything other than having enemies behave the way that players have come to expect (hopefully a little smarter than in some other games). For me, getting this done this quickly is a small triumph.

Under the hood the system works similar to other AI systems I'm sure. It first assesses the current state of the decider, then it uses preset conditions that need to be passed to decide what to do. All of the different conditions currently allow for over 800,000 different combinations to ensure that enemies are always doing something smart. Adding a combination to an enemy takes a single line of code and adding a new condition would only take about ten lines of code. All in all I think it's a really positive start to creating a deep and robust battle experience.

Skillz!

Phew! Just finished up with the majority of the player skills. There will be over 200 once everything is done. Next up is going to be working on the AI for enemies you face in battle. I want to set up a ProLog style infrastructure. This would do three things: 1) It would allow all enemies to draw from a single set of rules. This would help improve performance by limiting the amount of objects every enemy needs. 2) The single set would allow for easy creation of new enemies. 3) I think it'd be really cool.

I've gone over to Touch Arcade and asked for people's input on what they would like to see from enemies in an RPG. What I would like to do is take people's suggestions, interpret them into prolog-esque rules and then build the enemy AI to interpret those rules. Hopefully this will make the battles feel much more dynamic than the repetitive attack spams that a lot of party-based RPGs are (still love 'em though).

As I continue to build the battle system and reading people's thoughts on random encounters and grinding, I become more and more convinced that the way to go will be to have fewer battles that are longer and more engaging. To be honest, I'm not sure why more games haven't gone this route. Having longer and more engaging battles just ups the importance of good AI.

After reading tons of forums and playing researching as many iPhone RPGs as possible, I think one of our main goals has to be to eliminate grinding from the balance to TEoR as much as possible. I'm not sure how simple that will be, but I think having good AI is a good place to start, since then you're not dependent on a player's party simply being able to survive an attack every five seconds.

I look to have more on the AI and battle in general towards the end of the week.

  -Lazer