Hey Adam, I’m glad that you’re bringing all these issues up and starting this discussion, and I think (maybe) I can convince you of the benefits of freemium games, or at least present an alternative viewpoint. I should also point out that I’ve never made a freemium game, and that I usually make the kind of games I imagine you’d enjoy.

To start off, I think we need to talk about perspective.

You (just like me, and a lot of other people here), approach games as a game designer first. This has a bunch of interesting side-effects. The first is that we have “game-designer-itis”, where we play a lot of games, but usually only play them long enough to grok what they’re about and to experience whatever it is that makes them unique. This is why people like us love games like Braid where there’s very little repetition. Every single level introduces a new element, a new twist. There’s no fluff, no filler.

On the other hand, we never finish most blockbuster games for the same reason. They just get too repetitive. I’ve never finished Halo, Gears of War, GTA, etc. It’s not because I couldn’t finish them, in fact, it’s just the opposite: I knew I could finish them, so I didn’t see the point; I had already explored all of the systems that the game had to offer.

Now let’s be clear, there’s absolutely nothing wrong with the way we approach games, but I don’t think it’s fair to assume all gamers are the same as us. A lot of people play games purely as a form of entertainment, and so they want as much of it as they can. They’re not nearly as concerned about whether each moment they’re experiencing is unique or not, they just play games as a way to escape normal life, a way to kill time, a way to be someone they aren’t.

Ok, so how does this all tie in with freemium games? There was a fantastic presentation at GDC 2011 called “The Fantasy of Labor”. If you have access to the GDC Vault, I highly recommend you check it out. The ideas I’m writing about here are rooted in the concepts that were presented there.

The core idea of the talk is that all games require three things from a player, in varying amounts depending on the game: skill, luck, and labor. A game like Street Fighter requires mostly skill, a game like roulette requires mostly luck, Farmville requires mostly labor, etc.

The common attitude in both the game development and “hardcore gamer” communities is heavily biased towards skill-based games. These games are appealing to the majority of the traditional gaming community, but they have flaws. The talk goes into detail into quite a few issues, but the most important take-away is this: *a lot of players do not want to play games that require skill*.

Now let’s move from skill to labour. There are a huge number of players (a large portion of the “casual” demographic) who *enjoy* games that are labour based, and dislike games that are skill based. They want a game where they know that the longer they work, they will always improve, no matter what.

It took me a long time to come to grips with the fact that some players really don’t want a game with interesting gameplay or systems for them to grok. They just want something where the more time they spend, the more results they’ll get. They aren’t looking to be rescued by some well-meaning game designer, saving the day, saying “no, this is what games really are! Try all these interesting systems, look how intrinsically motivating this game is!”, instead they just want to check boxes on a checklist. They *want* to.

Alright, now for the final piece of the puzzle. In your post you implied that the only reason someone will pay to skip ahead is if their urge to complete the extrinsic checklist overpowers their enjoyment of the intrinsic mechanics of the game. I heard someone summarize the main take-away of your post as this: “If a game lets you pay to skip playing, it’s not fun. Why wouldn’t you want to play?”.

One issue with this argument is that it doesn’t consider all of the other elements that make up a game, especially the aesthetics and mythology. I think we can agree that it’s possible for these to motivate certain players way more than “the desire to experience the mechanics” or “the desire to improve their skill”. Players will sometimes want to advance just so they can experience more of the story or more of the aesthetics, and there’s nothing wrong with that.

Now coming back to the checklist. I think this is probably the main point I want to make: some people actually enjoy filling out the checklist. And really, it’s not just some people, but a large portion of players in the casual gaming space. Even more importantly, they don’t enjoy the kind of games that *you or I* wish they would enjoy. Specifically, they don’t want games that require skill, and they don’t want games with interesting mechanics (unless there’s also a checklist attached).

One more thing: even if you think I’m completely fabricating the existence of this type of player (I can assure you, I’m not), I think we can probably agree that even regular gamers can become this type of player *some of the time*. For example, long after I’d grokked all of the core mechanics of Tiny Tower, I kept playing for weeks because of the desire to see my tower get taller, and I loved every minute of it.

