Earlier this week, we wrote a post inspired by Taro Omiya’s confession that he hates his game Star Driller Ultra (it looks pretty awesome to me, though). It’s one of the indie dev tips indie devs needs to know about – especially if you don’t know what to do next if you discover that you hate your game (a lot of the advice coming straight from Omiya’s mouth), how you can turn the situation into a positive, and so on. I thought that was going to be the end of the topic – that is until I found Gabriel Cornish’s post titled “How to create a horrible game with grace.”
Cornish uses this blog to discuss his thoughts and feelings on creating one game – from concept to completion – in a week; and I suppose it was inevitable that he would run into a game that he absolutely hated. Yet, Cornish offers some sound advice on making bad games:
“If you’re an indie dev, you’re going to make bad games. If you’re not making bad games or prototypes, then you’re playing it too safe.”
It’s one of the indie dev tips that acts as a reminder that this is all part of being indie – and heck, it’s part of being a game developer! You’re going to have those moments where you can already tell that the new idea you’ve chosen to prototype doesn’t have any legs to stand on – but that’s okay! If you feel there is hope in the idea, keep chugging along and working to make the idea realized, and when you truly believe that the idea is a hopeless case? Know that there is value in quitting and walking away from your project.
As Cornish notes, walking away from your project isn’t the worst thing in the world – in fact, any project you work on is never a lost cause! There’s scraps that can be reused in additional games, failed ideas you can scratch off of your, ‘tried that, didn’t work’ list, etc.
Cornish offers additional gems of advice:
“If you see your game isn’t turning out the way you’d hoped, scrap the project and see what you can take away from it.”
I remember reading an interview with an indie developer that said as he was looking back on his indie game, he knew that he had focused on the wrong areas. Although he was ultimately pleased with the game, he stated that he spent way too much time on one of the game’s boss battles by trying to add in some advanced animations, tried to get the boss to do too much simultaneously, etc. At the end of the day, he knew that he should have focused on additional areas to make the game even better rather than focusing on something so arbitrary.
Believe it or not, this indie dev is better for his mistake. He states that it has caused him to know where to focus his attention initially, how to plan better, and ultimately taught him how to make a balanced, well thought-out game better than ever. His mistake has led to better games, and so too can your failed project.
Now, I’m not going to say that every failed project will yield useable assets every time – it won’t. But there are lessons to be learned in failure – namely, how to never repeat this mistake again. Even so, it can be difficult to want to continue developing after failing: after all, your ego is hurt, you’re probably annoyed, and you may even question if you, ‘have what it takes,’ (it happens to the best of us). Yet, Cornish states that you can’t do this:
“As useful as it is, failing isn’t fun. The best way to get over this is to start on the next game as soon as you wrap up the old one. This keeps the momentum going and gives you less time to dwell on your failure. Don’t get me wrong, you should absolutely do a written or mental post mortem, but don’t linger on it too much. You have work to do.”
Learn from the past, but look to the future. If you released the game, do everything that you can to make it as polished and fun as possible. If you hate it, don’t release it and scrape it for assets and knowledge you can use for future projects. Remember: a bad project/game is only a waste of time if you make it so!