The Cost Of Doing Business

“A game is only late until it ships, but it’s bad forever.” In one form or another, the sentiment has been with the games industry for about as long as it has existed. Ask ten developers and you’ll hear nine times that the best games get built over a (relatively) long time by (relatively) small, dedicated teams. Yet that is not how a lot of projects are run.

Even studios that started out with a ‘low & slow’ approach will often find themselves ramping up and shooting for hard deadlines on subsequent projects - even if there’s no particularly strong external pressure to do so. It can leave people baffled. And since it’s often my job to try and help teams with such a new scale, I sometimes get asked to explain.

Image Credit: Kai3952. CC 4.0 Attribution-Share Alike [Cropped]

Now, like anyone who has (skim-)read the Mythical Manmonth and worked on systems-heavy game projects, I am aware of the perils that come with trying to short-cut iteration time or overcrowding a creative process. If possible, it’s a good idea to exchange team size for development time. But I’ve also worked with enough studios to understand what leads to the shift. And as I’m sure you’ll be ecstatic to hear, the explanation involves spreadsheets!

How It Started

You founded the studio because you got laid off alongside a few folks you really liked working with. The severance paid your way to a pretty exciting prototype, and one of your co-founders had a friend at an indie publisher who signed you on its strengths.

It was all pretty shoestring: You worked out of your bedrooms. In-person conversations happened mostly at the café across the street from your old studio; if the meeting needed a bit more calm, you invited people around your kitchen table. Admin, bizdev and legal duties were split between yourself and this on-the-ball assistant you had gotten in on a 50% freelance contract that you still feel a bit guilty for.

When you got close to Alpha and things just didn’t feel right yet, you and the other co-founders shared a look and without much fanfare slashed your own salaries. Somehow, you managed to stretch the two extra months of budget the publisher could get you into half a year. In the end, you even found enough cash in there to have a little launch party. A few local actors your partner knew showed up dressed as the game’s main characters. It was all a bit dorky, but the team enjoyed it. You figured — If tomorrow goes badly, make the adventure end on a high note.

You never truly got around to structured accounting in those days. There was what you’d have to pay each month, and how much the publisher would send you every eight weeks for the milestone. But if you’d had someone controlling your books, a typical month’s top-line would’ve looked roughly like this:

You’ll have guessed that things are going to go downhill for our studio head, so before we dig into the details, let’s spell out that they and their co-founders have done everything right here: They put their team first, chose a galvanizing project, found a partner that put skin in the game, and were ready to double down themselves. Our indie start-up has earned all the success that may come their way.

If we look at the (heavily simplified) cost breakdown, the first thing you’ll notice is just how much of the project’s cost lives directly in staff salaries. This isn’t a surprise — look at any financial primer on the tech industry and you’ll read about how personnel is the main expenditure — but it really comes to an extreme in game start-up situations. Let’s say that the team’s overall size is eight, and there are three or four co-founders in the room. By doing nothing more than changing their own salaries, these entrepreneurs can scale about half of the total monthly budget.

Image Credit: Andy Li. CC0 1.0 Public Domain

It’s not a comfortable decision, you don’t want to have to take it, but it’s possible: Rely on your reserves (and in the case of one studio founder I know, the amazing money-saving properties of a 10lbs rice bag), and you can turn one month of runway into two. No angry calls from suppliers, no employees going hungry. Very few other companies one might dream of founding — no pub, no fashion label, no biotech start-up — could offer its owners the same deal. Those come with significantly bigger ratios of non-personnel costs: Stock and ingredients, venues, laboratories, machines (or machine time), product certifications, and so on.

In game development, our versions of these costs can be miniscule. For this example, I added a “Tech & Misc.” section for things like licenses and hardware that can be directly attributed to the needs of the project (think “engine fees”) — and what’ll soon turn out to be the villain of our story: Overhead.

As a very quick primer, overhead costs (“OH”) are all those expenditures in a company that can’t be connected to a money-making endeavour, like a game project. In our case, that’ll cover the salary of the assistant, any kind of administrative payments you’re due as a new company, and not much else. I don’t know whether it’s good accounting practice, but you’ll often see non-revenue-dependent taxes lumped in here, as well.

At well below ten percent of the operating budget, these two cost factors taken together really aren’t much of a concern yet. In our studio head’s life, they’ll have cropped up in their attempt of avoiding too many extra seats on the studio’s Miro account, or a guilty pang when they realize that their assistant has again put in more than the twenty weekly hours she signed up for. The overall project strategy isn’t really impacted.

How It’s Going

Today, your studio’s first game is at the centre of a minor new genre. You got a sequel out within twenty months. It should’ve been DLC, but it grew into an expand-alone. Along the way, you retrofitted some of the new features into the first game, and people seemed to appreciate that.

The second game did really well, though not quite as well as the first one. Another dev released their own spin on your concept three months after, and that kinda blunted those first big discount sales. You knew you’d have to step things up for the next one.

You’ve been in development for about two years now. It’s a point of pride that the whole team worked hard to only grow where necessary. You have about twice as many devs as in that first game’s team, not counting outsourced art and QA. It’s the absolute minimum. You know you need to hit a completely different fidelity level this time ‘round.

