The Mysterious World of Game Budgets

Reposted from the Award Winning* Thimbleweed Park Dev Blog. *Awards TBD.

During last week's Thimbleweed Park podcast, I asked Gary and David what scares them the most about the project. I find this a useful exercise to do with the team to see what they are worried about. The answer always changes as the project progresses and new worries come and go.

The common theme from the three of us was the amount of work there is to do. It's daunting. But as I've said several times on this blog, that's normal. I've never not been daunted by the amount of work facing me on any game I've done. If you're not daunted by the amount of work, there's probably something wrong and you need to be pushing harder. Be daunted and push yourself right up to the point of being overwhelmed.

During the podcast I mentioned my concern about money and seeing the bank account go down each month. This was somehow turned into "we're running out of money", which is far from the truth. I am worried about money, anyone running a project should be.

The thing is: I worry about things so they don't become problems, and worrying about money is one of those things. If we didn't worry about money everyday, we would run out of money. It sneaks up on you.

Seeing $500,000 in your bank account can make you cocky. It can seem like an endless supply of cash and more money than most people (including me) have ever seen in their bank account. But you have to treat that $500,000 like it's $5,000 or even $500. Every dollar matters.

It's why I like to have a budget.

It is one of the advantages of having a publisher, they will poke your budget full of holes and challenge your assumptions. The downside is, they will also push your budget down and it's not uncommon for developers to then fake the budget so they get the deal (which their studio is often dependent on to stay alive). It's not malicious, they (and I have done this as well) just convince themselves they can make it for less, and that's often not true.

I want to know where every dollar is being spent from here until the end of the project. You start putting line items into the budget and you instantly see your money starting vanish. A few line items later and you're out of money. It's sobering and a necessary process. It really makes you appreciate spending anything.

We had budgets back at Lucasfilm, but we were very isolated from the gory ramifications of those numbers. I could make a budget and if I went over by 20%, I might get a stern talking to, but it's not like people weren't going to be paid. When you're running your own company and project with your own money and you run out, people don't get paid and they don't like that. In the real world, they stop working.

I do a first pass budget before I start designing. I often know how much money I have and I want to see how many people and how long I have before that money is gone. If I know I have 15 months and can afford 5 people, then that helps me in scoping the design. If I have 24 months and can have 100 people, that's another scope.

Once I've done the preliminary budget, we'll start designing and then enter pre-production, all the while, adjusting the budget as I know more.  When pre-production is done, we can look at the amount of work and do a final budget based on the schedule. Budget and Schedule are two different things that feed into and help refine each other. You can't do one without the other, but they aren't the same thing.

A schedule lists everything you have to make and who is going to make it and when. A budget takes all those people and how much they cost and tells you what the project is going to cost.

Below is the current budget for Thimbleweed Park.  It's what I like to call a living budget. You'll notice that the first monthly column is October, not the beginning of the project. Money spent is "water under the bridge" and is only relevant for historical and educational reasons. What I want to focus my attention on is how much we have and how much we need to spend going forward.

Anyone who has a real background in accounting is probably having spasm right now. There are much better ways to do this, but I'm not an accountant and neither are most indie devs. This is a much simplified way of budgeting and it works for me.

Each month I look at what we spend versus what we expect to spend then make any adjustments to future costs. I then remove the current month column, look at the projected total and the bank balance. If there is more in the bank then we're projected to spend, then we're OK, back to programming and designing.

Let's go through the budget.

First up are the people. Gary and I are working for peanuts (honey roasted). Neither of us can afford to work for free for 18 months and we're making about a quarter of what we could get with "real jobs" but we do need to eat and pay rent.

Everyone else is working below what they could get, but I do think it's important to pay people. I don't feel getting people to work for free ever works out and usually ends badly (and friendships) or you "get what you pay for." The reality is that when someone works for you for free, you aren't their top priority. They may say you are, they may want you to be, but you rarely are and you end up dealing with missed deadlines and hastily done work.

It's important to have team members that can work as professionals and you pay people that are professionals. You should respect people's time and talent and pay them for their work. It's what the Kickstarter money was for after all.

Everyone is budgeted in at 5 days a week and 8 hours a day as we're trying to keep normal hours. I have no doubt these hours will go up towards the end of the project, but I try to never budget crunch time, it's a dangerous precedent. It's a cost we will have to manage down the road, either by hiring someone new, spending for extra time, shifting resources or cutting content. There is enough slop built into the rest of the budget to cover some of this, but I never want ink to paper, because then crunch becomes real.