So to wrap up: freemium games are giving players what they want.

An afterword: I really want to be clear that I’m not saying “freemium games can do no evil”, because they can, and a lot of them do. I simply want to point out that the core mechanics of these games are not inherently evil, and that they fulfill the needs of certain types of players.

The Conference

I really want to keep this post short, so I won’t go into too many details about 360iDev itself. I could spend more than a few paragraphs just talking about all the things I ate, but instead I’ll  summarize the whole conference: it was great.  I loved learning and being inspired by presentations, I loved eating copious amounts of meat and fried food, and I loved hanging out with “old” friends and meeting new ones that’d I’d previously only known through Twitter.

The Jam

A game jam is usually where a bunch of people get together and make games over a short period of time, and the 360iDev game jam was no different. It started on Tuesday at 8pm and went through the night. There was no defined end time, except that the games had to be done by noon on Wednesday so they could be presented to everyone else. This was a pretty crazy schedule, especially considering that Wednesday was a regular conference day.

The Theme

The theme for the jam was “opposite”, which was announced at noon on Tuesday, giving everyone about 6 hours to come up with a game idea. I had already decided that no matter what the theme was, I wanted to make a “freemium style” game. This isn’t really because I enjoy that kind of game, but more because I wanted to try that genre out so I could learn more about it.

I struggled with combining “opposite” and “freemium” for a while, and actually didn’t come up with an idea until 45 minutes *after* the jam had started. I considering things like magnets and “opposites attract”, but it wasn’t until I thought about actual opposites, like “hot and cold” and “up and down”, that I found my starting point: “night and day”.

The Result

I spent the first 7 hours in the jam room, and the last 5 in my hotel room, where it was quieter, finally finishing at 10am. The result is a game I call “Luna Soul”, a play on luna (moon) and sol (sun). The game features a constant day-night cycle. In daytime, flowers grow, and at night, mushrooms grow. Your job is to harvest both types of plants and combine them as herbal “recipes”, which you then sell. You can use the money from selling plants to buy more complicated recipes.

I developed the game in Flash, because of just how fast it is to develop in, and because I knew I wanted to have a bunch of animations. I used Adobe’s AIR-to-iOS packager, so people could actually play the game on my iPad at the jam. Due to the magic of Flash, you can even play the game right now. This is the *exact state* the game was in at the end of the game jam after 12 hours of work. I haven’t changed anything since then.

The Music

The final thing I wanted to mention is the music. The multi-talented Phil Hassey (creator of Galcon) brought his fiddle to the game jam and offered to create music for anyone that wanted it. There were four games that ended up using his music, including mine. It really helps to signify the exact change between night and day, and more importantly, it adds a lot of character to the game. I’ve included a video of him performing at the jam below.

Wrapping Up

Luna Soul is far from perfect but I’m pretty proud of how far I got with it. I’m not sure if I’m going to do anything else with the game, but I do have a bunch of ideas for how it could be improved.

One last thing: make sure you check out all of the other game jam entries,  there were lots of really impressive games demoed at the jam, so it’s worth browsing that site to see how much stuff was made in a single night. If I had to pick a favourite entry, I think it’d be Vocab Bots by Ray and Vicki Wenderlich. Great idea and great execution.

Thanks for reading this post. As usual, if you have any feedback, you can post it here or send it to @MattRix on Twitter. Cheers!

I wrote a post last week about my struggles and dilemmas while creating the new Trainyard Engineer Update. This week I’d like to talk about what I actually did in this update. I’m not going to get too technical, but if you have technical questions about anything I did, I’d love to answer them, just ask in the comments section.

Backend

The backend for this update was probably the biggest area of concern for me. I was seriously considering switching to something like Amazon Web Services, but eventually decided to stick with my current backend (PHP+MySQL on Dreamhost PS). I finally got around to learning a whole lot more about SQL (big thanks to Jim McGinley) and optimized the database with better indexes and smarter queries. I also wrote dozens of new scripts for handling uploaded puzzles, solutions, and other user data.

