Immigration Jam Post Mortem

This past weekend was the Boston Immigration Game Jam, and like previous Jams, I'm going to do a quick post mortem about my experiences, not only because I think it will help others, but because it will help me as I prepare for my next game jam. For this Jam I was in a team of 5 on day one, which included 3 musicians, which later went down to 4 when two of the musicians decided to not show up for day 2 and one new programmer joined the team.

The game we ended up making was called "Cultural Exchange" and was supposed to be about managing a country, trying to attract the "right" sort of people while keeping out undesirables. To do this, you would enact legislation to make your country more appealing to some people, and erect fences and the like to keep out undesirables. However, people in the country wouldn't like things being too restrictive, since they value their freedom, so it was a constant balancing act.

Now I know normally I start with what went right at the jam, but this time I feel what went wrong is more important. So here we go:

What Went Wrong

  1. Not having a clear idea: While the description is fairly clear, neither me nor Kevin had any idea how we were going to get it working. We didn't actually get anything designed until very late in the night, and even that was just kind of border-line. Since we didn't have a clear idea about how the game would play, we had no idea what our restrictions were.
  2. Using Flixel: Now, no offense to Flixel, but I was not impressed with my first outing with it. This is partially linked to not having a clear idea of what we wanted to do, and not having a clear understanding of the limitations of Flixel. I spent 90% of the first day fighting with ActionScript and Flixel, not only because I didn't understand Flixel's limitations, but because Flixel has some issues with transparency, some of which it inherits from Flash. I spent at least 3 hours trying to move some buttons off screen, only to throw up my hands in frustration. In addition, we were using FlashDevelop, which does not have a debugger included for Flash, which made dealing with all the problems that much worse.

    I took 3 learning points out of my Flixel experience, which don't actually relate to Flixel at all:

    1. Always use something you're familiar with for a game jam, even if it's not the best tool for the job.
    2. Constrain your idea to what you know is possible in the tool you're working with.
    3. Do not take platform into account. If you really like your game after the game jam, you can always port it to a different platform.
  3. Too big a scope: Out game had way to big a scope for our time frame. There was just no way it was getting done.

What Went Right

  1. Switching to AngelXNA: At about 10 on Saturday, I switched all of our code from ActionScript to C#, and all of our Flixel code to AngelXNA. I was too pissed with Flixel's limitations to deal with learning how to get around them, whereas I knew the limitations of Angel really really well, and I could get around them very quickly (see point 3a). Even though this meant losing a programmer on the project, it still ended up well (see the next point).If nothing else, Angel, I've realized, is EXTREMELY transparent. I find pretty much everything does what you'd expect. That said, getting started up in Angel is hard, and I do need to do some tutorials for it in the near future.
  2. Having a dedicated designer: The second day, Kevin ended up doing only design. This was the ONLY way we actually were able to finish at all. Kevin ran through turns on paper, and looked into how legislations would affect the population on each turn. Looking back at other Jams, I think we could have done better if we'd had someone we dedicated as "designer" to look into these problems earlier, rather than playing it by ear the whole time.

Generally this was a short Jam, and I went into it already tired, so I wasn't super psyched about it. But I think I learned a little bit more about jamming, and some things I really want to add to Angel for the next jam, so keep an eye out for that.

My Favorite XBLIG Games

