Thoughts on the iCade (and on using it with Flash games)

I got an ION iCade a few days ago. This post is about my thoughts on the iCade, and also on how to use it with Flash games.


The iCade

So the basic idea with the iCade is that it’s meant to give you physical controls for iPad games. First of all, the physical build quality of the device is fantastic. I’ve heard some people say that it looks small after seeing photos of it, but it’s definitely not small in real life; it’s actually quite big compared to the iPad, and it’s very sturdy. The joystick and the buttons feel solid and substantial, and they’re very responsive. The idea of the iCade may seem like a gimmick or a joke, but the actual execution of it is anything but.

The iCade runs on two AA batteries. It acts like a Bluetooth keyboard, so setting it up is really easy. The only issue is that because the iPad thinks it has a real keyboard attached, it doesn’t show the normal virtual touch keyboard when the iCade is synced, which can be a big pain. This is compounded by the fact that the iCade doesn’t have a power off button (it just turns off after a few minutes of being unused), so you either have to wait for a while or un-sync it just to type text. This is annoying but most of the time it doesn’t really matter, because you’re using it to play games, not type stuff.

Some people have asked if it has speakers: it doesn’t, but the shape of the cabinet amplifies the iPad’s sound a lot, which it really does make it seem louder.

The games

Most iPad games are built for touch controls, not keyboard controls, so there aren’t very many games that support the iCade. Luckily, ION convinced Atari to build iCade support into every game in their Atari’s Greatest Hits iPad app, so for $14.99 you can have 99 retro games to play. I really enjoyed playing through a bunch of classic arcade games on the iCade, it is definitely much more fun than playing them on a touch screen.

If you’re worried you’re gonna get bored of retro games, there are also a few indie devs that have built iCade support into their apps. Compression HD from Little White Bear is a great puzzle game that supports the iCade, and Retro Dreamer just announced that the next Velocispider update will have iCade support. I’m really excited for that one. For a list of other games with iCade support, you can check out the wikipedia page.  The list is pretty short, but I have no doubt it’ll get longer over time.

Implementing iCade support into iOS games

So how do you add iCade support on iOS? Luckily someone made a library that makes it super easy: https://github.com/scarnie/iCade-iOS/ – basically you just add a special view to your main view controller which listens to keyboard events, and that view then sends messages to a delegate when buttons are pushed. There’s really not much more to it. The one big catch is that for some reason Apple won’t let you mention the word “iCade” anywhere. You can’t put “iCade” in your app’s name or description, and you can’t even mention the word iCade *in your app*. That’s crazy.

Ok, but how does the iCade actually work?

Alright, so when I said the iCade acts like a Bluetooth keyboard, that was true, but it’s not quite that simple. Rather than just emulating keys, the iCade actually emulates two keys for each control. Each button fires one key when it’s pressed down, and a different key when it’s released. For example, the red button in the top left fires a Y when pressed, and a T when released. The joystick does the same for each of the 4 directions. The image below is a diagram from the iCade Developer PDF that shows exact which keys are fired by which control.

The magic of Bluetooth

When I realized that the iCade was acting like a normal Bluetooth keyboard, I decided to do some tests; sure enough, it can connect to any device that works with Bluetooth keyboards: an iPhone, iPod Touch, PC, Mac, or even a Playbook (more on that later). Being able to connect it to a device other than an iPad is cool, but it’s not much use if there are no games that support it, so I set out to do what I could to change that.


iCadeManager.as

Flash games are awesome. They’re constantly pushing the envelope, especially when it comes to game design, and they run on pretty much everything except iOS devices. There’s also a huge Flash development community. Before I started doing iOS work, I worked for 5 years as a Flash developer, so the Flash world still holds a warm place in my heart.

I decided to create a library to make it really easy for Flash developers to add iCade support to their games. Even calling it a library is a bit of a stretch, it’s really just a single class, and it only takes a couple lines of code to implement:

        
iCadeManager.start(stage);
iCadeManager.mapControl(Keyboard["SPACE"],"A");
        