I rewrote most of the frontend code on the website, creating “AJAX-style” puzzle and solution browsing systems. I added the ability to comment on puzzles, and the ability to open puzzles directly from the site if you’re browsing on an iOS device with Trainyard installed.

The editor

The in-game puzzle editor itself was a huge amount of work, and took a ton of planning to get right. I went through pages and pages of sketches and potential interface designs before I settled on its current look and flow. I’m really happy with how it turned out, but man, it took a lot of effort to get there.

Although creating the puzzle editor itself took a lot of time, I spent even more time creating all the extra stuff to surround it. For example, there’s a screen to enter the puzzle name and description, a screen to let you solve your own puzzles, and even a screen to show you the data you’re about to submit, so you can verify that it’s correct before submitting it.

On top of all that, there are also tons of little subtle features that most people will never see. One small example: if you submit a puzzle that’s identical to a puzzle someone else submitted, it’ll warn you and even allow you to download their puzzle instead.

If you want to see how the editor works and the whole process of creating a puzzle,  just watch the video below:

Browsing

Creating the system for browsing puzzles was also a lot of work. One of the key issues for me was discovery; I needed players to be able to find great puzzles without having to shuffle through thousands of so-so puzzles. The solution I arrived at is now called “featured puzzles”. This is a list of puzzles that I’ve hand-picked, and that I can update online at any time. This ensures that there will always be a stream of fresh, interesting puzzles.

For players that are brave enough to explore all of the user-made puzzles, I made a “worldwide puzzles” section. There are a bunch of different search options there, so for example, you can find puzzles that are new, popular, or unsolved. I also created a Facebook-ish “like” system where players can choose to like a puzzle after they’ve solved it. As of writing this 5 days after release, there have already been over 10000 likes submitted.

The last two areas of puzzles are “my puzzles” and “saved puzzles”. “My puzzles” is a list of puzzles that the user has created, regardless of whether they’ve been submitted or they’re still being created. “Saved puzzles” is a list of all the puzzles that a given user has tried, whether they’re solved or not.

The video below shows me going through all the different puzzle browsing sections so you can see how they work:

Wrenches

If you’re familiar with the normal game in Trainyard, you’ll remember that all puzzles award “stars” when solved. I decided to do the same thing in engineer mode, but with “wrenches” (spanners for you UK people). I let users assign their puzzles an arbitrary wrench count between 1 and 30 when they submit the puzzle. In theory the wrench count represents the difficulty of the puzzle, but in reality it’s not always accurate, which is totally fine. I considered some more accurate systems for determining puzzle difficulty, but it just wasn’t worth the effort, because wrenches really don’t matter for anything anyway.

Goodies

The last major thing I added to the game is the “Goodies” section. Goodies is essentially just a catch-all for all the features I had wanted to add but didn’t have a chance. It’s also very flexible so it’s super easy to add more features to it in the future if needed. Here are the items that are there right now: News, Achievements, Tutorials, Mailing List, Tips & Tricks, Solutions.

Goodies: News

News is a list of Trainyard related news items for users to read. The data comes from an xml file hosted on Amazon S3. Each news item has HTML content that can be shown in a webview, which allows for stuff like embedding YouTube videos.

If I want I can also specify that a news item is an “alert”, and then it will pop up when the user starts the game. I can also do things like targeting news alerts to specific users, for example, to those who have a certain version of the game, or to those for whom this version is an update (rather than the first time they’ve played).

Goodies: Achievements

One of the biggest requests for Trainyard has been Game Center support, so I finally decided to put it in this version. The tough part of integrating it was that Trainyard allows you to have two local users, so I had to figure out how to make that work with Game Center.

What I ended up doing is making it so that the local data is authoritative on achievements. The game will never download achievement progress from Game Center. Instead, if an achievement has more progress locally than in Game Center, it’ll automatically push that progress to the server.

