Risk Assesment: Don’t Put All Your Games In One Market

Owen Goss, the owner of Streaming Colour Studios released a great article about his iPhone App Store experience that has been sweeping the Indie blogosphere. If you have not read the post, you really need to do it right now, but the gist is that Owen invested $32,000 in Dapple, a color matching game, that has returned only a couple hundred dollars in the first few weeks of release. Owen’s post was awesome. He was not whining. He was just putting out a data point for the community to digest, and I, for one, appreciate his honesty.

A day after the release, the article was picked up by Slashdot, and Owen wrote a follow up article describing the responses he has gotten. Here is an excerpt:

Perception of whining or quitting

Many people perceived my post as whining about my sales, or that I was giving up on the game. This couldn’t be further from the truth. The post was meant purely as informational. I thought it would help people to see that selling an app on the App Store is just like selling any other product: it takes a lot of work and you shouldn’t expect to be an overnight success. I am also not giving up on Dapple; far from it. I’m only just getting started with it. That post was only a single data point on what I hope is a long upward trend for the game. Every game, every company starts somewhere, and I wanted to document where that was for me.

Don't put all of your eggs in one basket, or your games in one market either.

Don't put all of your eggs in one basket, or your games in one market either.


The observation that I would like to make is that it would be great if Owen’s work could be leveraged across multiple platforms. I think Dapple looks like a game that would work in the casual portals, on Facebook, and in the Flash market. Adding all of those revenue streams together may not have made the game profitable, but it could lessen the blow, and who knows, maybe activity in one market will lead to recognition in another market.

This is the strategy we are taking with our Push Button Labs game, Grunts: Skirmish, and a strategy that I am seeing a lot of developers talk about. We will be counting on a lot of activity in the Flash market to drive sales in the other markets. If hundreds of thousands or even millions of people play our game on the Flash version, it will drive traffic to our site so we can potentially upsell them on our High Definition or heavy client versions, or eventually on microtransactions or even subscriptions. Imagine what you would have to pay in advertising dollars to get that kind of exposure, but the cool thing is, we will get PAID to release the Flash version.

Some developers only want to focus on a single platform. As an example, Jeremy Alessi, a frequent commenter on MBG, is just about to release his third game on the iPhone. He is happy with this strategy, and does not want to take the time to develop tools or processes to put the game anywhere else. As always, the best thing about being an Indie is that you have the freedom to do what you want. However, it is my firm belief, as an Indie, that spreading risk around is the best path to success.

I don’t want to turn this blog into a big advertisement, but I do need to mention that our open source Flash based Push Button Engine is the basis of how we are going to be bringing our games to multiple markets. It is currently in closed Beta, but we hope to announce the Open Beta before GDC.

