search slide
search slide
pages bottom

Failbetter Games: Seven Years, Ten Lessons

Last week I was the CEO of a prosperous mid-sized indie studio. This week I'm a freelancer. No-one expected this, but it was what I found I wanted. My time at Failbetter was wonderful, but there are a lot of things I wish someone had told me - things I'll bear in mind if I found another studio - things that other growing indies might find useful. Here are ten of them.

Take yourself seriously from the start. It took a couple of years before I could bear to take seriously the possibility that this might be my career. I worried that it would be arrogant or unrealistic to think of myself as a game developer or a writer, rather than a software engineer on sabbatical. So every time I introduced myself to someone, I said 'tiny' or 'trying' or 'sort of'. When we found clients, I was so dazzled by the idea that people might pay us to make games that I didn't negotiate effectively. Every time I thought about spending money, I looked at what we could afford, not what we needed. It held us back.

I don't mean you need to be one of those startups where the site says grandly LONDON, PARIS, TORONTO and where one person (who has 'Founder, CEO and Chairman' on their biz card) writes all the posts and refers to her/himself anonymously as 'we'. I mean, sure, it does no harm, but it's just playing house. I do mean that if you're making a game, you're a game developer. If you're making a game full-time, you're a professional game developer. If you're cash flow positive, you're a successful professional game developer, and if you're not, you're a struggling professional game developer. There are no other qualifications. If you're doing it, tell people what you're doing and don't be abashed.

If something seems unthinkable, think about it anyway. Some things that happened in my time at Failbetter: I had to lay off the whole writing team; we made a commercially and critically successful PC game (after making nothing but browser games for five years); the founder and majority shareholder (me) sold his shares back to the company.

A couple of years before any of these things happened, they were unthinkable. All of them went okay, because we'd taken good advice and we were lucky. But we were lucky, and we'd have managed more easily if we'd thought about them as possibilities. Even if they hadn't happened, it would have stretched our brains in useful directions. Again, the gods won't punish you for your hubris if you spend fifteen minutes thinking about what you'd do if your next game really took off, or your colleague who was never going to leave suddenly wants to go into politics or be a full-time parent.

Client work, or your own IP: pick one and stick to it. When you're a cash-strapped indie dev, it's very tempting to take time away from your own projects to pay the bills with client work. But client work always takes priority over your own work. You'll be working to their schedules, on their terms, and developing the competencies that they, not you, require. It's difficult to wean yourself off client work, and it requires a whole different set of processes and skills. And you can't make it rain. If, as a small business without a sales team, you need client work and none's forthcoming, then good luck.

I say this even though at Failbetter, we were really lucky with our major clients - they treated us well and paid us on time, and they're all people we genuinely liked. But I have to say that if I had everything to do over, I'd hire slower or spend more time looking for funding or put the effort into trying to get profitable with our own stuff. "We'll do one for them and one for us"? This never works.

Marketing is no less (and no more) important than QA. It's very hard to have a success without good marketing and QA (and it's impossible to have it without good production.) Always remember, when you're convinced you've told everyone in your network everything about your game, half of them won't even know you're working on a game. This goes both for marketing and for community relations.

This goes, like, triple, for indies. You're invisible without putting proper effort into marketing. You can't compete for coverage with the big guys, and if you're in it to make money rather than make games, you're probably in the wrong room. (You're certainly in the wrong article. You should be reading that piece on Business Insider about the uptick in Series C funding rounds or whatever.)

So for God's sake do open production! - by which I mean developing where your potential audience can see your work. This means development blogs, Early Access, crowdfunding, a founders' beta, all the above. This means the things you can tell the world are the things you're already thinking about. Sure, it means being transparent, but you're an individual or a small team. Tell your story directly and honestly; if you're going to be different, be different; don't sausage-machine it into generic marketing glurge.

Get early feedback earlier than feels safe. This is the other big win from open production. Get early versions, and updates, out as soon as you can get useful feedback. The bar here is 'will anyone bother to play it?' If it looks so dreadful, is so buggy, or is so light on content that people are going to fire it up, go 'eh' and never get around to saying anything useful, hold off. But if it has a face that only an enthusiast would love, get it out now - if only to your enthusiasts. Don't make people sign NDAs! If it leaks a little beyond your core community, fine. It won't go far, and when the time comes, you'll need all the eyeballs you can get.

'Ship early, ship often' is advice that's been around a long time in software development, but it's still good advice. It may take work to get your game running reliably outside your development environment, to distribute it to volunteers or enthusiasts, to deal with feedback. But a lot of this is work you'll need to do anyway. If it's prohibitively time-consuming, find tools and processes to make it easier, and train your community to help. In any case, the time you'll save on not making daft mistakes is going to be a lot more valuable.

Go beyond your community. For an indie dev, your community is essential. They're your evangelists, your early warning system, your Baker Street Irregulars, your Praetorian Guard. They'll tell the world about you, they'll QA your game unevenly but enthusiastically, they'll keep your morale up when you most need it... and all you need to do in return is treat them with courtesy and give them the best game you possibly can.

But you have to look beyond them, too. Another term for 'your community' is 'the people who've already heard about your game'. They'll buy your new products, but wouldn't it be nice to have customers who'll buy your back catalog too? You need new customers. At Failbetter, we spent years focusing on our core players, because they were keeping us afloat - but when we launched Sunless Sea, Fallen London suddenly got a whole new non-core audience, and Fallen London revenue literally doubled overnight.

And when you're looking for those new customers, never forget that a core player (a) sees the game very differently from how a new customer will see it (b) will give more feedback, good or bad, and attract your attention more easily than a new customer. Elsewhere I've called this 'the Veteran's Curse'. We learnt this the hard way on Sunless Sea. Listening disproportionately to feedback about the endgame rather than the early game probably lopped 5% off our metacritic score. Of course not listening at all would have been much worse.

Above all else, hire people you can trust to work effectively when you're not looking. Indie teams have to be small, lean, and run with minimal oversight. If you have to chase someone to do what you need - not just 'do work', but 'do the work you need' - you're not just losing productivity. You've also missed out on the chance to get someone who'd do a better job; you've missed out on Christ knows how many wins you can get from someone showing useful initiative; and you'll find the rest of the team knows what's going on.

Conversely, when you find someone who understands what needs doing and can do it, give them their head. It's better for them to get something non-critical wrong, and learn from it, than it is for you to guard them from every possible mistake. Especially since you won't always be right either.

Story is not a feature. Failbetter has a very good name for the quality of the writing, but the writing wasn't the story. In a good narrative game, the story is expressed through everything, from writing to game mechanics to art direction. If you're making a narrative-centric game, make sure the whole team understands the story - not every detail of continuity, but what's going on, and why the player should care.

"Overnight successes are years in the making." This isn't a novel sentiment, but I want to dig into it a bit. Reading industry news is vital to keeping informed; but unless you remember that newsworthiness is by definition unusual, you may end up with a distorted idea of normality. "Unknown indie dev has a surprising success" is newsworthy. "Beloved indie dev shuts down" is newsworthy. "Reasonably successful indie dev continues to have a reasonably good time" rarely makes headlines. Most life isn't stories: that's why we have stories. Don't panic, don't get distracted, and leave bandwagons to roll on their own.

It's more important to focus on what you're good at than try to fix what you're not good at. I took this away from a talk by Fredrik Wester of Paradox, and it's probably the most important point here. If you can't be distinctive as an indie, you're screwed anyway. Be distinctive.

Leave a Reply

Captcha image