October 01, 2019

Why I released my game before I started making it

When I decided I wanted to make a space-farming video game (sort of like Stardew Valley but traveling between planets), I had a bunch of fun gameplay ideas I wanted to work on. I wanted to be able to hop in my spaceship, fly to procedurally generated planets covered with hostile alien landscapes, and slowly make them livable by transporting soil, seeds and resources from one to another. I wanted to build a base that was a safe haven and invite my friends to come work on it. I wanted to dock at a local space station, trade with other players, and mod my ship with new craftable equipment.

But instead of working on that fun stuff, I spent months on boring things like making a website for the game and hooking it up to a payment platform. I spent time implementing user signup/login/password resets, wrestling with localization and joystick accessibility, dealing with code signing certificates, creating a deployment pipeline, making lots of accounts on lots of different websites, and tons of other work I'd usually put off until much later. 

Walking around in Starsteaders

And yesterday, I launched it! I "released" a playable build of the game, despite there being almost no gameplay (you can walk around and that's about it). There's a full company website with user accounts, an optional pay-what-you-want subscription, and some info about what I'm trying to do. On my end, I have deployment scripts that make it easy for me to test and deploy development and production builds. The game even auto-updates itself when there's a new build - I wanted to make it as easy as possible for people to stay in the loop.

This is the opposite of how I usually approach things. In the past, when I've had a game idea, the first thing I'd want to do is see if it's fun. I'd code the basic mechanics in a quick and dirty way, and then play around. I'd want to make sure I wasn't going to spend a bunch of time on an idea that wasn't going to work out - "fail fast", I guess.

So why didn't I do that this time? A few reasons.

1 | When should you quit, and when should you pivot?

There's something to be said for failing fast, but in the past I've given up a little too easily when I should have pivoted or compromised instead. Sometimes, when I look through old abandoned screenshots, I realize that what I was working on was actually pretty cool! All I needed was to lose my tunnel vision, scale down, and I could have kept going. Occasionally I've even seen others be successful with a similar idea to one I've had - not the exact same idea of course, but close enough that I could see how to get there from here, if I had stuck with it. In other cases I've released projects or demos to very little reception, and then watched them slowly build a bit of a fanbase - maybe if I had kept pushing new updates I could have built them into something bigger. My whole approach to marketing was wrong; I didn't realize it takes lots of exposure over time rather than one single push for attention.

All this has made me realize that sometimes it's not really about whether your idea is objectively good or bad, but how much you can adapt and compromise through obstacles without getting discouraged. The difference between a bad game and a good one might simply be trying some new game mechanics until it feels more fun to control, or adding more content until there's enough stuff to do. 

So with this new project, I decided I want to commit for a while, and do my best to compromise before throwing out the whole concept. And that means I can justify doing some up front work before diving into the core game.

Starsteaders settings

2 | The last 20% is the least fun to do, so why not get it out of the way early?

Usually, the most fun part of a project is the first 20%. That's when you feel smart and cool for implementing the mechanics, you get to play around with your exciting new ideas, and it's easy to work on because you aren't mired in a bunch of bad code you wrote (yet).

The middle 60% is okay. It's not as fun as the first part, but there are still some satisfying bits and watching it all come together is pretty cool.

But the last 20% is stressful - that's when you have to do all the stuff you've been putting off because you didn't want to do it earlier. Stuff like accessibility, error handling, the marketing website (if you're like me you will not have done any marketing until the end), whatever arcane rules your publishing platform decides to impose, etc. Also it somehow takes five times longer than you think, and you're already pretty burned out on this whole thing anyway.

I'm exaggerating a bit and it's impossible to do absolutely everything up front, but I think I've done a fair amount of boring ground work that I would normally have put off. Now I'm excited to dive in to some fun game programming knowing I've already done some of the prep work.

3 | I wanted to have a revenue option as early as possible.

These days, it's hard to support yourself by making indie games. The market is hugely saturated, and you need to find some way to get noticed. I don't really have any ideas for that, so I'm trying to maximize my chances by creating a revenue stream early and having it available for the entire time I'm working on the game.

It may seem bad to ask for money before the game is playable, but it's basically the Patreon model - if people want to play my game and support me developing it, they can sign up on my site and pay a monthly amount of their choice. This seemed like a good fit to me because the game is online-only, and I'll need to cover server costs with a monthly subscription anyway. It's also important to me that it's not mistaken for early access - the idea here is to create a community of people who enjoy watching the game as it develops, not to sell a product that doesn't exist yet.

It took some work to make this option available up front, but I think it's important so that as soon as somebody thinks my work is worth supporting, they can chip in. Before that time, they can still sign up for the newsletter and check in occasionally.

What do you think?

What do you think of this approach? Am I being smart by doing prep work up front, or making a mistake by not focusing on making a good game first? Let me know!