For this week’s iDevBlogADay post, I’m going to look back at a presentation I did a couple weeks ago at FlashInTO, a local Flash user group. I’m also going to go over a bunch of random questions and things that I mentioned during the presentation, so this’ll be a bit of an “odds and ends” post.
You may be wondering why I gave a presentation about an iPhone game at a Flash user group. Well, there are a couple reasons. The most obvious one is because of my background as a Flash developer, I think I proved that it’s possible to make the jump from Flash to iPhone successfully. The second reason is that because of Adobe’s Flash CS5 Packager it’s now possible for any Flash dev to become an iPhone dev, so even if the technical advice doesn’t apply, the business and marketing tips do.
You can view the slides for my presentation here. It follows the same outline as my original The Story So Far and The Week That Was posts, so if you’ve read those, there won’t be too much new information. The main thing that’s different is that I delved a little bit more into how I used Flash and I gave a bunch of miscellaneous tips at the end of the presentation. Since I haven’t mentioned those things before, I figured I’d write a bit more about them now.
How I used Flash
As you may know, Trainyard was originally envisioned as a Flash game. Because of this, the engine and a large chunk of the puzzles were all created in Flash. You can try the original Flash prototype here. With that prototype, each level was created with hand-written xml. Not the best process, but it worked.
Later on, I decided I needed more control over the puzzle editing process, so I created a full puzzle editor in Adobe AIR. I used that editor for the rest of the puzzles, and I still use it right now. It’s way too ugly and buggy to ever release to the public, but it works perfectly for my purposes.
In the last few slides of the presentation, I gave a bunch of random tips. There isn’t a particular theme, they’re basically just answers to some of the most common questions I get asked.
Don’t get a publisher
This is something that’s been said a lot recently, but I think it’s worth repeating: don’t get a publisher. If your game is good, it’ll do well eventually anyway. If your game isn’t good, no publisher is going to be able to turn it into a hit. The way I see it, a publisher just accelerates the inevitable.
Don’t launch at $0.99
At some point I’ll probably have to dedicate a whole post to my thoughts on the “ideal launch price”, but for now, I’ll just over-simplify it. If your game is deep enough to have a solid lite version, you should launch your game at $1.99, and then raise the price to $2.99 a month later. Only drop the price to $0.99 if the game enters the top 50 or if you want to have a sale just for fun. Never launch at $0.99, unless you’re planning on your game staying at $0.99 forever.
Don’t release the lite version at the same time as the full game
Unless you’re an imaginary person, your game won’t be perfect when it launches. At the very least, it’ll have bugs and some general usability issues. Give yourself a couple months to listen to user feedback about your game and improve on it. Take every opportunity to make your game as good as you can. When you release your lite version, it had better have every single kink worked out, because free users are incredibly unforgiving.
Users should like your lite version by itself
This is a little tricky to explain, but I’ll try. Way too many developers make their lite games into seriously hindered versions of their full games. At first, this might seem like a good idea, because you want the users want the full game, but in reality, even with the best games, the conversion rates from free to paid are only around 2%. If your game does a great job of making the full game seem good, 98% of your users are still going to delete your app because they don’t want to pay for the full game. The lite version doesn’t offer them any value, just the promise of the full version. You need to make a lite version that is a good game by itself.
Take a break
Don’t work on a single game forever! If you’re truly sick of a game, take a break from it and work on a new game. In the end it’ll make both games better.
Work hard, believe in what you’re making
Always keep in mind that your life will dramatically change if your game succeeds. Make sure what you’re making is something you’re proud of. Have a clear vision and work hard towards your goal.
This has definitely been a mish-mash of a post, but I hope you’ve found some of it useful. As usual, if you have any feedback, feel free to post a comment, email me at email@example.com or message me on Twitter.
Later tonight I’ll be heading to Montreal for Unite 2010 (the Unity conference), but before I do that, I’ll be making a game for the 360iDev Game Jam. Most of the participants will be working overnight on their game prototypes, but unfortunately I’ve gotta catch a bus, so I’m only going to have a couple hours to work. You can follow my progress here, and you should follow everyone else too. I think you’ll see some really cool stuff.