My first game design aspirations were creative, but as my career unfolded I learned that many of my strengths were operational. I’m organized, I’m pretty good with detail-work, and I have an unusual affinity for the process of bringing creative products to market.
I try to do a new presentation each year at the GAMA Trade Show. I like to talk about things that interest me, but I also try to choose topics that will prove genuinely useful, especially to newer creators, designers, and publishers.
It occurred to me this year that a sample game production budget would meet both criteria, and could be presented in the form of a functional document for real-world use. Here it is, with commentary.
What Project Budgets Are
The first principle of budgeting — which you’d think would be obvious, but sort of turns out not to be — is this: A budget is a plan. A budget isn’t cash, isn’t a guarantee, can’t be used to buy groceries. But a budget is a great tool for predicting what’s likely to happen financially.
Doing anything that’s important without a plan is a bad idea, especially if whatever project you’re considering has lots of moving parts and you haven’t done many things like it in the past. Go grocery shopping without a budget — you’ve bought groceries lots of time before. Don’t make a game without making a budget.
Before we go any further, may I grossly over-simplify the general topic of financial reporting? There are two kinds of financial documents. One shows profit and loss over some period of time. (Fancy term alert: This is called a “P & L.”) It records how much revenue came in, how many costs were paid, and how far out of balance those two subtotals were. It’s a document about how much. The other kind of financial report documents cashflow, or on what date each bit of money was collected or spent. Cashflow documents are primarily about when.
With those magnificent simplifications in hand, understand these two things about budgets:
- A project budget is a guess-filled, forward-looking, profit-and-loss document, where the period of time is the duration of the project.
- A project budget says nothing about cashflow. Even with the sparkles-and-magic of Kickstarter, you’re likely to need at least a little bit of actual money before any of your theoretical profit has turned into Earth-monies. A budget doesn’t help you very much with financial issues related to when.
Estimation is the Key Technology of Budgeting
A budget is a plan, so everything in your budget is an estimate. It follows that your budget can never be any better than your estimations. The great news is that it’s possible to train yourself to make better estimates, even about things you don’t know anything about.
(Entirely apart from the question of project budgets, being able to make good estimates about things you know very little about is a killer professional and life skill. Even if you never plan to make a game, teaching yourself to make good estimates is one of the best things you can learn.)
Most of what I know about estimating I learned from (a) practice, and (b) a book called How to Measure Anything (book site, Amazon affiliate link). You should buy it or reserve it at your local library immediately.
This isn’t the place to half-assedly regurgitate what you can learn from How to Measure Anything, but there’s one key insight you’ll need to understand how the budget document works, and it’s this:
Estimates should be ranges, not points. When you make an estimate, it should be a range of values as wide as it needs to be for you to be certain that the actual result will fall within your estimated bounds 90% of the time. Don’t estimate that it’ll take 45 days to edit the manuscript, estimate that it’ll take somewhere between 18 and 120 days. The odds that you’ll be on-to-the-day with a 45-day estimate are ridiculous; you can’t win that game. (Does “18–120 days” seem like an exceptionally broad range? If that’s all the more accurate your 90% confidence interval can be given what you know, a tighter estimate won’t actually help you. It’ll just make your budget — or, in this case, your timeline — a useless sham.)
Here are some things you should be aware of when making estimates. Please keep in mind that this is the barest possible introduction imaginable to a truly critical subject.
- The vast majority of people wildly overestimate their ability to make accurate guesses. When in doubt, assume that you’re overreaching.
- The Equivalent Bet Test is an extremely useful exercise. As suggested above, you should try to estimate ranges where the actual result will be within your range 90% of the time. The Equivalent Bet Test says that if you could win $1,000 by either (a) the actual answer being within your range, or (b) rolling a ten-sided die and having it come up 1–9, and that if you have a preference between winning based on your guess or based on the die, then you’re not actually 90% confident about your range.
- When estimating a range, consider the upper and lower bounds of your range as separate questions. For example, when trying to predict how many backers you might have at a given tier of your crowdfunding campaign, consider the lowest number you might reasonably have, and then consider as a separate question the highest quantity you might reasonably achieve. (Perhaps obviously, to generate a 90% interval using this strategy, you must be 95% confident about each individual boundary.)
- When you think you’ve got a good guess, brainstorm and consider one additional factor that might affect your estimate. Better yet, think of a couple. Considering additional factors increases the accuracy of your estimates.
As regards creative projects, here’s a good rule of thumb: Creative projects tend to cost at least twice as much as your first ballpark guess, and always take three to eight times as long as you think.
Seriously. Ask anyone who’s done it before.
And Now, the Sample Budget
The sample game budget is a Google spreadsheet, so it has a long, gross Google URL. Through the magic of redirection, this much-easier URL redirects there.
jefftidball.com/gamespreadsheet
Open that in another window, maybe, so you can keep following along here while you check it out. You can’t edit that document directly, so to make you own version where you can experiment, choose File > Make a Copy and go to town.
First, three notes about the whole spreadsheet:
- You can change anything in a green cell to any other number that you want. Experiment!
- You can change pretty much anything in Column A, too. These are almost all just labels for the rows, so if a different label makes more sense to you, by all means, switch it up.
- None of the placeholder values are endorsements. The cost on the “cover illustration” line says $1,250. I’ve paid lots more, and lots less, for cover art. That number might or might not be reasonable for your project. (In fact, given the wide range of possible amounts that could be spent on cover art, it’s almost certainly not the right number for your project.)
Those things in hand, let’s go through section-by-section.
First, the Expenses section is about money you’ll have to spend.
Wordcount expenses are most applicable to books, be they novels or roleplaying games. If you’re not making one of those, zero those lines out and move on.
Illustration expenses are straightforward; there’s one line for each kind of illustration you need. The “Page % Each” column and its extension work with the wordcount section, above, to help you calculate the number of pages long your book will be, if you’re making a book, which is important because page count is a number you need to know to get a useful printing quote. If you’re not making a book, zero those out and move on.
The hourly and flat rate expenses section is about how much it will cost to get the creative and producing work done. You’ll estimate a range of hours each kind of task will take (“low estimate” to “high estimate”), and how much you’ll pay for each of those hours.
This section tends to cause panic. People notice that there’s a “playtesting” line and an “hourly rate” cell on that line, and they leap to assumptions. No, I don’t expect that you’ll pay your playtesters; that would be unusual. You can go ahead and zero out the “hourly rate” cell on that line. But I’m not going to do it for you, and the reason is that I want you to spend just a minute on the barest consideration of how much volunteer work your friends are going to do to help you make the thing you’re planning. Contrary to Popular Internet Wisdom, you are not an asshole if you ask people to help you without paying them, unless you fail to appreciate what that means, in which case, yes, you are an asshole. Making you zero that cell out yourself is my way of helping you not be an asshole.
You’ll probably be doing lots of the work described by this section yourself, and you probably won’t be paying yourself. And that’s fine. Zero out any of the hourly rates where that’s the case. Don’t let yourself off the hook by failing to make estimates about how long each category of work is going to take you, though. One of the best ways to improve your ability to make good estimates in the future is to compare past estimates to the way reality actually unfolded.
You’ll probably pay some kinds of work at a flat rate rather than an hourly rate. Graphic design for an entire project is often billed that way, for example. There’s a separate column for flat rate work.
Production expenses are what the factory or printer will charge you to build the physical product. (Assuming that there is a physical product. Is yours digital-only? Zero this out and move on!) Request quotes for three different quantities. The quantities you choose should represent the top and bottom of your 90% confidence interval, and a third number (between those) that you think is the most likely size of your print run.
Other expenses are the unique things your product needs, your special snowflakes.
Contingency is a slush bucket for the things you’re going to need to spend money on that you don’t know about, and can’t foresee. Ten percent is pretty reasonable if you’re new to game production. Vets can push that down to 5%, or lower if deluded.
Next, there are two revenue sections, one for crowdfunding revenue and one for traditional (“post-crowdfunding”) sales.
Crowdfunding revenue assumes six backer tiers; create more rows in this section as needed. Each line includes low and high estimates for backers at that tier. “Add’l Expense Per” is a place to account for expenses unique to that tier, such as the cost of printing a t-shirt or bumper sticker per backer. “Stock Use Per” is the number of games (or whatever) you’ll send to each backer at that level. Stock use doesn’t apply to digital-only backers, obviously.
There’s an expense lurking beneath the crowdfunding revenue block, for royalties to creators (or whoever — it’s also useful for calculating fees to the platform and credit card prcoessor) that are based on the gross campaign take. It could have gone up in the expenses section, but since it’s tied to a concrete revenue line, I thought it made more sense to put it here.
Post-crowdfunding revenue is broken down into rows for different sales venues like Amazon, your web store, traditional distribution-to-retail, and so on. Each venue can have a different retail price (because your print-and-play edition will probably cost less than your boxed game) and a different discount off of the retail price. The “% of Sales” area is the proportion of your overall sales, in units, that you think this row will represent. If, for every 100 sales, you think ten of them will be through your web store, that line should read “10%.”
In the unit sales by venue section, you can create seven different sales scenarios to span your 90% confidence interval about how many units you’ll move.
After another lurking expense section, this one for royalties on post-crowdfund revenue, there’s — finally! — a table of profit and loss. These are your best- and worse-case scenarios, by print run, per sales scenario. Best- and worst-case scenarios arise from your low and high estimates of hourly expenses, and your high and low crowdfunding estimates, respectively.
Three Warnings
Beware impossible scenarios. This spreadsheet doesn’t eliminate the possibility that your plan rests on selling more games than you actually printed. As with the driving directions your phone provides, always sanity-check what the spreadsheet says before driving off a cliff.
Beware massive overprinting. You can’t lose money on every sale but make a profit due to volume. Your skill at estimating things it’s impossible to know — seriously, read How to Measure Anything — will be a huge help in figuring out how many copies of a game it’s reasonable to imagine selling.
Beware the Excel Three-Column Fantasy. This is a state of delusion you can engender by putting the budgetary answer you really want to see in between two other budgetary possibilities that are complete nonsense, one of which is optimistic and one of which is pessimistic. Just because you can describe in writing both a spectacular scenario and a dreadful scenario doesn’t mean that any scenario in the middle of them could reasonably transpire.
Planning the Work; Working the Plan
A budget is not a document you’ll prepare in one sitting, set aside, and never return to.
Expect to revise your budget over multiple visits as you accumulate both more information (e.g., additional printing quotes) and better estimates (e.g., “the veteran publisher I asked to look over my budget laughed out loud at my sales projections and told me to cut them all in half”).
Don’t move forward with a budget that shows a loss all the way across the P&L table, even if you really want to. Revisit the sections, change your component mix, look for new vendors, raise the MSRP, and keep working around the edges until you have a plan that presents at least a theoretical break-even. If you’ll allow me a platitude, you owe it to yourself.
Come back to your budget while you’re executing the plan that it represents. Make sure your contact-with-the-enemy reality doesn’t completely demolish your potential to make money.
Get In Touch!
I hope this budget template and commentary on it is a useful tool for you or someone you know. If you have a question, don’t hesitate to ask. If you find an issue or have a suggestion for some future iteration, drop me a line. Most importantly, if you use this tool to plan for and then actually produce a project, please let me know, whether the project works out or not.
I’m eager to hear from you!