Opinion: Why Project-Based Game Budgeting Could Work

[Could a project-based approach to game budgeting present advantages over traditional operations-based budgeting? Game designer and producer Tim Carter explains, pointing to benefits from transparency to greater creative freedom.] We know how operations-based game development is traditionally budgeted. This is the model we use today. Basically a self-contained pre-existing company (a development studio) submits a prototype to a publisher. For discussion purposes, publisher says yes, then a list of milestones are agreed to. Publisher advances cash as milestone deliveries are met. Finally, studio delivers gold master, continues with updating work and moves on to next game. But how would a world of project-based game budgeting work? What is Project-Based Game Budgeting? What is the significance of bringing up this topic? Isn’t budgeting budgeting? Whether done in the traditional operations-based model (studio-publisher) or a new project-based one (similar to the film industry)? Project-based game budgeting is the business side of a core-talent-driven project. Basically, a bunch of talented people get together and say "Let’s put on a show in the barn." Then ,they work out the details of how much it will cost, including how much to rent the costumes, how much to rent the venue, the cost of the props, the cost for the talent, the extras, the make-up, et cetera. They decide that the show is a company unto itself for the sake of simplicity (so they can wrap it up). Then this is submitted to the investors for funding. It’s a staple of the entertainment business. You’ll notice the first thing that is different: Transparency. Transparency First off, the creators get directly involved in planning the budget. The writer of the show starts out wanting a hundred extras carrying full spears and so on. Then the producer shows him the budget. Whoa! Well, let’s just get that down to 10 extras, and we can use a cardboard cutout for the rest. Or better yet, rewrite it so the extras are officers and they refer in their dialogue to having a few legions offstage. There. We just trimmed our extras budget by a huge amount. So we have the key creative directly involved in adjusting their vision to compensate for the budget. But it doesn’t end there. The investors see exactly how much is being spent on what, where, by whom and for how long, because it’s all laid out in black-and-white. It’s not like a milestone-based system. In an operations-based venture (like a game studio), publisher asks for the milestone deliverables, and then dumps a bunch of money into this black box called a game studio, trusting that studio has it’s shit together to know how much to spend on what, et cetera, so that the milestone deliverable will be delivered. But not trusting too much: after all, the milestones are set up to make sure that publisher isn’t dropping money into a black hole. That’s why they only advance the cash in chunks. They can just decide, after Milestone X, to pull the plug. This sounds all very great for the publisher, but what about the developer? Well, from the developer end, the milestone system is really a half commitment. The developer isn’t revealing everything to their funder, playing their cards close to their chest, which is why the publisher is going on milestones. I mean, is this advance actually going into the game, or is the developer in hoc and the milestone advance being used to pay off old debts? But in a project-based, budgeted scenario this is gone. It’s all out in the open. Because we’re looking at this as a clean sheet project, which key creative have been instrumental in shaping, planning and directly budgeting. Now publisher knows developer has planned it out and they aren’t paying money toward old skeletons. So they greenlight it. Not fund a first milestone. Greenlight it. The whole thing! When the publisher funds it, they fund it! Imagine that. No milestones. Just a full out commitment. So it works for the developer too because the developer knows that money is earmarked. It isn’t going to disappear. The plug isn’t going to be pulled. Well, to be honest this isn’t entirely a blind faith situation. Why? Because we can insure the project. The publisher has amassed enough data in and experience about these situations, and the production procedures and technologies are now so well understood, that we can pretty accurately know what the odds are that 1. the project will get made (the gold master delivered); and, 2. we know the likely volume of sales (not the best-case scenario, the average case one). This informs our insurance agents (completion bond guarantors) who insure the gold master. Remember, it’s not 1998. The game industry is maturing. It’s more predictable. Your true risk factor lies less in "can they actually simulate physics?" and more in "will this gameplay really be fun?" Reducing Burn The next bit is, since we’re talking about projects here, we can wind the production company down after it’s done to stop the burning. Want to mitigate risk? Well, you can talk waterfall development or agile development or spiral development or critical path management. Nice theoretical exercises. But what about this good old-fashioned method?: write up a to-do list, do it all, check everything off as you do, then wrap it up, shut it down and stop paying for stuff you don’t need when you don’t need it? In a traditional game industry scenario, between projects the developer is sometimes in dire straits to get another project to meet overhead costs. Result: the early planning (design, budgeting, et cetera) can be compromised. Rushed. In a project-based scenario, since you haven’t had more than a tiny office, a producer, a lead designer, a lead programmer, your burn is miniscule. You can take your time. Plan things out. Core designers can dream a bit and see what gnaws at them, what they really think will work as a game. It’s often called core-team / outsourcing. But we all know about this by now. The Project Budgeting Culture You probably see a challenge now. If you’re budgeting like this, you’re going to a scheduled development scenario. Current talk is you don’t want to be prototyping in a scheduled scenario. You instead want to iterate. Well, 1. we can do a hybrid: we can iterate inside this phase of development, but set an ultimate deadline; and 2. maybe project-based development isn’t for everything. On the other hand, as mentioned above, you’re not iterating but you are taking the pre-project phase to plan out everything while not burning a huge payroll. And let’s look at it through the cultural lens. Project-based development is almost totally used in film. Yet things aren’t predictable on a film. (No. Stop it. They aren’t. No matter how much you game developers who are experts in filmmaking insist that filmmaking is predictable, you’re wrong.) How do you iterate on a film? The simple answer is each film already is an iteration. Does it do well or poorly? Get that sucker out there for sale, and see how it does. So now your next iteration is the next film. You can contrast that with the game culture where there is the seductive possibility of endlessly iterating on a game until the point of absurdity. But in the current climate where basic features (such as normal maps, physics simulation and so on) are so well-understood, do we really need to iterate so much? Do we want to play it so totally safe we never let our baby out the front door, or do we want to go forth and meet our fate? I’ve wondered why this is. Why filmmakers push hard to get their films done and out the door, while game makers will strive to remake and remake and remake. (I’ve experienced it from both sides.) My answer is that the two are made on wildly different circumstances. It’s easy to iterate and iterate and iterate when you’re sitting in a comfortable office environment. It’s much harder when you’re shooting in a steamy jungle in the Philippines, you have hundreds of extras in weird costumes standing around impatiently (which you must feed every day you’re delayed), the army keeps taking away your helicopters to go fight (real) guerrillas in the hills, your lead actor has a heart attack, and typhoons come in and destroy your movie set (yes, that’s Apocalypse Now). In a situation like that, nobody gives a shit about iterating -- "Fix it in post!" is a common saying on a movie set. But, you know what? Sometimes that pressure is a good thing. Sometimes that pressure forces you to focus on what works and what doesn’t. And you can then look at the project as an entire iteration. Wind down your production capacity in the interim (let it go, the contract for your outsourcers is over); take some time to think about what worked and what didn’t; and then plan again for the sequel or your next project. For the next iteration. And remember: do up a good budget. [Tim Carter is a game designer and producer who has worked for companies such as Kaos Studios, BreakAway Games, Amaze Entertainment, the Washington Hospital Center and various serious games clients. He has experience as an independent film writer and director. He previously taught game design and business at the University of Ontario Information Technology in the Toronto area, and is currently the CEO of Core Talent Games Ltd, a game producing company.]