This has the benefit that both of the local users can still earn achievements by themselves independently. It doesn’t matter what has happened in Game Center. It’s almost like Game Center acts like a “high score list” for your achievements, they’re only submitted when they’ve improved.

I also have a really cool technical system for keeping track of the achievements. I won’t go into it here too much, but basically any time something good happens, an “achievement source” gets incremented. You can base multiple achievements on a single achievement source (ex solve 1 puzzle, solve 5 puzzles, solve 10 puzzles). It also has a system for tracking uniqueness, so that if you solve the same puzzle 10 times, it’ll only count as one puzzle in the “solve a puzzle” achievement.

All of this was pretty complicated to create, but now I have an extremely robust and flexible way to do achievements that will work for any kind of game in the future.

Goodies: Compare Stars

It’s not in the actual “Goodies” list, but Compare Stars is an option under Achievements. It’s basically just a Game Center high scores list where you can compare how many stars you’ve earned to how many your friends have earned.

Goodies: Tutorials

A tutorial list has been a highly requested feature for a long time. Normally the tutorials are interspersed throughout the levels, but this makes them a lot easier to browse through.

Goodies: Mailing List

I’ve had a Trainyard mailing list set up for a long time, but it’s always been on an obscure area of the Trainyard site where it was super hard to find. I decided I’d finally make it easier to sign up in this update. I’ve been using MailChimp, and they have a super easy API that was really easy to integrate.

Since the update went live 5 days ago, more than 200 people have signed up for the mailing list. That’s not too shabby considering there were only 300 people in the list a week ago. The way I look at it, that’s 200 people who are likely to buy whatever my next game is. I wish I’d put it in sooner.

Goodies: Tips & Tricks

I really wasn’t sure about this section but I threw it in at the last minute. It works similarly to the news section, but each item just contains a single YouTube video. Each of the videos is a short tutorial on some aspect of the game. You can watch them all in this YouTube playlist if you want.

Goodies: Solutions

Not much to say about this. It’s just a link to http://trainyard.ca/solutions. I’m hoping it’ll cut down on the number of “How do I solve *****?” emails, and if I’m really lucky, it’ll cut down on the number of “Trainyard Solutions” copycat apps as well.

Wrapping Up

Phew. Ok, a golden horse to everyone who made it this far. There were a ton of other smaller features that I didn’t cover in this post, but I think I hit on most of the major ones. Once you consider creating all of these elements and integrating them all cleanly (and mostly buglessly), I think you can probably see why this update took me 3 months to make, hah.

I hope you enjoyed these last two posts. If you have any questions, especially about technical stuff, I’d love to hear it, so just leave a comment down below. As usual you can also reach me on Twitter at @MattRix, cheers!

A promise

Never promise anything. Seriously. Ok, well at least never promise anything if you’re a game developer, no matter how tempting it is, and no matter how much you think you’re going to be able to deliver it.

So here’s what happened: Back in December I was wrapping up my old job, and I was super excited about finally starting to work for myself as an independent game developer. I was thinking “oh, I’ll get so much work done now that I’m working full-time”.

So I did something silly; I put out a Trainyard update with a video message that was seen by around 80,000 players, and in that video I promised that a massive new Trainyard update with a puzzle editor would be coming in the first couple months of 2011. Whoops.

Dread and fear

January came and for a few weeks I got caught up in a bunch of company-forming stuff, but I eventually started thinking about the Trainyard update. When I began to figure out the logistics of it, it quickly dawned on me just how much work it was going to be. And then I did what most people do when they’re faced with a daunting task: I procrastinated. A lot.

I worked on all kinds of other projects, including a Playbook app, a multiplayer HTML5 Tetris game, and a music generation toy, as well as a ton of game prototypes. The one thing I didn’t do was actually work on the update.

In late March I wrote a post about what I’d been up to for the past four months, where I said I was hard at work on the Trainyard update, although in reality, I hadn’t even started. Time and distractions kept dragging on. In fact, it would take a few more months, until June, when I would finally, actually, for real, start working on the update.

Decisions