The iCadeManager API is super simple, but getting it to work correctly was pretty tricky. The main issue I had to overcome was that the iCade uses 24 different keys to send its messages, but most Flash games already use the keyboard, so there could be tons of conflicts. In Flash, you can’t tell which keyboard a key press comes from, so it’s impossible to tell whether a key press is a real key being pressed or one of the many keys the iCade uses.

My solution was to implement a special “iCade” toggle to turn on and off iCade mode in Flash games. You activate it by holding the top four buttons of the iCade at the same time. When the game is in iCade mode, it swallows up every incoming key event and converts it into the key event you’ve assigned for that iCade input. Check it out in the video below:

The Playbook

My final challenge was getting the iCade working with the Playbook. Unlike the iPad, the Playbook supports Flash in the browser, but unfortunately a huge number of Flash games are still left unplayable because they’re built for use with a keyboard. Luckily, the Flash Player in the Playbook’s browser still gets keyboard events from any synced Bluetooth keyboard, so iCadeManager worked perfectly, which you can see in the video below.

Get the code

All the code for iCadeManager is on Github, and like I said before, it’s literally a single file, so you have no excuse not to use it! https://github.com/MattRix/iCadeManager

If you want to see a demo of it in action, I retrofitted the Flixel EZPlatformer tutorial with iCadeManager: try it out here (remember to hold the top 4 buttons to turn on iCade mode).

Parting thoughts

So to wrap up, the iCade is awesome, and being able to use it with Flash games is pretty sweet. Now all we need is a bunch of Flash devs to add iCade support to their games :)

If you have any questions or issues, please post a comment on this post or send a message @MattRix. I’m tempted to start curating a list of Flash and iPad games that support iCade, so if you think that’d be cool, let me know. Oh, and if you make any games using iCadeManager, I’d love to hear about them. Cheers.

Posted in Flash, iOS Development | 8 Comments

What Just Happened?!

Last weekend I went to TOJam, and it was awesome. In this post I’m going to explain a little bit about what TOJam is, and then I’ll explain what I ended up making there.

TOJam

TOJam is Toronto’s big annual game jam. This year there were over 250 game devs all making crazy games for 3 days straight. Everyone got there on Friday and worked through the weekend. Some people even slept at the building (or didn’t sleep at all!). It was held at the George Brown College Autodesk Building, and there were tons of great computers (dual quad core Mac Pros with 12gb ram) and great monitors (Apple 24″) for everyone to use.

Being at TOJam was a great experience. Everyone had a ton of energy and enthusiasm the whole weekend long. There seemed to be a pretty even mix of artists to coders, so I got to see tons of game art getting made over the course of the weekend. Lots of people were using Unity to make their games, although I think the most popular tech was still Flash.

Bonus

One of the best things about TOJam was how much free food there was. It was completely free to attend, and yet throughout the weekend there was a TON of stuff being given away. There were bagel and pastry breakfasts, a chinese food dinner, a pizza dinner, and an unending supply of candy, chips, and drinks. I was given the opportunity to sponsor something at TOJam, and so I decided to sponsor the candy area, which was named “Trainyard’s Candy Yard”.

Who?!

I didn’t dare do my first game jam ever by myself. I partnered up with Owen Goss and Whitaker Blackall. Together we formed Team RGB (Rix, Goss, Blackall). The plan was for Owen and me to do art and coding, and then Whit, who lives in Chicago, would do all the sounds and music remotely.

What?!

Alright, so what did we actually make? Well, the theme of the jam was “What Just Happened!?” and so we decided to make a gameshow style party game called “What Just Happened?!” (note the punctuation, hah). The idea was that something would happen, and then as a player, you’d have to answer a question about what just happened. The key was that each player would have their own device to play on, and so we could do things like giving different information to each player and making them work together (or not) to answer correctly.

How?!

Neither Owen or I had done much work with HTML5 Canvas stuff, yet we decided that it was the best option. It was kind of a strange choice considering that we’re both professional iOS developers, but it really just made sense. We wanted to make something that anyone could play just by going to a website on their phone, rather than having to download a specific app. Creating it in HTML5 also meant that it would work on all kinds of devices, including iPhones, iPads, Android phones, and even Playbooks.

