We released our first game, Now Boarding, a little over a year ago. I’ve been putting off writing a post-mortem on it for a while, because I’ve been busy. However, I recently resolved to write down more of what we’ve learned, and then Ada Chen from Mochi asked if I would be willing to write this. So here we are.

Tim and I started Gabob originally while working on an online tool for board games and other tabletop games. The path that led from that to being a profitable game studio was intense, and I hope we won’t have to do something like that again. We have learned a lot from the journey, and hopefully some of the things in this article will help make your journey shorter and/or smoother.

Overview

When we first started Now Boarding, it was called Turbulence, and it was just going to be a simple Flash game. Our plan was to get it sponsored for a chunk of cash, make another one, and repeat. As we were shopping for a sponsor, we met Matt Spall from Gimme5Games, and he suggested we consider making a casual downloadable game. We wrote up a design doc for an expanded version, Tim recruited a friend to do some art mock-ups, and then Tim started shopping for a publisher to fund the game. We ended up getting 2 offers from publishers to fund development of a casual downloadable game in exchange for 50% of the profits. The offers differed in how much money would be advanced and in how quickly the company could move on it. We went with the one that could pay us immediately, because we were at the end of our cash.

Having previous experience with swf2exe tools, we figured we could make the game in Flash and still sell through download portals. Our primary reason at that point was that Flash is such a productive, rapid development environment. That choice turned out to have a significant impact on the project, for good and bad, that I’ll talk about in more detail below.

We figured it would take us 6 months to make the expanded, downloadable version, and the company we were working with was going to pay us 1/6 of the advance each month until the game was done. When the 5th payment had been overdue a couple weeks, they finally told us they were cancelling the project. They weren’t going to pay us any more, but we retained full ownership of the game. So if we could figure out how to pay the bills while we finished the game, we would make more money than we planned.

Tim contacted Matt again, and he offered us a sponsorship on the original Flash version. That gave us another 2 months to finish the download version. It wasn’t enough time, but we had to release it, so we did. Our site promised that version 1.1 would come out soon with a bunch more cool content at which time the price would go from $14.99 to $19.99, “so get it cheap while you can.” That kinda thing (more on this below).

We put an ad for the “full version” in the Flash version that had been sponsored, and we shared a small percentage of sales revenue with Gimme5. We released 1.1 about a month later, for a total development cycle of 9 months. We made a new web demo based on the download version’s code base and art and released it about 3 months after that, and that’s when sales really took off. We haven’t given ourselves raises yet, but we have several months’ worth of money in the bank in case sales drop. So far, the game has continued to sell more than we need to survive, so we’re profitable and free to make more games.

What went right

During the development process, many unexpected things happened. We had no idea when we went into it that things would turn out the way they did. Most of the unexpected things turned out to be good, even if they were short-term headaches (like being dropped by the company funding development). Most of what went right and wrong concerned our choice of platform, Flash.

1. We used Flash

Flash really is a productive environment to work in. It’s easy to create the visual elements of the game and write script to link them all together and make them work. I wrote the original game in ActionScript 2.0, and we used Flash 8 to build the game. By the time we started working on the download version, Flash 9 and AS3 were available, so we used those. After several years of working in C++ and a few years working in C#, I must confess that I really like AS3. I think it’s a lot of fun to work with. Adobe’s development tools aren’t nearly as good as Microsoft’s, but I like the language quite a bit. We made NB in 9 months with 2 people working full time and 1 working part-time.

Using Flash enabled us to have a web demo and a download version using the same code base. For a team with limited resources, one code base is essential. Most indie developers give up the web demo, because they’d have to rewrite the game. The web demo enabled us to leverage the existing Flash distribution network to put our game in front of people. We’ve experimented with buying a couple ads here and there, but those collectively didn’t get us more than a few sales. Almost all sales have come from the web demo virally spreading around Flash portals, and they continue even now, more than a year later.