Something that bothers me about XBLIG is that too few good games get the spotlight. For some reason, some really good games get passed over in favor of games like "Z0MBIES" (which anyone who knows me knows I'm not a huge fan of) and "Missile Escape." The front channel even advertises crap games like "Try Not To Fart." And this angers me. These games aren't interesting. In many cases, they're one off jokes, and they don't interest me in the slightest.

So, I'm going to quickly go over some XBLIG games that I have enjoyed a lot and have been passed over in Top Rated and in the news.


Lumi is actually the reason I'm writing this post, as I feel as it's being completely overlooked and underrated.  The first thing that stuck me about Lumi is that it's really pretty. The second thing that struck me is that it has a really interesting movement mechanic which makes up most (not all) of the gameplay. You move by attaching yourself to spinning disks, and then launching yourself out. You're attracted to disks by using the same color (one of the triggers) and repelled by using the opposite. You move around like this, collecting fireflies to relight the world, attacking evil bosses along the way.

The only reason that I feel that Lumi is anything short of a 5 star game (it's certainly better than "Missile Escape") is that people are rating it low because it has the highest price point available on XBLIG. But I've played Arcade games less pretty, less polished, and more frustrating than Lumi. I feel like it deserves a bit more recognition.

Ninja Bros

Ninja Bros was recommended to me by friend and former colleague Darius, and it's actually really awesome. The gameplay is simple: you have a ninja that you can move around, and he jumps with a given button. Get him to the exit. What makes the game interesting is when you're controlling multiple ninjas. Each of them is controlled by the same thumbstick, but each has a separate jump button. In harder levels, you have to coordinate each ninja, when they jump and when they move, to try to get everyone to the exit in a reasonable about of time.

The game is surprisingly complex for something so simple, and it gets to be very hard. It's definitely worth paying for and playing through.

Miner Dig Deep and Soul Caster

Both of these games are on the Top Rated, so I won't take too much time going over them.

Miner Dig Deep isn't that interesting except in its polish. The game is the definition of grind, but it does it very well, and thus deserves a mention.

Soul Caster is an interesting twist on the RPG / Tower Defense genre. I hate tower defense games, but I enjoyed Soul Caster, which is saying something.


What to others think? What XBLIG games aren't getting their fare share? Have I missed something I actually might enjoy?

Jamming Post Mortem 2010 Edition

Last weekend, I took part in the Global Game Jam, like I did last year and let me say it was just as fun, if not MORE fun this year than last. Our game, Quest for Stick, was really, really awesome this year, and you can learn more about it from the GGJ page and from our Twitter account. We even have a video of a complete play through of the game. The game is super pretty, only a little bit buggy, and generally I think accomplished everything we wanted.

But this year I went in knowing what to expect. How'd I do this year? What did I learn?

What Went Right

  1. The Team. Last year, I said one of the things that went right was having a team. This year, that was even more so. We had a total of 7 people working full time on the game, which, initially, I thought was way too many. So much so that I actually asked people to leave the team and considered leaving the team myself to reduce the number of people. But, when it came down to it, I decided I wanted to work on the game idea and went with the other 6 people to create the game. Honestly, 7 people may still have been too many, as communication and tasking did get hard near the end of the project, but there's no way the game would have been anything near what it was if we didn't have at least that many people. Everyone was basically tasked the whole time, and the game came out great because of it.
  2. Getting Down To Business: We spent very little time talking design this time, which worked out to our advantage. Although we spent a lot of time later arguing about how exactly the game was going to play, it didn't take away from everyone working, which was good. We got down to making something playable quickly, and didn't try to design too much stuff up front.
  3. Tools choice: Last year, I was super happy with XNA. This year, the team used AngelXNA, even though I was the only one familiar at all with it, and I was the really the only one well versed in XNA. Even though I spent a lot of time helping people understand Angel / XNA, it was still, by far, better than attempting to use only XNA. It performed a lot of the heavy lifting for us in terms of doing animations, placing and managing actors, and, surprisingly, editing levels, though this is its own bullet point.

What Went Wrong

  1. Unclear tasking: Occasionally, we got duplicated work or weird moments of down time because, like most game jams, people just shouted out things they needed. Kate was really the only person keeping track of most of these tasks, and really only for herself. For the artists, no one was really in charge of knowing what art was still needed and who was doing what. For a team this large, what we needed to create and consult a list on a whiteboard or cork board that had any asset requests, who was potentially doing them, what was in progress and what was up for grabs. This would have avoided duplicated work and would have given us an idea of how much work was left.
  2. Late Playable: Despite my work to prevent this (more on this later), we still didn't end up with an actual playable game until mid day on the last day. Just having *SOMETHING* sometime on Saturday to hand to the artists and designers to make levels on would have helped. We did have lots of pieces that worked, essentially, but didn't get them integrated together fast enough.
  3. Encapsulation problems: We had three programmers working together on individual parts of the game, which helped not only keep them tasked without stomping on each other, but made it so people were in charge of very small systems. However, some of the systems were weirdly encapsulated, and required copying and pasting over when we actually got to the point of integrating. Though this actually ended up *helping* at the very end, I would have liked fewer instances where I had to copy and paste the code from one class to another in order to integrate a new system into the main game.

What Didn't Work

So, these things really didn't go wrong, but they were things I was hoping would help us during the jam, but didn't.

  1. The Simple CI: Before the Jam, I wrote a simple python script that would query a mercurial repository, pull down new code, build it, copy it up to a network location, then message everyone over gchat. This was awesome in theory, but not so much in practice for a few reasons. First, it didn't work so well. If anyone was signed out of gchat when it went to message them, the CI would get stuck in an endless loop. Second, the network drive would occasionally flake out and not be able to take the new build. Third, we didn't have anything the team could play until Sunday, so the CI ended up being useless until then.
  2. The Angel Editor: The editor in Angel was an awesome idea, but when we got to the Jam, it was buggy and untested. It didn't save out things correctly, crashed, spawned items in weird places, and didn't work at all with our custom actors. In addition, the editor saved all levels out to the build directory, which was great for everyone but the people who were using it. Besides fixing the other editor bugs, in the future, the editor will probably need to detect whether a debugger is attached, and figure out where to put the levels from there, or create a custom levels folder that can be easily moved back and forth and through to an integratable build.

All and all, an awesome Jam. Please play Quest for Stick, and let me know what you think. I'm super proud of it.

Is There Money To Be Made?

As I said in my last post, I'm looking at releasing an Xbox Live Indie Game in the next few months. Today, along with Darius, I started doing a little bit of math about indie game numbers, and it's gotten me wondering, can you actually support yourself, and a company, on indie games (indie, in this case, meaning a smallish team experimenting with interesting gameplay concepts and styles). Now, I understand that this whole post, since it deals more with money than passion, may end up alienating me from the indie community, but as a developer I want to see small experimental games flourish, and I want to see those people developing them do well for themselves. This post questions whether or not that's even possible under our current thoughts and models.

We've been seeing recently a number of small game companies really hitting a wall when it comes to funding. Introversion had a post on their blog about their money problems, and Mommy's Best, though still pushing ahead, made it clear that the number's on Weapon of Choice were not good. We've had rants from game players about alternative funding models and suggestions from Gabe Newell about public funding for games. What can we take from all of this? What can we do for funding models?

So this whole thing starts with one piece of information: How many copies of a single game does a developer need to sell per year in order to support themselves? Let's start at a base line of $40k per year for a single developer. This may sound like a lot for indie developers and, let's face it, it really is. But I will tell you it SHOULD be a pretty good base line number, for a lot of reasons, not the least of which include the fact that, in the US, as a single developer, you will be taxed on that both as a business and again as a person. Also take into account health insurance costs and the possibility of supporting any person other than yourself, and $40k starts to sound pretty slim.

Now we need to figure in loss to distributors. Let's ignore distributors with up front cost / approval process (XBLA, PSN, and WiiWare) because even developing for these services usually requires either an already proven game or proven team, and we're assuming neither. This leaves us with iPhone, PC (in various forms, we'll focus on two as you'll see shortly) and Xbox Live Indie Games. For each platform, you need to look at distribution numbers, likely price points, and gross income, meaning the income after your distributor (or whatever) has taken their fair share.


Let's start with the newest (and, for all accounts, sexiest) guy on the block, the iPhone. Most apps on the iPhone sell for $.99 to $3, with Apple taking 30% off the top. In addition, selling on the iPhone is really all about staying new, staying fresh, and staying on top of the most popular list. In order to do that, you need to stay at the lower price points to encourage impulse buys. That means staying at around $.99 for as long as possible. Here are the numbers:

App Price Gross to Dev Number of Sales Needed / developer
$1 $.70 57,000 / year
$2 $1.40 28,500 / year
$3 $2.10 19,000 / year
$5 $3.50 11,400 / year

So at the pretty much standard rate of $1, a single developer needs to push 57 thousand copies of their game per year in order to support themselves, or push multiple applications which can come up to that number. With the number of iPhones on the market somewhere around 6 to 10 million, the question is, how many sales can you except? Mac Rumors reports 4 apps that easily hit almost a million sales, but what's the data like for games? And indie games at that? The most telling post probably comes from the developer of Dapple, who wrote a very long post on how much money he actually made on the product (summary, he has sold a total of about 500 copies). In addition, this post on the price of apps versus their popularity shows very few indie games in the list, Field Runners (essentially an App Store Launch Title) being the notable exception, and very little money being made. Is it possible to be an indie and loved on the App Store? Only indies who have accomplished this can tell you, but 57,000 copies is a really hard number to hit with something interesting or experimental.

Xbox Live Indie Games

So what about Xbox Live Indie Games. Their Gross To Dev numbers are actually exactly the same, though the $2 price point doesn't exist, and the highest amount you can charge is $5. That said, until recently $2.50 was the lowest you could charge, which required about 22,800 copies to be sold per year. Unfortunately, XBLIG sales figures came up very short for most developers. Total download rates are low, as Indie games were hard to find on the dashboard until recently, and good apps are very hard to find, so I believe most people have been ignoring the service entirely. Sales for most games topped at probably around 5,000 copies since launch, far from the required 22 thousand to support a single developer.


Finally we come to PC. On PC, sales numbers small, but you can expect to be able to charge more, though more is expected of a finished product. Games average anywhere from $5 to $30, even from indie developers, and you'd think that, hosting it on your own or through Steam, you'd get more of the pie. Steam unfortunately doesn't publish their numbers, but PayPal does, and we can actually use them as a baseline. Now, we're assuming that you're looking to get above $40,000 here, so we're going to use their range for $10,000 to $100,000, which is 2.2% + .30 per transaction. Here's the numbers:

Game Price Gross to Dev Number of Sales Needed / developer
$5 $4.59 9000 / year
$10 $9.48 4000 / year
$15 $14.37 2800 / year
$20 $19.56 2000 / year
$30 $29.04 1400 / year

Looking at these numbers, it's almost obvious why most successful indie developers start on PC. Even with the PC market shrinking (this talk form GDC shows us that you can expect PC sales numbers in the hundreds of copies, thousands if you're lucky), you get to keep a lot more of your money, and the audience is self selecting. People interested in indie games tend to have PCs and may buy your game. (A note to pirates: Look at those numbers and see how much you're taking from that developer, and the numbers EACH DEVELOPER has to hit before even becoming profitable. That, more than anything, should make you think twice about piracy). Hitting these numbers is possible, but not probable. It's quite obvious, to me, from these numbers why most successful indie devs are one man shops, making fairly quick games. This model doesn't scale to multiple developers, and definitely not for multiple years.

Alternative Funding Models

So what about Gabe's suggestion? Running basically a "stock market" for games where you can invest in projects, get a game out of it, and possibly see a little bit from the net profits off of a game? So far, We've seen a commission system partially go out, and partially work, but what about Gabe's suggestion?

Let's assume that for these systems, we're talking about multi-developer, multi-year projects. Still talking indie, let's say 4 developers over a year and a half, which is pretty reasonable I think. This totals (not taking into account taxes, office space, servers, or anything else) $240,000 that needs to be raised over the course of a year and a half. Though this is potentially possible, we'd have to look at other concerns. If a person invest in this game with a promise of returns on the net profits (after other expenses / taxes), he needs to understand the risks involved. After all, if a game company never hits that $240,000 number, and can't survive long enough to complete the game, that money is lost. Attached to this, is the idea of due diligence. Each investor is now an INVESTOR in your game, and can have possible legal rights to it. If you just take the money and never finish the game, they might be able to sue you. What is there in place to protect both the investor and the investee if this happens?

Now, provided these legal fees could be worked out, how much of net profit would you be looking at loosing, and how much would you charge for each point of net profit? What would developers look to gain, and what would investors look to gain. This post is all about numbers, so here we go.

First, let's start with a game that sells about 20,000 copies at $20 each (we're assuming these are good games that have a following, otherwise they wouldn't have been funded in the first place), on PC using the numbers above. That totals $391,000 revenue on the game, and let's assume (for argument's sake) that we have $41,000 in expenses for the game (to make nice round numbers). That leaves us with $350k net. Assuming we split to always end up with getting the funding we need, here's what the graph looks like:

Percent of Net Available Value for each point Net Total Invested Total Revenue to Investors Total Revenue / point Total Revenue to Developers
70% $3500 $245,000 $245,000 $3,500 $105,000
60% $4000 $240,000 $210,000 $3,500 $110,000
50% $5000 $250,000 $125,000 $2,500 $125,000
30% $8000 $240,000 $105,000 $3,500 $245,000

In general, that's pretty grim. Only in the 70% case do the investors come out just breaking even, and the developers have enough to fund half of their next game. Is it possible? Maybe. But is it worth it for the investors? How many times will an investor loose most of their money from games that aren't finished, or games that don't break 20 to 30 thousand copies before they just kind of give up investing? How much work is required of developers just to set up the legalities to make sure they don't get sued, and their investors don't get screwed?

Another funding model for indie devs is to keep titles relevant from year to year, keeping sales of the title up while you work on the next title, and into your third.  By keeping these games selling, you can start to see actual profits. However, this also means consistently releasing games year after year, and surviving until these games come out. This takes a lot of start up capital, or at least the ability or desire to eat ramen for years on end, with only the smallest chance of reward (from looking at these numbers anyway).


These numbers make it really obvious to me why most indie (and, in some cases non-indie) business models exist, and why they produce the games they produce. To be successful, you need to be in one of a few situations:

  • A single developer that makes a good title (Petri, for example)
  • A single or set of developers with short release cycles to keep multiple games relivant over short periods of time.  (Almost all iPhone developers).
  • A developer that has an already popular game and is able to get on one of the more visible services  like XBLA, PSN, or WiiWare (That Game Company, the Behemoth, 2D boy, Number None)

This is why indie games experiment the way they do.  Shorten the dev cycle, concentrate on mechanics and prototypes, keep art resources and requirements low, release lots of games quickly.  I feel like there needs to be more available.  I'm sure there are indies out there that want to experiment with things that take longer dev cycles, (weird dynamics, involved dynamic art styles, or, god fobid, strange narative structure), but can't for survivability reasons, and that's a damn shame.

So my answer to everything here is, maybe there's not a good living to be made in indie games. Even with alternative money sources, it doesn't look like you can sustain a business, even of small number of developers, without competing for AAA numbers, which seems to have a quality bar that almost requires a AAA team. Obviously, the math for that is wrong somewhere, as we've seen it happen, but is it worth it for me (or anyone else) to attempt the struggle when the reward seems to be mostly just more struggle? Is there an answer I'm possibly missing? Is there money to be made in remaining truely independent, or even survivability?  And if there is, can it be done for more models than what we have now?