The golden rule of game jams is that you should use tech you’re very familiar with, but we blatantly disregarded that. Luckily, we found a framework called EaselJS which let us get up-and-running with HTML5 dev pretty quickly. The backend multiplayer code is written with Node.js and Socket.io, which I had used once before when creating Nodetris.

We split up the coding work pretty evenly between us. Owen did the majority of the frontend UI work, and I did most of the backend stuff and minigames, although we definitely switched roles a few times over the weekend (the Goat minigame was 100% Owen, for example). All of the work on art was also split between Owen and me, with some small debates about what style to use for the buttons and the logo, among other things :)

We gave Whit the rough guideline of “create music that sounds like an old game show, something like The Price Is Right or Jeopardy”, and he did an amazing job. Whit also did all the announcer voices and other sound effects as well, all of which were spot-on.

Whit’s The Price Is Right style theme:

Audio MP3

Whit’s Jeopardy style theme:

Audio MP3

The Result

So after 3 days, TOJam ended at 8pm on Sunday night, and we finished right on time. The final game has six different minigame types (clock, robot, numbers, colours, penguins, goats). Each minigame has 3-4 possible questions that could be asked. For example, in the number game, it puts a different number on each person’s screen for a few seconds, and then asks a question like “which number was on the most screens” or “what’s the total of all the numbers that were shown”. Every minigame has tons of random variables, so no two games will ever be the same. Below is a quick quick demo video I made of the game:

Try it out

If you want to try it out right now, just go to WhatJH.com. It’s set up so that you can create a room at whatever subdomain you want. You can play it by yourself by opening up a few browser tabs, although it’s a lot more fun to play with real people. It’s worth noting that if you want the awesome sounds+music, the host should be run in a real browser with Flash, because HTML5 audio support is awful.

So that’s about it! Let me know what you think in a comment or on Twitter. I’ve also included Owen’s demo video of it below, because he does a great job of showing what it looks like to go through a full game.

Posted in Game Design, Other Games | 1 Comment

Introducing EasyIPA

This post is different from the usual struct.ca fare: it’s focused on Flash instead of iOS, and it gets a little technical. Consider yourself warned. :)

Flash to iOS

For the past week I’ve been playing around with the Adobe AIR 2.6 SDK. I used to be a Flash developer and I still really enjoy using AS3, so when Adobe announced a version of AIR with better support for iOS, I had to check it out. It’s pretty impressive, or at least, it’s not awful anymore. You can see an example of it in action here (note that this is NOT something I made, just an example I found):

I tried porting a couple random Flash projects to iOS and they worked well. They didn’t run perfectly, but they ran well enough to say that Flash-to-iOS is actually viable now. (For the record, the iPad doesn’t run Flash stuff nearly as well as the Playbook, but I haven’t had a chance to try it out on an iPad 2 yet.)

The problem

I do my Flash development on Windows (now I’ve really lost everyone ;) ), and one of the issues that frequently comes up while testing Flash-to-iOS apps is the pain of getting IPA files onto my iPhone and iPad. On OSX, it’s easy, you just drag and drop IPA files directly onto the device in Xcode’s Organizer, there’s no need to even bother with iTunes.

On Windows, it’s trickier. You could use iTunes, but its syncing is just way too slow. You could also use Apple’s iPhone Configuration Utility, which is pretty sweet when it works. Unfortunately, I get errors and other weird glitches with it most of the time, but maybe you’ll fare better.

The third option is jailbreaking, which just isn’t worth the hassle, and the fourth is using something like TestFlight or HockeyKit. These tools are awesome when you want to send out ad hoc betas to testers, but it’d be overkill to use them for actual development.

A different way

The way TestFlight works intrigued me, so I decided to do some further investigation. In iOS 4, Apple added the ability to wirelessly download apps directly from your browser, as long the apps are signed and provisioned correctly for your device. This article has all the necessary info on how to do it. You have to create a webpage that links to a plist, and the plist then has links to some icon PNG files and the actual IPA file. There are some caveats, but that’s the gist of it; it’s actually pretty straight forward.