Using Flash also got us Mac and Linux support for free. While Mac and Linux sales together are only 19% of our total sales, what developer wouldn’t want to increase sales by almost 25%? Our Mac conversion rate is also twice what our Windows rate is. Supporting other platforms isn’t worth the effort for most developers, because they would have to rewrite the game, just as with a web demo.

2. We made a downloadable version

One challenge for the Flash game industry right now is the general player perception that browser games should be free. Historically, “serious” developers didn’t develop Flash games, and so browser games were short games that weren’t worth paying for. A year ago, all efforts we knew about (other than the micro-trans MMO’s) to get players to pay for games they play in a browser did poorly. This is changing right now, which is exciting for developers, but there’s still a lot of entrenched expectation for free in the Flash industry. By offering a download, players get the feeling of ownership and value that they typically associate with downloadable games.

Most players don’t understand the underlying technology anyway. They say, “Flash games should be free”, but what they mean is, “Browser games should be free.” I think that’s why Instant Action failed, and why Adobe AIR is allowing developers like us to sell Flash games.  Since this is changing, browser-based payments (like MochiCoins) will likely become more and more acceptable to players.

Whether a game is downloadable or browser-based, no one will is going to pay money for it unless it has enough content to justify the purchase.  The original web game had the basic pick-up-and-deliver gameplay and offered two game modes (challenge and survival), but only had 1 map.  This is what we added to make the expanded version:

• More aircraft with some special abilities
• Several more maps
• Employees
• A career game mode (common in the casual market)
• Passengers walk around terminal and visit shops and sit in seats
• The terminal can be upgraded and customized to help passengers wait more happily
• Much better art and music
• Many achievements and stats

3. We made our own payment processing system

If we wrote our game in C++, we likely would have used something like BMT Micro to process our payments. Since we didn’t, we couldn’t. Rolling our own was really the only option we had, but it has turned out to have several advantages.

First, we have real-time access to sales data. There are other services that do, but not all. This is more “nice” than “critical,” but it is nice.

Second, we have control over price. Our original intent was to sell through casual download portals, and we would have had to give this up. Because we didn’t, we’ve been able to experiment on finding the optimal price for our game. We’ve tried lowering it and raising it to see if our revenue was affected. We launched at $14.99, went up to $16.99, dropped to $12.99 and even to $9.99. We’ve since gone back up to $14.99, because the lower prices actually decreased our conversion rate, and they would have had to increase it significantly to make up for the lower price just in order to break even.

There’s been a lot of controversy in the casual game industry over price. Not all games are the same, and so they shouldn’t all be lumped together at one price point. In particular, clones have to be cheap, but games that are innovative can be more, because there’s more perceived value there. Players are less price sensitive when they get really hooked on a game, and they’re more likely to get really hooked on something new. They’ll still buy every hidden object game that gets released, but the honey moon is over, and price matters.

Third, we keep a larger chunk of the revenue. We use PayPal for accepting payments. They take about 5%. There’s a reason PayPal is huge: they only take 5%. The lower the cut, the more attractive the service is to vendors. On top of that, some of the larger portals that posted our game wanted 35% of sales from their site. We implemented a simple tracking mechanism to make that possible. It’s not uncommon for indie developers to spend that much on marketing, and that’s really what portals are doing for us.

At the time we released NB, there weren’t payment services like Mochi Coins available.  Mochi Coins provides the first and second benefits of doing your own I listed above.  It is much better than download portals for the third item.  It’s primary advantage over doing your own is that it saves you the hassle.  That is far from a comprehensive treatment of Mochi Coins, but we are trying it out in our latest game to see how it works for us.  Our net income with NB is 60% of sales (Paypal’s 5% + Portals’ 35% = 40% to other parties).  One of the things we’re still waiting on is to see how Mochi Coins does with portals.  With MC, they have a chance to get up to 20% (if I understand it correctly), whereas they get 35% working with us directly. (The interested reader may read more on my blog about my thoughts on Mochi Coins and portals.)

