The App Store is Still a Viable Business Model

A lot of information has been released recently that suggests it’s not worth a developers time to make a game for the iOS App Store anymore. Reports that 30% of App Store apps make less than $1000, have scared away many of those gold rushers that had been filling the market for the last few years. Unfortunately, the average iOS developer publishes 4.2 apps. As well, more statistics that suggest that 20% of the apps make 97% of the revenue on the app store. There have been 18 billion downloads or 500,000 apps for a total of $3 billion dollars paid.

If I’ve lost you, then here is the information the above statistics suggest:
- 20% of app developers have made an average of $125,000
- 80% of app developers have made an average of $950

As an indie game developer, if our games can pull in an average of $125K, we’re doing alright. We’ll be able to feed our families, enjoy our life and have more opportunities to create the next game that could be our hit. If you have what it takes to create a game better than 80% of the rest of the games on the App Store, then you might have a business case to stay in the App Store for a little longer to hopefully find your hit.

Sources:
30% of apps make less than $1000 – http://adtmag.com/articles/2011/06/17/mobile-apps-earn-less.aspx

20% of app developers make 97% of the revenue

http://www.gameinformer.com/b/news/archive/2011/09/30/survey-20-percent-of-ios-devs-earn-97-percent-of-app-store-revenue.aspx

Apple has paid $3 billion to developers

http://www.engadget.com/2011/10/04/apples-lets-talk-iphone-keynote-liveblog/

The average Android publisher has brought 6.13 apps to the market, while their iOS counterparts only published 4.21 apps each.

http://creatingapps.telekomaustria.com/500000-apps-android-developers-more-active-than-ios-developers-but-less-strictly-wellbehaved.html

500,000 Apps, 18,000,000,000 App Store Downloads (http://www.tuaw.com/2011/10/04/more-than-18-billion-apps-downloaded-from-app-store/)

On Improving the Quality of iPhone Games and its Marketplace

Earlier this week I was able to attend the inexchange 2010 conference. For those who aren’t familiar with it, its main focus is on interactive and cross media productions in Canada. More specifically, the province of Ontario.

With the changes occuring within the gaming industry in the last while, this year featured much talk about mobile gaming and the future of the industry. During a panel titled “Game Changers”, discussing the changes in the way players may consume game content, Denis Dyack (of Silicon Knights) pointed out the scary fact that the average iPhone game makes only $700 in revenue.

The one discussion I left the conference hungry to discuss is how we can leverage the mobile platform to create great games, now that the hype is dying down. And hopefully, in the process, see some better ROI for the talented content producers.

Although the average game in the AppStore makes $700, I doubt the average great game on the iPhone makes that little profit. There are many factors that go into sales including the problem of visibility in the overcrowded AppStore. But, in the end we must create compelling game experiences if we want to sell our games. The poor quality of games in the AppStore is what is bringing down the marketplace. Even the games released by the big studios, are simply big wastes of money, trying to replicate console style successes on a movie device.

So, here are two ideas on how we can make better mobile games, and improve the mobile gaming marketplace:

1) A Proposal for a new type of mobile game

Mobile gaming is still waiting for it’s Space Invaders or Super Mario Bros or Doom (do I need to go on?). We are still waiting for that game that shows us that a compelling experience can be had on a mobile device. Although I love it, it is not Angry Birds, nor do I think it’s Epics Citadel. Or maybe it’s already out there, just hidden in the AppStore somewhere… I doubt it, but maybe we need an AppStore Palaeontologist, who digs through the masses of bad games to find the one gem we all missed.

Let’s stop expecting the same formula that has been used on the console games to be applicable in the new mobile marketplace. Let’s spend time analyzing and researching the game design that works on mobile before we spend time analyzing our poor ROIs. Design, prototype, test, design, prototype, test… it’s really not a foreign concept to us. But, by the look of the games in the AppStore, this is not being followed well.

2) A Proposal for a New AppStore

Although Apple has been getting some very bad attention because of their “strict” developer agreement and “closed” development platform. As a developer, I can tell you that their review process is quite lenient. If your app doesn’t contain anything deemed offensive by Apple or make the iPhone explode (literal read: crash) you can pretty much count on it being accepted into the store.

So, every Joey Developer (including me), who wants to put their game into the AppStore, can. This has been great for innovation. We’ve seen some incredible art emerging from some talented individuals who would have a hard time getting their work on the PSN or WiiWare. Passage is one that was mentioned at in10 (Its creator, Jason Rohrer is now working on a Nintendo DS game for Majesco).

But, we have to admit that this has also opened the floodgates to allow a plethora of (sorry to say) crap into the store. As a producer and consumer, I find it far too frustrating to sift through all this poo-poo while trying to find that gem.

