Budget Viability

When they're preparing for a pitch, I frequently see independent developers freeze up at the word "budget" - understandably so: not much in game developer is more opaque and less discussed than the financials. Whether because of non-disclosure agreements or because of competitive considerations, very few people are willing to discuss the budgets of their work in a way where new and aspiring developers can research them to learn.

The good news is that in essence, budgeting is very simple. The bad news is that in practice, a lot depends on your budget, and things get a bit more complicated & unpredictable. For this article, we're not going to go into the specifics of a proper budget - we're going to look at how to evaluate the viability of your budget. We're not going to discuss timelines and scheduling -that's for a later LTPF episode- this one will purely be about money.

What is a budget?

If you've ever looked up the definition of budget, it is officially "an estimate of income and expenditure for a set period of time", and I need you to forget that definition immediately - because in games business, value is a bit of a wonky subject, and budget often doesn't actually mean budget.

Think of it this way: a title like Among Us took three developers about 18 months to create. If you were to budget that as "an estimate of expenditure", you could assume a globally average $2,200 salary for independent developers that all own part of the company - so $6,600 per month, so $120,000 for the full project. If you add a 30% safety buffer, you end up at a $160,000 budget. If the exact same team would make another game today, in the exact same time, the budget would end up at millions of dollars. Nothing has changed, besides their value increasing. Their value is a whole bunch of abstract, speculative estimates about potential earnings, reach, and quality.

The most important thing to take away is this: a budget is where you say this is the amount for which we will be able & willing to make something we can convince you is worth (far) more than that.

There are two important parts to that sentence: the first one is the we will be able & willing to make something: a budget needs to communicate competence and consideration. That means your budget needs to be at the very least the amount of money your team requires to develop the game. How do you calculate that? Quite simply by making a list of people that'll work on the game, and then for each of them, writing down how many months they'd work on the game and multiplying that by a reasonable salary. For smaller projects with younger developers, I tend to use anywhere between $1,600 & $2,200 of monthly salary as a default if the team hasn't discussed this yet - but this is really a discussion you should have based on your team's needs to live comfortably - depending on where you live, that default can either be ridiculously high or not nearly enough money.

You might recoil at the number that comes out of that: budgets between $75,000 and $250,000 are incredibly common for small indie teams on their first few projects - while budgets between $750,000 and $2.5 million are common for mid-sized indies with some games under their belt. It is critically important that you resist the urge to get the number down. I cannot stress this enough: the risk of your budget being too high is far less severe than the risk of your budget being too low. Plenty of publishers will negotiate down, or accept the same pitch again in the future for a lower amount - but almost no publisher will negotiate up, or accept the same pitch again for a higher amount. Too high a budget at worst looks arrogant - too low a budget at best looks incompetent.

Too high a budget at worst looks arrogant - too low a budget at best looks incompetent.

The second important part to that sentence is make something we can convince you is worth (far) more than that. Assume that anyone looking to fund your game is going to take your budget, multiply it by three or four, and see whether they think your pitch is realistically going to make that amount of money assuming the game will get their support and audience. This is an incredible generalisation, but in essence it is how investment works - they try to make bets that will likely allow them to fund more than one game.

That leaves a good budget in a particular place: your budget needs to be realistic and you should be able to make people believe in the possibility of a profit of three times the budget. It is not always possible to balance those two - and in that case, you're going to have to take a very hard look at what you're making, and whether your chosen method of funding is appropriate for the game.

One method of balancing these two budgets is a comparative analysis, and for that, I've created a spreadsheet I use a lot in my consultancies. The basic way it works is simple: the red-outlined cells you can fill out. Everything else, you don't touch.

Under Team, write the names (or disciplines) of the people you intend to work with. For each of them, fill out their flat fee, or their monthly salary.

