Indie Dev is Super Hard: Lessons Learned

Hello! Ryan here. Co-founder and programmer for Propulsion Games.

Propulsion Games started off a solo dev’s foray into the world of indie video game development. Before we became the small team that we are today, it was essentially just me. On my lonesome. Making all the mistakes that a person in a bubble inevitably does.

So to perhaps save you some of that time, effort and heartache, this post is all about my lessons learned. It focuses on controlling your content, scaling back so you can scale up, and aiming for the moon but not blasting off in a rocket that's built to leave the entire solar system.

I'll reflect on my challenges with scaling and scope from my last few years of game development in the hope that it will provide you with some insights and perspectives you may not have considered fully. This article isn’t one of those financial success stories and how to replicate it; quite the opposite.

There aren't enough posts and reflections on projects that weren't financially successful or took longer to develop than anticipated, but the lessons learned are just as important. And those lessons, friends, I have in spades. Whilst our team has organically developed a solid, efficient way of bringing games to the market now, this was not always the case a few years ago when it was basically just me.

In 2015, I had ambitions to develop a co-operative PDF party game, which later became our flagship party game and first Propulsion Games release,  Rockets are Super Hard. Aside from Matt Javanshir (my brother and co-founder of Propulsion Games) who made the music and SFX, and friends & family providing various input such as playtesting, I developed the game alongside studying. I spent a significant amount of time and effort designing and programming the game itself, and the huge PDF manual that is needed to play the game. The manual alone, adorned with bespoke diagrams, descriptions, logos and graphics, was a huge undertaking which pushed my limited graphic design and illustration skills to their limit. 

The game had dozens of puzzles with many hours of content and the manual had over one hundred pages, but the vast majority of players didn’t even scratch the surface.

Here are four mistakes I made with the project.

Mistake #1: I didn’t have a clear plan going in.

Aside from releasing to early access first to get some feedback, I had no solid plan going into the project. I was planning and implementing at the same time, agonising over small details and worrying that there wasn't enough content. This was the first mistake. With every new puzzle came more graphics, manual content and an increased complexity when it came to balancing. I underestimated how long it would take, and how tricky it would be to make new puzzles fit within the corpus of existing puzzles. Especially as a solo developer, making a multiplayer game.

If I had made a plan from the very start, had a vision and scope of what I wanted the game to be, I would have known where to stop. I would have been able to take a step back and consider how the puzzles worked together, instead of in isolation. In essence, I would have saved myself a lot of time, headache and worry. Planning might at first seem like a waste of time (and time is so precious when you’re an indie), but I’m now a firm believer that in the long run, it saves you both time and mental strength.

Mistake #2: I tried to please everyone.

The game was first released in early access, during which time dozens of players provided feedback; good, bad and suggestive. I tried to please them all, spending the following months adding modes, features and more puzzles as an answer to this feedback.

This resulted in a game that, in the end, was far larger than when I first conceived of the idea. In addition, in my efforts to please everyone, I ended up creating a game whose identity was even more nebulous than it originally was (there's a single player mode… in a game designed to be played in a group), and whose content would never be played by the vast majority of players. Content that I would ultimately have to patch and bug fix.

Just take a look at how many people have reached the latter level achievements:

The antidote to this particular issue is, if given enough feedback, thematic analysis. This method calls for the identification of emerging themes and trends in the feedback. For example, if the majority of players are saying it’s just too hard, it probably is. It’s not Rockets Are Too Hard, so this is feedback I should have addressed early on.

Don’t dwell on every comment or desired mechanic though. If they don’t fit in with your desire for what the game is or its identity, don’t be afraid to reject these ideas, albeit respectfully.

Mistake #3: I didn’t prepare for the future.

What I mean by this in a game development context is to prepare your code, architectures, designs and assets in such a way that you can extend them later, if the game does well and you have capacity to add more content.

For example, in my case, it would have been far better to make a quarter of the puzzles in Rockets are Super Hard, but have code that was easier to extend, so that in the future more puzzles could be added if that’s the direction things were going. The holy grail in this space is procedural generation, where the development hours to play hours ratio can look extremely alluring to us indies. (I would strongly caveat this with the content produced has to be conducive to the game, make sense and uphold the quality you expect of your game).

You might be thinking “if I’ve put all this effort into making my game extendable, why don’t I just add more content at launch”, and the reason against this is that more content equals more work. More content means additional balancing, quality assurance and testing. More ambition will invariably scale with everything else, unless you prepare in advance.

Players calling for more content is a good sign, it means they like playing your game. If you’re in that situation and enough players have bought the game, then is the time to extend. However, if (like many games) your game doesn't sell well enough to sustain you financially, you’ll not have wasted time making content that only a few people, or no one, played.

Mistake #4: I didn’t know how to price it.

It’s hard pricing a game, and I struggled with this throughout development. You might assume that more content means higher purchase price; and generally I've found this is the case. Many folks say a rule of thumb is one GBP for one hour of good quality content.

Of course this doesn’t always apply - some games have huge amounts of players with hundreds or thousands of hours, and are on sale for less than a tenner. And vice versa.

If you follow the thesis of this article and aim to prove your concept first before trading years for more content, you need to price your game accordingly. This article is not advocating for making less content in games and charging the same amount. I’m saying in a world with dozens of games coming out daily, as an indie it’s sometimes better to find additional baskets for those indie eggs of yours. Then make your omelette when you find something that works. This egg metaphor isn’t really working, but if you’re reading this then I couldn’t really find a better one.

Essentially, scope well, price appropriately, and scale when you find something that’s working.

A good way to find a baseline price of your game is to look at similar games and see how long a typical player spends playing. It's also a good idea to look at discount trends and factor that into your pricing (going 50% off on a £1 game would need a lot of sales to become profitable).

In Summary

Are you still here? Good! Here’s a summary as a reward for all that lovely reading. Or wait, have you just scrolled to the end to get to the salient points? Yes? That’s fair. I don’t want to take up any more of your time than I have to. Buy Orbitect and we’ll call it even.

Here we go, in summary:

• Dedicate a sufficient amount of time to planning, and have a clear vision for what your game is.
• Be cautious with audience feedback. Look for themes, but don't add every mechanic and feature that's suggested.
• Plan for the future. Develop your game so that if it “takes off” you can add more content more easily.
• Price appropriately. Look at similar games and note how long players play the game for.

I would love to hear other peoples experiences, whether it’s games or otherwise. It would be good to get other perspectives that may align or challenge the ideas presented in this article, so don't be shy to comment!

Thanks for reading!