Alexander Zacherl is a game designer & entrepreneur based in Munich, Germany. He currently serves as Managing Director of Fairytale Distillery and Game Director of Sandbox-MMO-meets-MOBA "Das Tal". He has spent the last six years learning how to be successful as an indie dev but has not made it yet - so take his analysis with a grain of salt.
Depending on who you talk to nowadays, people might tell you that the end is coming and that the Indiepocalypse is nigh. Or maybe they say it's not - this might all just be business as usual. I'm not sure who's right.
But consistently making enough revenue to sustain your independent development studio for years is a very tough business and something that most game developers fail at eventually. So I've talked to many other devs and found some strategies that can help you survive - and even thrive - in a competitive market.
In this article I'll talk about portfolio strategies, homerun strategies and community-building strategies. Don't think that's an either-or-setup - a lot of those strategies combine well. Just make sure to read this until the end to learn about what I think you definitely should NOT do.
The core philosophy here is essentially always the same: Since it's hard to predict which of your game releases will be successful, try to have many of them to make decent revenue on average. Having fewer releases comes with a bigger chance that you won't make any money in total, so try to minimize this risk.
1a) Go Fully Multi-Platform
Just because your game flopped on Steam and Xbone, does not mean it will also fail on PS4. Just because your game gets ignored on the US App Store does not mean it will fail on Chinese Android Stores. This is something many grizzled developers tell stories about: Their games would not have been profitable on the first or second platform they launched on - but they made good money in the end. In order to maximize revenues here you will want to make your game run on as many hardware / input platforms (PC, console, mobile touch, VR etc.) and store fronts (Steam, Humble, App Store, Google Play, Amazon etc.) as possible. This could be done via picking a lead platform (where the game runs best) and then doing a couple baseline ports for other platforms. Or if you want to release consistently great games then it's probably better to design the core of the game to work with any control scheme and with many business models.
Prominent example: Hello Games' Joe Danger
1b) Agency / Contract Work
Who says you need consistently spend all your team's time on working on your game? It might not be as fun or as glamorous to work one someone else's projects but contract work can be a very reliable source of income to live off while you work on your high-risk in-house project. There are two things you need for this: First, the ability to be great at business development. Going out there to meet people who might be potential clients. Once you've found them you'll have to turn from the salesman to the account manager, manage your client's expectations and budgets and so on. This might not be why you got into games in the first place but it's a relatively straight-forward business. There's only one secret I suggest here: Don't work for games companies. Game contracts are notoriously badly payed. Instead aim for industry clients (you know, the usual mix of banks, car manufacturers and other big corporations) who have deep enough pockets to not negotiate your daily rates down too much.
Prominent example: ustwo's Monument Valley
1c) Create Many Small Games
There are other ways then to spend three years on a game with a ten-person team. Time-box your development time to only spend a small amount of work on each game or game prototype. Call it a "minimum viable product", release many of them to real players and then double-down on the most successful experiments. Years ago these would have been flash prototypes but in the days of wide-open app stores and Steam Greenlight / Early Access you can now be on most major channels with even small games and prototypes. This combines very well with schemes like One Game A Month, monthly game jams and contract work. In order for you to produce great little gems in only a short time make sure to use well-known tech, re-use art and in general don't add any additional risks to the process.
Prominent example: The Experimental Gameplay Project / World of Goo
1d) Become a Publisher / Investor
This is a bit of a stretch for most of us. Foremost because you kind of stop being a developer when you focus on financing and / or releasing other people's games instead of your own. Of course you'll already need to have made a decent amount of cash in order to help finance and market those projects. But a combination of working on your own games and supporting the best and brightest of your peers in releasing theirs might be a great way of spreading risk between many projects - if you can handle the additional stress of multiple projects and the increased focus on non-development tasks that is.
Prominent example: Cliff Harris / Positech
After talking about spreading your risk between many projects in different portfolio strategies the ideas described in this chapter are approaching the problem from a different angle. Homerun strategies are all about making one game but then making sure that the one hit you might have will be big enough to pay for all your future endeavours. While portfolio strategies might give you a 50% chance at a 500k return; a homerun stategy might give you a 1% chance at making back 25m (those numbers are obviously made-up examples). At this point you might leave bedroom-coder territory and fully arrive in startup-land with its hunt for the mythical unicorn.
2a) Blue Ocean / New Platforms
Every couple years a new game platform rears it's head. In the early days of a new platform you see a very different environment from what you know in mature marketplaces. There are not a lot of players around yet and they haven't had a chance to develop anaquired taste in games yet. There are way fewer games. Big budget publishers haven't entered the market - since not much money is to be made here yet. So you might not have to make the greatest game and ad campaign ever to be a big fish in this small pond. As the pond is growing, so do you. Once you've made "the best experience on platform X", your game will be talked about (and bought) for many generations of players to come.
So where do you go today? We're already quite a bit into the latest console cycle and the mobile gold-rush has been over for years now. But VR is right around the corner. Maybe it's a good time to start thinking about how to go fishing in the VR pond?
Prominent example: Halfbrick's Fruit Ninja
2b) Games as a Service
A game designer friend calls this model "hobby games". The idea is that you do not create games that are just another blip on your player's radar. You're not making something that your players buy for 5 bucks in a steam sale and then play for half an hour or never even try out. Instead you try to create a game that becomes a massive part of someone's life. Not just "a game" but "the game". And just like model train people spend a lot of cash on model trains and base jumpers on base jumping equipment, us games people tend to spend a lot of cash on our game hobbies. At least some of us do. That does not mean you need to make a one-armed-bandit-like F2P monster full of gacha monetization. Even the boring ol' $15 subscription model nets you $300 from a player who sticks with you for two years. Just make sure they stick around for that long - be it through multiplayer, user-created-content or modding.
Prominent example: Grinding Gear Games' Path of Exile
The following two strategies are again not easily distinguishable from what you've read above. They work well in combination with most of those models. The core idea here is that the value you generate does not only lie in your game, it lies in the community of players and fans you build. Those people can be a great way for you to get the word out about your newest releases. They will be relatively sure-fire prospects for your new games, and they might even help crowd-fund them.
3a): Focus on Your Tiny Niche
Many designers and developers I know - including me - are easily distracted. We get bored with what we do very fast and tend to hop from project to project and from genre to genre. Today I'll work on a mobile digital board game, tomorrow on a dungeon crawler and next week on a twitchy platformer. And while that's fun, it's not always a smart thing to do. The fan base you'll create with each release will rarely make it over to your next project. So why not stay within the boundaries of a genre, a setting or a play situation? Make only local multiplayer games. Create only turn-based strategy games for tablets. Or create an elaborate, living world that you re-visit in each of your games, whatever genre they are set in. Your player base will grow over time and so will your revenues.
Prominent example: Spiderweb Software
3b) Performative Development
Twitch is really big nowadays, right? Everybody knows that. And many of us have dabbled in game dev streams and in dev blogs before that. But some of us have adapted to this new age of transparent and entertaining game development better than others. Showing the details of how you create your game can be very enganging to some people, especially if you manage to make it entertaining. If you have the personality that makes it fun to watch you debug your AI code for six hours straight then definitely go for it. If you are the kind of person who loves discussing design decisions with your player base then you have a great way to keep people engaged and make sure you have a rabid following once you are ready to launch. Be good enough and people might buy your releases not for the games themselves but because they think you are cool. You might even be big on Patreon one day.
Prominent example: Vlambeer's Nuclear Throne
After having spent the last minutes reading about what I think you SHOULD do - here's what I think you definitely SHOULD NOT:
Develop one single mid-budget (200k to 5m) game with a medium sized team (5-25 people) in 2-3 years of dev-time. A single-player game without any moddability or community aspects. Act through publishers without building up a fan-base for your own company. Launch the game on one platform, despair when it does not make you rich in the first five days, scramble to set up a new publishing gig and set onto the journey for the next 3-year-development cycle in a different genre and with a completely different target audience.
To me this is by far the riskiest model you could run and the reason why the history of video games is littered with so many rushed titles, so many disillusioned developers and so many dead dreams.
Now I'd love to hear your opinion. What do you think of the strategies I outlined here? Did I forget anything important? Am I completely on the wrong track? Please tell me your thoughts in the comments and feel free to check out my own game at das-tal-game.com to see what I'm working on directly.