Delaying Your Indie Game Won’t Cure Development Anxiety

Building games isn’t easy.  It’s personal.  You’re spending your time and energy on building something you aren’t sure the world actually wants.  Doubts creep in.  About yourself, your abilities, your ideas.  When you’re working on a game and it isn’t fun yet, one question plays on repeat, ‘Will this be any good?’  And when the answer isn’t clear, it quickly prompts a follow-up.  ‘Should I scrap this?’

But if you’re deciding between canning a project and carrying on, more time can’t always fix bigger design problems.  While a rushed “bad game is bad forever,” a delayed game doesn’t always become good.  And the doubt lingers, ‘how much longer should you delay?’  A cycle begins to form, driving what feels like recursive iteration.  And now you’re working longer and delaying again, beyond what is reasonable.  

Some indie games find an audience, some indie games don’t… Some indie games are Star Citizen and make $250m before ever releasing.

For every developer striving for years on a Stardew Valley, there are dozens with similar time commitments who were greeted with little fanfare and meager sales.  Tastes change, expectations change, studios get lucky, opportunities arise.  The ideas and designs incubating for years could become dated and tired.  A lot of a game’s success exists outside the game being made or even its quality.

It is important to realise that gratification from success is relative.  Finishing a game, having a few people play it on itch.io, gaining experience and feeling accomplishment can be justification enough.  But knowing this is what you want before embarking on a months, or years, long journey, is important to keeping expectations in check.

If you desire getting better at the craft of game development, then the destination isn’t quite the goal.  Learning, building experience, finding answers to questions, and meeting people in the community who can help you. That is the goal.  You have to learn to be retrospective as you work.  And get feedback, earlier that you're comfortable.  Being able to bounce ideas off people, especially people who have done it before, will give you some confidence in the path you’re taking or be a less painful way to realise you need to change direction.

Conversations With My [Indie Dev] Anxiety.

But that’s easy to say.  When my team was working to build our last game, Conversations With My Anxiety, I held back getting feedback.  I made the mistake of thinking we needed to wait until the game was more complete.  Being too close to anything is blinding.  

This came into focus when we went to PAX.  We met a producer at a small indie publisher and we discussed our game with them.  It was early, but playable, and they wanted to see it immediately.  We weren’t prepared for this.  But given their excitement about the topic and their acceptance that the title was early, we realised we needed to be gathering feedback earlier than we thought.  

Instead of just talking to people who played our game, we also gave them a survey.  This exposed areas we were too close to notice.  One character was universally putting people off, and we meant for this character to be comic relief.  Our dialog options were a little too opaque.  And the doubt we had about the shortness of the game was alleviated by hearing everyone liked its brevity.  Feedback put our decisions in context of player experience.

Showing off an unfinished game at something like a PAX seems like it would be terrifying. No quip here, just giving my respect to indie devs that do this.

Another benefit of uncomfortably early feedback is knowing what you can cut.  Do you need that cool online feature that will require server maintenance?  Do you need fully animated 3D backgrounds in your 2D dating sim?  This is an area where we could have used more feedback earlier in development, given that we planned to finish our Conversations With My Anxiety in two months, and we ended up finishing in eight.  Isolating necessary features and cutting our scope to something accomplishable was what gave my team the ability to finish our last game.  It was later than we would have liked, but we got there.

Remember to have different vectors for feedback, like other developers.  Fostering a community of people who can help identify issues and present solutions, will leave you more prepared.  If someone else has finished or canned something similar to your work, reach out.  Use that experience as a foundation for decision making.

While we were pushing through the less fun parts of development, game jams helped revive our passion.  We could learn something new, play with a different engine, switch roles, and finish a full game during a weekend.  They’re invigorating.  Participating in the Epic Mega Jam last year and building Cat Stranded gave us the momentum we need to finish Conversation With My Anxiety.

But after all this, I’ll conclude with the truth.  We have scrapped projects before.  Time is everyone’s most valuable resource.  And if after evaluating the project and the benefits aren’t there, it may be better to shelf the project and build something else.  While that may feel like a loss, it isn’t if you’ve left the project with experience.  A ‘failed’ project isn’t a failure if you learned what worked and what didn’t.  It’s not a waste if you learned some new Photoshop technique or a nuance of Unity.  That experience will prevent you from wasting time in the future and help you to solve problems faster.  It’s not a mistake to try, it’s a mistake to not learn something from the attempt. ‘Should I scrap this?’ Maybe, but that isn’t a bad thing.