How Long Should I Work On My Game?

Doom and gloom time! Indie game development seems to be at a real low these days. For every news story about failure, I know at least another indie dev who dramatically undersold expectations but is keeping quiet about it, because of the law of social proof: if you publish a news story that says, "Well, our game tanked," a lot of people are going to think, "It was probably a bad game, then!" 

Sometimes a game developer seems to do everything right - they're nominated for awards in the IGF and other indie shows; they spend years polishing their game to perfection, pouring their heart and soul into it; they build awareness in the interim with blogging and social marketing ... and then they sell five thousand copies, making much less than minimum wage. Why do some IGF finalists turn out to be Braid or Fez, while others ... don't? You got me.

But most of you know that, as I found out by posting that 'just how hard do you think indie game development is' survey a while back. My impression then was that a lot of people thought it was a pretty viable career choice - now I know most people have their head on straight and realize that trying to be an indie game developer is only marginally more sensible than trying to be a rock star or a novelist.

Now, for the few of you who just recently decided to become indie game developers, and are hard at work on your first game ... you poor fools ... I hope you have better financial success than I have had over the past several years ... but you may be wondering, "Just how long should I work on this thing?"

Should you just get a Minimally Viable Product out the door?

Should you work on it for as long as possible, going into debt, polishing it to the highest gloss?

I can't say that 'work on it as long as possible' doesn't work. This is the Braid / Fez / Castle Crashers / World of Warcraft strategy . It has produced some amazing financial successes. It's also pretty logically sound: we have a very hit-driven industry. If you want to make a hit, you're going to need to invest more than your competitors. And it used to be the only game in town - there were no platforms that allowed you to easily update your product and respond to feedback after you shipped. 

But that's not true anymore. It's so easy to release incremental updates with so many of the new platforms that the 'it has to be perfect at ship' rule is simply not true anymore. They shipped Farmville after five weeks.

And there are so many other reasons not to go there. First, it's far from a guarantee - think of Gaksetball and Outwitters and games I won't name that spent a long time in development only to crash and burn. The risks are very high, and you're probably betting with your life savings rather than someone else's money.

Another reason is that every time a game ships and fails, a bunch of people seem to pick that moment to pipe up and say, "I knew that would fail, because you did X, Y, and Z wrong." Doesn't matter what X, Y, and Z are - maybe they're your team was too big and you didn't listen to your playtesters and you didn't do enough inbound marketing. (<cough>Schizoid</cough>) The thing is, there's about a zillion mistakes you can make and you may be reading a ton of blogs (like this one) telling you what not to do and you'll have covered your ass in a multitude of ways but you'll still probably miss some important things, and those things suddenly will be crystal obvious ... after you've shipped.

So, another argument for going for the Minimum Viable Product: because it's good to fail early. There's something about shipping that reveals your mistakes in a way that just plain old listening to feedback doesn't accomplish. 

But we here at Happion Labs (and by 'we' I mean 'I') have a different reason to ship games that aren't yet perfect: because perfectionism is an unhappiness habit. Perfectionism usually means nothing is ever good enough. You're constantly focusing on that 1% that sucks instead of the 99% that's pretty good - and that's a drag. Being a perfectionist means making yourself miserable for years, thinking, "Once I ship a perfect game I'll be happy," only to find out that your game isn't perfect or - even if it is perfect - you're still not happy for some reason. The doom and gloom can hurt morale. And you risk never shipping, because you don't give yourself permission to fail. 

So ... don't be a perfectionist. You might say, "Easier said than done!" and you might think I'm free of the devil of perfectionism, because all of the games I've made are deeply flawed in one way or another, and I shipped them anyway. (Not to mention my blog posts.) But perfectionism happens to me too. (Perfectionism bit me particularly hard with my novel, which I spent ten years working on.) So how do I avoid perfectionism when shipping a game?

• Have a deadline
  Most of my games had a hard deadline we couldn't escape: the company would run out of money or our contracts had penalties for lateness or we had a frickin' movie release date to hit. (Do I wish we could have released an update to Spider-Man 2 that fixed what most of the reviewers complained about? You bet.) So it was pretty easy not to be a perfectionist on those titles. Didn't have a choice!
  So pick some possibly arbitrary date and tell yourself that you're going to make the best game you can in the time available. Some of the indie rpg designers I know (Vincent Baker & Epidiah Ravachol) call this 'the countdown.' It's quite possible it'll blow by and you won't be finished, and you'll just keep working, but it helps.
  (I'm feeling the devil of perfectionism with this blog post about perfectionism - fortunately Cathy just called to say dinner's ready, so I have to ship.) 
• Remember The Law of Diminishing Returns
  This is even more true for software projects than other creative works, because the more you work on your game, and the bigger it gets, the harder each change takes to make, and the less value you add for effort invested. 