This breed of crappy games would never make it to the PSN or Xbox Marketplace or WiiWare, or even Steam. Why? Because they have a more strict selection and review process than Apple. Could that be? Apple? The new chosen army of the Devil has a more lenient review process than our beloved Nintendo? But they don’t run Flash?

To me, the answer is simple. Create a new Apple game store that requires a game to be (*gasp*) entertaining if it is going to be available in it. If apple is serious in turning the iOS platform into the next mobile game system they need to separate the crap from the gems for us.  A place where specially selected content producers can showcase their products – ones that meet a higher standard of value.

Let’s buy some land down the street from the flea market and make a Shopping Mall!!

Next Steps

Smartphones and tablets are here, and they will be in our future for a long time. As game developers, we need to ensure that we are delivering on our promise to the world to create engaging, exciting and fun game experiences to the players, no matter what platform they are on, no matter how much innovation is necessary to do so.

The industry needs to be more active in leading the future of the marketplace by working together with these new platform providers to deliver entertaining content to this market.

I’m hoping this article will act as my first contribution to this great cause.

If you have a great game in the AppStore that is hidden in crap, I’d like to hear from you.

Simple accelerometer movement with Cocos2d and Chipmunk

We all need a quick and easy way to move a body based on accelerometer movement. This method allows quick execution and testing. In this post I’ll be detailing how to move a cpBody on screen using the accelerometer.

I’m assuming you’ll make all the connections between your sprite and the cpBody and understand how to set up a cocos2D and Chipmunk project. If you need help with this check out Alexandre Gomes’ excellent tutorial “An introduction to game physics with Chipmunk“. Much of the code below is not directly related to the acceleration, while I am not including all the methods required for the class, I like to provide complete methods, so you can see how things will interact.

In this case we’ll just move a body based on the x (left and right) movement.

1) enable accelerometer in the init method and initialize the acceleration at 0.

-(id) init
{
    if( (self=[super init]) ) {
        self.isAccelerometerEnabled = YES;
        accellX = 0; // float defined in header
 
        // setup chipmunk
        [self setupChipmunk];
 
        // setup your cpShapes, cpBodies and CCSprites here
        // I'll be using spriteBody to these
    }
}

2) Setup Chipmunk

- (void) setupChipmunk
{
    // start chipmunk
    cpInitChipmunk();
 
    // create space object
    space = cpSpaceNew();
 
    // define gravity vector - zero gravity here - change the vector to apply gravity
    space->gravity = cpv(0, -0);
 
    // Add some elastic effects to the simulation
    space->elasticIterations = 20;
 
    // Create an update schedule
    [self schedule:@selector(step:)];
}

3) Update the current acceleration when an update is received

- (void) accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration
{
    // set current acceleration to 10x the current acceleration of the device.
    // change 10 to any number that works for your implementation speed.
    accellX = acceleration.x * 10;
}

4) The step function we referred to in #2. This move the cpBody based on the current acceleration as defined in #3. Remember, right now this is x only, I’ll let you make the connections to get y working.

-(void) step: (ccTime) dt
{
    cpSpaceStep(space, dt);
 
    // get new x position based on acceleration
    // spriteBody is a cpBody defined in the header file and setup with a shape and sprite in the init
    float newX = spriteBody->p.x + accellX;
 
    // move the sprite body to the new x position
    spriteBody->p = cpv(newX, spriteBody->p.y);
 
    // call our function for each shape
    cpSpaceHashEach(space->activeShapes, &updateShape, nil);
}

5) Just for completion’s sake, I’ll include the method to update the shapes called in the last line of the previous code. None of this effects the acceleration at all… simply moves the sprite to the position of the shape.

void updateShape(void *ptr, void* unused)
{
    cpShape *shape = (cpShape *)ptr; // the shape
    CCSprite *sprite = shape->data; // the sprite
 
    // set the sprite position to the shapes body position
    [sprite setPosition: shape->body->p];
}

And that’s it, your body should be moving based on the accelerometer input.

Xcode – Base SDK Missing

Just upgraded to iOS SDK 4 GM release along with Xcode 3.2, so I can test some of my projects on my device.

When I opened up the first old project (built for OS 3.2 on XCode 3.1), I received a “Base SDK Missing” error in the Device | Debug drop down menu.

Clicking the info icon in the tool bar of the open project allows you to select the “Base SDK for All Configurations” drop down. Select your new SDK and voila! You can also change the “Project Format” here as well, might be a good idea to select your current Xcode version.

Pretty simple problem and solution, but it seems like developers (like me) are experiencing this every day.

Update 1: Tom has pointed out in the comments, that you can retain compatibility with 3.0 devices if you set the base SDK as 4.0, but set the deployment target as 3.0. Thanks Tom!