What was holding me back? Aside from being overwhelmed, there were a few tough choices that every other new feature hinged on. One of the biggest decisions was whether I was going to rewrite the backend code from scratch on “the cloud”, or just retrofit my current backend code. Among other problems, I also had to decide how to integrate Game Center achievements with my current dual-user system, and how to squeeze Engineer mode into the rest of the game.

Along with the technical decisions, I had to make numerous choices about the design and user experience of the new content. There were over a dozen new screen types to add to the game, each with its own special caveats and issues.

Scope

It’s worth taking a second to talk about the scope of this update: I bit off way more than I should have been chewing. Note my wording: just because you can do it, doesn’t mean you should. If you learn nothing else from this post, you should at least learn to keep your updates small and quick.

I decided that with this update, I’d add all of the little things I felt were missing from the game, including a news feed, mailing list signup form, “tips and tricks” video list, tutorial list, and more. I created a section called “goodies” to hold all of them.

There were a few times when I seriously considered releasing a web-based puzzle editor. It would have been way simpler, and it would have still accomplished my goal of allowing people to make their own puzzles. It also would have literally saved me two months of work. I just couldn’t do it though. I knew it’d be a second-rate solution, and I didn’t want to cut corners.

Buckling down

Ok, so how did I eventually get focused? At the end of May I went on a vacation, and when I returned, I was determined to get down to business. I created a carefully structured schedule that I forced myself to follow every single day. I gave myself rules and stuck to them. I won’t go over my new focusing methods here because I’m planning to write a post about them soon, but they worked like a charm, and I spent the next three months working on Trainyard for over 8 hours every day.

The results

I was originally planning to write all about what’s actually in the update, but this post is already way too long so I’ll save that for part two (coming in the next couple days).

For now, let me just leave you with this: I’m really, really happy with how the update turned out, and I’m proud to have created it… However, there are zero good business reasons for making an update this large. If I’m lucky, it’ll give Trainyard a temporary boost in sales, but even then it’ll quickly drop back down to where it was before. If I knew just how long this update would take to make, there’s no way I would have done it. Let me be even more clear: I hated working on this update; it was a bad idea.

What’s the moral of the story? Never promise anything.

The Guelph Game Jam

This is the second game jam I’ve participated in. The first was TOJam, which I wrote about back in May. I enjoyed TOJam so much that when I heard about another game jam in the area, I just had to go. The jam was organized by Owen Goss, and despite being the first Guelph Game Jam ever, it went really smoothly (great job Owen!).

If you’re not familiar with what a game jam is, it’s basically just when a group of people get together to make games over a short period of time. In the case of the GGJ, it went from 12pm until 7:30pm (with a 30 minute dinner break), so it lasted only 7 hours. This may seem like a really short amount of time, and it was, but everyone was still able to make some cool stuff. The theme of the jam was “Big”, and there were a total of 16 participants. If you want to see the other games, I encourage you to check them out on the GGJ site, there are some really interesting games there.

Ideas and Technologies

I spent some time during the week leading up the jam trying to come up with an idea for a game, but I was having a hard time arriving at a solid idea that could also be executed in only 7 hours. Knowing that the theme was “Big”, I came up with a lot of concepts for physics games, but none of them really stuck out to me.

At this time I also wasn’t 100% sure of what technology/platform I wanted to create the game with. I had just received my iCade, so I knew I wanted to create something that used it, but I wasn’t sure whether I wanted to create a game for the iPad or a Flash game. After a ton of internal debating, I finally settled on going with Flash. Using Flash would give me a lot more development flexibility and speed, especially when it came to making art and animations.

On the morning of the jam, I knew what tech I was going to use, but I still didn’t have a game idea. The trip from my home (in Mississauga) to Guelph takes about an hour, so I figured I could finalize the game as I was driving. The game I came up with on that trip became “Big Runner”.

The Big Idea

The gist of “Big Runner” is that the main character is a skinny guy, but his goal is to burn as many calories as he can, so he’s trying to get as fat as possible so he can burn more calories. The catch is that the fatter he is, the slower he’ll move, and the screen is constantly moving, so he can’t get too fat or else he’ll go off the edge of the screen. I realize this game makes no sense, and I can’t be bothered to make up a decent story for it, so you’re just going to have to invent your own.