Along with the payment system, we created our own DRM solution that requires payment to unlock all the features of the AIR version.  It’s a simple system that uses AIR’s Encrypted Local Storage, some md5 hashes, and a few database tables on our server.  The details of the payment processing and DRM stuff we implemented is beyond the scope of this article, but I’ll post more technical details of that on my blog in the near future.

What went wrong

1. We used Flash

Using Flash limited our distribution options after all. The swf2exe tool we originally planned on using didn’t end up working. It crashed randomly. We tried others, and they had similar stability issues. So we tried AIR, which was pretty new at the time. It was stable and performed better than the swf2exe executables. We bought an air2exe tool so we could still use submit to download portals, but it actually turned out not to work with any portal DRM we tried. Our original plan to sell the game through download portals came crashing down.

However, even before we found out our game wouldn’t work with download portals, we were having second thoughts about using them anyway. Not going with portals, we retained control, increased the long tail of our income, and we did not support portals who take ridiculous cuts (some portals take up to 80% of revenue). Seeing what has happened over the last year in the casual game market, we’re very glad we’re not involved in that.

If you want to go with download portals, stay away from Flash.

We also ran into bugs with Adobe’s tools that cost us many extra days of development time to work around. Now that we’ve learned our lessons, we don’t have problems with these things anymore. Adobe’s tools are powerful, but they are bloated and slow. They’re also expensive, but I wouldn’t want to try making a game with only the Flex SDK. To my knowledge, Flex Builder 3 has the only AS3 profiler out there. That alone makes it a must-have $699 tool.

Some of our players have occasionally run into hardware and OS issues with AIR. We have no control over those. Really though, that’s the nature of PC development. No game runs on all platforms and hardware configurations. But it would be nice if we could fix some of the simpler things that have come up. That said, letting Adobe handle those nitty-gritty details makes a lot of sense for small teams like us who would rather spend their time making games. A couple times, we’ve just had to apologize and issue a refund.

We also ran into performance issues. NB has a lot of objects moving around the screen at once, and I wasn’t aware of techniques to optimize rendering performance before I wrote the code. On low-end machines, the game gets quite laggy in the later stages of levels when the player has a dozen airplanes flying around and hundreds of passengers in a month. A DirectX game wouldn’t have any problem rendering that stuff. (One of the benefits of the profiler is that it told me where the game was spending its time executing. That’s how I knew it was rendering.)

Compared to DirectX, Flash is also greatly limited in the visual effects that can be displayed. Despite the drawbacks, we continue to use Flash, and we do recommend it to other developers.

Fast development + Cross platform (browser, Mac, Linux) > Limited visuals + Performance overhead

For games the size of most indie projects, Flash works great. There’s no reason not to take advantage of an easy web demo, cross platform support, and rapid development tools.

2. Poor QA

Tim and I are both terrible testers. We hate it, we forget about it, we do a crappy job when we do it, and sometimes we assume the other will do it. The reason we found out about the stability issues of the first swf2exe tool we used is because our first few customers reported it. We built the exe, tested it a little bit, found no problems, and released it. That was embarrassing. However, we would go on to release at least 2-3 major bugs in the next few months. These are bugs that we would have found if we took the time to test the game a little more, bugs that took only a few minutes to fix once we found out about them.

This is one of those things that every developer knows should be done. Being entrepreneurs requires us to wear many hats. Coming from a software engineering background, I’m used to focusing on programming, which is what I enjoy most. But sometimes I have to sit down with a checklist and run through the game, and it’s an exercise of tremendous will power that leaves me on the verge of suicide.

Sales

