Here's a cautionary tale on Indie Game development from Matt Gilgenbach. Some people think that - particularly with console development - you'll get out of it at least what you put into it. Not so - my experiences with Schizoid and Matt's experiences with this say otherwise. There's no sure thing in indie game dev.
And it also goes to show migrating from AAA to Indie is harder than you might think. It is almost a completely different sport, seems like.
A couple possible 'mistakes' that Matt didn't call out explicitly (or if he did, I spaced at that moment) that it's easy for us ex-AAA people to fall into:
Why are you writing your own engine?
I did this with Schizoid and with the Richard Garfield game that endlessly chased publisher funding to no avail. Oh yeah, and Sixty Second Shooter. With Schizoid and Sixty Second Shooter it was arguably the right call, because it let me have "first game with such-and-such tech" PR stories, but who can say for sure. Anyhow, my own internal logic went something like this - and maybe Matt shared it: "This is a really simple indie game. Therefore it'll be easy to write our own engine." And then later, when we decided to add awesome post-processing shaders or network play or this that and the other already solved feature, it became a burden. (And another thing that led me down the path is it's also fun to write your own engine.) But you have to ask yourself: are you a game developer or an engine developer?
Obviously there are plenty of hugely succesful indie games out there where they wrote their own engine, so it's hard to say making your own engine is clearly a mistake, but you also have to wonder - would given succesful indie game X *not* have been succesful if they used a pre-existing engine?
What's Your Relationship To Feedback?
I have a difficult thought to articulate here. It's not cut-and-dry. I keep rewriting this paragraph as I think about it. As indie developers showing our work to people, whether it's just youtube videos or alphas or showing it off at conferences and contests - we're going to get more feedback on our work than we could respond to in our lifetime. That can be murder on a perfectionist. A lot of people-on-the-internet complained about the graphics in my first trailer for Energy Hook, and since I've became perhaps overly concerned with making it look better, even though the game isn't supposed to be about the graphics, it's about the gameplay. The graphics are supposed to be a means to an end and while I'd like them to look distinctive and consistent and not bad it's certainly a mistake for me to waste time trying to compete in that arena. And yet I have been anyway.
On the other hand, a place where feedback can be really beneficial is when there's some feature or fix that I think might be important - and none of the players I show the game to seem to notice. There can be a massive time savings there as I punt on the feature or fix that nobody cares about. Matt might have saved some serious time not working on things if he resisted the temptation to add features that nobody asked for?
So, you need feedback, not just to find out what you should fix but also to find out what you don't have to fix. But some stuff that feedback says you should fix - you shouldn't. And that's the really tough part. How to decide. Maybe asking- "Is this going to be one of my actual players or is this just a random internet troll who isn't going to play my game anyway because he just wants the next CoD?" -is a good place to start...
And speaking of feedback, I'm looking for more. I'm selecting just a few people to look at an early pre-alpha build of Energy Hook to figure out what I should fix before showing it to journalists before the Kickstarter. If you'd like to, and have a few hours to play it and write up some thoughtful, specific feedback, comment here or send me an e-mail (firstname.lastname@example.org) and I'll put your name in the hat. Let me know what kind of computer you have and whether you're a mouse/keyboard or gamepad sort of person.