I decided that there’d be cake in the game as the food that makes him fat, because I love cake. Nom. I knew I was using the iCade and wanted him to be able to do more than just move around, so I planned on giving him two actions: puke (to make him lose weight), and jump (to burn extra calories – I later took this out).

The Big Animations

When the jam started, I quickly sketched out what the guy might look like as he gets fat, and then I then started making all the assets in Flash. If you have Flash enabled, you can see some of the awful sketches and the animation above. I knew I had to work fast, because with only 7 hours, I couldn’t afford to spend very much time on art.

I made the guy, the cake, and the street background. I also had to make a bunch of UI elements (main menu, score, etc.).  The key with the guy was that I wanted him to visibly get fat, and do it gradually, rather than simply snapping to different fatness levels. Flash’s shape-tweens really helped to create a seamless transition between different amounts of fatness.

Late in the jam, I still needed some sort of “enemy”, and I happened to overhear Connor Pridham (son of @madgarden) jokingly saying something about how every game should have tanks. I realized that tanks would be a perfect fit for Big Runner, so I decided to put them in. Oh, and it turns out that Connor was working on a sweet mix of tanks and Minecraft called TankCraft.

The Big Finish

I spent 2 hours on art and animation, and the rest of the time coding. I finished implementing the tanks right as the jam ended at 7:30 (ok, a few minutes after). The “finished” game was playable with the iCade, and it was actually kind of fun. The music was made by Guelph local Tyler Shaw. My request to Tyler was “music that sounds kinda super-nintendoish, and upbeat, with the melody from Happy Birthday”, and he nailed it (Tyler also made the music for a few other games during the same time period – impressive!).

That 7-hour version had a bunch of things missing, including sound effects and a jumping mechanic. There are also some weird bugs and the hit areas on the tanks are really bad. I hadn’t finalized what I wanted to do with the puking mechanic, so you can puke almost all the time. Through the magic of Flash, you can play the original version right now.

Polish

On the drive home from the jam, I came up with a bunch of ideas for how to tweak the game. The next day, I spent two hours adding sound effects, changing how the puking works, and fixing most of the bugs. I decided it was good enough to put on Kongregate (a popular Flash games site), so I spent another hour implementing the Kongregate API (highscores, achievements, etc), and then I put it up there on Wednesday, after a total of 10 hours of work. You can play the Kongregate version here. See if you can beat 1500 calories.

Game Design

The game is a simple side-scroller with very few elements, and yet it has a surprising amount of depth. The original version allowed you to puke whenever you wanted, so you could control your weight precisely, but I realized that having that much control actually took a way a lot of the decision making and planning. The final version has the limitation that you can only puke when you’re at your fattest, which adds a lot of interesting dynamics.

I really wanted the way you play the game to naturally change and evolve as you play it, and that’s exactly what happens. At the start of the game, you want to eat all the cakes you can, so you’re running around trying to collect cakes. By the later stages of the game, you actually want to stay skinny, so you start having to avoid the cakes. I think twisting something good into something bad over the course of a run is a pretty novel way to create depth and choices for the player, and at the end of the day, this is a game about trade-offs.

There were many happy accidents with the game design of the game, and one of them was with the tank; I really like how the tank’s turret gives a visual warning that the tank is coming. It comes far ahead of the tank’s hit area, so in the early stages of the game, you can tell exactly where the tank is going to come from before the full body of the tank arrives on screen – a subtle but interesting element.

Wrapping up

I think that’s just about all I have to say about Big Runner. Please try out the game and let me know what you think! Feel free to send it around on Twitter and Google+ too, I’d love to see how high the scores can go. Also, make sure you check out the other Guelph Game Jam games, there are some cool projects there. As usual, you can post your comments here or send them @MattRix. Cheers.

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.

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:

Whit’s Jeopardy style theme:

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.

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.

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.

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!

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 twitter, send 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.