I decided I would create a local web server to host a basic html page and all the required files for wireless app distribution. Think of it like a local version of TestFlight running on your computer. The beauty of it is that it works over wifi, and the IPA gets served directly from wherever it is on your computer, with no uploading required. The issue with most web servers is that they’re usually a bit of work to get running, and I wanted something that was super-lightweight and ridiculously easy to set up, which is how I ended up with good old Adobe AIR.

Over the AIR

Server Sockets are an oft-forgotten feature of Adobe AIR that let you create HTTP servers. This great article by Chrisophe Coenraets is a solid primer on how it’s done. The ability to write a *cross-platform* web server in less than 100 lines of code is pretty powerful.

To get it working all you have to do is start the server and select an IPA file. It even monitors the IPA file for changes using the ideas from this post, so that any time it’s modified, a chime will sound. This is handy because AIR’s IPA packager usually takes a couple minutes, so it’s nice to know when your IPA has been created. I also set it up so that if you keep your device’s browser open, it’ll actually automatically trigger the new IPA to install when it’s been changed.

I use the FZip library to browse through the IPA file (which is really just a zip file), and extact some data from the Info.plist, specifically the bundle identifier, the version number and the app name. These pieces of info only matter while the app is downloading, because after the download finishes, the values in the app’s Info.plist take over.

Once you start the server, all you have to do is navigate to the correct url on your phone (usually something like 192.168.0.10:9999) and you’ll be good to go. Just wait a few seconds or hit the “GET APP” link and the app will download straight to your phone.

Here’s something sneaky: every time you download the app, it appends an incrementing integer to the version number, so that the device always thinks it’s a new build. When the version number says “1.5.1″, it’s actually using “1.5.1.44″, “1.5.1.45″, “1.5.1.46″, etc.

It’s called “EasyIPA”. The magic of AIR means it’ll work on Windows, OSX, and Linux. Just be aware that I didn’t test it very much on OSX (or at all on Linux).

Known issues:

  • On OSX (and probably Linux), you’ll have to manually figure out your machine’s local ip (look in network settings).
  • If you get a “Port #### may be in use” error when starting the server, refresh your device’s browser then restart the server.
  • It can’t extract data from binary Info.plists. This isn’t really a big deal, you’ll just have to enter the info manually (the info doesn’t really matter anyway).

To get it, download and run this.

The AIR runtime should install automatically, but if it doesn’t, get it here.

I threw this together really quickly just as a proof of concept, so the code isn’t very pretty, but if you want to have a look, you can get it here. Feel free to do whatever you want with it.

Please post a comment if you find the app useful or if you run into any issues. Thanks!

UPDATE April 7th: Just made a new version and updated the links above. The only change is that now there’s a field for you to manually specify the server’s IP. This should help in those cases where it can’t figure out your local IP automatically.

Posted in Flash, iOS Development, Workflow | 35 Comments

Four Months

It’s been four months since my last post back in November. I know I said I’d keep blogging, but that just didn’t happen. Luckily, it’s been so long that it’s my turn to do iDevBlogADay again. Due to the new rules, this means you can expect me to post every other Sunday, although I’m actually planning(*hoping) to post every week.

I figure the best way to re-start blogging with is a summary of the past four months, in semi-chronological order, so that’s what this week’s post is gonna be.

Quitting

I finally finished my job at the end of the year. I was employed at Indusblue for over five years, basically since graduating college, so it was bittersweet to leave. I worked with some really awesome people there, learned a ton of stuff, and just generally had a great time. As much as I loved it, I knew it just didn’t make sense to stay there if I wanted to have a career making games, and so the end of the year was a great time to start fresh.

Christmas

I did a Christmas sale that started a couple days before the 25th of December. I dropped the price of Trainyard to $0.99 from $2.99 and made a couple videos to tell current Trainyard players about the sale. The video that went to the regular players basically just explained what was going on with Trainyard, what was in the new update, and was was coming up in the future. The video that went to the free players was more of an upsell video, trying to explain why they might want to buy the full version.