• Agile good, waterfall bad
  As rapidly as possible, get to a point where you've got something you can ship and make it incrementally better. Yes, you'll have an endless list of things you want to do to make your game better. Nobody will know that you intended to add HDR or network play.
• Improvise. Turn off the internal critic
  The other day I was shown a design document for a fantasy game and it had a bunch of made-up fantasy-sounding names in it, like "The Kingdom of Borgavovix" - and I was like, "Where did you get these names that sound like they come from a random word generator? J.R.R. Tolkien didn't just make shit up, he had a linguistic basis blah blah blah." That was my internal critic talking. If the product shipped and was succesful, nobody would have to know that Borgavovix was just some word that the designer made up while on the toilet or whatever - it would just become accepted canon, like, say, Tatooine. Two useful things from improv theater when you're being creative: 'go obvious' - say the first thing that pops in your head, even if it's Borgavovix; and 'yes, and...' - don't shoot down other's ideas, build on them.
• Remember You Have A Ton Of Game Ideas And The Sooner You Finish This One The Sooner You Can Get On The Next One
  Which would you rather do? Make one 'perfect' game or a whole bunch of pretty good ones? I'm pretty proud of having made a bunch of pretty good games. I do wish I made some universally loved, 'perfect' game like Braid or Portal, but I wouldn't want to erase all my other games for it...
• Remember Perfectionism Often Stems From A Feeling Of Low Self Worth
  Dropping some therapyspeak on you. Being highly critical of your work can stem from being highly critical of yourself, which, who knows, might come from highly critical parents or peers or who knows what sort of unresolved childhood trauma. It's important to remember that your work is not your worth - the game you're working on might be the crappiest POS under the sun, but you would still give the last of your water to a child dying of thirst in the desert. Wouldn't you? So ship that game (that really isn't that crappy after all) and be proud of yourself.

Thoughts?

Comments

[MadameBerry]

I agreed with most everything, but I also think it could be used as a poor excuse to rush a mediocre project out the door without taking time that you do have to polish it.
What I'm saying isn't applicable to contracted work, because those do have hard deadlines, but I think it's better to extend a personal deadline for a few weeks or months if you know you can greatly improve the product.
Regardless, still definitely sharing this with other devs I know, and my own team. =D

[Bram Stolk]

I agree that long term polishing is not always required.
I've published quite a few games.
My biggest hit (The Little Crane That Could) now has 3.5M downloads, but the first 1.0 release was incomplete.

I published it without sound, with a really intrusive techno score which could not be switched off, with very few levels, and a whole range of shortcomings.

The core gameplay was rock solid though, and many people got hooked playing it. It was a hit right from the start.

My 1.0 release got a lot of feedback, but one user,who seemed to be a QA pro, summed up all the things that were wrong with it. I never had such an incredibly useful user feedback. I listened, and fixed pretty much his entire list.

To this day, the game keeps selling well.

An early release without polish paid off for me in that case. I would advice against years of polish.
But having said that, I feel that some of my other games were released too soon which hurt their performance.

[James Hofmann]

I've been doing indie games for about 2.5 years now, and - for the most part - each go around I've gotten faster at shipping something. (When this isn't the case, it's because there's some hold up at the business end or the early feedback has already warranted extra time) There is an end point to speed, though, and I've hit it. It's the 48 hour game jam project.

If you do one of those, and it gets a few users really excited, at that point it's worth it to start thinking about expansion. (In my case, this LD entry had someone playing for two months: www.newgrounds.com/portal/view/595772 )

The only problem with game jam projects is that they're over so fast, and the results tend to be so frail, that it takes a while to figure out how scope should be increased, and the increase can be enough to radically change everything.

And there are projects that take longer to realize themselves fully...however I think with most of those, getting to MVP is a question of successfully making/applying technology, and not prototyping the game design. If you build solid tech but then cheaply prototype on top of it, the prototype can be swapped out to something else using the same tech very quickly; so cost accounting it is really an issue of how much you're willing to experiment with a given set of tech.

Also, I've failed a ton. It is nothing short of miraculous that I've been able to keep going at it long enough to learn these lessons.

[jv]

"If you fail, I will like you more." There are rare examples of someone's first game becoming a fantastic hit, like Fez. But there are even more examples of people who failed or had only mild success for years, before they eventually created an amazing, hit game - Minecraft, Super Meat Boy.

You can try and risk at all on one huge project - but wouldn't you rather take that risk when you've spent time recognizing your flaws and improving your abilities?

[Beige Turner]

This was a great read. I just wanted to mention that games like Braid, Fez, and Super meat boy were not these developers first games. They "failed" or I like to say practiced, on multiple earlier titles. Ed (smb) has been very open on these othee works too.

[Metrix]

I can agree with all of the above. I have had just as much success with a game i wrote in 6 days on my own as I have with a game I developed with 2 other team members over nine months.

interestingly I have iterated twice on the 6 day game and released both and have not iterated at all on the 9 month project.