We do have two additional artists budgeted and yet to be hired. We don't know if we'll need both of them, but I've budgeted them just in case. We might need help with animation and there are also a lot of close-ups (telephones, control panels, bulletin boards, etc) and ancillary screens that aren't on Mark's schedule right now.

There is a line item for an additional writer. We made the decision to go with full Monkey Island style dialogs and I don't feel confident I can get all those done with everything else I need to be doing (like budgeting).

Testers, testers, testers. One of the most important and often forgotten roles in a game. It's money well spent because not testing will cost you down the road in emergency patches, dissatisfied players and crappy review scores. The original budget had 3 testers, but I added a 4th when we added the Xbox. I over budgeted for testing and it's an area that will probably come in under budget (ass, prepare to be bitten).

It's important to distinguish between testing and beta testing as they serve very different functions. The paid testers on a project are there to (primarily) find and help squash bugs. This is a paid role because it's grueling work and, quite frankly, not a lot of people are really good at it. Testers don't just "play the game". They are "testing" the game and that often involves countless hours of playing the same 5 minutes over and over, trying to get an elusive bug to appear. Testers need to write clear and concise bug reports and endlessly regress bugs to make sure they are fixed. It's a hard job. Good testers are worth every penny.

Beta testing is different. Beta testers (an unpaid role) are still finding bugs, but what you're really looking for are big picture issues, like puzzle complexity, game flow and story clarity. You want beta testers to "play" the game like normal players will and get feedback (mostly through silently watching, analytics and debriefs). You want to turn 50 beta testers loose and see where they go and what they do.

Next we come to Music and SFX. Musicians usually charge by the minute, so if you're going to have 15 minutes of unique music and they charge $1000 a minute (not uncommon), then your budget is $15,000. That $1,000/minute includes a lot of exploration and revisions and mixing. If you're saying "Hey, I'll do your music for free" you need to ask yourself if you're willing to spend weeks exploring different styles and tracks while getting constant feedback, then spend months composing it all, then additional months of making little revisions and changes, then producing 3, 4 or 5 flawless mixes. It's a lot of work and all the while, you have to hit deadline after deadline. And this is all for a relatively low budget game.

Next up on our journey through budget land is Translations, Voice Recording and Mobile. I'm kind of rolling the dice on these. I don't have a good idea what these will cost so I've padded the hell out of them and I expect this is where a lot of the slop will come from to fill other leaks. I got bids for voice acting and translation then added 30%. I have no idea on iOS and Android. I just chose a big number. This is where the voodoo of budgeting really plays out. If we had a producer, they would be spending more time nailing these numbers down. I've added enough extra that I feel comfortable.

On to Events. This is for stuff like PAX, Indiecade, E3 and other events we might want to show the game at. All this is really marketing and PR. It's also where we will pull extra money from if we get in trouble down the road. Not showing the game will screw its long term hopes, but not finishing the game is worse. Plus, it's a number we can scale up and down as needed and it's far enough down the road that we'll have better idea of how we're really doing.

Then it's on to the really exciting part of the budget: Legal, Accounting, Software, and the always important Misc. Assuming we don't get sued, these are fairly predictable and fixed expenses, but don't forget them.

And finally, the Kickstarter physical rewards. We have a fixed budget that was based on our final Kickstarter pledge numbers. It's probably around 25% too high, but that gives us some flexibility to make a better boxed copy or use the money elsewhere on the project. Or, we might have estimated wrong.

At the bottom is a total. I look at that each month and look at the bank balance. So far, we're fine. But that's because I worry.

One thing that is not on this spreadsheet is the money that is currently coming in from Humble Bundle and new backers. It's not significant, but it's not inconsequential either. I choose the leave it off the budget calculations because it provides this small margin of error.

We are planning on some new stretch goals in the next few months, and those are also not in the budget because if we don't make the goals, they won't become expenses. If we do, then all the numbers will be adjusted to account for the new work.

It's also possible that we'll move resources around, spend less on an artist and add a programmer. Budgets are living documents.

One thing to note, and I'm sure it will raise some eyebrows, is the monthly burn rate. That's a lot of money to spend each month. No one line item is very large, but they add up and can catch you by surprise. This is a pretty barebones project (but not scrappy) and it still costs $20K-$30K a month. It why when I look at other Kickstarters asking for very little money and they have a three page long team list, I get skeptical.

I hope this was informative. There are a lot of ways to do budgeting and I'm sure there are better ways, but this has always worked for me.

Please be respectful that we're sharing a lot of information with you, not only to be transparent, but also to educate and inform. This is how games are made, they take time, cost money and it's a very messy process.

- Ron Gilbert