A big step forward

This December marks a big step for both Galaxy Grove and me personally; a step that I have been working towards for a long time. 

When I left my previous studio Ronimo in 2021 it was to found a new studio, where I would be creative director and CEO. I had lofty goals for my new studio Galaxy Grove: 

1. Make great games
2. Stay within budget and meet deadlines
3. Specialise in one genre (management games)
4. Build a great team
5. Be good to my employees
6. Be part of the game dev community
7. Multiple teams working in parallel
8. Yearly releases
9. Be ambitious on the business side
10. Become a beloved brand among gamers

Last year with the release of our debut game Station to Station we achieved the first two: a great game (90% positive on Steam), on time and within budget.

While Station to Station was a puzzle game masquerading as a management game, the game we have in production now is a real management game, achieving #3. It also proves we are achieving #4: I am not writing a single line of code this time and the game is turning out great due to our great team!

As for #5: whether I am good to my employees is not for me to judge, but I work hard for this and I feel I provide a warm and healthy work climate without crunch.

To give back to the community (#6), I share knowledge and experience wherever I can. Some examples are that we organise the NL Unreal Meetups every quarter, that I am a mentor in the Dutch Games Association mentor program and that I do talks and projects at game schools.

That brings me to the big step forward I mentioned at the start of this post: our new colleagues Ramon Huiskamp and Jordy van Opstal joined the team this month to start prototyping on another new game. I am very hyped for what they are making and very excited that this now officially achieves #7, making us multiple teams working on multiple games in parallel. It also sets us on the path to #8: yearly releases starting 2025!

As you can tell, I have in general been very ambitious with the business of running this studio. There’s something big on that side in the works too. So I hope to have something to announce for #9 in a few months as well… fingers crossed!

5 years below minimum wage: the financial history of Ronimo

Starting your own game company is fun and exciting, but it’s also challenging. It takes courage and skill, but above all: patience and perseverance. Some become successful quickly, but in many cases it takes years to achieve financial success and actually make a decent living out of your own game company. It might take long to make your first product or get your first deal, and that first achievement might only be a stepping stone towards a next step that brings financial stability. Today I’d like to show an example of just how long that can take by sharing the financials of the first five years of Ronimo, the company I co-founded with 6 friends nearly 14 years ago.

TLDR: The very short summary is this: it took us 2 years to make any money from Ronimo at all, 4 years to earn (almost) our country’s official minimum wage and 6 years to receive a more decent monthly salary from our own company. During that period we were near bankruptcy twice. Why did it take so long? Read on and you shall know!

A note before I continue: this blogpost is partially about how long it took us to “make a decent living”, but the cost of living differs hugely per country. The Netherlands is a wealthy country so cost of living is relatively high. A quick internet search shows that cost of living is much higher in some countries and only half in others. Since most revenue is worldwide, the same sales might mean financial stability in one place, but not enough to pay the rent in another.

Also, for anyone used to reading US dollars instead of euros: if you just replace the € sign with a $ sign, you’re in the right ballpark (especially given that the exchange rates between dollars and euros have varied a lot over the years).

In our second year of studying at the Utrecht School of the Arts our classmate Fabian Akker brought up the idea of starting a company together, with a group. Around that time we had done a couple of school projects that had failed quite miserably, so my first thought was: “we suck, let’s not.” However, the third year was to bring the first major game project, so we figured that if we could make something awesome there, then maybe we could also start a company making our own games.

The resulting game was De Blob: a huge success! We put it online and got attention from gaming press and even had some publishers contacting us, wondering whether they could buy the rights to De Blob.

(Note that De Blob was not exactly made by Ronimo: of the 9 students who made De Blob, only 5 were part of the 7 founders of Ronimo.)

Convinced by De Blob’s success, we decided to really go through with starting our own company. However, each of us still had to do a 7 months graduation project. We combined them and made starting Ronimo our graduation project. Getting school to approve of that was a bit of a struggle, but once they did, we even got our own office inside school.

At the time, 'indie' as it's known today hardly existed and we had definitely never heard of it. We thought the only way was to make retail games and that required funding from a publisher. So we set out to make a pitchable prototype: Snowball Earth. This was intended to be a Nintendo Wii game and we hoped to find publisher funding once we had graduated. At this point Ronimo didn’t make any money at all, but that was okay since we were still students.

September 2007. We were so focussed on pitching to publishers that we did our graduation stuff on the side and crunched for what came a few weeks later: Games Convention in Leipzig, Germany! There we pitched to at least a dozen publishers. Some were interested and continued conversations with us afterwards. Hopeful, we continued work on the game, looking to improve it and increase our chances of signing a deal.

Our very first presentation was for a then pretty famous person from a big company. He was so excited that… he feel asleep during out presentation. Jet lag. Or disinterest. Or both. When we woke him up, he proceeded to try to sell us his own middleware and hardly looked at our game.

By this time we had graduated and had moved to our own office in Utrecht. A very small office for 7 people, but it was cosy and exciting. What we didn’t have, however, was money. We did some minor work-for-hire jobs, but since we weren’t fully committed to that, we hardly made any money there. Just enough to pay the rent of our office, but definitely not enough to provide ourselves with any income.

This is something I've seen quite a lot: studios who want to make their own games and finance that with work-for-hire rarely succeed at both. Either they hardly make any money from the work-for-hire, or they spend so much time on that that they can hardly focus on their own game. Often the result is that the game takes many years to build and turns out mediocre because of the lack of focus and time. The reason for this is simple: doing work-for-hire well and making it lucrative is hard and it's rare for that to work as an aside, especially for inexperienced recent graduates.

So, we didn’t make any money and we weren’t students anymore. How did we not starve? This varied amongst the founders. First of all, in September 2007 we managed to sell all the rights to De Blob to THQ, a then major publisher that’s now defunct. (Note that THQ Nordic is a different company that later bought the rights to the name and games of THQ, including De Blob.) For this we were each paid a nice amount (can’t disclose it due to NDA unfortunately), enough to pay the rent for quite a while. However, only 5 of the 7 Ronimo founders were part of the De Blob team, so 2 others didn’t have this.

Six of the founders had an additional source of income: the now defunct WWIK government subsidy. This paid recent art graduates around €600 per month. That’s less than half of the official minimum wage in the Netherlands at the time, but enough to not starve. To live cheaply, three of Ronimo’s founders rented an apartment together with one more person.

I personally didn’t get WWIK because I had some savings and thus didn’t qualify, so I went even cheaper: I kept living with my mum until I was 26 years old. I have a lovely mum though so I totally didn’t mind. Thanks, mum!

This is also a good moment to mention how privileged we are to be doing this in the Netherlands. In many places in the world all of this would have been much harder.

So, how did the pitching go? A few publishers were interested and one even flew over to do due diligence: judging whether we would really be able to make the full game. In the end none of them actually offered us a deal because Snowball Earth was too unique and we were too inexperienced to be trusted with that much money. We were asking for €1.5m development budget. Not much for the big game we envisioned, but definitely too much to give to a bunch of students who had so little clue about business and production processes.

Snowball Earth was too big a game to finish without funding, so we ended up cancelling it altogether. Years later we did release our prototypes, which you can still find here together with videos and screenshots.

What next, then? By this time indie was on the rise and we had managed to get Nintendo Wii devkits. We decided to make something small that we could finish and publish ourselves: Swords & Soldiers for WiiWare (the predecessor of the current Nintendo eShop).

We estimated we could make this game in 3 months. One year later, we finished and launched it. I’m still impressed that we managed to make something of that size and quality in just one year, and I’m even more impressed that we were stupid enough to think we could make something like that in just 3 months...

Throughout this year we still didn’t make any money, but we did hire interns. In the Netherlands internships are a standard part of many schools and are not paid like normal jobs. So for only €200 per month we could have a game student work for us full-time. Despite that low compensation, those interns were getting more money from Ronimo than we were! On average, we had 2 or 3 interns at a time helping with development.

In May 2009 Swords & Soldiers launched on Nintendo Wii. It got critical acclaim, reached the #1 selling spot on WiiWare in Europe and #3 in America. In total it sold 30k copies and made €146k during the first year (and very little on WiiWare afterwards). A big success for us at the time, but not that much money in retrospect.

In August 2009, after 2.5 years of working full-time with seven people, we were finally able to pay ourselves a monthly income. A whopping €600 per month! Oh wait, that’s super little… but it certainly felt like a big step forward!

Something we hadn’t realised yet at the time is the importance of porting our games to different platforms. That is, until Sony offered us money to make a PlayStation 3 port of Swords & Soldiers, including multiplayer.

To make this port and continue work on our next game OMG Space! (which would later be renamed to Awesomenauts) we needed more programmers. Up until this point I had been the only programmer at Ronimo (besides interns) and that wasn’t enough to make a port and a new game. We hired two programmers. Unlike us, those coders were paid real wages (though not very high ones). And so, while we the founders finally made more than our interns, we instead now had employees who made way more than us.

In September 2010 Swords & Soldiers released as a downloadable game on PlayStation 3. Unfortunately it didn’t make break even, so the only money we made from this was the initial porting budget we got from Sony.

Now that we realised that porting is a super important source of revenue, we also ported Swords & Soldiers to Steam and released that in December 2010. Making a port is only a fraction of the effort of making a full game, and every new platform is a new roll of the dice: a new chance at success. And indeed, while the PS3 version hardly sold, the Steam version would make us €120k in its first year and €35k in its second year.

Now that we had employees and paid ourselves a little bit, we had significant monthly costs. Too much to carry ourselves, so we were looking for a publisher for Awesomenauts. Near the end of 2010 this was becoming dire: we were only a few months away from being out of money altogether.

We were saved when we signed a publishing deal with DTP (yet another company that doesn’t exist anymore). The total development budget we got from them was €300k. Not much for a game of this size, but it was a lot for us! As is common, we received that money spread out over milestones and not all at once.

Awesomenauts was a very ambitious project, with complex multiplayer and simultaneously launching on two platforms that were new to us (Xbox 360 and PlayStation 3). We needed more programmers to pull that off. Good thing the budget we got from the publisher allowed us to grow a bit more. In the first half of 2011 we hired two more programmers and a producer, bringing the team’s total size to 12 full time employees. On top of that we usually also had 3 or 4 interns working with us.

The funding also allowed us to finally pay ourselves almost minimum wage: €1400 per month. Still less than our employees got, but at least we felt like we were finally making real money.

In March 2012 we managed to secure some additional income: Swords & Soldiers was included in the Humble Android Bundle and this made us €37k. Towards the end of the year it got included as a bonus in another Humble Android Bundle, making us another €10k.

This money was needed desperately, since Awesomenauts had seen numerous delays at this point. I don’t remember the exact original planned release date, but I think in total the console release got delayed by around half a year. The publisher didn’t give us extra budget for that, so we had to make do with the money we had.

In May 2012 Awesomenauts finally launched on Xbox 360 and PlayStation 3. But not before our publisher DTP went insolvent a mere week for launch. This made everything extremely complex and we didn’t know whether we would see any royalties at all. We got lucky: we had some unreleased DLC they wanted so we managed to strike a deal with the trustee for the insolvency so that the DLC would be released and we would still get royalties.

Nevertheless, Awesomenauts initially didn’t sell all that well on consoles and it took long before we got any royalties at all. We were nearly out of money but had one more card to play: a Steam port of Awesomenauts. Finances were so tight that we couldn’t pay ourselves anymore for a short period. We continued to pay our employees though, so only the founders were hit.

Then in August 2012 Awesomenauts launched on Steam and this version turned out to sell way better than the console versions. We were saved! And we had gotten lucky again with our publisher: since DTP was insolvent, they couldn’t pay for development of the Steam port of Awesomenauts, and thus we got the full rights to that version.

Awesomenauts kept doing very well so we supported it for 5 more years with tons of additional content. It also allowed us to finally switch what type of company we were: we switched from being a V.O.F. to a B.V. These are Dutch legal terms so let's not go into the details here. What it comes down to, is that a V.O.F. is strongly tied to the owners’ personal finances. If the company goes bankrupt, so does the owner personally. Being a B.V. is much safer, since now the company can go bankrupt without giving creditors the right to come after your personal belongings as well.

Being a B.V. does come with a requirement here in the Netherlands: unless you have good reason not to, the company needed to pay the active owners at least €2300 per month (after taxes). So in February 2013, six years after we started the company, we finally started to make a wage significantly higher than minimum wage. And even then it wasn’t that much: this excludes some insurances that are standard for employees but not for owners, and for me personally as a programmer: I’m pretty sure I could have made more had I worked elsewhere.

As far as I can tell, most game startups take several years to become financially successful. I think it might have taken us longer than most, but we made it at all and that’s already special. In fact, since the 'indiepocalypse' happened a few years ago most people who start a game company never manage to make a living at all (as I've previously said: the future of indie is amateur). With Ronimo we were lucky that we happened to start our company at a time when indie was hip and happening and it was relatively easy to reach players. Today, competition is much tougher than it was when we started, so chances of success are lower as well.

What’s the moral of this very long story? It’s simple: to start a game company, you don’t need just skill, vision and bravery, but also perseverance and a willingness to make little money for a long while.

5 tips for reducing stress as a game company owner

Being a company owner can be a stressful occupation. Your decisions can make the company successful or run it into the ground. There's plenty one can worry about: the game market is constantly changing, so what's the best strategy to follow? How to handle when a co-owner wants something different than you? Mistakes can cost you both your livelihood and your dreams: after all, most people who start a game company do so because they have a passion for doing their own thing. Oh, and if you have employees, you're responsible for their fate as well!

While such topics can indeed cause a lot of stress, I have been relatively relaxed under all of that for the past 13 years. So I was wondering: do I have any mental tricks that help me cope with all of it? Turns out I do! Here are 5 things that I do that help me experience less stress. I hope sharing these can help make entrepreneurship a slightly more chill experience for others as well.

Before I continue I should mention that there are many other factors that determine how stressful it is to run a business. For example, I've always made sure to live slightly cheaper than I could afford so that I could build up savings for cases of economic hardship. This post is not about such financial choices. This post is also not about how a successful game launch or signing a good publishing deal will alleviate stress. Nor is it about raging communities review-bombing your game over a single removed feature or seeing company finances being only a few months from bankruptcy. At Ronimo we've experienced all of these things and much more over the past 13 years and while the things I'll discuss in this post have definitely reduced the stress a lot for me personally, it's been an emotional rollercoaster nevertheless! This post however is about coping with the day-to-day, constant pressure of running a business.

Also, one more side note: I wrote most of this post half a year ago and held back on posting it because one of my colleagues got a burn-out just before I got around to publishing this article. This post isn't about that colleague at all, but it seemed rather insensitive to post anything about stress right after that so I shelved this one. Now that that's a little bit less recent I feel I can post this. In a way it's even more reason to post this, since it shows just how stressful things can be!

1. Figure out why the worst-case is still nice

To me the most important element of being relaxed when I'm afraid things might go wrong, is to figure out why the worst case would actually still be pretty nice. This way regardless of whether something is a success or not, I can always be happy about it. One of the easiest examples for this is that if your game fails to sell well, at least you can be proud of finishing and releasing your own game. That's pretty amazing by itself!

The point where this made the biggest difference for me, was when we started Ronimo. Something I wondered about back then was: what if we would work on a game for a year or two but then can't find a publisher so it would end there? No game released, no income for two years, company gone. That's pretty bad, right? Well, actually, to me back then even that scenario wasn't a nightmare. Making games was (and is) my dream job and making my own games with my friends is one of the best things in the world. In the worst case I would still have done the coolest thing for a year or two. That's pretty neat even if it hadn't been a success!

Another example of this way of thinking is more recent. The owner of another studio told me they were really stressed out over the idea that if their company would go bankrupt, their employees would loose their jobs. That's a huge responsibility and indeed a horrible thing if it happens! However, even here I would argue that the worst case still has a silver lining. If you had never started your company, those people wouldn't have had that job in the first place. Even if it ends, you as the studio owner have provided them with an awesome job for years. You'll have given them a chance to gather a lot of experience that will go on their resume and with which they can get their next job. This may sound crude and even though it stinks if it ends, being able to have done that even for a few years is already an amazing thing to have achieved!

2. Better to make a wrong decision than no decision

An easy trap to fall into when being responsible for big decisions is to analyse them into infinity. "Maybe if we gather some more information, we can make a better choice." "Maybe if we discuss it a bit longer, we'll all agree on the next decision." While it's certainly true that important decisions need to be researched and discussed thoroughly, it's also important to act. Try things. Experiment. Don't get stuck in decision paralysis.

As Asimov wrote in his Foundation series (which just so happen to be among my favourite books):

"To succeed, planning alone is insufficient. One must improvise as well."

Often it's better to try something and see whether it works, than to endlessly think about what the best choice is. In game design this is an obvious rule that most people know: prototype, experiment, test, iterate. What you may not realise is that this same mindset can be applied to business as well. The key here is to not just act, but also constantly evaluate whether what you're doing works. If it doesn't, then change it. Don't be afraid to make mistakes and don't be afraid to admit that you've made a mistake. It's far better to fix it afterwards, than to pretend it didn't happen.

For example, we released many updates to Awesomenauts and often we would debate how to communicate about them. What would be the best marketing strategy for an update? However, far better than that was to simply try things and if it didn't work, try something different with the next update.

Another example is a lot more mundane. At Ronimo our daily lunch with the entire team is a coveted tradition (pro-Corona, that is). However, now that we're growing it becomes impractical to let the entire team lunch at the exact same time. So it was suggested that we should spread the lunch period so that people don't all lunch at the exact same time anymore. Some of the owners of the company (including me) really disliked this idea since it seemed to go pretty strongly against Ronimo's very DNA. However, instead of debating this forever, it was decided to just give it a try and evaluate afterwards. Now that we've tried this, it turns out this not only solves the overcrowded lunch, but also solves the issue that the same cliques formed daily at the lunch table. Now that people are moving in and out of the lunch, where people sit is much less static. Even I now think the spread lunch period is an improvement! If we had tried to make a final decision on this topic before trying it, then I doubt it would have happened at all.

3. Ask lots of advice

Whatever you're doing, someone is bound to have tried something similar before, especially when it comes to the business side of running a game studio. Hearing their experiences is an invaluable source of information for making better decisions yourself.

You may think the games industry is pretty closed off, with all those NDAs (Non-Disclosure Agreements), press embargoes and secretiveness around new games. However, towards fellow devs many game studios are a lot more open. I've often emailed other studios, asking them how they approached something, and often I got really in-depth answers, sometimes even including offers for Skype calls. Of course this is easiest if you know someone at the studio or know someone who can introduce you, but in some cases I've even cold-emailed someone I didn't know at all and still got an insightful answer. And if you think that only goes for indie developers, think again: I know some people at AAA studios and even they were happy to give us advice on topics we struggled with ourselves.

Just keep in mind: be respectful of other people's time and don't go prying just out of curiosity. If you have a real question, ask it and learn from their experiences.

You may wonder how to do something back for people who share their knowledge. Often that's difficult because in many cases the person who gives advice is more experienced than you are or might just not be in need of your own knowledge. In my opinion that's fine. Instead of doing something for them, pay it forward: help someone else when you can and ask nothing in return.

4. Don't feel responsible for everything

A common pitfall when running your own company is that you feel responsible for everything. After all, it's your own company, or at least it partially is. While this may work at first, it's also a great way to get a burn-out, especially as the company grows. Once you employ a dozen people, it's impossible to check all the details of everything they do. Trying to do so costs too much time and distracts you from your own work. You'll simply have to trust them to do their work well and only check on some parts of it.

My own approach to this is that when a new programmer joins our team, during the initial period I review all their code. Then, as they get more experienced with our way of working and thus the amount of feedback I give decreases, there comes a point where I rarely check their code anymore at all. The key in my experience is that while that first period might be time-consuming and maybe even frustrating for both parties, it sets clear expectations as to what I expect in terms of code quality, working method and coding style.

Letting go can be really hard. The boss of another studio recently had a nice way of explaining why you need to do so anyway. He said something along these lines: "Previously I did everything myself. Now I employ dozens of people and don't have the time to code much myself anymore. This was frustrating, until I realised that all those people are working for me. Previously I could spent months making one thing. Now I tell all those people what to work on, and a few months later many things are done. Much more than I could ever do on my own. In a sense, while I don't do those things myself anymore, I've gotten more productive than ever."

5. Accept that things won't always go your way

Most people who start a game company do so with a few co-founders: often there are 2 to 4 founders. In our case we went a little over-the-top and started the company with no less than 7 founders, all with equal ownership rights over Ronimo Games. I've often been asked how we managed to make this work: seven captains on a ship is a whole lot and they're bound to all steer the boat in a different direction. That's bound to produce a lot of friction.

The reason this has worked for us for over a dozen years now, is that having such a big group of founders meant that we immediately ran into disagreements but needed to make decisions anyway. So we decided that if we don't agree on something, we'll just decide by voting. In practice that means that a lot of times we make decisions that I personally don't agree with. Realising this early on also made me accept this early on. Once you've accepted that many decisions will not be exactly what you want them to be, it becomes a lot easier to cope with this.

I expect smaller groups of founders will often have this problem to a lesser degree: it's easier for 3 people to share the same opinion than for 7. However, that also means that when you don't agree, a group of 3 founders might also be more likely to get into a fight over it, resulting in lots of frustration and stress. So I think that even for smaller groups of founders, it's crucial to accept early on that even though it's your own company, it will not always go according to your own plan.

Note that this mindset will also help when dealing with employees. To make talented people shine, you have to give them some room to express their own creativity and ingenuity. This also means occasionally letting something happen even though you disagree with it. As a boss you may technically have the right to force your own decisions on your employees, but sometimes it's better not to.

Regardless of your mindset, there's bound to be stress involved when starting and running your own (game) company. However, the things I've listed in this post have greatly helped me cope with it all and have made me relaxed most of the time. What are your tricks to reduce stress and stay chill?

An overview of many ways of doing a beta

Giving players access to the beta of a new game or new content before it's released is a great way to get feedback and find bugs, allowing you to add that extra bit of polish, balance and quality before the official full release. There are many different ways to give players access to a beta. Which to choose? In this article I'd like to give a comprehensive list of options in today's market and discuss the differences.

Traditionally bugs in games are found by QA testing companies. However, hiring a QA company to exhaustively test a complex game is very expensive. Many smaller companies don't have the budget to hire QA at all, or can only get a limited amount of QA and can't let QA cover every aspect of the game, let alone doing so repeatedly for every update. However, even if you do have the budget for large amounts of QA testing, that won't give good feedback on whether a new feature is actually fun or balanced. That requires real players, experiencing the content in the wild. So whether you can afford paid QA or not, a beta might still be a good idea.

There are many aspects to doing a beta. Should everyone get access, or only a limited number of players? Is the beta for a new game that hasn't released yet, or for new content for an existing game? Is the beta also intended to gather additional development funds, or only for testing purposes?

Another interesting topic is what to actually put in a beta. Should it be all the content, or only a portion so as not to spoil the main release too much? (There's an interesting bit about that in this talk about Diablo 3.) How early should we do a beta? Although these are important questions, to limit the scope of this post I'm going to ignore the content of the beta: today I'm focusing exclusively on how the beta is delivered to customers.

Over the years at Ronimo we've done a bunch of different approaches to betas. With Awesomenauts and the recently released Swords & Soldiers 2 Shawarmageddon we tried betas before release and for new content, through DLC and through beta branches, limited paid betas and open betas, and more. That means a large portion of this post is based on our own experiences, but since I want this list to be as comprehensive as possible I'll also discuss approaches that we haven't tried ourselves.



Since consoles offer very few possibilities for betas and since Steam is the biggest and most complete platform on PC, this post mostly lists options in Steam. Some of these will probably be possible in similar ways on competing platforms like GoG or Itch.io. If I missed anything that's fundamentally different on other platforms or if I missed some approaches altogether, then please let me know below in the comments so that I can add them.

Steam beta branches

For updates to an already released game

This is the most common way to do a beta on Steam. When uploading a build you can select in which branch it should go live. This makes it possible to release a build under a 'beta' branch only. Users can then simply right click the game in Steam and select the branch they want, after which Steam will download it and replace the main game with the version from the branch.



If you want to limit access to the beta you can set a password for the branch. This works fine, but it's a single password for all users, so if you share this password with players there's a good chance that some might share it further with others. For Awesomenauts we got lucky with our community: no players posted the passwords for closed betas publicly online. Undoubtedly some players did share a password with a few friends privately, but that never caused any problems.

Branches are also great for internal testing purposes. When we want to test a build internally or want to provide a build to QA we also use Steam branches and simply share the password only internally or with the QA company.

Beta through (free) DLC

For updates

A downside of Steam beta branches is that when you switch to or from a branch, Steam downloads and updates the game to this version. In other words: switching takes time and bandwidth and it's not possible for users to have both the beta and the main game on their computer simultaneously. If updates are hundreds of megabytes or even bigger then this gets cumbersome for users. In cases where an Awesomenauts beta didn't get a lot of feedback we often saw players mention that they didn't like to wait for the download.

Our solution was to not use beta branches anymore and instead put the entire beta build in a DLC. Users can then enable the DLC to get the beta. This allows them to have both the main game and the beta on their computer simultaneously. On Steam it's possible to set a DLC to being disabled by default, so users can deliberately choose to get betas or not by enabling the DLC in the Steam interface.

That the beta is a DLC doesn't mean it needs to be paid: it's possible to do free DLC on Steam. Nevertheless, the option to make the beta paid is useful in some cases. For example, backers of the Starstorm Kickstarter campaign were initially the only players who got Awesomenauts beta access. We could have handled this by making the DLC unlisted in the Steam store and sending keys for it to Kickstarter backers. I guess it's even possible to make a beta a paid DLC directly on Steam, although I imagine this might rub some players the wrong way.

Giving out keys for the main game before launch

For new games

This is the easiest way to do a beta before the release of a game. Just put the build live before the store opens and give keys to the players you want to have access to the beta.

A big question with this approach is what to do once the game actually releases. Do those users keep the game, or do you revoke those keys? If this was an open beta then you'll probably want to revoke the keys, but in case of a closed beta with a small group you may also choose to consider the game a gift for those who did beta testing.

If you choose to revoke the keys, be sure to do so a few days before launch. I've heard of cases where users couldn't buy the game on launch because the revocation of the keys had been done too shortly before launch: Steam apparently hadn't processed that entirely yet. I have no idea how much time is needed for that to not go wrong, but revoking the keys a few days before launch seems safe enough I guess.

Beta as a separate app

Both for new games and for updates

An issue with giving users keys to the main game and then revoking those before launch is that if they had the game wishlisted, then the wishlisting will be gone after this. A solution for this is to do the beta in a separate app entirely. This way it's an entirely separate game with its own settings, achievements, leaderboards and AppID. This version of the game is not listed in the store, so it only exists for those users who activated the game with a beta key.



An additional option when doing your pre-launch beta through a separate app is that it can continue being used after the game has launched and can then be used to do betas for updates.

Note that some developers have reported that Steam didn't allow them to do this. We've applied this method in Autumn 2018 ourselves and it wasn't a problem then. Apparently Steam's rules for whether this is allowed or not are not entirely clear.

Steam Early Access

For new games

Early Access allows you to sell a game that's not actually finished yet. This way development of the game can be done in a very public and interactive manner, getting constant player feedback while still adding core systems to the game. Another benefit is that Early Access games are generally paid, so this can help generate additional funding before the actual launch of the game.

Common wisdom seems to be that the launch into Early Access should be considered the main launch of the game. In many cases the final launch of a game is completely ignored by press and players alike, unless the game became a success during Early Access already. This means that a game should be really strong before going into Early Access: it might have missing features and bugs but if it's not super fun yet, then you likely won't get a second chance when the game releases out of Early Access.

An interesting aspect of Early Access is that it functions as a strong excuse towards players for bugs, balance issues and a lack of content. Reviews by both players and press for an Early Access game will often mention things like "It's buggy but that's okay since it's still in Early Access." The equivalent of that for a normally released game is "Don't buy this buggy mess."

For some users Early Access has left a sour taste because some games never launched out of it or didn't deliver on the promised features. Nevertheless, Early Access remains a strong category with many successful games.

Xbox Game Preview

For new games

While Xbox Game Preview is roughly the same as Steam Early Access, I'm listing it as a separate option because it's the only form of beta or early access that's currently available on consoles (as far as I know), making it quite a unique thing.

I don't know what Microsoft's policy around Game Preview is exactly, but I expect this option is not open to just everyone, so if you want to go this route you probably need to talk to Microsoft. I'm guessing that for the right projects, Microsoft might even have some budget to help get them into Game Preview. One thing to keep in mind is that competing platforms might be less interested in featuring your game on launch if it has already been on Game Preview for a while, just as they are generally less interested in featuring a game that launched on another console first.

Soft-launch on a smaller platform

For new games

As I mentioned above, the Early Access launch version of a game needs to be pretty strong. That's kind of counter to the goal of Early Access: getting feedback in an early stage. To work around this problem some developers choose to release their games on a smaller platform like Itch.io first, and then come to Steam (with or without Early Access) once the game is strong enough.



One might expect this strategy doesn't work: by the time the game gets into Steam Early Access, it's been available elsewhere for a while so it's old news. However, I've heard from some devs that if a PC game is not on Steam, to a lot of people it doesn't exist. So even if it's been on another store for a while, the moment it gets to Steam is apparently considered the 'real' launch. (This logic of course doesn't apply to juggernauts like Fortnite, Minecraft and League of Legends.)

Regional soft launch

For new games and for updates

This is a common approach in the world of free to play mobile games: launch in a specific country, improve the game until it makes enough money per user, and only then launch worldwide. I haven't heard of any PC games using this approach, but undoubtedly it has been done. I expect the challenge here would be that hardcore gamers are much more informed and internationally connected than casual free-to-play mobile gamers. If your game is to sell through word-of-mouth then it's going to be weird if the word on Reddit and Discord ends at a single nation's border. Still, I imagine this approach might work in some cases, especially for single player games.

So, that's it! These are all the relevant ways I know of doing a beta in today's market. Did I miss any? Let me know below in the comments so that I may add them! Which approach do you prefer?

The future of indie is amateur

The number of indie games being released on Steam and consoles has sky-rocketed this last year. At the same time, the amount of money being spent on indie games doesn't really seem to increase. In other words: the average indie game is making much less money! SteamSpy recently released some graphs that show that while total sales for all games together are pretty stable, median sales per game have dropped enormously. You only need to open Steam's list of new releases to see why: so many new games launching every day! Five years ago only a couple of games launched on Steam per week. Now there are dozens launching daily, and they're all competing for the same players. The average income of a new indie game has dropped so far that some even call this current trend the 'indiepocalypse'.



There are several reasons we're seeing this now. The most obvious reason is that marketplaces like Steam have made worldwide distribution easy. They have become more and more open to release games, and not just the cream of the crop. Five years ago, if a hobbyist made a game he put it on Newgrounds and didn't expect to make any money. In contrast, professionally made indie games released as paid products on other platforms and thus competed with hobby developers in a less direct manner, and often in different genres. Today many smaller games can also release on Steam. If Steam keeps going in its current direction, then soon everyone will release their games there. The same goes for other platforms: ID@Xbox isn't anywhere near the speed of Steam yet, but with 21 indie games released in August alone they too are stepping up the pace enormously.

Another important factor is that tools like Unity, GameMaker and Unreal make game development much easier and cheaper than it ever was. Previously many developers were confined to 2D browser games because 3D was technically too complex, as were mobile and console. Licensing a decent game engine that handled this was very expensive. Five years ago only teams with significant technical skill could make such games, yet now these engines don't require much more than the click of a button to reach most platforms.

The final drop is that game dev courses are abundant now. For example, here in the Netherlands we used to have only a few schools teaching game development. Today there are dozens. I'm seeing this same kind of educational expansion everywhere in Europe. More graduates means more people to make games and many of those are starting indie companies straight out of school.

Together these three factors have caused an enormous influx of people all trying to make a living making indie games. Their number is growing much faster than the market, so the average sales of indie games are dwindling. Many indie games that release today won't make much more than a few thousand dollars, far from enough to make a living as a full-time game developer.

What does this mean for indie studios? I recently met a young dev who had started a company with friends and spent a lot of time making their first game. When it launched it literally sold only a few hundred copies. His conclusion? He was going to look for a job and continue making his own indie games – in his spare time, as a hobby.

I think we are going to see this pattern for a lot of start-ups. There are so many games that only a few actually make a decent buck. The rest won't make enough money to sustain the company, causing those indies to bail out of trying to make a living as an indie developer. Many will become amateur indie developers instead.

I don't think this dire financial situation will stop people from making games. Development is just too much fun and that small chance at success just too awesome. What if your game becomes the next Braid or Minecraft? If you can't do it professionally, I'm sure many people will just build those games as a hobbyist instead.

Talented amateurs won't be able to make AAA games like the next Grand Theft Auto, but they will be able to make games similar to what indie teams of only a few people can make. A bunch of highly talented hobbyists working on a game in their spare time for a few years might be able to make the next Banished or Nuclear Throne. This is great of course, but they will be competing for the exact same audience as those trying to make a living as an indie.

Full-time indies competing directly with hobbyist developers will cause the chances of indie games being a financial success to plummet even further than they already have. As the chances decrease, it will become highly infeasible to start a company and 'go pro'. Heck, it probably already has! In the long term people will realise this beforehand and most won't even try to make a living making indie games anymore. I expect they'll just get a job somewhere (hopefully still as game devs!) and keep doing their own projects on the side.

Of course, some will become a hit and be able to make a living. Some others already have an audience and are really good at what they do, so those too will stick around. But in general, the vast majority of future smaller indie games will be amateur games.

Is this bad? No: 'amateur' and 'hobbyist' aren't negative words. They just indicate someone who does something without making money from it. This doesn't mean they can't be good at what they do: just like there are tons of hobby musicians who are actually amazingly good, we will be seeing more and more fantastic games by talented hobby game developers. As well as a lot of bad ones of course, which is fine as long as they too are having fun making games. I expect there will also be a lot of indie games from people who have a regular job as a game developer or freelancer and make their indie games as hobby projects on the side.

I've heard the current trend described as the 'indiepocalypse'. I don't think that word makes sense: this isn't an apocalypse as it isn't the end of indie. Instead it's a shift from professional indie to hobbyist indie. We'll keep seeing awesome indie games and some of those will break through to huge success.

There is a big downside though: this is very sad news for those who release their first game now. Many will have started their company when the indie scene was still small enough that all decent games sold at least okay, not just the amazing ones. Many will be disappointed when their game launches and doesn't reach an audience. I can only hope they'll realise how awesome it is to have made their own full game and feel proud of having released it. But it's a bittersweet second prize, when you dreamt of making a living as an indie dev.

What does this all mean for the bigger indie studios, the ones with more than ten people working on a single game? I don't know. They're capable of creating bigger, more polished productions than hobbyist developers, making those bigger games stand out from the crowd. Will this be enough for a good chance to earn back the much bigger investment? Time will tell. One thing I expect is that they will make more business deals with publishers, investors and other partners to decrease their risks and gather the required budgets. This will move those bigger indie studios further away from what is traditionally considered 'indie'.

If an indie studio is successful and grows its team, it is often not considered 'indie' any more. I regularly get the question whether our own studio Ronimo is still indie: “Aren't you too big for that now?” If that's true, then 'success' often means 'not indie anymore', as using that success to grow the studio apparently isn't indie. By that definition the only successful indies are those who not only have a hit but also stay small.

From a gamer's perspective I don't think any of this matters much. My favourite game this year so far is Ori And The Blind Forest. For me as a gamer it offers exactly what I look for in an indie game: it tackles a genre that AAA doesn't do (2D platformer), has a beautifully crafted atmosphere and brings a focussed experience that dares to take risks. Yet I haven't seen this game mentioned as being 'indie' at all. Apparently a type of game that I perceive as typically high-end indie isn't called 'indie' anyway.

An odd part in all of this is the new breed of 'indie publishers'. Now that the overflow of indie games has made reaching a bigger audience so difficult it makes sense to look for a partner to work with: a publisher that specialises in marketing indie games. However, I remember 'indie' was originally mostly defined as 'not working with a publisher or investor'. Doesn't that make the term 'indie publisher' a contradictio in terminis?

The result is that 'indie' is a word with very little meaning today. It's more marketing buzzword than anything real. Even the gigantic company EA has published games that they marketed as 'indie'.

Let's piece all of this together. What do we have? The vast majority of smaller indie games doesn't make money. Hobby devs can use cheap, high quality engines to make bigger games. They can release their games on more open platforms to reach more people. And finally, the bigger games often aren't called indie. Combining this can lead to only one conclusion: in a few years the word 'indie' will mostly be interpreted as 'probably made by hobby developers'. In other words: the future of indie is amateur!

Why indies should care less about financial independence

Many people in the games industry think the word "indie" stands for "financially independent", and indeed this is something that a lot of indie game developers care about a lot. Although it is an important topic, I think we should care about it less: being indie should be about creative independence, not about financial independence.

You might argue that one is impossible without the other: if someone is funding your game then of course that someone is also influencing your creative decisions. However, what a lot of people don't seem to realize is that no one funding your game is also a big influence on your creative freedom. You will need some way to get food and pay the rent if you want to spend a significant amount of time making your game the best you can.

Disclaimer: this post is only targeted at those who want to make a living making games. If you are making games as a hobby in your spare time, then please ignore this post and do whatever you want! ^_^

Without enough money to make a game you will often have to cut back on the quality and size of the game. You might even have to choose a different game concept altogether. In many cases this influence might be much bigger than that of a publisher or investor. Game development is always about compromises between time and budget on one side, and the quality of the game on the other side. Having an investor might open up a lot of creative options, even if the influence of the investor also closes some.

Of course you can work around all of this by just making really small games. Nothing wrong with that, but being constrained to making small games only is just as much a creative limitation as a pushy publisher would be.

The ultimate solution is to just have a hit. Then your next game will have a big budget and you will have complete financial independence. But few people have a hit and you cannot just force yourself into one. Until you have that hit, you will have to work with your real situation.

A common solution is to do work-for-hire half the time and spend the other half of the time on your own indie games. This can of course work, but it also means spending half as much time on your own game, or taking twice as long to build it. Often this simply results in spending most of your time on work-for-hire to make ends meet while making a mediocre game of your own on the side. Doing work-for-hire is often more limiting to development than any publisher would ever be.

Another reason it might sometimes be a good idea to let go of your financial independence is that you can focus more on your actual game. The business and marketing of releasing games takes a lot of time, so working with a financial partner who takes care of these things can free up valuable time to make your game better.

Note that actually getting financing from a publisher, investor, platform holder or other kind of partner is really difficult. In that sense it is not a simple choice of yes or no. What I am saying here is that indies should consider this option more often, not that it is an automatic win.

The solution that is all the rage right now is to avoid publishers and investors and go for crowdfunding instead. Crowdfunding is often praised as the ultimate freedom for an indie developer: if you successfully get funded you won't have a pushy publisher and you can make whatever you want with the help of the crowd. If only this were true...

In reality being crowdfunded is an incredibly limiting form of funding. You will have to make a lot of promises of how awesome the game will be to entice players to fund it, especially if you look for funding early in development. But what if during development some of those planned features turn out to not actually be fun? In practice there is a good chance that your backers turn out to be extremely exacting and will demand that you deliver exactly what you promised, even if you have already figured out that what you promised was just a really bad idea. Game development is inherently iterative, so you cannot know what features work until you've built and tried them.

It gets even worse if during development you get a better idea. For example, let's say that during the crowdfunding campaign you promised that the game would feature villages that grow as you progress through the game. What if during development you get some great new ideas for wildlife hunting mechanics that would be much better for the game than those villages. You cannot do everything and during normal development you would be able to just cancel the whole concept of the villages altogether and build the hunting instead. When being crowdfunded there is a good chance that doing such a thing would raise an angry mob. The so-called "financial independence" of crowdfunding might turn out to be very limiting to your creative independence!

A good example of this was recently seen in the rage over Godus. During their Kickstarter campaign they promised all kinds of things that turned out differently or not at all during development. Basically, the game just evolved as 22 Cans worked on it, and maybe it turned out to not be as much fun as was imagined at the beginning. The community reacted so aggressively that they even started threatening Peter Molyneux's family. I happen to also be a backer of Godus and all I ever expected from 22 Cans was to make the best game they could within the spirit of their Kickstarter. But this is not what the majority of the community expects. A specific feature set was promised and that feature set needs to be delivered or Peter Molyneux's family gets it. It is a sad example of the crowd stifling development, not supporting it.

My point here is not that crowdfunding is bad. The community funded the big Starstorm expansion for our game Awesomenauts on Kickstarter. This allowed us to grow the game way bigger and better than we otherwise could have. We are extremely thankful for that and really happy with how the collaboration with the community has been going so far. ^_^ I am just saying that the creative freedom that crowdfunding would give is extremely overrated and you should realise this before starting a crowdfunding campaign. Good communication and choosing the correct wording (like avoiding "promises") might also help a lot.

Of course my point in this post is not that every indie should start looking for a publisher or investor. There are a million ways to get your gig going. For example, I kept living with my mom during the first four years of Ronimo. This way hardly any budget was needed and we could spend as much time as needed to make the best games we could. There are many other ways to make things happen. Some concepts, like my crazy live-performance-art-game Cello Fortress, are just so impossible to make money with that no business would ever want to invest in it, so a different way of 'funding' is needed. My solution there was to just make the game in my spare time and not expect to make any money at all (note that I did get some funding for it from the Gamefonds government fund once I had a basic version running).

An obvious reaction to this post would be that I am "telling indies to be less indie". If your definition of "indie" is "financially independent" then yes, that is exactly what I am saying. And honestly, if that is your definition of indie, then I don't care about indie anyway. The only thing that really matters to me is the creative freedom to make the games I want to make, and that is what I consider "indie". I don't care what financial constructions are needed for that and I definitely don't care whether anyone else wants to call that "indie" or not. The only thing that really matters is to make awesome games.

What many indies are doing wrong

The indie explosion has finally happened. New indie companies and teams appear every day. At the same time a lot of pessimism has entered the scene: so few indies are actually making money! This is mostly because the market simply isn't big enough to support us all. But I believe another cause is that a lot of indies are all making the same mistakes. Here is what I think many indies are doing wrong.

Before I continue, a little disclaimer: this post is about what I think gives indies the best chance at making a reasonable income from their games. If you don't care about that and just want to have fun making games, then none of this applies.

Too small games

Every day dozens of indie games are released. During big game jams this can even be hundreds during a single weekend. To stand out from this crowd more indies should focus on making larger games. If you and your team spend dozens of man-months on a single game, then that game is much bigger than most competing games. This way you aren't being compared to a dozen games per day, but 'only' a few games per week.

Too many gimmick-games

Lots of indie games are based on a super unique idea that is fun... for exactly five minutes. There are tons of games that purely resolve around some weird gimmick. This trend is fuelled by game jams, since it is often impossible to make more than that in just 48 hours. Such gimmicks can be fun and exciting, and can sometimes grow into larger products like the excellent World Of Goo. But too often they don't grow beyond a simple gimmick.

The true skill of the game designer isn't in coming up with something original, but in turning that original idea into a substantial game that is enjoyable for hours. And no, adding a highscore list to your gimmick-game doesn't solve this: very few people will be triggered enough by that to play longer (even if it does work for a few people who might play your game for dozens of hours to get the best score).

Not enough polish, depth and quality

Very few indie games seem to execute on all fronts. Looking at trailers it is rare to see a game that has interesting, original gameplay and a cool visual style and good animation and good audio and etc. A game can't be excellent if not all aspects are at the very least acceptable. Especially animation seems to be something that few indies get right.


Too many bugs

Many indie games launch with a lot of bugs. Early Access seems to have triggered a trend where bug fixing and polish isn't valued as much any more. It seems like many developers think we only need more features and more content. You might want to reply that Minecraft and DayZ were huge successes despite being really buggy, but this isn't the norm and not an example that should be followed. In general, good games sell better than bad games. Don't make a bad game.

Too small teams

All of the points above have one thing in common: you need to spend more time on a game. This is easier said than done of course. What if a lot of indies joined forces and formed larger teams? Ten people all making a game on their own could combine into ten people making one big game together. Not only does this allow making bigger and better games, but it also fixes the problem that one person can't be good at everything. With a larger team it is possible to have specialists on board, instead of only generalists.

We made our first big release Swords & Soldiers 1 with a team of seven people and spent a whole year on it, full-time. Yes, we were lucky that we released that game in a time when there was hardly any indie competition, but that isn't the only factor. With around 100 man-months spent on it (including interns), Swords & Soldiers 1 was much bigger than most indie releases today. So even in today's crowded market it would stand out at least a little.

To avoid confusion: by "bigger teams" I don't mean 50 people. I mean 5 to 15 people who work on a game full-time for something like 1 to 3 years. That is big for an indie studio but still minuscule compared to triple-A.

Too many side-jobs

A lot of the indies I meet make money through work-for-hire and then spend the remaining time on their indie games. I understand the necessity of this of course, but often it doesn't work. If you work on your game part-time, how are you ever going to spend enough time to make a truly polished game? It is possible of course, but not focussing fully on your main game makes it really difficult.

How to fund development then? For me personally the funding was really simple: I kept living with my mom until Ronimo made enough money to live on. This took a whopping four years! I wasn't the only one living cheaply back then: three of the other founders of Ronimo rented a single apartment together. Had we sought a normal job, each of us would have made enough to get a decent apartment of his own right away. If you really really really want to make it as an indie, you have to be willing to make serious personal sacrifices. (Note that my mom is great, so not being able to move out until I was 26 wasn't that bad.)

Too little focus on the craft

Making games is hard. Programming complex systems is hard, drawing anatomy is hard, designing puzzles is hard. To make good games, you need to hone your craft. This seems obvious yet in the indie scene there is very little emphasis on hardcore creation skills. I saw this recently at the Screenshake indie festival in Belgium: hardly any of the talks were about actual development. Of course there should be room for a conference that focusses on other aspects of indie games, but I do think it exemplifies a trend that the only indie conference of Belgium ignores the craft of making games altogether.

Unity and GameMaker are a big part of this: they have made it possible to make games without serious technical skills. This is great but if you don't have those skills then it is also extremely limiting. Many indies wouldn't be able to make tech that isn't available as a standard Unity plug-in. This limits your possibilities and makes it more likely that you will make something similar to what others are making. Our own game Awesomenauts and my hobby project Cello Fortress wouldn't have been possible without serious tech knowledge of respectively multiplayer and sound programming. Having the skills to make whatever you want opens up enormous possibilities to stand out from all of those who are limited by the standard features of Unity and GameMaker.



No originality

This point pains me greatly. Five years ago being indie was all about being original, expanding what games can be and delivering unique experiences. Today so many people are making pixel-art rogue-likes, voxel sandbox games and platformers-with-a-twist that it seems like 90% of all indie games fall under one of these very specific categories. Not to mention zombies... I think it is super lame that 'indie' is now often the equivalent of unoriginal me-too games. This also means that you are competing with lots of very similar games, decreasing your chances of success greatly.

Of course not everyone is doing the same thing, but too many indies are. There are opportunities elsewhere. For example, Reus and Banished each brought a unique twist to the god-game/management genre, and both sold really well. For some reason hardly any other indies were doing this genre so Reus and Banished easily stood out.


Stand out from the crowd

Luck is always involved in success, but my impression is that if you want to stand a decent chance, you need to have at least one of these:

• A better game than the competition
• A game that does something truly new
• Appeal to an underserved niche audience
• More marketing budget than the rest (and being pro at using it effectively)

That last one only really applies to big companies with big budgets. I think a company like Supercell simply bought the success of Hay Day and Boom Beach through the massive marketing budget they earned with Clash Of Clans. For an indie, the other three are the reasonable alternatives.

A great example of this is Ori And The Blind Forest, currently a big hit on Steam. Not only is it incredibly polished and beautiful, and thus simply better than most other games, it also serves an underserved niche: big metroidvania 2D platformers are rare. Luck is always involved, but this game had really good chances at becoming the hit it is now.


Don't blindly follow my advice! Instead, figure out your own path and find an original way of doing things. There are a million ways to be an indie and many can work. But please stop all making the exact same games and mistakes, and consider what I have explained here. Some of these things are really difficult to achieve, for reasons of budget, skill or inspiration, but that shouldn't be an excuse to not strive for them!

Special thanks to Ronimo producer Robin Meijer for discussing these topics with me and coming up with most of that list at the end. This is the second part in a short series on the state of indie. The first part was about luck and in a few weeks I will write about why I think indies should care less about financial independence.

Luck and success in the indie business

Luck is an important part in the success or failure of any game studio. Why do some studios succeed while so many others never make a significant amount of money? Regardless of how good your theories are on what makes a successful business, you can never know for sure which games are going to be a hit. Games are entertainment and hit-driven and thus their success is inherently unpredictable. Luck cannot be controlled, but you can help it a bit by making the right choices. Looking at what many starting indies are doing right now, I think a lot of them don't think about luck enough. Here are some of my thoughts on the matter.

The success of a game is determined pretty much equally by three factors: the game, marketing and luck. Marketing and luck are just as important as the game you are making. If you do not market your game, then no one will know it and thus only a LOT of luck can make it a success. Similarly, if your game is not good enough, then it is also very unlikely to sell well.



While luck cannot be controlled, you can make such decisions that you need as little luck as possible. If you make an awesome game, do really good marketing and release it on the right platforms, then your chances are actually pretty good. But luck always remains a factor. Even the very best games can sometimes fail, and even the worst games sometimes become a hit. Anyone remember Psychonauts? It is considered a classic now, but sold hardly any copies at the time. On the other hand Flappy Bird was an enormous success, despite how crappy that game actually is.

When making your business decisions it is of course a good idea to look at what other companies are doing. What games sell, and why? However, it is a big mistake to attach too much importance to the outliers. Lots of people look at Minecraft and try to copy what it did, hoping to achieve similar success. But Minecraft is a one-in-a-million outlier. Of course Minecraft has some great mechanics, but it also required an enormous amount of luck to become that successful. The chances that you can achieve something even remotely similar are practically zero.

The same goes for Angry Birds and Candy Crush. It is not because of great talent that these games became such huge successes: they are well-made for sure, but there are tons of other games of similar type and quality that somehow did not become such hits. Before Angry Birds and Candy Crush became a success, there was no way anyone could have guessed that these would be the titles to become such big hits.



A strategy some studios use is to not make one big game, but instead make lots of small games and then hope one of those becomes as successful as Angry Birds. The reasoning behind this strategy seems to make sense: every game you release is a roll of the dice. Releasing more games gets you more rolls of the dice, increasing your chance at success.

I do not believe this really works. I think a single really good game has a much bigger chance at becoming a success than dozens of lesser games combined. Of course it is impossible to prove a theory like this, but I believe that a better game has an enormously larger chance of becoming a hit. If you can raise your game's quality from a 7 to an 8, or from an 8 to a 9, then you stand a much, much, much better chance. If you can somehow make a game that scores a 9.5 on Metacritic, then you can be almost certain it will sell like crazy. Even then you can never be sure though!

For this same reason I also do not believe in the 'fail early' strategy that some companies use, especially in combination with Early Access or free to play. The idea of 'fail early' is to release your game when it is only half of what it could be, and then see how well it does. If it does well, then you continue development and make it better. Otherwise you just drop the game and make something else. Like above, this allows a company to make more games and thus get more rolls of the dice. I do not believe that this works: the chance of the game becoming a success is infinitely better if the game itself is much better. That game that is dropped because the half-finished version did not sell well might have become a hit if it were actually developed into a good game, instead of a buggy or too small one.

(Note that I do think Early Access and soft launches can sometimes work, but for other reasons: they provide tons of testing and user feedback and it might also help fund the rest of development.)



'Chance' is also why big publishers can be relatively stable over time: they release a lot of big games, so the chance of them all failing is really small. This is the benefit of size, and it is a benefit that indie companies generally cannot have.

A good way to get more rolls of the dice is porting. If your game failed on one platform, it might still do really well on another, especially if that other platform has a different audience.

We have experienced this ourselves: Swords & Soldiers was a hit on WiiWare back in 2009. A year later we released an HD version of the game on Playstation 3, with added online multiplayer, but this sold very poorly. Then we released the game on Steam, and there it again sold really well. In hindsight one can come up with theories on why it failed on Playstation 3, but beforehand we had no idea. Every port is a new roll of the dice. Ports are much cheaper and faster to develop than completely new games, so porting is in general a good idea.



Luck cannot be controlled, but you can influence it. I would like to finish this blogpost with a great example of this: our own Awesomenauts. Awesomenauts is a big hit with around two million copies sold. Its success is partially due to its excellent release timing, which was pure luck.

Awesomenauts is a complex game to communicate. During the three years it took us to make the game, League of Legends appeared and became a gigantic hit. Suddenly our marketing became really simple: Awesomenauts is platforming League of Legends! This is a message everyone understood and that immediately had people intrigued with this interesting combination of elements. This helped our sales enormously.

There is no way we could have planned for this: the game took three years to develop so at the beginning we had no idea what would happen in the meanwhile. This might make one think that the success of Awesomenauts was all luck no skill, but this not the case at all. More like the opposite! Awesomenauts has a unique concept, is large for an indie game and is high quality. We spent a lot of time on marketing and have so far released the game on four different platforms, giving us four rolls of the dice. All of these combined mean that our chances were pretty good to begin with. Still the game could have failed, and luck was the final push that we needed.

There are two ways to improve your luck: get more rolls of the dice by having more releases, or improve the chance of each roll by having better releases. I personally think each release should be the best possible, by making a remarkable game with good marketing, a fitting payment model and on the right platforms. You can also handle luck by finding an investor who is willing to invest enough to make several games, so that you get more rolls of the dice. There are many possible approaches and it is important to think about luck and make sure your chances are as good as possible.

This is the first post in a short series on the state of the indie business. Part 2 is more controversial and will hopefully stir up some discussion, as it is about what I think many indies are doing wrong.

Other developers on the ideal patching frequency

Last week I wrote a blogpost about how we think it is better to have a bigger patch once every one or two months than to have really small weekly patches. I was curious what other developers' experiences with this are, so I asked around for more opinions on this. Since patching on console and mobile is so different I looked for developers who have a game on Steam, which is the platform that enables regular patching best.

Someone also pointed me to the Valve talk where they explained the importance of communication around patches and how this helped them grow Team Fortress 2. This is an incredibly interesting talk, so be sure to check it out:



Here are the replies I got from fellow developers:

Jamie Cheng from Klei
developer of Don't Starve

"While I have lots of opinions, I think it comes down to "it depends". Personally I think many devs try to do it the Valve Way only to find they don't really, truly understand why it works for Valve."

Mark Morris from Introversion
developer of Prison Architect (currently in Early Access)

"I guess the update frequency is linked quite closely to the style of development. For us, we wanted to produce quite meaty chunks (the hope being that we would get press coverage for individual updates). A month gave us enough time to develop decent additions, but was at a frequency that would still be engaging for the players. I could see weekly working, but I think that each update would be a lot less polished and would have a much more iterative development feel about it."

Kimiko from Berserk Games
developer of Tabletop Simulator (currently in Early Access)

"I think it would also depend on the game. For us in Early Access, we are one of those who patch every week or 2 weeks. Our game is a different spectrum compared to ones with stories, weapons, & what not. So patching each week works well for us. We're only doing this for Early Access though or for "bigger" updates, we'll spread it out a bit, like when we add in Oculus Rift or some of our other bigger stretch goals. Once we are out of Early Access, then we'll spread our updates out every month or so."

"There's only two of us and we work well putting out our patches each week, because it's usually about tweaking things, fixing bugs and implementing a feature. TTS is more for people to create their own games, so for us, it's better to get things out to help our users out more. Once we feel TTS is at the point where the community has the tools they need to create their own games to their fullest abilities, then we'd go out of Early Access and we wouldn't need to update every week anymore. But my point is, is that we'll still update after Early Access, but we won't have that greater need to do it each week like we do now, because it's at that "completed" stage and we'd focus on the bigger picture of adding in the bigger things from our Kickstarter stretch goals, and find ways to improve it in general."

"I think we probably spoiled our community because of our weekly updates and who knows what the uproar will be if we switch to monthly, but it's probably something we'd do gradually and we'd let our community know since we're pretty transparent. [...] As long as we keep our community in the loop, that's most important."

Pete Angstadt from Turtle Sandbox
developer of Cannon Brawl (recently released out of Early Access)

"I think the regularity of update scheduling, whether it's a week or a month is probably the most important part. That and communicating the schedule to your audience. [...] Vlambeer has a weekly schedule which they communicate to players with their livestream. Other games I think have done 'in-game' countdown timers to the next patch, or at least had the latest patch notes visible in game. If we had to do it over again, I would have gone with a very regular monthly patching schedule and included patch notes in game."

Roel Ezendam from Ragesquid
developer of Action Henk (currently in Early Access)

"We recently switched from bi-weekly to monthly updates for our Early Access game Action Henk. The biggest improvement that we have noticed is that we have far less overhead that's being spent on finishing and releasing the update. With a short update cycle the game constantly needs to be in a stable state, which makes it harder to work on larger features or a big overhaul. It also just takes time to publish the update and check if everything is working properly. These bi-weekly updates basically put us in a constant state of crunch, whereas the monthly updates give us a bit more breathing room."

Erik Johnson from Arcen Games
developer of AI War: Fleet Command and The Last Federation

"We've found that patching often isn't a bad thing if supporting your core community members (in effort to expand your core community) is your aim. [...] Anyway, I agree that this isn't a solid way to market the game in the main, but that's where our larger, more content-focused updates and DLC releases come in. I've found you can't tap the well too many times no matter how you slice it (unless you're in that fortunate position to have a sizable audience just begging for more) as far as reaching out to new players -- but a consistent stream of smaller updates keeps the community you already have established active and growing. That said, we do find that even our most popular games occasionally hit periods of patch ennui for both our community and our development team. :)"

Josef Vorbeck from Chasing Carrots
developer of Cosmonautica (currently in Early Access)

"We update Cosmonautica in 2 week cycles. We even did this before Early Access, because it's our standard rhythm with two week sprints. And we think, that we can deliver enough in two weeks to make these updates meaningful. Also we think that it's crucial for an Early Access title, that the players see constant progress during the development. These days Early Access has a mediocre reputation, because some devs are leaving their games or decide their games are finished, even though more features were planned. With our update cycles and constant communication we're trying to earn the trust of the players. It just works for us, the response so far is really great. And of course it's important for us to get the valuable feedback from our players on a regular basis. But after our final release we might switch our update rhythm to aim for larger content updates which deliver their own story, as Joost stated."

While digging for opinions I also got a replay on Gamedev.net from a user named Orymus3 who wrote a really interesting remark on the term "patch" itself:

"I would avoid using the term 'patch'. To most people this suggests you are fixing bugs, which also infers you develop bugs. What you really want to put forward is the fact you're actively working in the game, and are releasing new content. 'Content Push', 'Release', etc. are all better terms to refer to what you're doing. This may not appear like much, but imagine that a player comes across a post about your game (it's the only thing he's ever seen) and he sees 'Patch'. He's likely to think: here's another incomplete Beta filled with bugs, I'll give this a pass."