But limited growth still means work. To support the team, you now have a HR manager, an IT specialist, and a build engineer, all of who patiently remind you that they’re doing the work of three people each. Tuesdays and Thursdays, there’s an office manager in the actual physical office you and a big chunk of the team works out of. Then there are the folks who bill hourly, like the lawyer who reviews the improbable amount of contracts you get to sign, the community manager who you gladly handed your social media to, the accountant who you joke is really your boss, or that user research agency your designers love.

You’ve tried to keep some things alive out of the old days. Your company parties are still a bit dorky, but in a much more professional, “we got a budget for this” kind of way.

The new game is nearing Alpha. Yesterday, you played the build and shared a look with your co-founders. This’ll take an extra six months, you know. The publisher will try to help, but there are limits to what they can do. You’re already the biggest project they ever funded.

Today, you sit in a meeting room with your COO (you recall when she joined as your assistant), who shows you your monthly costs. The top-line looks like this:

Again, I want to point out that our indie studio has been acting honourably. They had success and capitalized on it without getting too greedy: They grew in the way tech companies tend to, but arguably showed a lot of restraint and deliberation. There is a market full of goodwill waiting for them, and they’re taking the right steps to reward it. Still, they’re in trouble.

Part of this is just that the founders are a much smaller part of the overall team now. Even if they were to forego their salaries completely, it’ll save only a fraction of the project’s personnel costs. Doubling your runway via a few months of fried rice is just not an option any more.

But of course, that pales compared to the other costs. Our studio’s overhead now accounts for more than a quarter of the overall project budget. Suddenly, that cost is a strategic consideration; a sort of entrance fee to be paid at the top of every month of your project’s runtime. Across six months, it adds up — and means there are hard limits to how long you can make your money last:

Say our studio head makes a few incredibly painful decisions and manages to reduce the personnel costs by a third. Anyone who’s ever run a project will know that that’s more than you can save without losing some pretty vital scope. That bloodletting would save 25% of the monthly budget, about enough for one and a half of those six extra months of development.

The overhead would cost about as much as these savings, and not change significantly. For example, there’d still need to be somebody to look after IT — and a lot of that work (running the local network, managing license pools, negotiating with hardware suppliers…) is disconnected from the size and shape of the dev team. Overhead is a hard limit on how efficiently you can run your project.

Unsurprisingly, fights about overhead and what your project is supposed to pay for are a popular management pastime in every games company I’ve ever worked at. It’s all the easier because everyone will see something in there that they personally don’t find useful: In our example, I’d expect a few readers to have perked up around the mention of the physical office. Who needs that in 2023? Go remote; save the money!

Of course, a similar argument could be made about employing a dedicated build engineer — I doubt that many of the same people would make it, though. A studio’s overhead is also a picture of the priorities it’s set for itself. Very rarely does everybody agree on all of them.

It’s valuable to discuss them, but the conversation can very easily devolve into sectarian bickering — and as project leaders with our in-built biases, we’re liable to push it there. Things get even more fraught because in game development, almost everybody will at times end up being OH:

On the sequel, you worked with an absolute wizard of a freelance character artist. A lot of the positive feedback by fans and press about how the game was bursting with personality could be put directly at their feet. So you made an offer. You didn’t want to risk not having them around when the next game went into full Production.

Work for them was slow for the first year or so. They explored the protagonist and the main opponents, doodled up some way-too-advanced assets for the early prototypes; tried to be helpful. You’re sure the game will be a little better-looking thanks to their efforts in pre-production. But if you’re honest, they could’ve been on a one-year paid vacation, and it would’ve made little difference. Arguably, it’d have saved the art lead and yourself some time finding work for them.

So if we accept that overhead will usually grow faster than development costs and that this can limit efficient development strategies — how do we deal with the problem?

The Extremes

As always, there’s an easy solution: Be exceptionally successful. If your game cost $500.000 and returns tens of millions, odds are you’ll happily sacrifice some efficiency if it gets you a shot at earning the same or more next time. This is a hit-driven business, and many genres are monopolies where one series is the go-to for the vast majority of the available audience. If you find yourself in that seat, your revenues will likely dwarf your cost structure entirely.

This is what institutional investors look for: Your product has found its fit in the market? Great. Grow. Make your company the best workplace for the best people so that they can make that product (or its successor) better in a way no competitor can, so that you end up owning the niche, so that everybody interested pays for your product, so that your returns outstrip the cost of getting into this spot in the first place.

The SoftBank Vision Fund’s Silicon Valley HQ. Image Credit: Coolcaesar. CC 4.0 Attribution-Share Alike

There’s a lot to be said about the pros and cons of this approach, and whether it’s equally suitable for all parts of our industry. For now, let’s agree that it can work, that it carries risks and challenges not everyone will want to take on, and that it may not always be viable — let’s say, if the world is going through a time of high interest rates and investment money is hard to come by.

There is of course an opposite strategy: Stay small. Accept that there will be limits to what your team can build, and that you’ll forever be saddled with doing the admin work yourself. Double down on the kinds of games you can do well. Play the odds and instead of growing, turn any success into reserves for the dry times.