The sale wasn’t as successful as I’d hoped, but it worked pretty well. A week before Christmas, Trainyard was making around $800 per day, but on Christmas it made $1500. All in all, it made over $1000/day for the first 10 days of the sale. I definitely can’t complain about that.

People to watch

One really sweet thing that happened is that I was featured in a Toronto Star article called “People to Watch 2011″. Going to the photo shoot for this article was fun, as I got to meet a bunch of interesting people in all kinds of fields. After the article was printed, I received lots of encouraging messages from old friends, family, and school teachers. The whole experience was very cool, and I was honoured to be chosen for the list. You can view the full article if you click the image below.

Toronto Star - February 3rd

Click on the image to view the full article

Starting a company

In January, with my old job out of the way, I officially started my new company. It’s called Magicule. People seem to either love or hate the name. I go back and forth on it every day, sometimes I hate it, sometimes I kinda don’t mind it, hah. It’s meant to be a portmanteau of “magic” and “molecule”, because games are like mix of magic and science, or something like that. I still haven’t bothered to get a logo made for it, but when I do, I’m hoping it’ll help to convey the meaning.

PlayBook

For some reason, I decided to make an app for the Blackberry PlayBook in January. I used to be a Flash developer before I did iOS development, so making a PlayBook app was actually really easy to do, and it helped that Blackberry has a deal where if you make an app before the PlayBook comes out, they’ll give you one for free.

My app is called Scorekeeper. It’s a really simple tool for keeping track of scores while playing party games or board games with friends. I’d show a screenshot here, but it’s really hard to appreciate until you see it in motion. I don’t expect it to make very much money; I just made it for fun, to do something completely different for a while.

I got to present my app at the FlashInTO user group here in Toronto. RIM brought a PlayBook to the event, so I got to try Scorekeeper on a real PlayBook. The device was pretty impressive, and ran my app at a smooth 60fps. It’s a great product. People keep saying it’s not an “iPad killer”, but I don’t think that’s what RIM is trying to be at all. The way I see it, they’re targeting it solely at current Blackberry users, and I think they’re going to do really, really well with that audience.

GDC

At the start of March, I finally got to attend the Game Developer’s Conference. Of all the conferences I’ve wanted to attend, GDC was at the top of the list, and it didn’t disappoint. There were lots of phenomenal sessions, and it was awesome to get to meet with the rest of the “indie iOS” community. I highly, highly recommend it.

One of the best parts of GDC is just that fact that it’s in San Francisco. The food is great, the people are nice, and the scenery is fantastic. I spent my second day in San Fran up in Berkeley hanging out with Jonathan Mann. In my opinion, Jonathan is the most under-appreciated person on the internet. Seriously. He writes a new song and posts it online *every single day* and he’s been doing it for 808 days straight. How crazy is that? And some of them are really, really good. He wrote a bunch of songs you’re probably heard, like the iPhone Antenna Song, the Pocket God Update Song, and countless (well, 808) other songs. One of my favourites is String Theory, or if you want to see my cameo from the day I was there, check out his song on Settlers of Catan.

Where did the time go?

Right now when I look back over the past three months, I wonder what I was doing the whole time. I’ve definitely done some work, but it sure doesn’t seem like three months worth. I guess time flies when you’re working for yourself. Doing business-y stuff also gets in the way and just seems to suck up infinite amounts of time. I’m quickly learning that when you’re working solo, it’s more important than ever to carefully structure your time and hold yourself to strict deadlines.

What now?

I’m still working on the Trainyard “Engineer” update, which should be pretty sweet when it finally comes out. Along with that, I had a cool idea for a game on the way back from GDC, so I decided to prototype it. It’s an indie-style pixel platformer that I’m making in Flash (Flixel, specifically). I’m not really sure what I want to do with it, I might just release it as a webgame in its rough form, because I don’t see a good way to make it into a “real” game without a ton more work, and I’ve already got way too much to do.

I’m also working on another iOS puzzle game (or two?), and a game that’s very hard to explain. There’s definitely way too much on my plate, but I’m trying to tackle it one thing at a time, so I’m sure it’ll all get done eventually.

