It’s rough in the games industry at the moment, and a lot of folks are spinning up their own thing. So I thought now might be a good time to boil down what feel like the key things I’ve learned in 15 years of running an indie games studio.
If you’re just arriving, we are Suspicious Developments. We did:
- Gunpoint (2013) – 10k reviews, 98% positive
- Heat Signature (2017) – 6k reviews, 94% positive
- Tactical Breach Wizards (2024) – 10k reviews, 98% positive
I’m the game designer and writer, I do some code, and until recently I ran the company (I now have help).
As you might be able to tell from the list, our games are all over the place in development time and genre. But they all sold great and reviewed great, and to the extent that we controlled that at all, I credit it to prioritising sustainability.
That means definining success not in total sales or accolades, but in how sure you can be of making another game at a happy, comfortable pace. All our games made more than twice their money back, and we’ve never been closer than 2 years to running out of funds.
The biggest factor in getting to that position, of course, was sheer luck: we made our first game in our spare time, with no budget, and it came out at the perfect time: 2013. Indie games had started to make real money on Steam, but the scene wasn’t flooded yet, so a small-scope thing from first timers had much easier time selling. That kickstart from zero to game-budget-money is ultimately why we’ve never needed a publisher.
So I’m not the right person to ask about startup funding. But we weren’t that rare in our first success, and we are increasingly rare in our still-being-here, still-making-stuff, still-independent. So I can at least advise on how to make what you have go as far as possible.
Looking back, this is what feels like the highest-impact, most-copyable aspects of that. I hope it can be of help.
Why four?
Look, I’ve only been at it 15 years. It’s gonna take me til 2030 to learn a fifth thing.
Contents
- Stay as small as you can
- Pick something prototypable
- Testing is the magic bullet
- Price is a solved problem
- A timeline, to illustrate
1. Stay as small as you can
I hate to say this at a time when it would sure be nice if there were more jobs, but I say it to encourage more stable jobs. Staffing up doesn’t really create jobs if it leads to layoffs or closure, and it fucks with a lot of lives along the way.
I think we only get to a healthier industry for workers when more studios are sustainable, and more jobs are stable. And things get unstable very fast as you grow.
The maths of how team size affects your chance of success is brutal:
- Success is making more money than you spent
- Doubling your team size doubles the amount of money you need to make
- But as the numbers go up, vanishingly fewer games make that much money. So it’s not just half the chance of success, it might be a tenth
But wouldn’t more people make development faster?
That’s the dream! But I think it very rarely works that way.
If you’re hiring someone to do a job no-one’s doing, that’s generally making the game bigger or better, not quicker.
If you’re hiring someone to accelerate something you already do:
- Onboarding is costly
- Co-ordination is costly
- Conflict is costly
- And most indie game dev work is not churn
By churn I mean: work where what needs doing is completely figured out and understood, it’s just a question of churning it out. That’s the kind of work where you can reasonably hope more people will mean less time, but even then it’s only budget-neutral in a perfect vacuum where all the other factors I mentioned have zero impact.
In practice, most indie dev work is the figuring-out part. More voices in those conversations can lead to a better game, but they rarely bring release day closer.
For reference, Suspicious Developments’ average burn rate is about 3 full time salaries. I think if we had scaled up to 8 after Gunpoint, we would have made a bad game next, then no games at all.
Heat Signature was a tough game to figure out, and if we’d had less than 3.5 years of runway to test and iterate, we would have just had to release it in a bad state. If we’d had only 3.5 years of runway, I’d have been stressed as hell and the company would have collapsed if it wasn’t a hit.
We haven’t been consistent because all our ideas are golden, we’ve done it by staying small enough to keep testing and working until they’re good. And that’s a more sustainable kind of success, because rolling with punches is built in.
A lower burn rate is a superpower. There’s nothing else that’s fully within your control that can so dramatically increase your chances of success.
2. Pick something prototypable
This didn’t really work, which was useful to know 6 years before launch.
By ‘prototype’ I mean a playable build that meaningfully shows what’s good about your game – a proof of concept.
A prototypable project is one where you can build that in an amount of time you can afford to lose. If you can make a prototype but it’s gonna take 3 years, it can’t serve the main purpose of a prototype: to check this game idea works while there’s still time to change tack.
Being able to do this quickly is crucial for two reasons:
1. If the prototype ends up proving your idea doesn’t work, or is beyond your means, you’re gonna want as much time as possible to do something about that.
2. If your prototype proves the idea can work, how much time you have left directly determines how good the game will actually be.
It’s also just incredibly motivating and clarifying for the whole team to be able to play the game they’re working on, and see where it’s headed.
So:
- Choose your project based heavily on which seems the easiest to prototype.
- Pick stuff you can prototype with the people you already have.
- Don’t obsess about anything until you have a prototype: you don’t know what’s important yet.
- Assume everything you do before you have a prototype might need to be scrapped or redone.
The genre or idea I’m married to is not suited to prototyping!
Keep in mind a prototype doesn’t have to be testing a game mechanic, it’s just the smallest chunk of game you can build that shows what’s good about your game. A gameplay prototype might have no art but prove a mechanic feels good, a prototype for an art-driven game might be a single room built to final-quality visual standards, and a narrative prototype might be the opening chunk of story that’s supposed to spark the player’s intrigue.
If your idea truly can’t be prototyped, then, yes, I’m saying it’s probably not a smart pick for an indie project. It might be a great idea, but investing years of your life and all of your money into a game with no external evidence that anyone will like it is like playing Russian roulette with five bullets in the gun.
3. Testing is the magic bullet
How did we make Wizards good? We asked players which bits were bad, then fixed them.
You are going to take an exam that costs all of your life savings to sit. If you ace this exam, you’ll win 2-10 times your life savings. The games-playing public already knows all the answers to the exam, and will tell you if you ask them.
It is incredible how many devs don’t ask them. Or don’t ask enough of them. Or don’t ask them early enough, or enough times.
Testing can be a fair bit of work and time, but nothing is as expensive as launching without it.
When to start
Once you have an internal prototype, I think your next milestone should be getting it ready for other people to play. Asking what it needs for other people to ‘get it’ helps focus you on the stuff that matters most, and the questions that most need answering.
Your first external test can be with a handful of friends, it’s just easing you into sending it out to people, and giving you early warning of any issues you might wanna fix before testing at scale.
Don’t take anyone’s feedback too seriously yet, small-scale testing can be very unrepresentative of the general audience.
When to scale up
Once you’ve got anything resembling the game – it does not need to be remotely content-complete – test at scale.
- Try to enlist at least 100 testers, more the merrier up to about 2,000. If you can’t get 100 people to play your game for free, then that already answers one of the questions about how your launch will go, and you should address that first.
- As much as possible, get fresh testers each time you test. You never know how experience of a previous build might skew the feedback.
- For gathering feedback, the bare minimum is a Google Form linked in your mailout and in-game. I recommend asking them to rate the game out of ten: it’s very satisfying to see that average go up. And it also lets you filter the feedback if you’re looking for eg the complaints of people who truly hated the game, or the perhaps more-solvable niggles of people who gave it 6/10.
- Expect to do at least two rounds of this, separated by at least a month of dev time to react to feedback. We usually do four or five rounds.
In-person testing vs remote
Testing at scale (which pretty much has to be remote) tells you what the problems are. Watching people play will help you see how to solve them.
I consider the first to be essential and the second to be used as-needed.
With Heat Signature, we knew that a chunk of players struggled with the Newtonian physics of the ship movement, but it wasn’t until I watched them struggle in person that I saw the issue: some people can’t mentally factor in relative velocities. So we added a button that matches your speed to the ship you’re approaching, and that helped a huge amount.
On Wizards, though, we never really hit a sticking point that we struggled to understand like that. So we did almost zero in-person testing, and it didn’t seem to hurt – I think it’s our most polished game.
But I wanna make a weird, nasty lil game!
Cool, then you should definitely test a lot! Testing a game doesn’t mean ‘ask players what you should change about it, then helplessly do what they tell you’.
You’re still the designer, you make the decisions. You even decide the questions – tailor them to what you’re trying to achieve.
If you want it to feel weird and unpleasant, find out if it’s landing that way! Find out where the sweet spot is between feeling unsettled and losing the will to play. That’s a much smaller target than ‘fun’, so you’re gonna need testing even more than I do.
This phase of development is called ‘making the game good’, and if you don’t have time for it, that’s as big of a problem as it sounds.
4. Price is a solved problem
On a pretty real level, your sales are a function of:
- How many people arrive at your Steam page
- How much your Steam page makes them want to buy it
- How much it costs
The first one is famously hard. The second one heavily depends on making the game good, which you’re gonna spend 90% of your time on.
The third one is just a single number you can change in 30 seconds, and you can find out the correct value for it in one round of testing.
We just ask people how much they think the game should cost, and every time we’ve gone with the price most people chose, and every time they’ve sold great and reviewed great.
But we worked long and hard on this, we can’t charge less than X!
I’ve never understood this argument. It seems to be rooted in the idea that increasing the game’s price increases the developer’s profit margin – it doesn’t. It doesn’t even increase your revenue.
If you spend a month making a beautiful artisanal chair, sure, you have to sell it for at least a month’s wages. But we don’t sell chairs. We don’t even sell games. We sell copies of games, which incur no per-copy cost to replicate.
The audience is effectively infinite, and pricing is elastic within reasonable bounds. So if players say your game’s worth $20 and you charge $10, you’ll sell about twice as many copies and make half as much per copy – same revenue. If you charge $30, you’ll sell fewer copies at more money per copy, but it might hurt your review percentage and the enthusiasm of your word of mouth. If you charge $40 that’ll happen for sure, and you might also be outside those ‘reasonable bounds’, where nothing is guaranteed.
In that system, charging more than the optimal price only loses you money. The harder you worked, the more you invested, the more you need it to succeed, the more urgent it is that you ask the right price.
And the right price is just what people are happy to pay. A million complex factors go into it, but you don’t need to know what they are. You can just ask your testers what they’d pay. Set the price to that, and you won’t be far wrong.
But isn’t there a race-to-the-bottom?
If you count the 9 years I covered them as a games journalist, I’ve been paying attention to indie game prices on PC professionally for 22 years now, and I haven’t seen one.
In 2010 people were arguing about whether $15 was too much for an indie game. When we released Gunpoint in 2013, there was debate about whether $10 was too much for 3 hours. The grumbling’s always been there, and the numbers being thrown around back then weren’t higher.
What I have seen is just more everything. More successes at every price point, more failures at every price point, more developers, more competition, more noise.
Among the many genres and models that didn’t exist back then is the occasional janky/silly/ugly game charging $5 to encourage a kind of ‘fuck it, why not’ good will, and blowing up if it lands right with streamers. That might bring the median price down, but it’s not a sign that people will no longer pay $20 for an indie game.
A race to the bottom would be if people were bitching about Silksong costing as much as Hollow Knight. But Silksong charged $5 more, 9 years later, and people lost their minds that it was gonna be that cheap – even before they saw how huge it is.
I guess I’d ask: how bad, how real, and how important a cause would this have to be for you to tank your launch for it? And are you the size of studio for which that sacrifice would have any actual impact on the problem?
A timeline, to illustrate
I’m a visual thinker, so I laid all this out on a timeline. The positions are arbitrary, of course, but there’s no realistic place to put those five lines that doesn’t make doubling your headcount terrifying for your breathing room on both quality and stability.
Obviously most of this post is broadly aligned with conventional wisdom. But the thing I want to yell about, that people don’t seem to internalise enough, is how dramatically and reliably having more time, with a testable build, converts to your game being better and your studio being safer.
But does making a good game guarantee a hit?
Nope! But at the indie scale, making a bad one sure prevents it. And staying small helps again here: if you need to sell a million copies at launch, quality alone can’t ensure it – marketing and other factors all need to align. If you only need to sell 50k, you can get a lot closer to that with just good word of mouth.
Again, this is not a guide to selling the most copies. It’s a guide to making whatever funds, talent and good fortune you have go as far as possible, and keeping you better insulated from whatever bullshit happens next. And that comes down to giving yourself as much time as possible, and checking in with players to make sure you’re spending it well.