If you're going the salary route, fill out what you're expecting to pay as full-time salary each month and the amount of months they'll be working on the project. If you're expecting people to work less than full-time, fill out the FTE column as well. If you've never heard of the term "FTE" - it means "Full Time Equivalent" - and 1.0 FTE tends to equal 40 hours per week. Assuming 40 hours equals 1.0 FTE (and pays the full-time salary), if someone is working 20 hours on the project per week, fill out 0.5. For 40 hours per month, fill out 0.25 (because that comes out to 10 hours per week).

You'll notice the spreadsheet adds everything up, adds a thirty percent margin, and spits out a budget. That's what you should be asking for at the least. If you're wondering what the margin is: it's for all the things you haven't considered or couldn't predict - including how your studio will survive long enough to reach the next pitch if the game flops.

Next, you're going to fill out the target price for your game. That should immediately spit out the amount of units that need to be sold for the publisher to break even (your budget with an additional 43% on top of it to represent the platform cut). Take a long look at that number: with proper marketing, does your game seem like it'll reach that number of sales?

Comparison

This is where things get a little odd: we actually have no good way of knowing how many units a game has sold. What we do know, thanks to a hunch from independent developer Mike Boxleiter, is that there's a correlation between the number of reviews on a Steam game and the amount of units sold on Steam. We refer to that ratio as the "Boxleiter Number", and every now and then someone in the indie scene will do a call for data and update the Boxleiter Number accordingly. It was most recently updated by Simon Carless, and my estimate is that it sits around approximately 57 units sold per review written.

The spreadsheet should've given you three "target reviews" numbers. Using the Boxleiter Number, I've spaced the three targets out at 70% of the units you need to sell to break even, 25% more than you need to sell, and 3x what you'd need to sell. It is time to head to Steam and find games that are deeply similar to yours in important ways with those numbers of reviews. With "similar" I mean that it doesn't matter how they are deeply similar, nor that you need to be consistent between your three picks. You might be making a vampire-narrative RTS game, in which case it would be totally fine to use a vampire visual novel as one point of comparison, and a sci-fi RTS with some similar mechanics for another.

In each column, find a related game with the indicated amount of reviews on Steam, fill out the name, the base price (so ignoring any sales and discounts), and the actual number of reviews. The spreadsheet will calculate some (extraordinarily optimistic) numbers for sales figures for you to compare to your budget. Quickly check if the middle Sales number indeed is higher than your budget - if not, find another game for the comparison.

Your budget viability can then be assessed as follows:

• Is every single person on your team compensated for their work in such a way that they can complete the project even if some bad things happen in their life, or if the project is extended or delayed by a few months?
• Do you believe that you can convince someone that might fund your game that the revenue of your title could potentially double, triple, or quadruple the budget?
• Can you argue or pitch that your game is undeniably better than the "low" comparison game, competitive with the "middle" comparison game, and potentially a competitor to the "high" comparison game?

If the answer to all three questions is yes, on first glance you've got a viable budget & a solid business case. If the answer is not yes to all three, something in your budget is not checking out: it might be too low or too high, or your game might not be competitive for the costs. Based on what the article, see if you can play around with the numbers to make things check out.

As always, keep in mind that tools aren't truth: they're ways to wrap your head around things that might otherwise be opaque. Use it to inform your options and understanding of the situation, not as the end-all to greenlight projects or make other decisions.

Actionables

• Read Simon Carless' article over at GameDiscoverCo, where he's compiled the most recent update on the Boxleiter Number. It might be worth reading Jake Birkett's original article on it from 2015, too.
• Sit down with your team (or with yourself) and make a genuine inventory of what you would need to live comfortably, assuming an emergency or two might come along in the years you might be working on the game. Don't try to make the number go down to be more appealing, don't try to make it fit some imaginary upper limit. Just take inventory.
• Fill out the 📄Budget Consideration spreadsheet for your current or upcoming project as per the instructions above. You can get your own copy by clicking the link, and then going to File > Make A Copy or Download. Fill it out, then answer the three Viability Questions. Be very honest with yourself here: it'll increase your odds of killing an unrealistic project before it starts to cost you lots of time and money, and it'll decrease your odds of your game getting rejected because the business case makes no sense.