Tips

So that this post isn’t completely useless, I figured I’d throw a couple tips in:

Form a corporation before you sell a game on the App Store

Not incorporating has given me so many headaches. It’s really not that hard or expensive to create one, but it’ll save you from so many hassles later on.

Give yourself very strict deadlines

You need to treat each one of your own projects as if they’re for a client, or else you’ll never get any of them done. I’m really bad at this, but I’m working on it.

Don’t use Twitter or email or Reddit during the day

This is something I struggle with, but it improves my productivity a ton when I do it. Yes, even ignore email. Unless you’re a sysadmin (you’re not), then you’re probably not getting an urgent email. At the very least, don’t check Twitter and email first thing in the morning, it sets a horrible tone for the rest of the day. And if you’re not on Reddit already, don’t start, it’ll suck your time away like an evil meme-filled vacuum.

Make a goal for your company

This was the key message I got from Arash’s talk at GDC. All the decisions you make for your company become a lot simpler if you know what you want your company to become. You need some kind of mission statement, some kind of idea of what your purpose is. I think this applies to individuals as well. Spend a couple hours and really figure out exactly what your goals and ambitions are, then write them down and put them somewhere visible.

So with that, I think I’ll draw this post to a close. Many thanks if you’ve actually read this far. I promise the posts in the weeks to come will be a lot more interesting, so don’t forget to come back next Sunday!

Posted in iDevBlogADay, Meta, Trainyard | 27 Comments

How To Price Your Game

For this week’s iDevBlogADay post, I’m going to give my thoughts and recommendations on game pricing. This is a something I skimmed in last week’s post, but it’s a highly requested topic, so I figured it was worth delving into. Both paid and freemium are valid strategies for making money the App Store, but I’m saving freemium games and IAP in general for a future post, so this one will only cover paid games.

Surgeon General’s Warning

I am not an expert on game pricing. I have absolutely no background in economics or any other kind of business-y stuff. Really, most of this is just guesswork and extrapolation from my own experiences with Trainyard and from what I’ve heard from other developers. If you lose a million dollars from following my advice, I’m sorry. On the other hand, if you make a million dollars, you owe me half ;)

An overabundance of apps

Apple enjoys telling us that there are more than 250,000 apps on the App Store, but the thing they don’t tell us is that 99% of those apps are awful. There is a serious ton of junk out there. The ridiculous goodness-to-crapness ratio means that anyone who is even slightly adventurous with their purchases is going to run into a lot of duds.

People love comparing the price of apps to all kinds of things, especially coffee, but here’s the thing: when you buy a coffee, you know you’re getting a coffee. When you buy something on the App Store, you really don’t know exactly what you’re going to get. Imagine you bought your coffee, only to open the lid and find it was only half-full, or that it wasn’t coffee, but lemonade. If only 1 in 5 cups of coffee you bought actually contained coffee, a $3.99 coffee price would suddenly seem pretty high.

It’s all about risk

$2.99 is not a lot to pay for a good game, *if* a user knows it’s a good game. The problem is that with every App Store purchase, there’s a very high likelihood that the user is going to get a bad game. Over time, most users will have come to know and accept this about the App Store, and they’ll perceive a certain risk for every purchase. They subconsciously weigh the cost of the game against the chance that they’re going to be ripped off.  We can use this knowledge to our advantage when we price our games, by figuring out the perceived risk.

Risk reduction

There are a number of factors that affect how risky a game seems to a user. The most obvious are ratings and reviews. Apple has put these in place to give users a good sense of what other users think about the game. They help, but unfortunately they can also be gamed and abused, so they’re not as useful as they could be.

Being featured by Apple does a huge amount to reduce the risk of a game, because it tells a user that the almighty Apple has decided the game is worthy of the featured apps list. It also increases the exposure of a game a huge amount, which is why it’s such an effective boon for sales.

The top charts are similar to being featured in that they also increase the exposure of your game, and being in the top charts tells potential users that lots of other users are buying your game, which means it’s probably not a dud.