-Jeff Tunnell, Game Maker
Make It Big In Games
Follow me on Twitter
Photo by woodleywonderworks

  • http://blog.IgenOukan.com Steven Egan

    I for one am looking forward to the Push Button Engine. I'm not versed in Flash, nor do I have the time I'd like to put into it right now, so a free engine to give a head start in the process sounds great.

    When investing the usual advice seems to be to do just as you said, “spreading the risk around”. So, it makes sense in the business of video games to do the same. Another few things to add is that if you can make a simple demo you can probably make a bigger version, have a demo most people can play and might find a better platform for your next project.

    One last thing: It would be interesting to see if the results of the Push Button Engine could be used in other flash projects like Metaplace, a flash based virtual world program/project. I'm wondering because of another blog post I read that talked about Metaplace. http://learninggames.wordpress.com/2009/03/12/u

  • http://www.thestillofthenightcausesastorminthemind.com Jeremy Alessi

    Ouch, I just read Owen's article. With $32,000 to spend it seems like he had the resources to take the broad approach.

    My take on his circumstance is that he spent too much time and money on the project, the game is too expensive, and the game is puzzle game (with little wiggle room for other categories) which means that he's competing in the most high competition space on the App Store. He should have developed this game in a single month and tested the waters at $0.99. More than likely he would not have found success though due to the steep odds associated with a match-3 puzzler (whether it contains micro innovations or not, it looks like a straight up match-3). This sort of game is what you should use as a first project just to get your feet wet. Owen went head first into the deep end.

    As a side note, I definitely feel for him though. As such I talked to Arnold Kim at TouchArcade and he's thinking of giving the lite version some coverage.

  • http://www.flashgamesretreat.com Leroy Frederick

    Well, Owen's certainly getting a lot of coverage (some would say for all the wrong reasons) but it's better then none and if he takes advantage of it in some way he should be able to boast sells! By how much, I don't know…

    http://www.escapistmagazine.com/news/view/90154

  • aschearer

    I'm looking forward to the engine, too. I am curious how do you manage a flash file between multiple authors? I'm finding it to be a complete pain to manage changes between users as the file seems to be a black box — clobbering it each time is a pretty crappy way to go!

  • http://www.andrewrussellstudios.com/ Andrew Russell

    Indie Startup Lesson #1: Don't spend too much time
    Indie Startup Lesson #2: Don't spend too much money

    I've screwed up number one. I would have probably screwed up number two if I had any to do it with.

    I think lots of aspiring game developers get these wrong. Perhaps it's because we're generally pretty terrific at what we do (usually: programming) and we think “hey the business stuff can't be all that hard”.

    It looks like Owen is in the process of learning these lessons now. Hopefully he's still got enough “juice” left in him to keep rolling afterwards.

    (I think I have Lessons 1 and 2 hacked. I'm still working on “the business stuff” – check out my website.)

    @ Jeff: While I think this blog entry is a neat way of plugging your engine – as you say – I think that chances are a cross-platform approach would not have saved Owen.

    I myself wonder if, given the choice between having another basket in the form of “another platform” and another basket as “another game” ideally in “another genre”, which has the best risk/cost/reward ratio. Without the benefit of a fancy engine (like, say, yours), I'd be inclined to put my eggs in the different-game basket.

    Cheers,
    - Andrew Russell

    • http://www.makeitbigingames.com Jeff Tunnell

      I think it is a lot more work to come up with a new idea than to get your old idea out to as many platforms as possible. Ideally, I would look for diversification across both platforms and games. In my articles about starting game companies, I advocate building a portfolio of products that each bring in a small amount of “annuity” type revenue. A bunch of small streams of income is a better source than one large one, and making sure the risk is spread among IP's and platforms is the best.

      • http://www.flashgamesretreat.com Leroy Frederick

        A guess it's a bit like putting all your dominoes (sales streams, products, platforms) side by side rather then closely behind each other. If one falls, everything doesn't go along with it! :)

  • http://www.flashgamesretreat.com Leroy Frederick

    How to be a successful iPhone game developer:
    http://www.guardian.co.uk/technology/gamesblog/

    • http://www.makeitbigingames.com Jeff Tunnell

      The Pangaea guys have been working hard for a long time to finally be in the right place at the right time. Congrats to them on the success of Enigmo selling 810,000 units. I hope their success on this one product turns into success on their follow up products. A lot of my base assumptions for building a successful company are based on this being true.

  • Ori Cohen

    at 4.99$ the price is too high for people to try it, even if its cheap compared to other platforms the fact remains that people consider 4.99 to be somewhat at the 50$ zone.
    where 2$ is probably 19.99$ which is the “i dont have anything to lose by buying this game

  • http://www.houen.net/blog Houen

    Looking very much forward to the beta on the engine! I am currently starting on my own, but look forward to putting my time where it belongs instead – the game dev! No reason to reinvent the plate (or fire)

  • http://blog.IgenOukan.com Steven Egan

    I just read a post over at Lost Garden. First I was disappointed with the focus on flash for the graphics, but then I remembered the Push Button Engine. It might be cool to get the graphics Dan C. has made/is making with Engine. Just a thought.

    • http://www.makeitbigingames.com Jeff Tunnell

      Dan Cook's freely available graphics are awesome! People should be able to have a lot of fun combining his graphics with the PushButton Engine.

  • http://www.thestillofthenightcausesastorminthemind.com Jeremy Alessi

    That PBE page looks intriguing. I like the buy & sell components page. If this is made simple enough it could be a great way to monetize a developer's time even if they don't make a hit game.

    One thing I want to hear more about is the business plan for these broad games. If you start with a free flash game will Mochi Ads ( $0.35 CPM) be your only form of revenue initially? How long do you think people should spend developing that freebie. What numbers justify a heavy client and how much should that cost. Do you recommend creating the iPhone client and free client simultaneously and does the strategy revolve around a light client on the PC and iPhone for example or would the iPhone be considered a heavy client?

    Obviously, people can do whatever they want. I want to know your take on the situation personally though. If you had a $500 – $1,000 game budget (assume you already have the tools) how would you execute a PBE project? How could you make that back in the first day or first week?

    • http://www.makeitbigingames.com Jeff Tunnell

      I think that trying to get pay back in the first week of release of your game is the wrong way to look at things.

      If you have followed my advice of finding like minded people to team up with you to make games, then you don't really have a budget. You have a programmer and an artist that are both part of a team. If you need to make a living, you should have some form of steady income “day job” that will pay the bills while trying to build up your multiple streams of game income.

      I certainly don't have exact answers to any of these questions. My advice all comes down to my ways of combating falling prices and rising competition. It is very difficult to put actual numbers to these types of ideas. I do think that a budget of $500-1,000 is way too low. I can't imagine making something good enough for people to pay for with that kind of a budget.

      I would always release the free version first and try to find an audience, the figure out how to convert a small part of that audience to paying for something. In our case, we will have a free version and a for pay High Definition version (as well as some other bells and whistles, but you will have to wait to see all of it). The free versions are your marketing.