A web demo is a fast, easy, low-barrier method for players to experience your game.  But for some, that still requires too much effort.  Tim made a demo video that we have on the landing page of our game’s web site.  A video requires no effort on the prospective customer’s part.  The other advantage of a video is that you can show specific footage that really demonstrates your game’s strengths, to quickly show the player why he should play your game.  But the video has only 31,000 views, which isn’t surprising considering that the vast majority of visitors to our site have already played the web demo.  The video is cool, and it’s probably great for people who come to our site without having already played the game, but the web demo is way more important. (BTW, Tim made the video with Microsoft’s free capture software and then edited it in Pinnacle Studio.)

As a player, I never buy games that I can’t try first.  There are too many crappy games out there to risk it.  Even games that are popular often don’t appeal to me either (e.g. I’d rather spend 4 hours mowing my lawn than play WoW for 1 hour).  Everyone’s different, and the only way anyone can know if your game is one they will be happy with is to play it.  My rule for how much to give away in a demo is: give away enough for the player to get a correct perception of value.  If the player doesn’t get enough to really experience how awesome the game is, then you’re losing a sale.  If the full version delivers less than the player expects, the player regrets the purchase (lost customer, potentially lost money, poor recommendation to friends, etc.).

What demo is best for any given game will depend on the game and will require testing to optimize it.  We haven’t done that testing with NB, so it’s entirely possible that there is a more effective demo possible.  That kind of thing is a lot less exciting for us than working on another game, but we should consider it at least with future projects, if not with NB itself.  Probably the most common feedback we get from players (in varying degrees of eloquence and vulgarity) is that they wish the full version were free.  Maybe that means the demo is good enough?

As mentioned above, we had to release NB before we finished everything we wanted to put in it.  Since then, we’ve heard of other studios doing that formally as part of their strategy for funding development.  Here’s a screen shot of our original sales page on our site:

We got about 800 sales from that page.  We shipped 1.1 at the end of September 2008, and sales in October were about half of September’s.  How much the “get it now and save” pitch contributed to that we don’t know.  We made several press releases and got some other attention that also contributed to August’s sales.  The challenge of the internet is how not to get lost so quickly.

Some Numbers

As of October 1, 2009, we’ve sold about 10500 copies of the game. As mentioned, almost all of those have come from Flash portals. We actually haven’t gotten on most of the big sites. We’ve written some fat checks to a couple portals in particular, and I’m surprised more of them don’t want that. (If you want an affiliate deal for your site, just let us know.)

Here’s a graph of our sales over the last year. We released the game on July 29, 2008, so there were only 6 sales that month. Our sales in 2008 were driven primarily by the original web game sponsored by Gimme5.  We launched the new web demo and got it on a couple large sites at the beginning of January 2009. Once we got bumped off the front pages of those sites, sale plummeted.  The new demo got onto sites that the original web version didn’t.  The original version did quite well for a browser-based game, but the new demo was prettier and had more content (not just download content, but also free content in the demo).  We didn’t do anything to track sales from the new version separately so we could compare performance once both were “in the wild” (which in hindsight seems obvious).  All we know is the higher-quality demo definitely got better distribution.

Things are tapering off, but we have some new updates to the web demo that we’ll release in a few months to stoke the fire a bit, maybe get another round of front page traffic on portals. We don’t know how long the tail will be, but if it follows that trend, we’ll keep getting revenue for a while. The last 4 months have been viral distribution only. For example, recently we got on an Italian Flash portal, and we’ve had many sales from Italian folks in a the last week or so. 39% of our customers overall are outside the US.

Conclusion

10000 sales isn’t huge, but it’s enough to support a couple of full-time developers long enough to get another game out. We’re making enough money to continue to make games, and that is what’s most important to us.  We agree with Walt Disney (only for games instead of movies): “We don’t make movies to make money. We make money to make more movies.”

We didn’t know what we were doing when we first started work on NB, and we envisioned the project working out differently. Things happened, we ran into walls, we figured things out, and everything turned out well in the end. It was rather painful, but it’s been extremely rewarding. Waking up in the morning to do what we want is worth the sacrifice it has taken to get here.

Did you enjoy this post?  Get more by subscribing to MochiLand and following @mochimedia on Twitter!