Another great factor is having a solid brand. Having a well known brand helps immensely to legitimize your game. That brand could be a licensed property, like Skee-Ball, a company brand you’ve built up over time, or even a publisher, although I really discourage you from getting a publisher.

Mentions from friends are the ultimate risk-reducer. I consider this as anything from Twitter to blogs and especially actual word-of-mouth. If people the users actually trust recommend the game, then they *know* it’s not going to be awful.

There are dozens of other subtler factors that affect the risk of your game as well, including the quality of the icon, screenshots, and description. Using these well can increase the appeal of your game, but using them poorly can actually push potential users away.

Launch time

If you’re an indie developer, your game most likely won’t have anything but word-of-mouth and blog posts to go on at launch. Most users who get to the App Store ”buy page” for your app will have come there from a specific link or from typing your app’s name in the App Store search. A user who is looking for your specific app already knows exactly what they’re getting, so their perceived risk is minimal. What this means is that you can afford to price the app at a higher price, because they aren’t simply browsing.

At launch you should price your game at close to what it’s truly worth, but you still have consider the rest of the App Store market. Some games really are lifetime $0.99 games, and usually have fairly shallow, repetitive gameplay. As a completely arbitrary rule: if your game couldn’t have a substantial lite version without giving away the whole game, it’s probably a lifetime $0.99 game. Most other games deserve the premium $2.99 price point. Unless you’ve got a very established brand, anything above $2.99 is pretty much App Store suicide.

I originally launched Trainyard at $1.99, but looking back, I think that was a mistake. There’s very little difference between $1.99 and $2.99 to most users, and my sales stayed steady when I bumped the price of Trainyard up to $2.99 a few months after launch.

Keep in mind that these prices are for the iPhone and iPod Touch. I’ve never released a game for the iPad, but in general, it seems that iPad prices should be $1 higher than their iPhone equivalents.

Experiment

This is a very young and volatile market, so there are no absolute rules. Feel free to experiment with the price of your app every so often. Apple makes it incredibly easy to change the price as much as you want, although you should keep in mind that there’s usually around an hour long delay before it fully propagates through the App Store. One of the big things I hear some people worry about is whether they’re going to anger their current user base when they have a sale. Don’t worry! Most of your current users won’t even know you’re having a sale, and the ones that do usually won’t care.

Having a sale probably won’t rocket your app up the charts, but it’s a great reason to send an email around to your favourite blogs to drum up some more publicity. There are some apps, like Canabalt, that never go on sale, which becomes part of their “mystique”. I guess that’s fine if you want to be hardcore like that, but I really don’t see the point.

Push for the top

When your app gets featured by Apple, it’s time to start planning for a sale. I can only advise you to do what I did. Featuring only lasts a week, so your goal is to go as high in the charts as you can to extend your popularity well after the feature is over. That being said, I’d say wait a few days before you do the sale, because I think it only takes a couple days of being featured to max out your rank. Apps are always featured on Thursdays, and in my case, I waited till the Tuesday to do the sale, which was quite successful.

I know my situation was pretty much a perfect storm of dozens of factors all converging, but that doesn’t mean it couldn’t happen to you. Your circumstances could literally be once-in-a-lifetime, so you’ve got to take the chance when you get it. Even if you don’t hit the top 10 or even the top 100, your rank will still rise further than it would have at the higher price point, and therefore your descent should be slower. Feel free to raise the price back up when you’re off any of the major charts.

Wrapping up

I think that’s about it for my paid game pricing advice. There are a bunch of subtler things I didn’t cover because this post would have been a bajillion words long, but I think you probably get the gist. As usual, if you’ve got any comments or questions, please message me on twittersend me an email, or just post a comment.

One final note: I’m going to follow in the footsteps of Alex and Noel and make this my last iDevBlogADay post. The waiting list is getting way too long, and I’m so ridiculously busy right now that I really shouldn’t be spending as much time as I do writing these posts. That being said, I’ll keep writing stuff, so stick http://struct.ca/feed into your rss thingie.

Posted in App Store, iDevBlogADay | 35 Comments