This too can work: At the right size, studios have historically managed to weather multiple development cycles on a single moderate success. This’ll go furthest if you either pursue a small-ish niche (take the point&click adventure scene) where there aren’t significantly larger competitors driving customer expectations out of reach, or if the team is set up to move between genres anyway (think of auteur indies like Maddy Makes Games or Bennett Foddy).

Of course, the risk here is even more obvious: Securing that first success is never guaranteed; neither is a follow-up to it in the time it buys you.

In The Middle

There’s a cruel irony here: The arguably most efficient way of building high-quality games seems to be a privilege of the rich and the desperate. How do we who live between both extremes manage?

The intuitive answer, especially if you lead a studio and not a single project, is to try and spread the weight across more shoulders. By the same logic that keeps your IT costs from sinking if you reduce developer headcount, they don’t spike at the first increase. So usually, having two or more projects in development will be more efficient than being a single-title studio.

You’re unlikely to cut your OH ratios in half, of course: Things like hardware investment or per-seat licensing do scale with headcount, and as things get rolling, there will need to be a second IT expert eventually — but real improvements are possible. In an ideal world, you’ll also be able to keep more ‘seasonal’ employees like content authors busy by staggering projects. In practice, this’ll of course lead to constant fights between project leaders about who gets that amazing character artist next — but everyone will agree that that’s preferable to the studio not being able to afford them at all.

There are two main flavours of multi-project strategy: Genuine parallel in-house development (if you have the financial reserves or partners to make the lift), and co-development (or full-on outsourcing) for clients. Of course, blended approaches are possible. In my experience, the UK development scene is particularly good at this: It’s full of smaller devs who sustain their passion project by also going to work on other studios’ games.

A ‘horizontal’ growth pattern emerges, where the studio doesn’t invest into increasing specialization among its developers, but instead sets up parallel leadership teams and folks who can move between relatively diverse projects. There are still challenges and risks (you’ll need to build business development muscle, you’ll be more directly exposed to the ups and downs of the wider market…), but ultimately, I view this behaviour as one of the signs of health and maturity in a developer.

Which is great if you’re looking to choose a new employer, but what if you’re running a project and the overhead’s full weight rests on you? Well, you still have an incentive to spread that cost out across more heads:

Say that your budget is relatively set — extensions are possible, but they’re politically uncertain. Every month of development, you spend a certain part of that money on things that are not the game. If you can decrease the number of months you have to pay that entry fee by increasing the number of devs, you’ve just reduced the portion of your budget that goes to ‘waste’.

We’re through the looking glass: The counter-intuitive way of running a project doesn’t only make financial sense; if your margins are too tight, it may be the only way of releasing a game with a scope that the market will accept. It’s also still a bad way of making games.

Image Credit: Wpcpey. CC 4.0 Attribution-Share Alike [Cropped]

If you find yourself here, it’s good to remember that you’re in fact managing a crisis. Whether it’s due to a single-title strategy your studio has outgrown, unsuccessful bizdev, or just bad luck, you are being asked to mitigate a company-level issue within your project. There won’t be a perfect solution, and most viable ones will impact your project’s shape.

For example, you’ll have a strong incentive to put an emphasis on proven content types. Not to say that it’ll be painless, but they’re likely your safest option for a rapid scale up.

In the end, it came down to cutting stuff, of course. You hope you’ll never again have to explain to the team that you’re removing the big new feature three quarters of the way to Alpha. The lead designer is still furious about the two months it took to rework the economy loop into something closer to the second game’s, capable of working in the feature’s absence. You understand, but what else could you do? You had those two months. You didn’t have the time it’d have taken to get the new feature settled.

Talking to the publisher was easy by comparison. It felt weird, telling them you were removing stuff but also needed money for an additional set of levels to make up for that gap. In the end, they were just relieved. They had enough budget for some more artists and level designers. They didn’t have budget for the extra dev time.

The game did OK. One of the reviewers summed it up: “For this time, the formula still works.” The production values attracted a bunch of new players, and your core fans kept the faith - mostly. Your lead designer and a senior programmer are R&D’ing ways of retrofitting the big feature in time for the DLC. You have a bet going on whether it’ll spiral off into a fourth game. Either way — the idea is good. It’ll land well with the players when it’s done.

You just had a call with a friend who started an own studio some time back. They’re entering the hot phase and urgently need content people. You figure you can send six folks over there for half a year, maybe more. It’ll buy you some more runway for the next thing, and you’re pretty sure they’ll enjoy the project. You suspect that there are many similar calls in your future. It’ll work out.

Conclusion

So where does all this leave us?

I argue that we as developers tend to underestimate the impact of non-project cost factors, leading us to slowly lose access to efficient development approaches. This can be avoided on the company level by deliberate use of maximalist or minimalist strategies, or by setting up a project portfolio.

All of these take time and political will; in the short term, project leadership may find itself in a situation where there is little choice but to accept a hard target and invest budget into (inefficient) capacity increases. This will impact scope and quality, with strategies emphasizing content ramp-ups likely being your safest options.

As always — if you find yourself in that place: Good luck!